概要 AWSのRDSを使ってMySQLへ接続をしてみました。 前提事項 RDSの作成で行うパラメータ設定は、基本的にはすべてデフォルトで行っています。 また、接続方法はEC2インスタンスの踏み台サーバを使ってRDSへ接続します。 MySQLで接続してみる EC2にMySQLクライアントを入れる ・mysql8.0がインストールされているか確認する [root@ip-10-0-1-10 ~]# yum info mysql Loaded plugins: extras_suggestions, langpacks, priorities, update-motd Error: No matching Packages to list インストールできないのでmysql8.0のリポジトリを追加します [root@ip-10-0-1-10 ~]# yum localinstall -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm Installed: mysql80-community-release.noarch 0:el7-3 Complete! mysql8.0のリポジトリを有効化にしていきます yum-config-manager --disable mysql57-community yum-config-manager --enable mysql80-community mysql-community-clientをインストールする [root@ip-10-0-1-10 ~]# yum install -y mysql-community-client Installed: mysql-community-client.x86_64 0:8.0.26-1.el7 mysql-community-libs.x86_64 0:8.0.26-1.el7 mysql-community-libs-compat.x86_64 0:8.0.26-1.el7 Dependency Installed: mysql-community-client-plugins.x86_64 0:8.0.26-1.el7 mysql-community-common.x86_64 0:8.0.26-1.el7 ncurses-compat-libs.x86_64 0:6.0-8.20170212.amzn2.1.3 Replaced: mariadb-libs.x86_64 1:5.5.68-1.amzn2 Complete! RDSへ接続する [root@ip-10-0-1-10 ~]# mysql -h database-1.c5jqncbegdvz.ap-northeast-1.rds.amazonaws.com -P 3306 -u admin -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 22 Server version: 8.0.23 Source distribution Copyright (c) 2000, 2021, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> 参考 MySQLクライアントで接続する方法

1. はじめに 　つい先日、cloudfonrtにCLoudFrontFunctionsという機能が実装されました。確か今年の5月ぐらいだったと記憶してます。 　丁度都合よくCloudFrontにアクセスしたURLやクエリの変更処理を行いたかったため、是非もないといった具合で早速使用してみました。 2. Lambda@Edge と CloudFrontFunctions の違い 　AWSには元々Lambda@Edgeという機能が備わっています。Lambdaは様々なトリガーから起動することができます。（私はAPI Gatewayのトリガーしか用いたことがありませんが）Lambda@EdgeとはCloudFrontへのアクセス、つまりリクエストとレスポンスをトリガーに起動するLambdaになります。リクエスト、レスポンスの情報を処理・操作することでURLやヘッダー、様々なものを操作することができます。 　CloudFrontFunctionsでは、このLambda Edgeよりも手前で、より簡単に、よりリーズナブルにリクエスト、レスポンスを処理することができます。ただし、Lambda@Edgeと比べて機能に制限があります。詳しくはこちらをご覧ください。 3. CloudFrontFunctionsの作成 　それでは早速CloudFrontFunctionsを作成しましょう。CloudFrontのコンソールを開き、仰々しく「NEW」が添えられているFunctionsをクリックします。そしてCreate functionを押しましょう。 　名前と説明の入力を促されるので適当に入力しましょう。 　正常に作成できればこのような画面が表示されていると思います。 　この画面ではそれぞれ以下のようにCloudFrontFunctionsを操作することができます。 Build 　このページではFunctionのコードそのものを編集することができます。「Development」と「Live」がありますが、Liveが実際にCloudFrontDistributionと紐づいているコードでDevelopmentがテスト用のコードになります。「Sava Change」のボタンがありますが、こちらのボタンを押してもLiveのコードが変わることはありません。「Test」ページでテストを実行する際や「Publish」ページで関数を更新する時に、「Sava Change」ボタンで保存された最新のコードが実行・更新されます。 Test こちらのページではBuildで保存したコードのテストを実行することができます。テストを実行する際にリクエストやレスポンスのヘッダー、クッキー、クエリを好きに設定することができます。これで、より本番環境に近い形でテストを実行できます。また、コードの方でconsole関数を用いて出力を行えばその中身も見ることができます。 Publish 　こちらのページではBuildで保存したコードをCloudFrontDistributionに紐づけ発行することができます。「Add association」で紐づけるDistributionを選択し、「Publish function」でコードの発行を行うことができます。 4. コードの編集 URLの変更 　最終的にはクッキーで取得した情報をクエリに追加したいのですが、ひとまずURLをログイン画面に飛ばすことを想定しいじってみます。今回はURLの変更ですのでイベントタイプは「Viewer Request」を利用します。 　※ちなみにCLoudFrontFunctionsのjavascriptは少し古いversionになるためconstやletはまだ対応していません。 function handler(event) { var request = event.request; var host = request.headers.host.value; var response = { statusCode: 302, statusDescription: 'Found', headers: { "location": { "value": 'https://host/login/index.html' } } } return response } 　CloudFrontFunctionが実行されるとhandler関数がeventを受け取って実行されます。eventの中にはヘッダーの情報等が含まれておりクッキー・クエリ・IPアドレス等がここから確認できます。responseでステータスコードやヘッダーを指定すると変更が加えられた状態でDistributionにアクセスされます。 　今回はログイン画面へのリダイレクトになりますので、ステータスコードは302、locationヘッダーにログインページのURLを指定します。hostで取得してる値は実際にアクセスしてるURLになります。DistributionのDomain name ではなく Alternate domain names に該当する可能性もありますのでご注意ください。 　せっかくですのでこのコードでテストを実行してみましょう。BuildページでSava changeボタンを押し、コードを保存します。また、現状ヘッダの中にはhostヘッダーはなく、値を取得することができないため、Testページでヘッダーの追加を行います。TestページのAdd Headerボタンを押し、hostヘッダの中に任意の値を挿入しましょう。 　最後にTest functionを押し、無事にテストできたことを確認してください。 クッキーを取得しクエリに追加 　クッキーを取得し、それをクエリに追加するコードを書いてみましょう。 function handler(event) { var request = event.request; var cookies = event.request.cookies; var cookieTest = cookies['cookieTest']['value']; var response = { statusCode: 302, statusDescription: 'Found', headers: { "location": { "value": 'https://'+host+'/?cookieTest='+cookieTest } } } return response } 　先ほどのhostと同じ要領でクッキーを取得することができます。この関数によりクエリを追加した状態でリダイレクトできるようになりました。Testを行うにはTestページでクッキーにcookieTestを追加して行います。 条件の追加 　ただし、この関数では問題があります。CloudFrontFunctionはリクエストを受け取ると実行されてしますのでこのままでは下記のように無限ループに陥ってしまいます。 CLoudFrontDistributionにアクセス ↓ CloudFrontFunctionsによりクエリを追加してリダイレクト ↓ CLoudFrontDistributionにアクセス ↓ CloudFrontFunctionsによりクエリを追加してリダイレクト ↓ ・・・ この無限ループを防ぐため、以下の条件をこの関数に追加しましょう。 条件１　クッキーにcookieTestが含まれていなかったらログインページにリダイレクト 条件２　クエリにcookieTestが含まれていたら特に処理をせずにステータスコード200でアクセス 条件３　条件１、条件２を満たさない時、クッキーcookieTestをクエリに追加 function handler(event) { var request = event.request; var cookies = event.request.cookies; var host = request.headers.host.value if(!cookies['cookieTest']){ var response = { statusCode: 302, statusDescription: 'Found', headers: { "location": { "value": 'https://'+host+'/login/index.html' } } } return response; }else if(request.querystring['cookieTest']){ return request; }else{ var cookieTest = cookies['cookieTest']['value']; var response = { statusCode: 302, statusDescription: 'Found', headers: { "location": { "value": 'https://'+host+'/?cookieTest='+cookieTest } } } return response } } 5. おわりに 　いかがだったでしょうか。現状、CloudFrontFunctionsに関する情報はあまり多くなく、自分でコードを書くのに苦労しました。この記事が少しでも皆様の役に立てば幸いです。

ソリューションアーキテクト　プロフェッショナル試験の更新を済ませてきました。 前回の更新を忘れていて、アソシエイトから受け直すことになったので、今回は忘れぬうちに！ 試験においての自分流Tipsを共有しておきます。 誰かのお役に立てればこれ幸い :) 英語に切り替える 読みにくい日本語は英語に切り替えるとわかりやすいことも。 とくに、複数選択問題。 例えば、「2つ選びなさい」という問題の場合、 AとBを両方行うことで実現できるパターンと、 AでもBでもどちらでもできるパターン、どちらも考えられる。 前者の場合、「Combination」と書いているので、明確に判断がつく。 理解の浅いサービスに関する問題が出たら、サービス名と問題番号をメモる 試験内の別問題で、そのサービスが含まれる問題が出てくることもあります。 その問題が、大きなヒントになることも結構あります。 合わせて読むと、さっき不明確だったことが、別の問題で明確になることも。 途中での想定算時間を割り出す プロフェッショナル試験の場合、問題数75問、試験時間180分と長丁場。 最初に、ざっくりと途中時点での想定算時間を書いておくと、大幅な時間不足を防げる。 例えば、プロフェッショナル試験だと、25問の時点で残り１２０分、50問の時点で残り6０分が等分のペース。 これを下回るペースだと少し急いだ方がいいかも。 見直しを考える人は、25問の時点で残り１3０分、50問の時点で残り8０分のペースで進め、見直しに30分残すとか。 ペース配分は個人によるので、適宜チューニングになりますが、試験開始前または早いうちに時間見積もりを立てて、途中経過を観測することをオススメ。 図を描く ※ オンラインではできないらしい とくにプロフェッショナル試験は問題が長く、構成の説明だけで１０行ぐらい続くことも。 図に描くことで、長々とした説明を視覚的に捉えて、問題文で問われていることに集中できる気が。

概要と注意点 GlobalAcceleratorのトラフィックが経由するNetworkInterfacesはエンドポイントにトラフィックをルーティングするため、エンドポイントが存在するサブネットごとに1つずつ、NetworkInterfacesを作成します。 その際に、SecuryGroupも作成され、NetworkInterfacesにアタッチされます。 注意点1 任意のVPC内のエンドポイント用に作成されたNetworkInterfacesは、NetworkInterfacesが関連付けられているサブネットに関係なく、すべて同じセキュリティグループを使用するという点です。 また、このSecuryGroupのInboudルールを編集することはシステムによって禁止されてはいないですが、編集した結果、エンドポイントに異常が起きることがあるようです。 そもそもですが、複数のNetworkInterfacesが同一のSecuryGroupを使用するという仕様も気持ち悪いので、任意のSecuryGroupを作成し、それをNetworkInterfacesにアタッチすしたほうがいいと考えます。そうすることでInboundルールも適宜変更が可能になります。 注意点2 GlobalAccelerator作成時に作成されたSecuryGroupはterraform showでもIDがわからないため、別途APIで調べます。 $ aws ec2 describe-security-groups --filters Name=description,Values="GlobalAccelerator configured SecurityGroup" data "aws_security_group" "sample" { filter { name = "description" values = ["GlobalAccelerator configured SecurityGroup"] } } イメージ 環境 aws-cli/2.1.38 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off Terraform v1.0.3 on darwin_amd64 設定 globalaccelerator_accelerator.tf resource "aws_globalaccelerator_accelerator" "sample_accelerator" { provider = aws.oregon name = "sample-accelerator" ip_address_type = "IPV4" enabled = true attributes { flow_logs_enabled = true flow_logs_s3_bucket = "sample" flow_logs_s3_prefix = "globalaccelerator/" } } resource "aws_globalaccelerator_listener" "sample_listener_443" { provider = aws.oregon accelerator_arn = aws_globalaccelerator_accelerator.sample_accelerator.id client_affinity = "NONE" protocol = "TCP" port_range { from_port = 443 to_port = 443 } } resource "aws_globalaccelerator_endpoint_group" "sample_endpoint_group_443" { provider = aws.oregon endpoint_group_region = "ap-northeast-1" health_check_interval_seconds = 30 health_check_path = "/" health_check_protocol = "HTTPS" listener_arn = aws_globalaccelerator_listener.sample_listener_443.id threshold_count = 3 traffic_dial_percentage = 100 endpoint_configuration { endpoint_id = data.aws_lb.sample.arn weight = 128 client_ip_preservation_enabled = true } } resource "aws_globalaccelerator_listener" "sample_listener_80" { provider = aws.oregon accelerator_arn = aws_globalaccelerator_accelerator.sample_accelerator.id client_affinity = "NONE" protocol = "TCP" port_range { from_port = 80 to_port = 80 } } resource "aws_globalaccelerator_endpoint_group" "sample_endpoint_group_80" { provider = aws.oregon endpoint_group_region = "ap-northeast-1" health_check_interval_seconds = 30 health_check_path = "/" health_check_protocol = "HTTP" listener_arn = aws_globalaccelerator_listener.sample_listener_80.id threshold_count = 3 traffic_dial_percentage = 100 endpoint_configuration { endpoint_id = data.aws_lb.sample.arn weight = 128 client_ip_preservation_enabled = true } } security_group.tf // ENIにアタッチするSG resource "aws_security_group" "sample" { vpc_id = data.aws_vpc.sample.id name = "sample" description = "sample inbound traffic" dynamic "ingress" { for_each = var.ingress_elb_ports content { from_port = ingress.value to_port = ingress.value protocol = "tcp" cidr_blocks = [ "xxx.xxx.xxx.xxx/xx", ] } } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } resource "aws_security_group" "sample_elb" { vpc_id = data.aws_vpc.sample.id name = "sample-elb" description = "sample-elb inbound traffic" dynamic "ingress" { for_each = var.ingress_elb_ports content { from_port = ingress.value to_port = ingress.value protocol = "tcp" security_groups = [aws_security_group.sample.id] } } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } 作成したSecurityGroupをNetworkInterfacesにアタッチします（NetworkInterfacesはImportしてもいいかも） 参考 Best practices for client IP address preservation

1.はじめに 本記事では、クラウドでのDRBDを用いたディスクミラーリング方式についての読込み・書込み性能について検証します。 DRBDによりミラーリングされたディスクでは、複数のディスクにデータを書込むためオーバーヘッドが発生します(*)。特に、(AZ横断など)データセンタを跨いだ場合には、物理的な距離が遠くなるため、書込み性能への影響が気になり、その程度を測ってみることにしました。 (*)読込み性能については、どこか1箇所を参照するだけなのでオーバーヘッドはありません。 尚、記事内には参考の為、生データもダウンロードできるようにしていますが、当記事の目的は、各種性能測定ツールを用いたやり方の情報提供になります。測定は、手元で簡易的に動かして得られたものです。測定結果の正確性、有用性などにつきましては、一切保証するものではない点ご了承ください。 2. クラウドでの共有ディスク代替方式 オンプレでのHAクラスタをクラウド上で実現する際、単純には共有ディスク構成を作ることができません(2020.8)。(AZやゾーンといった)データセンタ内であれば、AWSではマルチアタッチを使用して複数インスタンスにEBSを割当てたり、Azureでも同様な機能は提供されてはいます。しかし、いずれの共有ディスクサービスにも制約はあるため、要件を満たせるかの確認が必要になります。 Amazon EBSのマルチアタッチ機能とAzure Shared Disksを比較してみる EBS Multi-Attachの使いどころを考えてみた 一方、共有ディスクの代替として、ノード間でデータをリアルタイムに同期させて共有するミラーリング方式や、リアルタイムではなく、一定間隔でデータの同期をとるレプリケーション方式といった他のやり方もあります。その他、Cephなど分散ストレージを使うというのも一手かもしれません。 それぞれの方式にはメリット・デメリットがありますが、ここではオンプレでの共有ディスクを用いたHA構成をクラウドにもっていく時によく使われる「ミラーリング方式」について検討してみます。 3.システム構成 測定は、下記2パターンでの影響を試してみました。 [アプリケーション負荷測定]PostgreSQLと、そのベンチマークツールpgbenchを使った計測 [ディスク負荷測定]ディスク負荷ツールfioを使った計測 AWSでは、東京リージョンの2つのAZを用いて、下記構成でリソースを準備しました。 各ホストの情報を、参考までに記載しておきます: - host1-3共通: - t2/medium - CentOS 8.2.2004 - Linux version 4.18.0-193.6.3.el8_2.x86_64 - DRBD 9系 host1: IP アドレス: 172.16.1.50 ディスク: /dev/xvda - OS /dev/xvdb – DRBD (/dev/drbd0) /dev/xvdc – DRBD (/dev/drbd1) /dev/xvdd – ローカル host2: IP アドレス: 172.16.1.60 ディスク: /dev/xvda - OS /dev/xvdb – DRBD (/dev/drbd0) host3: IP アドレス: 172.16.2.50 ディスク: /dev/xvda - OS /dev/xvdb – DRBD (/dev/drbd1) すこしみやすく、図にしてみると、このようになります。 4.環境構築 この章では、測定に必要となるOSやミドルウェアをインストール、セットアップしていきます。初めに、CentOS 8.2.2004のパッケージ管理ツールdnfを用いて、DRBD用リポジトリの追加や、プロファイリングツールのインストールなど準備を行います。 # dnf update # rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org # dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm # dnf install -y sysstat # dnf install -y dstat # dnf install -y fio 4-1. DRBDのインストール DRBDをインストール、セットアップします。drbd90パッケージをインストールしました。 # dnf install -y kmod-drbd90 # dnf install -y drbd90 無事にDRBDがインストールされれば、DRBDの設定に移ります。host1-host2間の同期設定を行います。host1で作成し、host2へコピーします。 /etc/drbd.d/r0.res resource r0{ net { protocol C; } options { } on ip-172-16-1-50.ap-northeast-1.compute.internal { address 172.16.1.50:7789; device /dev/drbd0; disk /dev/xvdb; meta-disk internal; } on ip-172-16-1-60.ap-northeast-1.compute.internal { address 172.16.1.60:7789; device /dev/drbd0; disk /dev/xvdb; meta-disk internal; } } host1-host3間の同期設定。host1で作成し、host3へコピーします。 /etc/drbd.d/r1.res resource r1{ net { protocol C; } options { } on ip-172-16-1-50.ap-northeast-1.compute.internal { address 172.16.1.50:7790; device /dev/drbd1; disk /dev/xvdc; meta-disk internal; } on ip-172-16-2-50.ap-northeast-1.compute.internal { address 172.16.2.50:7790; device /dev/drbd1; disk /dev/xvdb; meta-disk internal; } } host1-host2間のリソース作成と有効化。host1, 2で実行します。 # drbdadm create-md r0 # drbdadm up r0 host1-host3間のリソース作成と有効化。host1, 3で実行します。 # drbdadm create-md r1 # drbdadm up r1 下記はhost1のみで実施します。 // host1-host2間同期開始 # drbdadm primary --force r0 // host1-host3間同期開始 # drbdadm primary --force r1 // 同期中 # drbdadm status r0 role:Primary disk:UpToDate ip-172-16-1-60.ap-northeast-1.compute.internal role:Secondary replication:SyncSource peer-disk:Inconsistent done:83.70 r1 role:Primary disk:UpToDate ip-172-16-2-50.ap-northeast-1.compute.internal role:Secondary replication:SyncSource peer-disk:Inconsistent done:73.31 // 同期完了 # drbdadm status r0 role:Primary disk:UpToDate ip-172-16-1-60.ap-northeast-1.compute.internal role:Secondary peer-disk:UpToDate r1 role:Primary disk:UpToDate ip-172-16-2-50.ap-northeast-1.compute.internal role:Secondary peer-disk:UpToDate 最後に、ファイルシステムを作成し、適当なディレクトリにマウントして置きます。 // ファイルスシステム作成 mkfs -t xfs /dev/drbd0 mkfs -t xfs /dev/drbd1 mkfs -t xfs /dev/xvdd // マウント mount /dev/drbd0 /mnt/drbd0-fs/ mount /dev/drbd1 /mnt/drbd1-fs/ mount /dev/xvdd /mnt/local-fs/ // 確認 # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 8.0K 1.9G 1% /dev/shm tmpfs 1.9G 17M 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/xvda2 8.0G 1.3G 6.7G 17% / tmpfs 378M 0 378M 0% /run/user/1000 /dev/xvdd 100G 858M 100G 1% /mnt/local-fs /dev/drbd0 100G 858M 100G 1% /mnt/drbd0-fs /dev/drbd1 100G 826M 100G 1% /mnt/drbd1-fs 4-2.PostgreSQLのインストール PostgreSQLは、CentOS標準リポジトリから、下記でインストールしました。今回は性能測定にpgbenchというツールを使うため、合せてそちらもインストールしておきます。 # dnf install -y postgresql # dnf install -y postgresql-server # dnf install -y postgresql-contrib //pgbench用 次に、pgbenchを使うためのデータベースの設定を行います。今回は、1.AZ内レプリケーション(DRBD0)、2.AZ跨ぎレプリケーション(DRBD1)、3.ローカルディスクの3パターンで測定を実施するため、データベースは下記マウントしたファイルシステムをそれぞれ利用します。DRBDのセットアップ時に作成した、/mnt以下のディレクトリを確認します。 // mountポイント確認 # cd /mnt //postgreSQLは、デフォルトpostgresユーザを利用するため、所有者とパーミッションを下記の通り変更します。 # chown -R postgres:postgres drbd0-fs drbd1-fs local-fs # chmod -R 700 drbd0-fs drbd1-fs local-fs // 結果はこんな感じになります # ll total 0 drwxr-xr-x 2 postgres postgres 6 Jul 26 04:06 drbd0-fs drwxr-xr-x 2 postgres postgres 6 Jul 26 04:06 drbd1-fs drwxr-xr-x 2 postgres postgres 6 Jul 26 04:08 local-fs 3つのデータベースは、今回はSystemdの設定を使って切替える事にしました(もっとうまい方法があるかと思いますが、今回は簡単にディレクトリ事データベースを取替える方式を採用...)。下記のようにUnit定義の中の「PGDATA」として3つ準備します。 /usr/lib/systemd/system/postgresql.service (中略) #Environment=PGDATA=/var/lib/pgsql/data Environment=PGDATA=/mnt/drbd0-fs #Environment=PGDATA=/mnt/drbd1-fs #Environment=PGDATA=/mnt/local-fs (中略) その後、上記各設定ファイルのコメントアウトを(1つずつ)削除し、下記コマンドを実行しデータベースの初期化を行います(3回実施することになります)。 # systemctl daemon-reload #Unit定義更新 # postgresql-setup initdb #データベース初期化 データベースのセットアップは以上になります。 5.アプリ性能測定(pgbench) 5-1.測定方法 以下、pgbenchによる測定を行います。 pgbenchマニュアル (https://www.postgresql.jp/document/9.2/html/pgbench.html) このツールの特徴としましては、マニュアルによるとTCP-B(銀行のバッチ処理)を模したベンチマークとのことです。 pgbenchはPostgreSQL上でベンチマーク試験を行う単純なプログラムです。 これは同一のSQLコマンドの並びを何度も実行します。複数の同時実行データベースセッションで実行することもできます。 そして、トランザクションの速度（1秒当たりのトランザクション数）の平均を計算します。 デフォルトでpgbenchは、1トランザクション当たり5つのSELECT、UPDATE、INSERTコマンドを含むおおよそTPC-Bに基いたシナリオを試験します # systemctl daemon-reload #使うデータベース格納場所(PGDATA)をコメントアウトし、Unit定義を更新 # systemctl start postgresql.service # データベース起動 # sudo su - postgres $ createdb test #testという名のデータベース作成 $ pgbench -i test #pgbench用のテストデータをtestデータベースへロード $ pgbench -c 10 -t 1000 -l test #測定実行 starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 query mode: simple number of clients: 10 number of threads: 1 number of transactions per client: 1000 number of transactions actually processed: 10000/10000 latency average = 9.111 ms tps = 1097.529558 (including connections establishing) tps = 1097.770942 (excluding connections establishing) $ exit #postgresユーザから抜ける # systemctl start postgresql.service #データベース停止 上記より性能(TPS)は1097程度出ている事がわかります(PostgreSQLへの接続オーバーヘッド有り/無しで2パターンTPSは表示さる)。また、オプションとして「-l」を指定している事により実行後ローカルに「pgbench_log.1163」というトランザクション詳細結果ファイルが作成されます(詳細につきましては、上記サイトを確認ください)。これをデータベースを切替えてそれぞれ実行します。 5-2.測定結果 ざっくり、共有ディスク方式と比較した場合の処理性能(TPS)は、AZ内で62.5%(37.5%減)、AZ跨ぎで26.9%(73.1%減)という結果となりました。 6.ディスク性能測定(fio) 6-1.測定方法 ディスク性能測定に使えるベンチマークツールとしては、詳解 システム・パフォーマンスによると、dd、Bonnie、Bonnie++、iozone、tiobench、SysBench、fio、FileBenchなど多々ありますが、今回はfio(Flexible IO Tester)を使ってみました(著者のJens Axboe氏は同年代だそうで少し親しみもあります)。高機能なのですが、全く使いこなせていないため、今後勉強していきたいと思います！ ジョブファイルという設定ファイルを設定し、カレントディレクトリに格納します。 ※各種詳細はこちら。 以下が、fio設定ファイル(サンプル)となります: fio.conf [global] ioengine=libaio iodepth=1 size=1g direct=1 runtime=30 stonewall [Seq-Write-1M] bs=1m rw=write [Rand-Write-1M] bs=1m rw=randwrite [Rand-Write-512K] bs=512k rw=randwrite [Rand-Write-4K] bs=4k rw=randwrite 次に、負荷をかけている間のプロファイリングには「iostat」と「dstat」というツールを利用しました。Terminalを3つ立上げ、先にiostatとdstatを起動した上でfioを実行。fioの実行が終わったら、iostatとdstatをCtl+Cで止めます。fioの実行では、「--filename」オプションではディレクトリだけでなくデバイスも指定できるようです。 //Terminal1で実行 iostat -mx 1 | grep --line-buffered drbd0 | awk '{print strftime("%y/%m/%d %H:%M:%S"), $0}' | tee iostat_drbd0.txt //Terminal2で実行 dstat -t | tee dstat_drbd0.txt //Terminal3で実行 fio --filename=/dev/drbd0 fio.conf これを、drbd0、drbd1、ローカルディスクそれぞれで実行してプロファイルした結果は次の通りです。 6-2.測定結果(1)(スループット) 下記がiostatでの集計結果になります。ブロックサイズとして1M、512K、4Kとバリエーション指定してみたのですが、残念ながらEC2インスタンスのネットワーク帯域の制限がかかってしまっているようで、1Mと512Kのブロックサイズ指定は有効ではなかったようです(なんとなく2.mediumタイプを選んでしまったことが敗因)。また、EBS自体もボリュームサイズによりIOPS制約が異なるため、次回は測定条件の見直しから必要だと反省しました。 4Kブロックの結果より、ローカルが性能が一番よく、続いてAZ内、AZ跨ぎの順番が確認できました。 DRBD0のRAWデータの一部抜粋↓ 6-3.測定結果(2)(write待ち時間) iostatの「w_await」結果はこのようになりました。 w_awaitの定義は、iostat manual↓になります。 The average time (in milliseconds) for write requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them. 7.まとめ 共有ディスク方式をDRBDを用いたミラーリング方式に変更し、AWS上に単純リフトした場合の性能を少し実験してみました。結果につきましては、要件次第で「この程度なら問題ないね」や、「ちょっと厳しいかも」など変わるかと思います。また、アーキテクチャ見直しや（クラウドであればもう少しクラウドネイティブな等）、様々なレイヤにおけるチューニング方法もあり(RAIDを使うなど)、これをもって一概に「性能が悪くなる」と言えないところがエンジニアリングの楽しみかと思います。ではどうすれば良いのか、についきましては追々勉強していきたいと思います。 ※本測定で得られた生データはこちらからダウンロードできます。 参考 詳解 システム・パフォーマンス ファイルシステムのベンチマーク集

この記事 AWS Cloud Practitionerを取得したため CLFの試験を受けた記録を残します。 about me AWS業務を4年ほど行っています。 2019 Solution Architect Associate （7月） SysOps Administrator Associate (9月) Solution Architect Professional (11月) Developer Associate (12月) 2020 DevOps Engineer Professional (3月) Security Specialty（5月） Advanced Networking(10月) 2021 Database Specialty（1月） Data Analytics Specialty(6月) Machine Learning Specialty(7月) Cloud Practitioner(7月) 試験について 公式ガイドが最も有効です。 https://aws.amazon.com/jp/certification/certified-cloud-practitioner/ 推奨する学習方法 初級者向け AWSクラウドを利用することでどんなメリットが有るのか？ 例：サンプル問題にあるような「責任共有モデル」「AWS クラウドの利点」 どんな種類のサービスがあって、一言で言うと何ができるのか？ 参考：試験ガイド下部「AWS のサービスと機能」 ひたすら問題集を解く 問題を覚えるくらいの勢いで解くことをおすすめします。 https://aws.koiwaclub.com/ 中級者以上向け そんな方はあまりいないと思うのですが、なめてかかると本当に落ちると思います。 私は時間の都合で対策ができなかったのですが、スコアが思ってたよりも結構低かったです。。 主に２点気をつけたほうが良いかと思います。 ①分野ごとの主要サービスをもう一度把握する 特に、いつも一部のAWSサービスしか使用していない方は 他のサービスに関する問題が来ると軒並み落とす可能性があります。 サンプル問題を見ればわかるのですが、VPC, EC2, RDSしか触らない方は 多分セキュリティ面や管理に使用できるサービスを学習したほうが良いと思います。 ②AWSが推奨するAWS Well-Architected フレームワーク 具体的なAWSサービスがどうこうではなく、机上の話になります。 以下に、AWSでわかりやすいガイドが公開されておりますので、復習しましょう。 https://aws.amazon.com/jp/builders-flash/202101/awsgeek-well-architected/ 結果とまとめ スコアが想定よりも低かったですが、合格しました。 カバーしていなかった or 忘れていたサービスは覚えている範囲で復習しました。 これで、すべてのAWS Certificationコンプリートとなりました。 時間をかけてしまいましたが、とても良い学習のきっかけとなりました。 私は、資格取得をAWS学習のきっかけとして受けたので、 NetworkingからMachine Learningまで、幅広いサービスに触れることが出来てとても良かったです。 ストックしてあるAWSの検証したいことが結構あるので、Qiitaにもアウトプットしていこうと思います。 また、資格は勉強すれば取れるんだなという自信が持てました。 AWS資格に関しては、次の更新は最難関であった Solutions Architect - Professional になるので、引き続き精進しようと思います。 ありがとうございました！

この記事 AWS機械学習分野の資格を取得したので、その学習記録を記します。 about me AWSを主軸として、インフラエンジニアに従事しております。 また、半年ほど機械学習エンジニア(イチから)に従事した経験はあります。 2019 Solution Architect Associate （7月） SysOps Administrator Associate (9月) Solution Architect Professional (11月) Developer Associate (12月) 2020 DevOps Engineer Professional (3月) Security Specialty（5月） Advanced Networking(10月) 2021 Database Specialty（1月） Data Analytics Specialty(6月) Machine Learning Specialty(7月) 試験の特徴 まず正とする情報は、公式案内です。 https://aws.amazon.com/jp/certification/certified-machine-learning-specialty/ この試験に挑む方の中には、きっと全く機械学習技術に触れたことのない方も、ある程度いらっしゃるのではないでしょうか。 サンプル問題をよく見ると、問題の中に「機械学習の基礎知識がないと答えられない問題」があることがわかります。 つまりある程度は、AWSに関係ない機械学習自体のお勉強が必要になります。 （あくまで個人的な）学習方法例 目的が、概要理解と資格取得、その後の学習へのきっかけとする方を前提として記載します。 先に、機械学習にはどんなものなのか、大まかな流れと概要を理解します。 「どんな登場人物が出てくるのか？」「例えば何ができるのか？」「どんなデータを扱うのか？」「機械学習エンジニアは何をやるのか？」という観点で調べます。 たくさん出てきますが例えば以下のサイトがわかりやすかったです。 https://ledge.ai/machine-learning/ あとは今まで通り、問題集を解きます。 というのも、全く未知の分野を資格取得に向けて学習するには、問題集でわからなかった用語などから紐付けて学ぶことが間違いないと思います。 その際は必ず、基礎知識レベルで「ふーん、こんなものなのか」って感じたらあまり長くとどまらず戻ってくることをおすすめします。問題集が進まないことにより疲れてしまって、モチベーションが下がることを防ぐためです。 例えば、サンプル問題２番に「TF-IDFマトリックスの次元」とあります。 この用語は自然言語処理で扱う用語なので、始めはわからない場合がほとんどです。 まず用語を調べると「言語処理に使う」「文書の特徴抽出に使うもの」「実体はよくわからん数式？」ということがわかってきます。 素晴らしい解説サイトに出会うと理解の深度が変わりますが、ある程度（長くて５分くらい）で一旦問題集に戻ります。（良いサイトに出会えたら、メモを添えてブックマークはしておく） このくらいの深度で拾っていくと、単語自体に馴染んでいけるので、問題が出た際になんとなく聞かれていることがわかってくるようになります。 ただし、一部の問題はやはりそれでも全くわからん分野が出てきます。 全然わからない問題に時間をかけるよりは、他の問題をカバーしたほうが効率が良いことが多いため、次に行きましょう。 判断の目安は、解いた問題集の中で後回しの問題が15%を超えたらアウトだと思います。 主に復習した内容 機械学習における、評価指標 以下が理解しやすいです。 https://www.codexa.net/ml-evaluation-cls/ 「適合率」「再現率」「特異度」「AUC」など、問題をウィルス検査などの身近な話に置き換え、具体的に理解します。機械学習トレーニングでどんな学習結果になったときに、どの評価指標をどちら(大小)に改善すれば良いのか？を理解することが、実際MLエンジニアにとっては重要です。 扱うデータや課題の種類と、アルゴリズムの種類（対応） 以下が理解しやすいです。 https://ainow.ai/2019/11/26/180809/ 分類をしたいのか、回帰予測をしたいのか？ 用意したデータに正解ラベルがあるのか？ など、それぞれ解決手法＝アルゴリズムも異なるので、頭で紐付けをします。 DataAnalytics範囲のAWSサービス AWS Glue Kinesis系 Amazon EMR などの基本機能を復習 問題集 いつもどおり、こちらです。 結果 時間が思ったほど取れなかったので２回目かと思いましたが、結果は8割で合格でした。 学習時間は20時間でしたが、スキマ時間をたくさん使ったので結構疲れが蓄積しました。 今回も、試験中一部は英語表記に直してから解きました。。 最後の資格となったCLFも取得しましたので、別途記録します。 ありがとうございました。 戦いの記録 SAA https://qiita.com/shinon_uk/items/5525178bf98034676b2f SOP https://qiita.com/shinon_uk/items/e60bcb946b49bf5cabda SAP ・勝利編 https://qiita.com/shinon_uk/items/c6b599d1cd3000e84d59 ・敗走編（資料集め） https://qiita.com/shinon_uk/items/ba839ba048ba439cc3ff DVA https://qiita.com/shinon_uk/items/8015953c792ef4bc7223 DOP https://qiita.com/shinon_uk/items/5646d536e649b60b962a SCS https://qiita.com/shinon_uk/items/67fab096f9b85c47de55 ANS https://qiita.com/shinon_uk/items/05f90e2ff6e9c9e732e8 DBS https://qiita.com/shinon_uk/items/996edfa2ceab274c38cb DAS https://qiita.com/shinon_uk/items/b1d3510ee5fa452d91f1

1. はじめに この投稿では、AWSの既存システムデータ収集サービスであるApplication Discovery Service(ADS)の検証内容を紹介します。ADSは、AWS移行の計画フェーズにおいて、既存システムの情報が整理・更新されていない(可視化が不十分)場合に、効率的な既存システム情報の収集を手助けしてくれるサービスになります。特に「既存リソースがオーバースペック気味で、実際リソースに余裕があるのでは？このAWS移行を機に適切なサイジングを見直したい」 という合、是非本ツールで最新状況を確認されると良いかと思います。 コンテンツとしては、下記が含まれています: ADSによる情報収集(3章) AthenaやQuickSightによる簡単な分析手法(4章) 生データもダウンロードできるようにしています。「時間がなくてツールを試している時間は無いが、ADSでどのような情報が取得できるか見てみたい」という方は、是非ご活用ください。 検証には、下記AWS Workshopのコンテンツに従い、手元にある環境(移行元)でADSを試しました。本記事で言葉足らずな箇所につきましては、是非ご参考下さい。 AWS Workshops -AWS APPLICATION DISCOVERY SERVICE 2. システム構成 検証のシステム構成は次のようになります。 AWS Workshopに沿って、LinuxのWordpressシステムを使います。手元のPC(iMaC)のVirtualBoxに、VMを2個作成し、wordpressのシステムをプロビジョニングしています。 また、折角の機会ですので、上記のwordpressシステムに加え、AWS、Azure、GCPにプロビジョニングされたVMも追加しております。 3. ADSを用いた情報収集 この章では、ADSによる情報収集のための設定と、収集されたデータの確認、及び、適切なEC2サーバの推奨を取得する機能を見ていきます。 また、次の4章でAthenaとQuickSightを用いた分析を行いますが、Athenaでデータ分析を行うには、S3へ収集データをエクスポートしておく必要があります。これは「Amazon Athenaでのデータ探索」というオプションを有効化しておくだけで、後はユーザの見えないところでAWSサービスが自動で必要な設定・リソースを作成してくれるのですが、ここでは背後でどのようなリソースが実際作成されているかも確認しています。 それでは、早速試していきたいと思います。 3-1. Migration Hubの有効化 ADSを使うために、Migration Hubの有効化を行います。 突然見慣れない「Migration Hub」というサービスからスタートします。ADSはMigration Hubの一部として組み込まれているため、ADSを使うにはMigration Hubの設定が必須なのですが、Migration Hubは、ADSだけでなく、その後に続く移行ツール(例えばCloud Endure)などを統合的に追跡するためのダッシュボードサービスになっています。 3-2. Athena統合の有効化 4章で分析をするために必要な設定になります。従って、収集した情報をADS(Migration Hub)だけで確認するのであれば、この機能は不要になります。 この機能を有効にすると、後述するADSのエージェントから収集されたデータ(ストリーム)はKinesis Data Firehose経由でS3へ格納されるようになります。そして、Athenaからクエリ(検索)できるように、Glueを使ったデータカタログが自動で生成されます。 自動設定されたKinesisとS3バケット 自動設定されたGlueデータカタログ 3-3. ADSエージェントのインストール&セットアップ 情報収集したい対象のサーバに、個別にエージェントを設定します。設定は、ナビゲーションの「ツール」から「検出エージェント」を選択すると、Windows・Linux用エージェントのダウンロード&インストールの方法が表示されますので、指示に従い、個別に仮想マシンに導入します。 Linux用 curl -o ./aws-discovery-agent.tar.gz https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz tar -xzf aws-discovery-agent.tar.gz sudo bash install -r "ap-northeast-1" -k "<AWS key id>" -s "<AWS key secret>" Windows用 Import-Module BitsTransfer Start-BitsTransfer -Source "https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/windows/latest/AWSDiscoveryAgentInstaller.msi" -Destination "C:\Users\Administrator\Downloads\" msiexec.exe /i c:\Users\Administrator\Downloads\AWSDiscoveryAgentInstaller.msi REGION="ap-northeast-1" KEY_ID="<aws key id>" KEY_SECRET="<aws key secret>" /q 本投稿では、各仮想マシンにエージェントを導入する方法を試しましたが、vCenter上の仮想マシンであれば、「検出コネクター」(仮想アプライアンス-OVA/OVFパッケージ)を使うことで、エージェントレスでの 情報収集が可能です。 暫くすると「Data collection」のAgentsタブに、各エージェントが表示されます。エージェントを選択し「データ収集を開始」ボタンを押します。 3-4. 収集された情報の確認 エージェントから収集された取得項目を確認してみましょう。 ネットワーク関連も表示できますが、必要のない接続先(IP)も多いです(怪しい接続先がないかの確認に使えるかもしれません)。 3-5. EC2推奨取得 ADSが収集した情報をベースに、EC2インスタンスの推奨を取得できます。各サーバのCPU、メモリ使用率など、インベントリ情報の詳細を分析しているようです。 取得データは、下記のようになります。 生データは、下記からダウンロード頂けます。 CSVファイルのダウンロード エクセルファイルのダウンロード 4. AthenaとQuickSightを用いた分析 4-1. Athenaの有効化 はじめに、Athenaサービスを有効化します。 4-2. テーブル一覧 §3-2で自動設定されたAthena用のリソースでは、公式ドキュメント「Amazon Athena でのデータ探索の操作」より、デフォルトでエージェントから取得できます: 下記は、各テーブル(7つのテーブル)に取得したデータになります: 生データは下記からダウンロード頂けます。ただし、生データ内のアカウントIDはお見せする訳にはいかないため、ダミーで「123456789012」と加工しています。その他の値は未加工です。 生データのダウンロード(zip) 4-3. Athenaで分析 参考サイト[3]のハンズオンに従い、実験してみたクエリは下記になります: Obtain IP Addresses and Hostnames for Servers This view helper function retrieves IP addresses and hostnames for a given server. You can use this >view in other queries. また、このような実験も試してみましょう。 Amazon Linux(on AWS)のHypervisorが「Xen」と表示されました。 Azure VM(on Azure)のHypervisorは「Hyper-V」とは表示されないのですね。 他にも、下記サイトにあるクエリを参考にできます。 EXPLORE ADS DATA IN ATHENA 公式ドキュメント「Athena で使用する事前定義されたクエリ」 4-4. QuickSightで分析 ここではQuickSightの詳細は省略します。下記をご参考ください。 Amazon QuickSight とは AWS Black Belt Online Seminar QuickSight AWS Black Belt Online Seminar Amazon QuickSight アップデート Amazon QuickSight の製品デモ動画 初めに、Athenaをデータソースとして設定します。 こちらは、6台のサーバについて、cpu利用率を確認したものになります。収集されたデータに基づき、いろいろな観点での分析が可能になります。 5. まとめ 本投稿では、様々なサーバにADSエージェントを設定し、ADSを用いた情報の収集、分析方法を紹介しました。今回は4章で分析を詳細にするためにAthenaやQuickSightまで試してみましたが、実際の現場では 移行先サイジングの目安だけでも十分である場合が多いと思います(3章)。とても簡単に使えるツールですので、移行の際には是非一度お試し下さい。

1. はじめに この投稿では、AWSの既存システムデータ収集サービスであるApplication Discovery Service(ADS)の検証内容を紹介します。ADSは、AWS移行の計画フェーズにおいて、既存システムの情報が整理・更新されていない(可視化が不十分)場合に、効率的な既存システム情報の収集を手助けしてくれるサービスになります。特に「既存リソースがオーバースペック気味で、実際リソースに余裕があるのでは？このAWS移行を機に適切なサイジングを見直したい」 という合、是非本ツールで最新状況を確認されると良いかと思います。 コンテンツとしては、下記が含まれています: ADSによる情報収集(3章) AthenaやQuickSightによる簡単な分析手法(4章) 生データもダウンロードできるようにしています。「時間がなくてツールを試している時間は無いが、ADSでどのような情報が取得できるか見てみたい」という方は、是非ご活用ください。 検証には、下記AWS Workshopのコンテンツに従い、手元にある環境(移行元)でADSを試しました。本記事で言葉足らずな箇所につきましては、是非ご参考下さい。 AWS Workshops -AWS APPLICATION DISCOVERY SERVICE 2. システム構成 検証のシステム構成は次のようになります。 AWS Workshopに沿って、LinuxのWordpressシステムを使います。手元のPC(iMaC)のVirtualBoxに、VMを2個作成し、wordpressのシステムをプロビジョニングしています。 また、折角の機会ですので、上記のwordpressシステムに加え、AWS、Azure、GCPにプロビジョニングされたVMも追加しております。 3. ADSを用いた情報収集 この章では、ADSによる情報収集のための設定と、収集されたデータの確認、及び、適切なEC2サーバの推奨を取得する機能を見ていきます。 また、次の4章でAthenaとQuickSightを用いた分析を行いますが、Athenaでデータ分析を行うには、S3へ収集データをエクスポートしておく必要があります。これは「Amazon Athenaでのデータ探索」というオプションを有効化しておくだけで、後はユーザの見えないところでAWSサービスが自動で必要な設定・リソースを作成してくれるのですが、ここでは背後でどのようなリソースが実際作成されているかも確認しています。 それでは、早速試していきたいと思います。 3-1. Migration Hubの有効化 ADSを使うために、Migration Hubの有効化を行います。 突然見慣れない「Migration Hub」というサービスからスタートします。ADSはMigration Hubの一部として組み込まれているため、ADSを使うにはMigration Hubの設定が必須なのですが、Migration Hubは、ADSだけでなく、その後に続く移行ツール(例えばCloud Endure)などを統合的に追跡するためのダッシュボードサービスになっています。 3-2. Athena統合の有効化 4章で分析をするために必要な設定になります。従って、収集した情報をADS(Migration Hub)だけで確認するのであれば、この機能は不要になります。 この機能を有効にすると、後述するADSのエージェントから収集されたデータ(ストリーム)はKinesis Data Firehose経由でS3へ格納されるようになります。そして、Athenaからクエリ(検索)できるように、Glueを使ったデータカタログが自動で生成されます。 自動設定されたKinesisとS3バケット 自動設定されたGlueデータカタログ 3-3. ADSエージェントのインストール&セットアップ 情報収集したい対象のサーバに、個別にエージェントを設定します。設定は、ナビゲーションの「ツール」から「検出エージェント」を選択すると、Windows・Linux用エージェントのダウンロード&インストールの方法が表示されますので、指示に従い、個別に仮想マシンに導入します。 Linux用 curl -o ./aws-discovery-agent.tar.gz https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz tar -xzf aws-discovery-agent.tar.gz sudo bash install -r "ap-northeast-1" -k "<AWS key id>" -s "<AWS key secret>" Windows用 Import-Module BitsTransfer Start-BitsTransfer -Source "https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/windows/latest/AWSDiscoveryAgentInstaller.msi" -Destination "C:\Users\Administrator\Downloads\" msiexec.exe /i c:\Users\Administrator\Downloads\AWSDiscoveryAgentInstaller.msi REGION="ap-northeast-1" KEY_ID="<aws key id>" KEY_SECRET="<aws key secret>" /q 本投稿では、各仮想マシンにエージェントを導入する方法を試しましたが、vCenter上の仮想マシンであれば、「検出コネクター」(仮想アプライアンス-OVA/OVFパッケージ)を使うことで、エージェントレスでの情報収集が可能です。 暫くすると「Data collection」のAgentsタブに、各エージェントが表示されます。エージェントを選択し「データ収集を開始」ボタンを押します。 3-4. 収集された情報の確認 エージェントから収集された取得項目を確認してみましょう。 ネットワーク関連も表示できますが、必要のない接続先(IP)も多いです(怪しい接続先がないかの確認に使えるかもしれません)。 3-5. EC2推奨取得 ADSが収集した情報をベースに、EC2インスタンスの推奨を取得できます。各サーバのCPU、メモリ使用率など、インベントリ情報の詳細を分析しているようです。 取得データは、下記のようになります。 生データは、下記からダウンロード頂けます。 CSVファイルのダウンロード エクセルファイルのダウンロード 4. AthenaとQuickSightを用いた分析 4-1. Athenaの有効化 はじめに、Athenaサービスを有効化します。 4-2. テーブル一覧 §3-2で自動設定されたAthena用のリソースでは、公式ドキュメント「Amazon Athena でのデータ探索の操作」より、デフォルトでエージェントから取得できます: 下記は、各テーブル(7つのテーブル)に取得したデータになります: 生データは下記からダウンロード頂けます。ただし、生データ内のアカウントIDはお見せする訳にはいかないため、ダミーで「123456789012」と加工しています。その他の値は未加工です。 生データのダウンロード(zip) 4-3. Athenaで分析 参考サイト[3]のハンズオンに従い、実験してみたクエリは下記になります: Obtain IP Addresses and Hostnames for Servers This view helper function retrieves IP addresses and hostnames for a given server. You can use this >view in other queries. また、このような実験も試してみましょう。 Amazon Linux(on AWS)のHypervisorが「Xen」と表示されました。 Azure VM(on Azure)のHypervisorは「Hyper-V」とは表示されないのですね。 他にも、下記サイトにあるクエリを参考にできます。 EXPLORE ADS DATA IN ATHENA 公式ドキュメント「Athena で使用する事前定義されたクエリ」 4-4. QuickSightで分析 ここではQuickSightの詳細は省略します。下記をご参考ください。 Amazon QuickSight とは AWS Black Belt Online Seminar QuickSight AWS Black Belt Online Seminar Amazon QuickSight アップデート Amazon QuickSight の製品デモ動画 初めに、Athenaをデータソースとして設定します。 こちらは、6台のサーバについて、cpu利用率を確認したものになります。収集されたデータに基づき、いろいろな観点での分析が可能になります。 5. まとめ 本投稿では、様々なサーバにADSエージェントを設定し、ADSを用いた情報の収集、分析方法を紹介しました。今回は4章で分析を詳細にするためにAthenaやQuickSightまで試してみましたが、実際の現場では 移行先サイジングの目安だけでも十分である場合が多いと思います(3章)。とても簡単に使えるツールですので、移行の際には是非一度お試し下さい。

概要 プライベートサブネット内の Amazon RDS や Amazon Aurora のアクセス方法で困ったことないですか？ ローカルのクライアントツールからリモートの DB へ EC2 の踏み台サーバ経由でアクセスする方法です。 今回、実現する方法にはセッションマネージャーが必要ですので、予め設定しておきましょう。 動作環境 踏み台サーバ: AmazonLinux2 リモートDB: RDS or Aurora ローカル: Mac 前提 ローカル環境にセッションマネージャーのインストール Session Manager プラグインを macOS にインストールおよびアンインストールする EC2 にセッションマネージャーからのアクセスを許可するロールを付与 Systems Manager セッションマネージャを使ったら SSH 管理不要になった EC2 にローカル環境からアクセスできるように ec2-user の公開鍵を登録 予め接続したい AWS アカウントへの AWS CLI とプロファイルの設定をしておく SSH Config の設定内容 上記の前提の設定が完了したら、ポートフォワードするための SSH の Config を設定します。 ~/.ssh/config host <ホスト名> HostName <インスタンスID> Port 22 User ec2-user ServerAliveInterval 300 IdentityFile ~/.ssh/id_rsa.pem LocalForward 33306 <リモートホスト RDS or Aurora>:3306 ProxyCommand sh -c "env PATH=/usr/local/bin:$PATH aws ssm start-session --profile <プロファイル名> --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" 注目するところは下記です。 LocalForward 33306 <リモートホスト RDS or Aurora>:3306 ここでは、ローカルポートに 33306 番ポートを開けて、そこへのアクセスを SSH 経由で最終的に、リモートホストの DB: 3306 番ポートへアクセスを流しています。 また、下記の設定で、セッションマネージャー経由で EC2 へアクセスを行ってます。 セッションマネージャー経由なので EC2 には 22 番ポートのセキュリティグループを開ける必要はありません。 ProxyCommand sh -c "env PATH=/usr/local/bin:$PATH aws ssm start-session --profile <プロファイル名> --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" SSH 接続 事前にポートフォワーディング用に SSH を接続しておきます。 ~/.ssh/config で設定したホスト先（踏み台サーバ）にコネクションを貼りましょう。 ssh <ホスト名> 踏み台サーバへ SSH アクセスができていれば成功です。SSH のセッションが生きてる間は、ポートフォワーディングできる状態になっています。DB クライアントツールの作業中は常に SSH 接続を維持しておきましょう。 DB クライアントツールの接続情報 上記設定が完了したら、後は DB クライアントツールから接続します。 Connection Method は TCP/IP で接続 Hostname: は localhost Port: はポートフォワーディング元の 33306 を指定 あとは、DBのユーザ、パスワード、DBスキーマを設定すると接続が成功します。 まとめ AWS では、リモート環境でかつプライベートなDBへのアクセスには現状踏み台サーバを経由してアクセスするしか方法がありません。 その際に、毎度接続方法を忘れてしまうのでまとめました。 誰かにためになれたら幸いですm(_ _)m あとがき 以前投稿した下記記事の改良版になっております。 ポートフォワーディング部分のネットワーク図などを見たい方は参考にしてください。 セッションマネージャー over SSH 経由でプライベートサブネット内のRDSへ接続する方法

AWSの初学者です。 前回までで、Amazon VPCによる仮想ネットワークの構築とAmazon EC2によるインスタンスの作成まで行いました。 前回はこちら: Amazon EC2を利用した仮想サーバーの構築方法①(EC2インスタンス作成編) 今回はSSH接続を行います(私はMacを使用していますので、Windowsの場合は方法が異なる可能性があります。ご了承ください)。 SSH接続とは? SSH(Secure Shell)とは、安全に通信を行って、ネットワークに接続された機器を遠隔操作するための通信手段（プロトコル）の１つです。「通信する側とされる側で、SSHでやり取りをしよう！」と取り決めることで安全に通信を行います。 参考記事: 初心者がSSHについて学ぶ(´･ω･`) 今回の場合、 「Amazon EC2で作成したインスタンスを、インターネットからログインして操作するためのプロトコル」 がSSH接続となります。 Macでは、ターミナルから「sshコマンド」を入力して、操作を行います。 SSH接続の手順 sshコマンドは、暗号化された通信をつかって、リモート通信を行うコマンドです。 基本の使い方は以下2点の通り。 ・ssh オプション 接続先 ・ssh オプション ログイン名@ 接続先 接続先で実行したいコマンド 参考: 【 ssh 】コマンド――リモートマシンにログインしてコマンドを実行する それでは、ターミナルを起動し、以下のコマンドを入力します。 ターミナル ssh -i ダウンロードしたキーペアファイル ec2-user@起動しているEC2インスタンスのパブリックIPアドレス ・ -iオプションとは? → 接続に使用する公開鍵ファイル(今回はダウンロードしたキーペアのファイル。拡張子が「.pem」のもの)を指定する。 「ダウンロードしたキーペアファイル」と「EC2インスタンスのパブリックIPアドレス」については、以下の記事で解説しています。 Amazon EC2を利用した仮想サーバー構築方法①(インスタンス作成編) 初めてインスタンスにログインする際には、以下のような接続を確認するメッセージが表示されるそうです。 「yes」と入力すれば進みます。 ターミナル The authenticity of host ‘起動しているEC2インスタンスのパブリックIPアドレス' can't be established. ECDSA key fingerprint is ○○○○. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes もし以下のようなエラーが現れて接続できない場合... ターミナル @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '〇〇.pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. 上記のエラーは、「鍵ファイルのパーミッション(権限)が、他のユーザーも閲覧できる状態になっている」ために発生するそうです。 したがって、「AWSからダウンロードしたキーペアファイルを、自分以外は読み込めないようにする」という設定をする必要があります。 以下のコマンドを入力すれば、鍵ファイルを自分だけが読み込めるよう設定できます。 ターミナル chmod 400 ダウンロードしたキーペアファイル chmodコマンドの使い方については、以下の通りです。 chmod 権限設定　ファイルパス (中略) chmodはファイル or ディレクトリに対する権限を設定するコマンド。 ユーザー区分ごとに権限を設定できる。 参考: chmod コマンド SSH接続に成功すれば、ウェルカムメッセージが表示され、コマンドを入力できる状態(ログイン状態)になります。 ターミナル __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| [ec2-user@ip-10-0-1-10 ~]$ コマンドを入力できる状態 ログアウトしたい場合は「exit」を入力すればログアウトできます。 以上で、SSH接続については完了です。 次回は「ファイアウォールによる接続制限」を行いたいと思います。 ここまで読んでいただきありがとうございました。

AWSの初学者です。 前回までで、Amazon VPCによる仮想ネットワークの構築とAmazon EC2によるインスタンスの作成まで行いました。 前回はこちら: Amazon EC2を利用した仮想サーバーの構築方法①(EC2インスタンス作成編) 今回はSSH接続を行います(私はMacを使用していますので、Windowsの場合は方法が異なる可能性があります。ご了承ください)。 SSH接続とは? SSH(Secure Shell)とは、安全に通信を行って、ネットワークに接続された機器を遠隔操作するための通信手段（プロトコル）の１つです。「通信する側とされる側で、SSHでやり取りをしよう！」と取り決めることで安全に通信を行います。 参考記事: 初心者がSSHについて学ぶ(´･ω･`) 今回の場合、 「Amazon EC2で作成したインスタンスを、インターネットからログインして操作するためのプロトコル」 がSSH接続となります。 Macでは、ターミナルから「sshコマンド」を入力して、操作を行います。 SSH接続の手順 sshコマンドは、暗号化された通信をつかって、リモート通信を行うコマンドです。 基本の使い方は以下2点の通り。 ・ssh オプション 接続先 ・ssh オプション ログイン名@ 接続先 接続先で実行したいコマンド 参考: 【 ssh 】コマンド――リモートマシンにログインしてコマンドを実行する それでは、ターミナルを起動し、以下のコマンドを入力します。 ターミナル ssh -i ダウンロードしたキーペアファイル ec2-user@起動しているEC2インスタンスのパブリックIPアドレス ・ -iオプションとは? → 接続に使用する公開鍵ファイル(今回はダウンロードしたキーペアのファイル。拡張子が「.pem」のもの)を指定する。 「ダウンロードしたキーペアファイル」と「EC2インスタンスのパブリックIPアドレス」については、以下の記事で解説しています。 Amazon EC2を利用した仮想サーバー構築方法①(インスタンス作成編) 初めてインスタンスにログインする際には、以下のような接続を確認するメッセージが表示されるそうです。 「yes」と入力すれば進みます。 ターミナル The authenticity of host ‘起動しているEC2インスタンスのパブリックIPアドレス' can't be established. ECDSA key fingerprint is ○○○○. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes もし以下のようなエラーが現れて接続できない場合... ターミナル @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '〇〇.pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. 上記のエラーは、「鍵ファイルのパーミッション(権限)が、他のユーザーも閲覧できる状態になっている」ために発生するそうです。 したがって、「AWSからダウンロードしたキーペアファイルを、自分以外は読み込めないようにする」という設定をする必要があります。 以下のコマンドを入力すれば、鍵ファイルを自分だけが読み込めるよう設定できます。 ターミナル chmod 400 ダウンロードしたキーペアファイル chmodコマンドの使い方については、以下の通りです。 chmod 権限設定　ファイルパス (中略) chmodはファイル or ディレクトリに対する権限を設定するコマンド。 ユーザー区分ごとに権限を設定できる。 参考: chmod コマンド SSH接続に成功すれば、ウェルカムメッセージが表示され、コマンドを入力できる状態(ログイン状態)になります。 ターミナル __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| [ec2-user@ip-10-0-1-10 ~]$ コマンドを入力できる状態 ログアウトしたい場合は「exit」を入力すればログアウトできます。 以上で、SSH接続については完了です。 次回は「ファイアウォールによる接続制限」を行いたいと思います。 ここまで読んでいただきありがとうございました。

AWSのユーザーには細かなIAMポリシーが設定できるが、細かすぎるために新しくサービスを使用する際に必要なIAMポリシーの確認に時間がかかってしまう。だが時間の短縮のために関連するサービスの全てのIAMポリシーをつけると様々な操作ができてしまい、後々問題が発生する可能性が出てきます。 今回Lambdaをデプロイする作業があり調べましたが、必要なIAMポリシーについてまとめられているページが見つかりませんでした。ということでデプロイする際に使用するユーザーを新設し必要なIAMポリシーを確認したのでまとめました。 コマンドラインからAWSにLambda関数をデプロイするためのツール コマンドラインからデプロイするには「AWS SAM CLI」が必要になります。詳細は以下のAWS公式ページを参照してください。 デプロイの流れ コマンドラインからローカルで作成した関数でデプロイする流れは以下の通りです。 今回はMac上で作成した関数をデプロイします。関数はNode.jsで作成したものとし、ZIP形式でアップロードするものとします。 1)デプロイユーザーの作成 AWS上でデプロイに使用するユーザーは以下のページから作成する。必要なIAMポリシーは後述します。 2)デプロイユーザーの設定 AWSで作成したユーザーのアクセスキーやシークレットアクセスキーを取得して、ローカルの環境に設定します。 ローカルに設定するコマンドは以下の通りです。 $ aws configure AWS Access Key ID [None]:（作成したユーザーのAccess Key） AWS Secret Access Key [None]: （作成したユーザーのSecret Access Key） Default region name [None]: (リージョンの名前、東京の場合はap-northeast-1) Default output format [None]: json 3)ビルド 以下のコマンドを実行します $ sam build Building codeuri: （パス） runtime: nodejs14.x metadata: {} functions: ['（関数名）'] Running NodejsNpmBuilder:NpmPack Running NodejsNpmBuilder:CopyNpmrc Running NodejsNpmBuilder:CopySource Running NodejsNpmBuilder:NpmInstall Running NodejsNpmBuilder:CleanUpNpmrc Build Succeeded Built Artifacts : .aws-sam/build Built Template : .aws-sam/build/template.yaml Commands you can use next ========================= [*] Invoke Function: sam local invoke [*] Deploy: sam deploy --guided 4)デプロイ 以下のコマンドでデプロイが実行される。初回には後述するCloudFormationのスタックの設定を行います。２回目以降は初回に設定した設定を利用できるので細かな指定をスキップすることができます。 #初回の場合 $sam deploy --guided #２回目以降 $sam deploy デプロイに利用されるAWSサービス デプロイはソースコードをS3にアップロードし、その後Lambdaに関数が展開されます。 これらの流れを管理しているのがCloudFormationで、個別の処理ごとに名前をつけることができ、処理毎の単位をスタックと呼びます。 東京リージョンのCloudFormationのURLは以下のURLになります。 デプロイ時に同じスタックの名前を使用することで、以前に作成した関数に上書きが行われます。 またデプロイした関数にはポリシーが設定された専用のロールが付与されます。 デプロイに必要なIAMポリシー さて本題です。Lambdaをデプロイするのに必要なサービスは４つあります。（CloudFormation、IAM、S3、Lambda）デプロイを行うユーザーがこれらのサービスに対してアクションを行うためのポリシーを所有していないとデプロイに失敗します。（厳密には処理中に問題が発生し、取り消しが行われた際の削除のIAMポリシーも含まれています） サービス毎に必要なIAMポリシーの一覧を記載します。 1)CloudFormation DescribeStackEvents DescribeStackSetOperation CreateChangeSet DescribeChangeSet ExecuteChangeSet GetTemplateSummary DescribeStacks 2)IAM GetRole PassRole DetachRolePolicy CreateRole DeleteRole AttachRolePolicy UpdateRole PutRolePolicy CreateUser 3)S3 GetBucketTagging GetBucketWebsite GetJobTagging GetObjectVersionTagging RestoreObject GetBucketAcl GetBucketNotification GetBucketPolicy GetObjectVersionTorrent PutObject GetObject GetIntelligentTieringConfiguration GetObjectTagging GetMetricsConfiguration GetBucketLocation GetObjectVersion 4)Lambda GetFunction CreateFunction UpdateFunctionCode DeleteFunction AddPermission まとめ 今回のIAMポリシーの確認で関数のコードをアップするために使用されているS3のIAMポリシーが多く必要であることがわかりました。またロールの作成などでIAMに対してもIAMポリシーが必要になったのは盲点だと思いました。 外部からアクセス可能にするにはAPIGateWayなどLambdaの関数を起動するサービス追加で必要になるのでご注意ください。

これは何 TerraformでAWS環境を構築した際、ALBのHealth checkでrequest timed outになったので、解決のメモ。 つまり… request timed outなので、ググって以下を参考に対応。 "AWSのDocumentより" HTTP 408: Request timeout アイドルタイムアウト期間の期限が切れる前に、クライアントからデータが送信されませんでした。 TCP キープアライブを送信しても、このタイムアウトを防ぐことはできません。 各アイドルタイムアウト期間が経過する前に、1 バイト以上のデータを送信します。必要に応じて、アイドルタイムアウト期間を長くします。 "Qiitaより" リクエストが通るには、 ロードバランサに設定したセキュリティグループのアウトバウンドルール インスタンスに設定したセキュリティグループのインバウンドルール の双方で接続を許可する必要があります。 ふ〜む、なるほど。 どうやら、タイムアウト値が短すぎるのか、SGのルールを見直す必要がありそうです。 参考 https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html https://qiita.com/koseki/items/61372f25dfe8c8bb7a63 結論 SGのルールは問題なく、どうやらTimeoutの期間が短すぎた模様。 "Terraform Document より" timeout - (Optional) Amount of time, in seconds, during which no response means a failed health check. For Application Load Balancers, the range is 2 to 120 seconds, and the default is 5 seconds for the instance target type and 30 seconds for the lambda target type. For Network Load Balancers, you cannot set a custom value, and the default is 10 seconds for TCP and HTTPS health checks and 6 seconds for HTTP health checks. ALBのHealth checkについては、デフォルトのまま、特に値を変えることなくapplyしていたので、適当に以下に変更。 resource "aws_lb_target_group" "main" { name = "lb-tg" port = 80 protocol = "HTTP" vpc_id = aws_vpc.main.id health_check { interval = 90 timeout = 60 } } これで、request timed outは解決しました。 結局はデフォルトの値だとrequest timed outになる、ということだったのですが、他にも原因があるのかもしれません。 timeoutって普通はしっかり考えてデフォルト値にはしない(？)から、そんなに同じような問題を抱えている人がいないんでしょうか。 Terraformのデフォルトに従うとエラーになる、なんて天下のHashi Corpがするかなあと思ったりします。 なので他にも原因がありそうだなあと思いつつ、これで解決はしたので何だかなあという感じです。 参考 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb_target_group

1. はじめに データベースをオンプレミスからクラウドへ移行する場合、移行先DBのDBMSや構成を確定させたあとに、移行方式の検討を行います。本番移行でトラブルが起きると、計画外のサービス停止が発生して利用者に大きな影響を及ぼすリスクがありますので、安全な移行方式を選定したうえで、十分な検証を行う必要があります。 この記事では、はじめにDBの移行方式を決めるための検討ポイントを、Oracle DatabaseをAWSへ移行するケースを例にしてまとめます。次に、異種DBMS間のDB移行について、Oracle DatabaseからAuroraへの移行を例に、AWS Database Migration Service（DMS）とSchema Conversion Tool（SCT）を使った移行方式を検証したので、作業の流れや移行時の注意事項をまとめます。 なお、データベース移行の計画フェーズで検討すべきポイントについては別記事にまとめていますので、こちらも参考にしていただければと思います。 2. DB移行方式の検討 2-1. DB移行方式の検討ポイント DBの移行方式を検討する際、以下の2点が重要なポイントとなります。 移行元・移行先DBMSの差異 サービス停止可能時間 移行元・移行先DBMSの差異については、同一DBMSであればDBMSが提供する標準移行ツールを利用する移行方式が第一候補になります。標準移行ツールは利用実績が多いので、移行リスクを低減できるでしょう。一方、移行元・移行先でDBMSが異なる場合、両方のDBMSをサポートしている有償の移行ツールを使用することになると思います。 サービス停止可能時間については、DBデータの全量コピーを含む一連の移行作業を実施している期間中、DBの更新を伴うサービスを停止していても問題ないかが判断基準になります。十分なサービス停止可能時間を確保できる場合、DBの更新がない状態にして、export/importツールなどを利用したDBデータの全量コピーによってDB移行を実施することが可能です。短時間のサービス停止時間しか許容されない場合、サービス中にDBデータの全量コピー＋差分同期（CDC, Change Data Capture）を実施して移行元・先のDBでデータを同期し、サービス停止可能になったら移行先システムへの切り替えを行います。 2-2. 同一DBMS間のDB移行方式 移行元・移行先のDBMSが同一の場合のDB移行について、Oracle Databaseを例に利用可能なOracle提供のツールを挙げてみます。Oralce Databaseの移行では、Data PumpのようなバックアップツールやData GuardのようなDRツールを使うケースも多いので、これらについて比較し、AWSへの移行での利用可否も記載します。 移行ツール 概要・制約 Oracle Database on EC2 への移行 RDS for Oracle への移行 Data Pump DBデータを中間ファイルへ出力（export）し、移行先DBへimportできる機能OS・文字コード・Oracle Databaseバージョンが異なってもよいデータ移行中はDBの更新停止が必要 利用可能 利用可能 DBLink DB間をネットワーク接続し、接続相手のデータを内部データのように扱える機能 利用可能 利用可能 RMAN Oracle Databaseのバックアップ機能で、移行先DBへリストアすることでデータ移行を実施OS・文字コード・Oracle Databaseバージョンは同一であること 利用可能 利用不可 トランスポータブル表領域 表領域を構成するデータファイルをコピーすることでデータ移行を行う機能文字コードは同一であること、Enterprise Editionが必要データ移行中はDBの更新停止が必要 利用可能 利用不可 Data Guard Oracle Database間でDBデータをレプリケートする、主にDR用途で使用する機能OS・文字コード・Oracle Databaseバージョンが同一であること、Enterprise Editionが必要 利用可能 利用不可 GoldenGate 異種DB間でDBデータをレプリケートする製品（Oracle Database以外のDBへの移行でも利用可能）GoldenGate用の有償ライセンスが必要 利用可能 利用可能 2-3. 異種DBMS間のDB移行方式 移行元・移行先でDBMSが異なる場合、以下の2段階でDB移行を実施する必要があります。 移行元DBのスキーマを移行先DBMS向けに変換し、移行先DBへ適用 移行ツールを使用してDBデータを移行 スキーマの変換については、AWSが無償提供するSchema Conversion Tool（SCT）のような変換ツールを使用して自動変換を行います。ツールでは自動変換できないDBオブジェクトもあるので、この場合は手動変換する必要があります。手動変換が必要なDBオブジェクトの種類や量によってスキーマ変換に必要な作業量・コストは変動するので、計画フェーズでDBMS変更の可能性がある場合には変換ツールを実行して確認しておくのがよいでしょう。 変換したスキーマ定義の移行先DBへの適用については、外部キー制約のようにデータ移行前に適用しないほうがいいDBオブジェクトもあります。DBMSや移行ツールによって異なる動作をするものもあると思いますが、「3-3. SCT, DMSによるDB移行での注意事項」に例をいくつか記載するので、移行時に注意しましょう。 異種DBMS間のDB移行で利用可能なデータ移行ツールについて、AWSへDB移行を行う場合を想定して、GoldenGateとDatabase Migration Service（DMS）を比較してみました。どちらのツールもサービス中の全量コピー＋差分同期（CDC）をサポートするので、サービス停止可能時間が短い場合にも利用できます。 移行ツール ベンダ 概要 コスト GoldenGate Oracle 多機能で、柔軟な構成が可能なDB移行ツールです。GoldenGate Hubを導入したEC2を用意し、これを経由して移行元からのデータ読込み・移行先への書き込みを実施します。構成はOracle Databaseの移行に関するAWSのWhitepaperが参考になります。 GoldenGateライセンスとEC2の費用が必要 Database Migration Service (DMS) AWS AWSにDMSレプリケーションインスタンスを用意し、これを経由して移行元からのデータ読込み・移行先への書き込みを実施します。マネージド型サービスのため、インスタンス作成やマルチAZ化などを容易に構成可能です。 DMSインスタンスの費用が必要。Auroraへ移行する場合、6カ月間は無償で利用可能。 3. DMSを使ったOracle DatabaseからAuroraへの移行検証 ここでは、AWS DMS データベース移行手順ガイドを参考に、SCTやDMSを使った異種DB間での移行作業を一通り実行してみます。移行元はOracle Database、移行先はAurora（PostgreSQL互換）とします。 3-1. 検証環境の構成概要 検証環境の構成概要を以下に示します。構成の単純化のため、オンプレミス・AWS間のネットワーク接続は行わず、AWSの同一VPC内に移行元・移行先DBを配置します。移行元DBへ適用するスキーマとして、AWSがDMSの動作確認用に提供しているサンプルスキーマを使用します。 サーバ リソース 導入ソフトウェア SCTサーバ（EC2） インスタンスタイプ: t3.smallディスク: gp2 30GiB Windows Server 2019 Schema Conversion Tool 1.0.652 Oracle JDBC Driver 10 PostgreSQL 4.2 JDBC Driver 42.2.23 pgAdmin 4 v5.5 移行元DBサーバ（EC2） インスタンスタイプ: t3.largeディスク: gp2 50GiB Windows Server 2019 Oracle Database 19c (19.3) 移行先DBサーバ（Aurora） インスタンスクラス: db.t3.medium Aurora PostgreSQL (Compatible with PostgreSQL 12.6) DMS インスタンスクラス: dms.t3.medium ストレージ: 50GiB DMS 3.4.4 3-2. DB移行作業の流れ (1) 事前準備 事前準備として、以下のリソースを作成しておきます。 VPC、サブネット、NAT Gateway、Endpointなどのネットワークリソースを作成 移行元DBサーバとなるEC2を作成し、Oracle Database 19cのインストール・DB作成の実施後、サンプルスキーマをインポート 移行先DBサーバとしてAurora（PostgreSQL互換）を作成 (2) SCTによる変換レポート作成・スキーマ変換 SCTサーバとなるEC2を作成し、SCTを導入します。SCTにJDBCドライバを設定した後、以下の作業を実施します。 変換レポート作成 DB移行の計画フェーズで移行先DBMSの比較検討を行う際に、移行対象スキーマでの手動変換の要否や難易度を、DBMSごとにまとめたレポートを作成できます。SCTのメニューから [File] - [New Project Wizard] を選択し、移行元DBへの接続情報などを設定して、PostgreSQLやMySQL、MariaDBへの変換レポートを作成します。 スキーマ変換 SCTで自動スキーマ変換により移行先DBへ適用できるDDLを作成します。SCTのメニューから [File] - [New Project] を選択して、移行元・移行先DBへの接続情報などを設定し、移行元DBから移行対象スキーマを選択して [Actions] - [Convert schema] を実行します。自動変換できなかったオブジェクトは手動で変換を行います。今回の検証では手動変換は対象外としました。 (3) 移行先DBへの変換後スキーマ適用 SCTサーバにPostgreSQLクライアント（pgAdmin）を導入し、自動変換・手動変換したスキーマ定義を移行先DBへ適用して、DBデータを移行できる状態にします。 拡張パックの適用 SCTでは、移行元DBMSの独自関数と互換性のある関数を移行先DBで使用できる拡張パックを提供しています。SCTで移行先DBのスキーマを選択して [Actions] - [Apply Extension Pack] を実行し、画面に従って操作を行います。これにより、移行先DBに拡張パックが適用され、aws_oracle_dataやaws_oracle_extなどのスキーマが作成されます。 移行先DBへの変換後スキーマの適用 変換後スキーマの移行先DBへの適用方法について、変換後の初回はエラー発生時の原因特定を考慮して、DBクライアントからオブジェクトごとにDDLを実行することをお勧めします。DDLがエラーなく適用でき、オブジェクトが作成できたことを確認した後に、各種テストを実施して正しく変換されていたかを確認してください。 データ移行を行う場合は、「2-3. 異種DBMS間のDB移行方式」に記載したように、データ移行でのエラーの原因となりうるオブジェクトもありますので、必要最小限（テーブルのみなど）のオブジェクトを作成します。データ移行完了後に、残りのオブジェクトを作成します。 今回の検証ではデータ移行で必要なオブジェクトの作成のみとしました。 (4) データ移行準備 DMSによるデータ移行を実施するため、準備として以下の作業を行います。 移行元DBの設定変更 DMSでデータ移行を行う前提条件として、移行元DB（Oracle Database）でアーカイブログ設定・サプリメンタルログ設定を行います。 DMSの各種リソース作成 DMSでDB移行に必要な下記リソースを作成します。・レプリケーションサブネットグループ・レプリケーションインスタンス・ソースエンドポイント、ターゲットエンドポイント・移行タスク移行タスクではテーブルをマッピングするための変換ルールを設定しますが、SCTではPostgreSQL向けのスキーマ名・テーブル名・列名が移行元で大文字であっても小文字に変換されますので、これをルールとして設定します。 DMSでは、移行方式として全量コピーのみ、全量コピー＋差分同期、差分同期のみの3種類から選択できますが、今回の検証では全量コピーのみとしました。 (5) データ移行実施 前項で作成した移行タスクを開始し、データ移行を実施します。DMS画面で移行対象の表ごとに移行済みの行数が表示されます。最も移行時間を要する表に対して、事前に移行元DBで行数を確認しておくことで、移行の進捗を確認することができます。全量コピーが完了すると移行タスクも完了します。データ移行完了後に、移行先DBで残りのスキーマオブジェクトを作成します。これでDB移行は完了です。 3-3. SCT, DMSによるDB移行での注意事項 今回、SCT, DMSを使ってDB移行検証を実施した結果、注意した方がいいと感じた点を以下に挙げてみます。 SCTは数か月ごとにバージョンアップされています。以前のバージョンで自動変換できなかったオブジェクトが自動変換できるようになることもありますので、常に最新バージョンを使用しましょう。特に、変換レポートを作成する移行計画フェーズと実際にスキーマ変換を行うフェーズは時期が異なるので、スキーマ変換実行時は注意しましょう。 「2-3. 異種DBMS間のDB移行方式」に記載しましたが、移行先DBでデータ移行前に作成しないほうがいいオブジェクトがあります。サービス停止可能時間にもよりますが、データ移行前は必要最小限のオブジェクトのみを作成しておき、データ移行完了後に残りのオブジェクトを作成してからサービスを再開する方法もあるかと思います。以下にデータ移行前に作成しないほうがいいオブジェクトの例をいくつかあげます。 外部キーなどの制約 DMSでの移行するデータの順序は任意のため、参照先の外部キーより前に参照元データが移行される場合があります。この場合、移行先DBでのデータ挿入時に外部キー制約に引っかかってエラーになります。移行先DBへの制約の作成は、少なくとも全量コピーが完了した後にする必要があります。 インデックス データ移行後にインデックスが断片化しているとリビルドが必要になります。データ移行中は移行先DBでの処理のオーバーヘッドにもなりますので、特に要件がなければ、移行完了後の作成でもいいでしょう。 シーケンス 移行元DBから収集したスキーマ情報では、シーケンスの開始番号は次に採番される番号となっています。一方、SCTで変換したシーケンスのDDLでは開始番号は1になります。また、実際のデータ移行時にはシーケンス番号はスキーマ情報収集時点から変わっていると考えられます。そのため、データ移行が完了し、移行元DBの更新を停止した時点でのシーケンス番号を確認し、その値を反映させたDDLを移行先DBへ適用する必要があります。 トリガー 移行先DBでのデータ挿入をきっかけに自動実行されて、データの挿入・更新を実行するトリガーがあると、移行元・移行先のDBデータの不整合が発生してしまいます。データ移行中に必要でなければ、データ移行完了後にトリガーを作成しましょう。 今回の検証では、移行性能は検証の対象外としています。実際のDB移行では移行時間がシビアなケースが多く、想定した転送速度が出ない場合には大きな問題になります。DMSインスタンスはサイジングが難しい（無理？）ので、実際のDB移行では、実データを使用した検証が必要です。 4. 最後に この記事ではクラウドへのDB移行について、移行方式を決める際の検討ポイントと、実際にSCT, DMSを使ったAWSへのDB移行検証の結果をまとめてみました。 データベース移行の計画フェーズで検討すべきポイントをまとめた別記事とあわせて、クラウドへのDB移行を行う際の参考にしていただければと思います。

目次 1.はじめに 2.今回やること 3.ご紹介 4.前提条件 5.AWSの設定 6.Next.jsプロジェクトの作成、Amplifyの組み込み 7.ソースコードの管理 8.ソースのホスティング 9.おわりに 1. はじめに 業務でNext.js、Amplifyを扱うことになりました。 そのとき構築したことの手順をつらつらと書き綴っていきます。 本記事ではWindows10で構築しています。 2. 今回やること Next.jsで新規プロジェクトの雛形を作成。 AmplifyでWebサイトのデプロイ、ホスティング。 とりあえず開発環境を整えるというイメージで進めていきます。 3. ご紹介 今回登場する主役2名の簡単な紹介をします。 Next.jsくん Reactをベースとしたフレームワーク。 SSR（サーバーサイドレンダリング）やファイルシステムベースのルーティングができる。 SSRを行う事によって、初期表示の読み込み速度を大幅に改善してくれる。 Amplifyさん AWSで提供されているサービス。 諸々のバックエンド構築をしてくれる。 フロントエンドとバックエンドの接続を容易にする。 静的ページのデプロイ、ホスティングを一瞬で実現できる。 4. 前提条件 以下環境が整っていることを前提に進めていきます。 nodejsがインストールされている。 git 1.7.9以上 がインストールされている。 pythonがインストールされている。 AWSアカウントを所持している。 Visual Studio Codeがインストールされている。(他のエディタでも大丈夫です) 5. AWSの設定 AWSCLI用のユーザーを作成 AWSの下記ページにてユーザーを作成します。 ユーザー追加ページ ①ユーザー名の設定 任意のユーザー名を設定 AWSCLI用のユーザーなのでAwsCliUserとします。 ②アクセスの種類の選択 AWSCLIでアクセスするので、プログラムによるアクセスは必須です。 ③次のステップを押下 ④アクセス許可の設定 既存のポリシーを直接アタッチを選択 ⑤アタッチするポリシーを選択 AdministratorAccessを選択(AWSCLIを操作するために管理者権限が必要なため) ⑥次のステップを押下 ⑦次のステップを押下 ⑧ユーザーの作成を押下 ⑨アクセスキーIDを確認＆メモ ⑩シークレットアクセスキーを確認＆メモ シークレットアクセスキーは他人にみせちゃダメなやつです。 そしてシークレットアクセスキーは必ずここでメモしてください。 後から確認できないです。 AWSCLI用ユーザーの作成完了です。 Amplify用のユーザーを作成 先程と同様にユーザーの追加を行います。 ほとんど同じ操作なので、画像は省略します。 ①ユーザー名の設定 任意のユーザー名を設定 Amplify用のユーザーなのでAmplifyUserとします。 ②アクセスの種類の選択 プログラムによるアクセスにチェック ③次のステップを押下 ④アクセス許可の設定 既存のポリシーを直接アタッチを選択 ⑤アタッチするポリシーを選択 先人様がいらっしゃったので、こちらを参考にポリシーを選択しました。 下記のポリシーを選択 AdministratorAccess-Amplify IAMFullAccess AmazonS3FullAccess 更に追加でAmplifyの全権限を持ったインラインポリシーを設定しますがそちらは後述します。 ⑥次のステップを押下 ⑦次のステップを押下 ⑧ユーザーの作成を押下 ⑨アクセスキーIDを確認＆メモ ⑩シークレットアクセスキーを確認＆メモ Amplify用ユーザーの作成完了です。 インラインポリシーの作成と適用 先程少し話が出てきましたが、Amplifyの全権限を持ったインラインポリシーを作成しAmplifyUserに付与します。 AWSの下記ページにてポリシーを作成します。 ポリシー作成ページ ①サービスの選択 Amplifyを選択します。 ②許可するアクションの選択 すべてのAmplifyアクションを選択します。 ③リソースの指定 すべてのリソースを選択します。 ④次のステップを押下 ⑤次のステップを押下 タグの追加は不要です。 ⑥名前の指定 今回はAmplifyFullAccessとする。 ⑦ポリシーの作成を押下 ⑧作成したポリシーを適用 ユーザー一覧からAmplifyUserを選択します。 アクセス権限の追加から先ほど作成したAmplifyFullAccessを直接アタッチします。 最終的に下記のようになればOKです。 AWS CLIのインストール、ユーザーの紐付け AWS CLIのインストーラをダウンロード くわしい手順はこちら ダウンロード後、AWS CLI をインストールします。 その後コマンドプロンプトを開いて下記コマンドを実行します。 aws --version 次のような感じでバージョンが確認できればOKです。 aws-cli/2.1.38 Python/3.8.8 Windows/10 exe/AMD64 prompt/off 次にAWS CLIとAwsCliUserを紐付けます。 ①下記コマンドを実行 aws configure --profile aws-cli ②（AwsCliUserの）アクセスキーを入力 AWS Access Key ID [None]: ③（AwsCliUserの）シークレットアクセスキーを入力 AWS Secret Access Key [None]: ④ ap-northeast-1 と入力 Default region name [None]: ⑤ json と入力 Default output format [None]: ⑥下記コマンドを実行 aws ec2 describe-instances --profile aws-cli プロフィール情報が表示されれば完了です。 ※-- More --　と出力されている状態は ctrl+c で処理中断できます。 Amplify CLIのインストール、ユーザーの紐付け 下記コマンドを実行し、 Amplify CLIをインストールします。 npm install -g @aws-amplify/cli 次のコマンドでバージョンが確認できればOKです amplify --version 次にAmplify CLIとAmplifyUserを紐付けます。 ①下記コマンドを実行 amplify configure ②ブラウザが開いてAWSの画面へ遷移するので、コマンドプロンプトに戻る。 ③Press Enter to continue　と表示されているので Enterを押下 ④ap-northeast-1 を選択 ※ユーザー作成済みなのでホントは何でも良い ⑤任意のユーザー名を入力（今回はAmplifyとしました。） ※ユーザー作成済みなのでホントは何でも良い ⑥IAMユーザーの作成画面が表示されますが、すでにユーザーは作成しているのでそのまま閉じてコマンドプロンプトに戻る。 ⑦Press Enter to continue　と表示されているので Enterを押下 ⑧（AmplifyUserの）アクセスキーIDを入力 ? accessKeyId: ******************** ⑨（AmplifyUserの）シークレットアクセスキーを入力 ? secretAccessKey: ******************** ⑩任意のプロファイル名を入力 今回はAmplifyProfileとしました。 ? Profile Name: AmplifyProfile 下記メッセージが表示されたら完了です。 Successfully set up the new user. AWSの設定が完了しました。 お疲れさまです！ 6. Next.jsプロジェクトの作成、Amplifyの組み込み プロジェクトの作成 ①コマンドプロンプトを開き、プロジェクトを格納したいフォルダの作成&遷移 mkdir Workspace cd Workspace ②Nextjsプロジェクトの作成 npx create-next-app ③プロジェクト名を聞かれるので任意の名前を入力 今回は nextjsapp としました ? What is your project named? » nextjsapp ④Visual Studio Codeでプロジェクトフォルダ(nextjs_app)を開く 今後はVisual Studio Code内のターミナルでコマンドを実行していきます。 Amplifyの組み込み ①下記コマンドを実行 amplify init ②プロジェクト名を入力 Enter a name for the project (nextjsapp) ③環境名を入力 Enter a name for the environment (dev) ④使用エディタを選択 > Visual Studio Code ⑤言語を選択 > javascript ⑥フレームワークを選択 > react ⑥ソースディレクトリを入力 Source Directory Path: (src) ⑦ディストリビューションディレクトリを入力 ※outに書き換える（デフォルトだとbuild） Distribution Directory Path: out ⑧ビルドコマンドを入力 Build Command: (npm.cmd run-script build) ⑨スタートコマンドを入力 Start Command: (npm.cmd run-script start) ⑩AWSプロファイルを使用する > AWS profile ⑪先ほど作成したプロファイルを選択 > AmplifyProfile 以上でプロジェクトの作成、Amplifyの組み込みが完了しました。 お疲れ様です！ 7. ソースコードの管理 コードの管理はCodeCommitを利用します。 CodeCommitは簡単に言うとAWS上で使えるGitHubのようなものです。 役割としては同じものになります。 リポジトリの作成とプッシュ ①git-remote-codecommit (GRC)をインストール CodeCommitを扱うためのツールです。pythonがインストールされている必要があります。 pip install git-remote-codecommit ②リポジトリを作成 aws codecommit create-repository --repository-name nextjs_app ③リポジトリの確認 CodeCommitでリポジトリが作成されていることを確認します。 ④リモートリポジトリ追加 git remote add origin codecommit::ap-northeast-1://nextjs_app ⑤プロジェクトのソースをプッシュ git push origin HEAD ⑥（再）リポジトリの確認 CodeCommitでソースがアップされていることを確認します。 これでCodeCommit上でソースの管理ができるようになりました。 お疲れさまです。 8. ソースのホスティング Web上に今回作成したソースを公開します。 ①FrontEnd Frontend environments タブを選択 ②AWS CodeCommit を選択 ③Connect branch を押下 ④リポジトリ:nextjs_appを選択 ⑤ブランチ:mainを選択 ⑥次へを押下 ⑦Create New Role を押下 新しいタブが開きロール作成画面が表示されます。（次へ の押下だけなので画像省略） ⑧次のステップ: アクセス権限　を押下 ⑨次のステップ: タグ　を押下 ⑩次のステップ: 確認　を押下 ⑪ロールを作成　を押下 ロール作成後、元のページに戻って操作をします。 ⑫devを選択 ⑬Refresh existing roles を押下 ⑭amplifyconsole-backend-role を選択 ⑮チェックを入れる ⑯次へ を押下 ⑰保存してデプロイを押下 デプロイには少し時間がかかるので少々お待ち下さい ⑱サイトの確認 Next.jsのプロジェクトページが表示されれば、ホスティング完了です。 以上で全行程完了です。本当にお疲れさまでした！ あとはNextjsを思う存分楽しみましょう。 9. おわりに NextjsもAmplifyもコマンドを打つだけで簡単に環境を構築できるのでとても便利だなと思いました。 技術の進歩は目覚ましいです！ 拙い記事でしたがここまで閲覧いただきありがとうございます。 今後も新しい技術に触れることがあればまた筆を取ると思いますのでよろしくおねがいします。 以上、したらば！

1. はじめに オンプレミスからクラウドへのシステム移行を計画する場合、「データベースの移行」は重要な検討項目の１つになります。この記事では、データベースをAWSへ移行する際に検討すべき以下のポイントについて、主にOracle Databaseの移行を想定して記載してみます。 検討ポイント1：DBMSの選定 検討ポイント2：マネージド型サービスの利用可否 検討ポイント3：サイジング 検討ポイント4：コスト 検討項目は移行対象システムによって様々なので、すべてを網羅できているわけではないですが、検討の参考にしていただければと思います。 2. AWSでのRDBの利用 検討ポイントの前に、AWSでRDBを利用する場合に利用可能な構成をまとめます。 (1) EC2にDBMSを導入する構成（IaaS型） 仮想サーバサービスのEC2（OSはWindows, Linuxから選択）に、利用者がライセンス調達したDBMSを導入して利用します。自由度は高く、オンプレミスとほぼ同等の構成を実現することが可能ですが、OSやDBMSの設計・構築や管理・運用は利用者自身が実施する必要があります。 (2) RDS（マネージド型のDBサービス）を利用する構成 RDSは、AWSが提供するOSとDBMSが導入済みのDBサーバを利用できるサービスです。RDBMSとして商用DB（Oracle Database, SQL Server）、OSS DB（MySQL, PostgreSQL, MariaDB）、およびクラウドに最適化されたAurora（MySQL互換, PostgreSQL互換）を利用することができます。商用DBのいくつかのエディションでは、AWSが提供するライセンスを使用することも可能です。 RDSでは、OSの管理やDBMSの製品管理（パッチ適用など）をAWSが実施し、利用者はDBのスキーマ以上のレイヤを管理・運用します。高可用化構成やバックアップ/リストアなどで、AWS提供の機能を利用することで容易に構成することができます。 ただし、RDSではOSへのアクセス不可や非サポートのDBMS機能があるなど、様々な制限があります。詳細はRDSのマニュアルを確認してください。 (3) サードパーティが提供するDBMSサービスを利用する構成（PaaS型） サードパーティがAWS内に構築したDBサーバをPaaS型で提供するサービスを利用します。例えば（手前味噌ですが）日立製作所のHiRDB Cloud Serviceのように、RDSには含まれないDBMSをPaaS型で利用することも可能です。 3. AWSへのDB移行での検討ポイント 以下では、データベースをAWSへ移行する際の検討ポイントを挙げてみます。 検討ポイント1：DBMSの選定 クラウドへのDB移行でも、DBMSは変更せず、同一DBMSの最新バージョンへのバージョンアップのみ実施することがほとんどと思います。ただ、長期的なコスト低減を目的に商用DBからOSS DBへ変更するなど、DBMSの変更を希望するケースもあります。 DBMSを変更する場合、アプリケーションの改修が必要になります。開発・テストフェーズにおいて、必要な機能がなかったり、SQLが想定通りに動作しないなどのトラブルが発生するリスクもありますので、計画時に十分な検討を行う必要があります。 例として、Oracle Database / MySQL / PostgreSQLの主な機能差異について、下の表にまとめてみました。これら以外にも、組み込み関数などDBMS間には多くの差異がありますので、使用する機能については各DBMSのマニュアルをご確認ください。また、Oracle DatabaseからPostgreSQLへの移行について、よく発生する課題とその対応方法がAWSのブログ記事にまとめられており、こちらも参考になります。 比較項目 Oracle Database MySQL (InnoDB) PostgreSQL アーキテクチャ（*1） 更新型 更新型 追記型 チェック制約 あり あり（*2） あり シーケンス あり なし（自動インクリメント等で代替） あり シノニム あり なし なし マテリアライズドビュー あり なし あり NULL/空文字の区別 区別なし 区別あり 区別あり 利用可能なJOINアルゴリズム Nested Loop, Sort Marge, Hash Join Nested Loop, Hash Join（*3） Nested Loop, Sort Marge, Hash Join トランザクション commit/rollback必須、エラー時は対象SQLのみ自動rollback デフォルトはSQL 1文でトランザクション確定。start transactionで複数文に対応。エラー時は対象SQLのみ自動rollback デフォルトはSQL 1文でトランザクション確定。start transactionで複数文に対応。エラー時は対象トランザクション全体が自動rollback （*1）追記型アーキテクチャは、UPDATE実行時に元のレコードは更新せず、更新後データを別レコードに挿入します。DELETEでも同様に元レコードは保持します。トランザクションごとに対象レコードの参照先を切り替え、元レコードを参照するトランザクションがなくなったら、vacuum処理により元レコードを削除します。 （*2）MySQLでのチェック制約は、MySQL 8.0.16以降のバージョンで利用可能です。それ以前はトリガーなどで代替する必要があります。 （*3）MySQLでのHash Joinは、MySQL 8.0.18以降のバージョンで利用可能です。Aurora MySQL互換でのHash Joinの利用は、マニュアルを参照してください。 検討ポイント2：マネージド型サービスの利用可否 「2. AWSでのDBの利用」に記載したように、DBサーバの構成として、利用者が管理を行う構成とAWS/サードパーティが管理を行うマネージド型のサービスを利用する構成から選択できます。基本的には、構築・運用にかかるコストを低減できるマネージド型サービスの利用が推奨されますが、制約事項もありますので、要件に合致するかを事前に確認する必要があります。 以下に、Oracle Databaseを例として、2種類の構成の特徴や注意事項をまとめます。 Oracle Database on EC2 OSとそのバージョンを指定してEC2を作成した後、Oracle Databaseの導入の前提となる各種設定を実施したうえで、Oracle DatabaseのインストールやDB作成を実施します。 OS・DBMSの管理・運用は利用者が実施します。 オンプレミスとほぼ同等の構成が可能ですが、以下の点は注意が必要です。 Oracle Real Application Clustersは、AWSではサポートされません。 マルチAZのクラスタを構成する場合、EBSを共有ディスクとして使用できません。代替の方式として、サードパーティのノード間ミラーディスク製品やNFS/CIFSなどの利用の検討が必要です。 オンプレミスでストレージのディスクコピー機能（例：日立ストレージのShadowImage）を使用したバックアップ/リストアを実施している場合、AWSでは同様の方式は実現できません。RPO, RTOなどの要件に応じた方式の再設計が必要です。 RDS for Oracle RDS for Oracleは、Oracle Databaseのバージョン・エディションを指定して作成します。 RDS for Oracleでは、Oracle Real Application ClustersやAutomatic Storage Managementなどサポートされない機能があります。また、Data Guardのように一部の機能のみサポートされるケースもあります。移行元DBで使用している機能がRDS for Oracleでも使用できるかはマニュアルを参照していただき、サポートされない場合は代替方式の検討が必要です。 Oracle Databaseのパッチ適用は、AWSが動作確認したパッチセットを指定したメンテナンス時間帯に自動適用させることが可能です。個別パッチの適用はできません。また、必須のパッチがある場合は、期限を過ぎると強制的に適用されます。 高可用化（別AZでのスタンバイDB/リードレプリカの作成）、バックアップ/リストアなどの運用機能は数クリックで実装可能です。 RDS for Oracleのディスク（データファイルやログを格納する領域）は、インスタンスを作成したAZ内で2重化されて保存されます。また、ディスク容量は最大64TiBです。 RDSのOSへはアクセスできません。既存システムでDBサーバ上で実行していた運用スクリプトは別サーバからリモート実行するなどの対応が必要です。 Oracle Databaseのビルドインの管理者アカウント（sys, system）は使用することはできません。代替の管理者アカウントを作成し、RDS向けの管理コマンドを使用する必要があります。 検討ポイント3：サイジング (1) CPU・メモリのサイジング EC2, RDSともに、AWS提供のインスタンスタイプからCPUタイプおよびCPU・メモリサイズの組み合わせを選択します。サイジングでは移行元DBサーバでのリソース割当量・使用率を元に必要リソースを見積ります。移行元で稼働統計情報を取得し（Oracle DatabaseではAWRで取得可能）、使用状況を確認してください。また、事前に性能テスト（性能検証PoC）を行い、リソース見直しを実施してください。 EC2では汎用・メモリ最適化・コンピューティング最適化などすべてのタイプ選択可能です。RDSでは、DBMSによっても異なりますが、DB用途に適した以下の3種類のインスタンスクラスから選択します。（EC2はインスタンスタイプで、RDSはインスタンスクラスという呼び方なんですね。） RDSのインスタンスクラス 説明 汎用クラス（mクラス） vCPU数とメモリ容量(GB)が1:4の比率の組み合わせの構成 メモリ最適化クラス（r, x, zクラス） vCPU数とメモリ容量(GB)が1:8の比率の組み合わせの構成 バースト可能クラス（tクラス） vCPUの数%～数10%を上限とするベースライン性能を使用可能。CPU使用率がベースライン以下なら、その差分をクレジットとして蓄積し、必要な場合にベースラインを越えてCPU性能を利用可能（バースト利用）な構成 インスタンスタイプを選択・変更する場合は、以下の点に注意が必要です。 デフォルトではCPUのハイパースレッドが有効のため、vCPU=2コアは物理CPU=1コアに相当します。既存サーバのCPU割当量を元にサイジングする場合は注意してください。 バースト可能クラスは、クレジットの蓄積状況によって最大性能が変動します。利用条件に合致する場合を除き、本番環境では使用しないことを推奨します。 Graviton2などのARMプロセッサでは他のプロセッサと単純な性能比較はできませんので、本番環境で使用する場合は必ず性能テストを実施してください。 リソースをスケールアップ/ダウンする場合は、DBの再起動が必要です。 (2) ディスクのサイジング ディスクは、容量要件と性能要件に合わせて設定してください。EC2では、複数の種別・性能のディスクを柔軟に併用することが可能です。RDSやAuroraでは、以下の表から1つの種別のディスクを選択して使用します。 サービス ディスク種別 説明 RDS（Aurora以外） マグネティック HDDディスクで、容量自動拡張は非サポートです。最大3TiB、1000 IOPSの制限があります。下位互換性のために存在しており非推奨です。 汎用SSD SSDディスクで、容量自動拡張をサポートします。ベースライン性能は1GiBあたり3 IOPSで、最小1,000 IOPS～最大16,000 IOPSです。容量1TiB未満では、クレジットの蓄積により最大3,000 IOPSのバーストが可能です。 プロビジョンドIOPS SSDディスクで、容量自動拡張をサポートします。I/O性能値としてIOPSを指定可能です。最大IOPSはDBMSやインスタンスクラスによって異なるのでマニュアルを参照してください。プロビジョンドIOPSのコストは割当容量に加え、指定したIOPS値に応じたコストが発生します。 Aurora - SSDディスクで、容量自動拡張をサポートします。容量・性能値は事前に設定せず、実データの格納容量・I/O量によりコストが発生します。Auroraではディスク仕様は決まっており設定項目はありません。 ディスクサイジングする場合は、以下の点に注意が必要です。 RDSでの最大ディスク容量（マグネティックを除く）はSQL Serverで16TiB、SQL Server以外では64TiBです。Auroraでの最大ディスク容量は128TiBです。 RDSでディスク種別はオンラインで変更することが可能です。ただし、変更処理中は性能に影響があります。 検討ポイント4：コスト DB移行に関係するコストは以下の3種類に分類できます。 DBのリソース、ライセンスにかかるコスト DBの構築・テストおよび稼働後の運用にかかるコスト DBを利用するアプリケーションの改修・テストにかかるコスト 2, 3点目のコストは、移行対象システムごとに大きく異なりますので、個別に見積もってください。 1点目のコストについて、商用DBではオンプレミスとクラウドでライセンスの考え方が異なることがあるため、注意が必要です。例として、Oracle Databaseのプロセッサライセンスの場合、AWSでは「コア係数」の考え方がないなどの差異があり、AWSへの移行によりコスト増となるケースがあります。正式にはAWSの「Oracle のよくある質問」や、Oracleの「クラウド・コンピューティング環境における Oracle ソフトウェアのライセンス」に記載の内容を確認していただいたり、購入元に確認して見積もりを行ってください。 4. 最後に データベースをAWSへ移行する際の検討すべきポイントを4点あげてみました。これらのポイントに加え、各システムに固有の要件に応じた検討を実施してください。 これらの検討によりDBサーバの構成を決定し、その後にDBの環境設計・運用設計・移行設計を行って、詳細を詰めていくことになります。DBの移行方式については別の記事にまとめますので、こちらも参考にしていただければと思います。

１．はじめに 　オンプレミスのシステムをAWSへ移行する際、ゲートウェイ型IPS（IDS/IPS）をどのようにAWSへ移行するかが課題となることがありました。その理由としては、 ・AWSではホスト型の事例が多く、ゲートウェイ型の国内事例が少ない ・AWSでゲートウェイ型IPSを構成するには、複雑な制御が必要だった(2021年1月以前) などが考えられます。 　しかし、2021年2月に東京リージョンにてサポートされたGateway Load Balancer(以下GWLBと略す)を使うことで、以前よりシンプルに構成が組めるようになりました。本資料では、GWLBを使ってAWS上でゲートウェイ型IPSを構成・動作させる方法を解説します。 　本記事は、GWLBの基本が分かっている人を想定して書いています。GWLBについて初めての人は次の参考資料を最初に読まれると良いと思います。本記事がIPSのAWS移行を検討する際に参考になれば幸いです。 ＜補足＞ 　2021年にAWS Network Firewallが新サービスとしてリリースされました。このサービスの中にIPSが含まれていますが、2021年7月時点ではこのサービスに含まれるIPSについては、ユーザ側でIPSルールを定義・管理する必要があります。常に最新のルールを手動管理するのは現実的な運用ではないと個人的には考えています。将来的に、このサービスに対しサードパーティによるIPSルール提供が自動化されるようになれば、最初からこのサービスへ移行するようになる可能性があります。残念ながら、現時点では採用が難しいと判断しています。 （参考資料１） 　　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ 　　　GWLBの概要からルーティングまで詳しく解説されていて参考になりました。 （参考資料２） 　　AWS Gateway Load Balancerの紹介：サポートされているアーキテクチャパターン （参考資料３） 　　AWS Gateway LoadBalancerを使用したネットワークトラフィック検査のスケーリング （参考資料４） 　　Gateway Load BalancerとTransit Gatewayを使用した一元化された検査アーキテクチャ 　　　GWLBの動作の詳細が説明されていて参考になりました。 ２．GWLBの概要 　GWLBは以下の特徴を持っており、GWLBを使うことでAWS上のゲートウェイ型IPSがシンプルに構成出来るようになりました。 ・ネットワークに透過 ・冗長化、スケールが簡単 ・リソース共用が可能 　2020年以前は、AWS上でゲートウェイ型IPSを導入するには、複雑な設計・構築が必要だったようです。例えば図2.1のように、IPS(図のfirewall）を冗長化するために死活監視をし、障害時にルートテーブルの書き換えを実装する必要がありました。 （図2.1) （参考資料１のスライド10より抜粋） 　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ 　他の例では、上記のようなルートテーブルの書き換えを不要にするために、VPNをVPC間で構成し、VPNを冗長構成にしBGPによる動的ルーティングを構成する方法がとられていました。 （図2.2) （参考資料１のスライド11より抜粋） 　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ 　他にもいろいろと課題があったようですが、次のようなサービスが拡充された結果、状況が改善しました。 2018年「AWS Transit Gateway」サービス発表 2019年「VPC Ingress Routing」サービス発表 2020年「AWS Gateway Load Balancer(GWLB)」サービス発表 それでは、キーとなるGWLBのサービス概要について図2.3を参照下さい。 （図2.3) （参考資料１のスライド12より抜粋） 　[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズ 再度掲載しますが、GWLBの特徴は次の3点だと思います。 ネットワークに透過 冗長化、スケールが簡単 リソース共用が可能 GWLBを使うことで、AWS上のゲートウェイ型IPSがシンプルに構成出来るようになりました。GWLBを使った基本的な構成や処理の流れについては、参考資料１[AWS Black Belt Online Seminar]AWS Gateway Load Balancer サービスカットシリーズを参照下さい。こちらに詳しく書かれています。 本記事では、前述の資料には記載されていない、複雑な構成について解説します。 ３．構成のポイント 　今回の構成を説明する前に、構成のポイントを3点あげさせて頂きます。 可用性 　IPSをAWS上へ導入する際、可用性の確保が大切です。1台のIPSだけで構成した場合、その1台に障害が発生した場合、通信が一切出来なくなりIPSを使っている全システムが停止します。このようなことが起きないよう複数台のIPSにて構成します。さらにAZ障害時にもIPSを稼働させるためには、マルチAZ構成が必要です。　 集中ルーティング 　IPSによる検査には大きく分けると２種類あります。１つはインターネットと内部システム間の通信(南北通信)の検査、もう１つは内部システム間の通信(東西通信)の検査です。この東西、南北、2種類の検査を一元的に対応できる構成にするためにTransit Gatewayを使って集中ルーティングします。 拡張性 　AWS社のリファレンスアーキテクチャの資料を参考にし、インターネットからのインバウンド通信、インターネットへのアウトバウンド通信、検査と各業務毎にVPCを分離しています。このようにすることで業務を拡張する際の構成変更をやり易くしています。 　以上の３つのポイントを満たす構成を次の章から説明します。 ４．構成図 　移行前のオンプレミスのサンプル構成を（図4.1）に示します。この構成図では主に３つの処理を表しています。 　（１）ユーザーがインターネットからWebサーバへアクセス時に検査します 　（２）WebサーバがProxyサーバ経由でインターネットへアクセス時に検査します 　（３）イントラネットの運用管理者が内部ネットワークへアクセス時に検査します （図4.1） オンプレミスからAWSへ移行する場合、次の表のようにAWSの各サービスへ移行することができます。 NO 移行前（オンプレミス） 移行後（AWSのサービス） 1 外部Firewall兼IPS Gateway Load BalancerとEC2（IPS） 2 Load Balancer Application Load Balancer 3 Webサーバ EC2（Webサーバ） 4 運用管理サーバ EC2（運用管理サーバ） 5 Proxyサーバ NAT Gateway 6 内部Firewall兼IPS Gateway Load BalancerとEC2（IPS） 7 ネットワーク Transit GatewayとDirect Connect 　（図4.1）のようなオンプレミスの構成をAWS移行し、さらにAZ障害にも対応し、東西・南北2種類の検査に対応したゲートウェイ型IPSの構成例を（図4.2）に示します。 （図4.2） この構成の特徴は以下です。 Inbound VPCにGWLBとApplication Load Balancer(ALB)を配置します GWLB Endpointの配置が自由なため、入り口にて検査が可能です 業務システムとVPCを分離することでインターネットからの攻撃が直接業務システムへ届かないようにします Inspection VPCは、IPSのEC2とGWLBを配置し，ここのIPSにて全ての検査を実施します IPSを共用することができ、管理コスト、リソースコストの削減が期待できます VPC間の通信をTGWに集中させ，TGWからInspection VPCへルーティングします データセンタやイントラネットなどAWS外部からの通信時の検査します VPC間の通信についても検査を可能にします Inbound VPCからWorkload VPC間の通信時は、二重検査をしないように制御します Outbound VPCは共用NAT gateway(NATGW)としてVPCを分離します　 VPC毎にNATGWを配置した場合、セキュリティの抜け穴になるリスクがある。それを回避します NATGWを共用することができ、コストの削減が期待できます Workload VPCは、業務システムを配置します 例えば、情報配信サイト、ショッピングサイト、営業支援システムやそのデータベースなどをこのVPCへ配置します。また必要に応じて、Workload VPCは複数VPCとして構成することも可能です。各VPCをTGWへ接続することで、IPSによる検査を追加することが可能です。 Operation VPCは、運用管理サーバを配置します AWS内のEC2は、運用管理サーバからのみ接続可能にします オンプレミスからは直接はWorkload VPCなどのEC2へ接続出来ないようにします 　以上のように用途毎にVPCを分離することで、拡張性を維持しながらIPSを導入できるように、今回の構成としました。 　参考までに（図4.2）を詳細化した構成とルートテーブル例を（図4.3）に示します。これらのルートテーブルの参照については次の章にて詳しく見ていきます。 （図4.3） ５．動作の解説 　それでは次の５つの処理パターンにおいて、どのように動作するのかを順番に説明していきます。 （１）インターネットからVPC内へのインバウンド通信を検査 （２）VPC内からインターネット上のパッチダウンロード時に検査 （３）VPC間の通信時に検査 （４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査 （５）マルチAZ構成において、IPSをAZ間で負荷分散・リソース共有 （１）インターネットからVPC内へのインバウンド通信を検査 　（図5.1）を使って①から⑲までの処理の流れを説明します。 （図5.1) ①一般ユーザは、Application Load Balancer (ALB)のDNS名に対してアクセスします。Internet gateway(IGW)からInbound VPCへ通信パケット（パケット）が入ります。 ②Inbound VPCのIngress ルートテーブルを参照します。この時点でパケットの宛先IPアドレスは、ALBのDNS名から返されたプライベートIPアドレスに変換されています。宛先IPアドレスに該当するTargetのGWLB Endpoint(GWLBE)#1へルーティングします。 ③GWLBE#1は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。 ④GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。 ⑤IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査後、GWLBへ返します。 ⑥GWLBは元のGWLBE#1へパケットを返します。 ⑦GWLBE#1は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるALBへパケットを転送します。 ⑧ALBは登録されているバックエンドのIPアドレスまたはEC2インスタンスへ負荷分散させ、データを送信します。バックエンドのIPアドレスへパケットを転送する際、このサブネットのルートテーブルを参照します。 ⑨バックエンドのIPアドレスに該当するルーティング先としてTransit Gateway(TGW)を入手します。 ⑩TGWへパケットを転送します。この際のパケットの送信元IPアドレスはALBのプライベートIPアドレスです。 ⑪Inbound VPCにアタッチしたTGWのルートテーブルには、Workload VPC宛のCIDRについては、Workload VPCのアタッチメントへルーティングするように記載しておきます。これにより、Workload VPCへパケットがルーティングされます。図に記載していないが、実際にはWorkload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、Webサーバへパケットが転送されます。 ⑫Webサーバにて処理後、送信元のALBへデータを返します。Workload VPC内のルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。 ⑬Workload VPCにアタッチしたTGWのルートテーブルには、Inbound VPC宛のCIDRについては、Inbound VPCのアタッチメントへルーティングするように記載しておきます。Inbound VPC内で検査を行うため、Inspection VPCにルーティングはさせません。これにより、Inbound VPCへパケットがルーティングされます。図には記載していませんが、Inbound VPCのTGW ENIが接続されたサブネットのルートテーブルによって、ALBへパケットが転送されます。 ⑭ALBは戻ってきたパケットから、元々の送信元のパブリックIPアドレスへ宛先を戻します。ALBを配置したサブネットのルートテーブルを参照します。 ⑮ルートテーブルの宛先0.0.0.0/0に対するルーティング先はGWLBE#1を記載しておきます。 ⑯ALBはGWLBE#1へパケットを転送します。 ⑰GWLBE#1は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。 ⑱GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。 ⑲IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査後、GWLBへ返します。 ⑳GWLBは元のGWLBE#1へパケットを返します。 ㉑GWLBE#1は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるパブリックIPアドレスへパケットを転送します。このサブネットのルートテーブルを参照します。 ㉒ルートテーブルの宛先0.0.0.0/0に対するルーティング先はInternet gateway(IGW)を記載しておきます。これによりIGWへパケットが転送されます。 ㉓IGWから依頼元にパケットが戻ります。 以上で”（１）インターネットからVPC内へのインバウンド通信を検査”についての説明を終わります。特徴は、行きのパケットと帰りのパケットの２回検査する点です。 （２）VPC内からインターネット上のパッチダウンロード時に検査 （図5.2）の①から⑲までは、サーバからインターネットに出るまでの処理の流れです。インターネットからサーバに戻るまでの処理は次の（図5.3）にて説明します。 （図5.2） ①Webサーバからインターネット上のサイトへアクセスします。Workload VPC内のルートテーブルを参照します。 ②ルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。 ③WebサーバからTGWへパケットが送信されます。 ④Workload VPCにアタッチしたTGWのルートテーブルには、Inbound VPC以外のCIDR宛先については、Inspection VPCのアタッチメントへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。 ⑤Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。 ⑥ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。 ⑦GWLBE#3へパケットを転送します。 ⑧GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。 ⑨IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。 ⑩GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。 ⑪ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。 ⑫TGWへパケットが転送されます。 ⑬Inspction VPCにアタッチされたTGWのルートテーブルにて、インターネット宛先の通信はOutbound VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがOutbound VPCへ転送されます。 ⑭Outbound VPCのTGW ENIのサブネットのルートテーブルを参照します。 ⑮ルートテーブルには、インターネット宛先の通信はNATGWへルーティングするように記載しておきます。 ⑯NATGWへパケットが転送されます。 ⑰NATGWのサブネットのルートテーブルを参照します。 ⑱ルートテーブルには、インターネット宛先の通信はInternet gateway(IGW)へルーティングするように記載しておきます。 ⑲インターネットへパケットが転送されます。 次は、パケットがインターネットから戻ってきてからの動作を（図5.3）にて説明します。 （図5.3） ①インターネットから戻ってきたパケットがNATGWに届きます。 ②NATGWのサブネットのルートテーブルを参照します。 ③ルートテーブルには、送信元（Webサーバ）宛先の通信はTGWへルーティングするように記載しておきます。 ④パケットをTGWへ転送します。 ⑤TGWのOutbound VPCにアタッチされたルートテーブルには、全ての通信はInspction VPCへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。 ⑥Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。 ⑦ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。 ⑧GWLBE#3へパケットを転送します。 ⑨GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。 ⑩IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。 ⑪GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。 ⑫ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。 ⑬TGWへパケットが転送されます。 ⑭Inspction VPCにアタッチされたTGWのルートテーブルにて、Workload VPC宛先の通信はWorkload VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがWorkload VPCへ転送されます。図には記載していませんが、Workload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、パケットが送信元（Webサーバ）へ転送されます。 以上で”（２）VPC内からインターネット上のパッチダウンロード時に検査”についての説明を終わります。特徴は、行きのパケットと帰りのパケットの２回検査する点です。 （３）VPC間の通信時に検査 　（図5.4）の①から⑬までは、送信元サーバから宛先サーバまでの処理の流れです。戻りの流れは（図5.5）にて説明します。 （図5.4） ①運用管理サーバからWebサーバへアクセスします。Operation VPC内のルートテーブルを参照します。 ②ルートテーブルには、Operation VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。 ③運用管理サーバからTGWへパケットが送信されます。 ④Operation VPCにアタッチしたTGWのルートテーブルには、全ての宛先については、Inspection VPCのアタッチメントへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。 ⑤Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。 ⑥ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。 ⑦GWLBE#3へパケットを転送します。 ⑧GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。 ⑨IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。 ⑩GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。 ⑪ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。 ⑫TGWへパケットが転送されます。 ⑬Inspction VPCにアタッチされたTGWのルートテーブルにて、Workload VPC宛先の通信はWorkload VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがWorkload VPCへ転送されます。図には記載していませんが、Workload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、パケットが宛先（Webサーバ）へ転送されます。 次は、パケットが宛先（Webサーバ）から送信元（運用管理サーバ）へ戻ってくるまでの動作を（図5.5）にて説明します。 （図5.5） ①Webサーバから送信元（運用管理サーバ）へパケットが戻ります。Workload VPC内のルートテーブルを参照します。 ②ルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。 ③WebサーバからTGWへパケットが送信されます。 ④Workload VPCにアタッチしたTGWのルートテーブルには、Outbound VPC以外のCIDR宛先については、Inspection VPCのアタッチメントへルーティングするように記載しておきます。これによりInspection VPCのTGW ENIにパケットが転送されます。 ⑤Inspection VPCのTGW ENIのサブネットのルートテーブルを参照します。 ⑥ルートテーブルにて、全てのパケットをGWLBE#3へルーティングするように記載しておきます。 ⑦GWLBE#3へパケットを転送します。 ⑧GWLBE#3は、パケットをカプセル化し、GWLBへ送信します。GWLBは、バックエンドに登録されているIPS#1またはIPS#2へ負荷分散させてパケットを転送します。 ⑨IPS#1または#2には、GWLBに対応したIPSを稼働させておき、パケットを検査してからGWLBへ返します。GWLBは元のGWLBE#3へパケットを返します。 ⑩GWLBE#3は、GWLBから返ってきた通信パケットのカプセル化を解除します。GWLBE#3を配置するサブネットのルートテーブルを参照します。 ⑪ルートテーブルには、全てのパケットの宛先をTGWにルーティングするよう記載します。 ⑫TGWへパケットが転送されます。 ⑬Inspction VPCにアタッチされたTGWのルートテーブルにて、Operation VPC宛先の通信はOperation VPCのアタッチメントへルーティングするように記載しておきます。これによりパケットがOperation VPCへ転送されます。図には記載していませんが、Operation VPCのTGW ENIが接続されたサブネットのルートテーブルによって、パケットが送信元（運用管理サーバ）へ転送されます。 　以上で”（３）VPC間の通信時に検査”についての説明を終わります。特徴は、行きのパケットと帰りのパケットの２回検査する点です。 （４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査 　（図5.6）の①から㉓までを使って説明します。 （図5.6） ①アベイラビリティゾーンC（AZ-C)が障害で利用出来なくなったと仮定します。AZ-Cが障害の場合、ALBのヘルスチェックにて利用可能なAZ-D側のパブリックIPアドレスがDNSより返されると想定されます。そのため、一般ユーザがALBのDNS名に対してアクセスすると、IGWを通過した際にAZ-D側のサブネットのALBのプライベートアドレスへ変換されると想定されます。 ②Inbound VPCのIngress ルートテーブルを参照します。この時点でパケットの宛先IPアドレスは、ALBのDNS名から返されたAZ-D側のプライベートIPアドレスに変換されています。宛先IPアドレスに該当するTargetのGWLBE#2へルーティングします。 ③GWLBE#2は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。 ④GWLBは、AZ-C側が障害のため利用出来ない場合、ヘルスチェックにて健全なIPS#2へパケットを転送します。 ⑤IPS#2は、パケットを検査後、GWLBへ返します。 ⑥GWLBは元のGWLBE#2へパケットを返します。 ⑦GWLBE#2は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるALBへパケットを転送します。 ⑧ALBは登録されているバックエンドのIPアドレスまたはEC2インスタンスへ負荷分散させ、データを送信します。バックエンドのIPアドレスへパケットを転送する際、このサブネットのルートテーブルを参照します。 ⑨バックエンドのIPアドレスに該当するルーティング先としてTGWを入手します。 ⑩TGWへパケットを転送します。この際のパケットの送信元IPアドレスはALBのAZ-D側のプライベートIPアドレスです。 ⑪Inbound VPCにアタッチしたTGWのルートテーブルには、Workload VPC宛のCIDRについては、Workload VPCのアタッチメントへルーティングするように記載しておきます。これにより、Workload VPCへパケットがルーティングされます。図に記載していないが、実際にはWorkload VPCのTGW ENIが接続されたサブネットのルートテーブルによって、Webサーバへパケットが転送されます。 ⑫Webサーバにて処理後、送信元のALBへデータを返します。Workload VPC内のルートテーブルには、Workload VPC以外のCIDRについては、全てTGWへルーティングするように記載しておきます。 ⑬Workload VPCにアタッチしたTGWのルートテーブルには、Inbound VPC宛のCIDRについては、Inbound VPCのアタッチメントへルーティングするように記載しておきます。これにより、Inbound VPCへデータがルーティングされます。図には記載していませんが、Inbound VPCのTGW ENIが接続されたサブネットのルートテーブルによって、AZ-D側のALBへデータが転送されます。 ⑭ALBは戻ってきたパケットから、元々の送信元のパブリックIPアドレスへ宛先を戻します。ALBを配置したAZ-D側のサブネットのルートテーブルを参照します。 ⑮ルートテーブルの宛先0.0.0.0/0に対するルーティング先はGWLBE#2を記載しておきます。 ⑯ALBはGWLBE#2へパケットを転送します。 ⑰GWLBE#2は、通過するパケットをカプセル化し、Inspection VPCに存在するGWLBへ転送します。 ⑱GWLBは、AZ-C側が障害のため利用出来ない場合、ヘルスチェックにて健全なIPS#2へパケットを転送します。 ⑲IPS#2は、パケットを検査後、GWLBへ返します。 ⑳GWLBは元のGWLBE#2へパケットを返します。 ㉑GWLBE#2は、GWLBから返ってきたパケットのカプセル化を解除し、元々の宛先であるパブリックIPアドレスへパケットを転送します。このサブネットのルートテーブルを参照します。 ㉒ルートテーブルの宛先0.0.0.0/0に対するルーティング先はIGWを記載しておきます。これによりIGWへパケットが転送されます。 ㉓IGWから依頼元にパケットが戻ります。 以上で”（４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査”についての説明を終わります。特徴は、正常なAZにパケットが転送される点と、行きのパケットと帰りのパケットの２回検査する点です。 （５）マルチAZ構成において、IPSをAZ間で負荷分散・リソース共有 　これは、今まで説明してきた（１）（４）の処理が、正常な複数AZにて同時に実施されることです。 （１）インターネットからVPC内へのインバウンド通信を検査 （４）マルチAZ構成のシステムにおいて、１つのAZ障害時に残ったAZにて検査 処理内容は（１）（４）と同じのため、省略します。 ６．まとめ 　今回は、ゲートウェイ型IPSをAWSへ移行した場合のアーキテクチャと処理の流れについて解説しました。実際のネットワーク設計については業務要件によって変わるとは思いますが、今回説明したGateway Load BalancerとTransit Gatewayによる通信制御を応用することで設計が出来ると考えます。 　もしかすると今回例示したルートテーブルの設定内容に誤りがある可能性があります。その場合はご了承下さい。最後まで読んで下さりありがとうございました。

Qiitaの記事であまり詳しい説明を見かけないので　ElasticBeanstalk の Time-based Scaling についてご紹介したいと思います。 Time-based Scaling とは ElasticBeanstalk では AutoScaling により、サービスへのアクセス増加に対して柔軟にリソースが追加される仕組みが備わっています。 しかし、AutoScaling では決められたCPU使用率などの閾値を超えない限りインスタンスの追加は行われないため、急激なアクセス増には上手く対応出来ないという欠点があります。 そこで登場したのが Time-based Scaling です。 あらかじめアクセス数の増加が予想できる場合、スケジュールを事前に登録しておくことで希望するインスタンス数を自動的に立ち上げておくことが出来ます。 普段10台で運用している環境で、19時を過ぎたら20台のインスタンスを用意したい、という場合には19時を過ぎたタイミングで不足分のインスタンスが自動的に立ち上がり、ロードバランサーに追加されます。 逆に24時を過ぎたら10台に戻したい、という場合もスケジュールを追加することで対応出来ます。 設定方法 マネージメントコンソールでの設定方法を簡単にご紹介します。 まず環境を選択し、「設定」を開きます。 「容量」の「編集」を押して編集画面を開きます。 よく使うのは AutoScaling の設定とスケーリングトリガーの部分ですが、画面の一番下に Time-based Scaling の設定メニューがあります。（日本語環境では「時間に基づくスケーリング」と表記） 「スケジュールされたアクションの追加」からスケジュールが追加出来ます。 インスタンスの最小数・最大数は指定した時間以降のAutoScalingの最小値・最大値を設定します。 希望する容量には必要なインスタンス数を設定します。 指定した時刻に起動しているインスタンス数と希望する容量とに差分がある場合、自動的にインスタンスの起動や停止が行われます。 頻度には1回限りか繰り返しが選べます。 通常は繰り返しを選択し、CRON式でスケジュールを指定することになると思います。 一定期間のみの適用であれば、開始時刻・終了時刻を指定して制御することも可能です。 「追加」を押すと先程のスケジュールの一覧に追加されます。 注意点 UTCベースなので時刻を間違えやすい CRON式を日本基準で書いてしまうと9時間ずれてしまいます。 また、曜日の指定なども注意が必要です。 スケジュールのリストにタイムゾーンの選択肢としてUTCとローカルがありますので、ローカルを選択して正しく設定されているかを確認するようにしましょう。 「適用」を押すまでは反映されない（スケジュールを変更した場合も同様） スケジュールは「適用」を押すまでは環境に反映されていません。 追加や変更をした後は必ず「適用」を押しましょう。 AutoScaling の設定にも注意 Time-based Scaling は指定した時間に希望した容量のインスタンスを確保する仕組みです。 あらかじめインスタンスを増加させていたとしても一定期間アクセスが無いと AutoScaling の設定に従って余分なインスタンスは停止されてしまいます。 もし、このようなケースが予想される場合はスケジュールで指定する最小値と希望する容量の値をそろえておくことで防ぐことができます。 まとめ スマートフォン向けのアプリではプッシュ通知やログインボーナスなどで急激なアクセス増加が定期的に起こりますが、AutoScaling だけではなかなか対処が難しい問題です。 もしこのような状況で悩まれている方がいたら Time-based Scaling を使ってみてください。

　本資料は、初めてCloudEndureを使ってオンプレミスまたはAWS以外のクラウドサービスからAWSへサーバを移行する人が、移行時間が実際に何分くらいかかるのかを検討する際の参考資料として作成しました。 　この検証はAWS内で実際にCloudEndure Migrationを使って、仮想マシンを移行し、その際の時間を測定しています。最大1TBのデータを移行していますので、移行時間の見積もりの参考になれば幸いです。 　また、この資料では移行を検討する際のポイントに絞って紹介しています。具体的な移行手順、前提条件、制限事項等についてはAWS社が公開しているドキュメントを参照下さい。　→　https://docs.cloudendure.com/ 　（参考情報） 　2021年5月から東京リージョンにて「AWS Application Migration Service」が利用可能です。このサービスはCloudEndure Migration と同様の機能を提供しますが、違いはAWS マネジメントコンソールで利用できます。さらに、AWS CloudTrail、Amazon CloudWatch、AWS Identity and Access Management (IAM) などの他の AWS のサービスとのシームレスな統合が可能になっているそうです。 　また、実際に「AWS Application Migration Service」を使って検証していないためあくまで推測になりますが、移行時間についてはCloudEndureと同等になると想定されます。 1.CloudEndureの特徴 　主な特徴をあげます。 切替直前までデータ同期を行うため、切り替え時のダウンタイムを短く出来る（最小数分） 元々は有償ツールだったが、AWSが買収し2019年１月から無償(※1)利用が可能。 従来AWSのサーバ移行ツールとして提供されていた「VM Import」「Server Migration Service(SMS)」による移行と比較し、少ない手順にて簡単に移行が可能。 日本国内（他社事例）において「CloudEndure」を使って数百台の移行事例あり。（海外では数万台の実績があるそうです） (※1)CloudEndure Migration自体は無償にて利用可能ですが、移行の為に利用するAWSリソース (例：後述のReplicationサーバ)や、移行後の仮想マシン(EC2)につきましては、従来通り課金されます。 2.対象者 対象読者：　AWSへのサーバ移行にかかわるエンジニア 前提知識：　オンプレミスでの物理サーバ移行、仮想サーバ移行の経験またはAWS認定クラウドプラクティショナー(初級レベル) 程度の知識を有していること 3.CloudEndure概要 　CloudEndureとは、AWSが提供するエージェント導入型の移行 / DR支援ソリューションです。 ソリューション概要 2018年末にAWS社がCloudEndure社を買収 エージェント導入型の移行、DRを実現(※1) 高速な切り替えを実現 移行ソリューション自体は無償利用が可能 インターネット接続が必須（可否判断要(※2)） ​ (※1) DRは別途有償ライセンスが必要となります ​ (※2) 認証付きプロキシが未サポート。ホワイトリスト登録にて対応必要。 　詳しくは次のドキュメントに詳しく解説されています。ご参照下さい。 　　Amazon Web Services ブログ 　　[AWS Black Belt Online Seminar] CloudEndure 資料及び QA 公開 　　https://aws.amazon.com/jp/blogs/news/webinar-bb-cloudendure-2020/ 　また、具体的な操作手順はAWS社のハンズオンが参考になります。 　https://application-migration-with-aws.workshop.aws/ja/server-migration.html CloudEndure Migrationの処理の特徴 仮想マシン全体を移行します。 CloudEndure エージェントが常駐し、データをReplicationサーバへ随時転送します。 移行先サーバは、仮想マシン全体の同期後、任意のタイミングで作成します。 4.検証概要 　CloudEndureを使って移行するための手順をまとめると次のようになります。詳細は公式ドキュメントを参照下さい。 　また、CloudEndureを使って移行する際には、次の点にご注意下さい。詳細は公式ドキュメントを参照下さい。 1．移行元サーバからAWSへのアウトバウンド通信必須（httpsと1500番ポート） 　（1500番ポートはDirect Connect またはVPN経由に変更は可能） 　補足：実際の環境では、1500番ポートを既存FireWallにて通すことは困難と想定。 　 詳しいネットワーク要件は、”付録．CloudEndureに関するFAQ”のQ:6を参照。 ２．認証付きのプロキシが現段階 (2021年3月)では使えません （インターネット直接続、認証無しプロキシまたはプロキシへホワイトリスト登録が必須条件） 補足：今回の検証ではプロキシを使用していないため問題になりませんでした。 しかし、実際のオンプレミス環境ではプロキシを経由することが一般的です。 ３．移行元サーバへエージェントインストールが必須 （CPU負荷や業務影響を心配しインストールが許可されないケースが想定されます） 　次に、今回の検証における構成の概要図を以下にしまします。 　今回の検証では、処理時間の傾向を把握するために３パターンのDISKサイズのVMを移行しました。 検証環境の構成 検証環境は、AWS 東京リージョン 移行元サーバは、ap-northeast-1aに配置 Replicationサーバ、移行先サーバは、ap-northeast-1cに配置 移行元サーバのインスタンスタイプは、 　t3.large(2コア、メモリ8GB)、 OSはWindows Server 2019 Replicationサーバのインスタンスタイプは、t3.small（デフォルト値） 各サーバのEBSは、汎用SSD（gp2）を使用 検証パターン別のEBSの割当とDISKの使用量は以下を参照。 検証パターン DISK1(使用/割当) DISK2(使用/割当) DISK3(使用/割当) 30GB 15GB/30GB なし なし 580GB 15GB/30GB 500GB/550GB なし 1130GB 15GB/30GB 500GB/550GB 500GB/550GB テストデータは、次のPowerShellスクリプトにて1GBのランダムテキストのファイルを作成し、このファイルを必要な容量分だけコピーしました。 $random_bin = new-object byte[] (1024*1024*1024); (new-object Random).NextBytes($random_bin); [IO.File]::WriteAllBytes("c:\temp\test.txt", $random_bin) テストデータ内容 5.検証結果 　CloudEndureを使って移行した場合の処理時間の測定結果は以下のようになりました。 起動時間は、１０分以内（DISKサイズが増えても変わらなかった） 初期同期時間は、DISK容量に比例 転送性能は、1.0GB/分以上 6.注意事項 　検証結果を参照する際には、次の点にご注意下さい。 1.初期同期の速度は、進捗率が進むほど悪化していました。今回の環境では16MB/秒～43MB/秒と差がありました。ただし43MB/秒のパターンは、途中までの初期同期時間しか測定出来なかったため、例外と判断下さい。傾向として同期開始から約150GBの転送までは、約50MB/秒の性能が出ていましたが、それ以降は徐々に性能劣化の傾向が見られました。 2.今回使用したEBSは、移行元、移行先ともに汎用SSD（gp2）です。 　　（550GBのEBSをDISK Read性能を測定した結果、200MB/秒以上出ていました） 3.移行元と移行先間のAZ間の通信性能は、実測60MB/秒以上出ていたため、 ネットワークがボトルネックではないと考えられます。 4.これとは別に２パターンテストを実施した結果では、約16MB/秒の初期同期の処理性能でした。 5.起動時間はインスタンス起動までの時間です。アプリ起動は別途必要です。 7.付録　CloudEndureに関するFAQ Q1: CloudEndureの実績はどれくらいありますか？メーカーはどこか？サポート体制は大丈夫か？ A: 2020年1月時点で、数万以上のサーバの移行実績があるときいています。メーカーのCloudEndure は、2018年末にAWSに買収され現在は AWS グループ企業。サポート体制は、EC2などと同様にAWSコンソールからAWS Supportへ問い合わせ可能です。問い合わせ時に日本語または英語かを選べます。 Q2: なぜCloudEndureを選択するのか？他の移行ツールは何があり、違いはなにか？ A: １番の理由は切替時のダウンタイムを短くすることができるためです。（目安は５分～１０数分）90日間は無償にて利用可能です。他のツールに対する優位性は、移行が高速（S3へのコピーが不要。データ転送時の圧縮。ブロックレベル複製）仮想サーバと物理サーバの両方に対応。操作がシンプルかつ少ない手順。他のツールとしては、Server Migration Service(SMS)、VM ImportがAWS社としてあります。また、AWS社以外からも移行ツールやサービスが出ています。 Q3: 価格は？前提条件や制限は？ A: CloudEndure Migration の各無料ライセンスは、エージェントのインストール後 90 日間使用できます。 CloudEndure Migration の使用は無料ですが、移行中と移行期間後にプロビジョニングされる、 コンピューティング(EC2)やストレージ(EBS)のリソースなどの AWS インフラストラクチャに対して料金が発生します。前提としては、対象サーバにエージェントがインストールされます。そのため、対象サーバに負荷が生じます。また、CloudEndure DRは有償です。 Q4: サポートOSは？ A:サポート対象の Windows と Linux OS のバージョンで実行されているすべてのアプリケーションとデータベースを移行できます。これには、Windows Server 2003/2008/2012/2016/2019 バージョン、および CentOS、RHEL、OEL、SUSE、Ubuntu、Debian といった Linux ディストリビューションが含まれます。 Q5: どのような移行方式なのか？ A: エージェント導入型の移行サービス。制御はCloudEndure 専用ポータルから行います。AWS側にReplicationServerが少なくとも1台構成されます。ここに移行元のデータが複製されます。データの複製後もリアルタイムで非同期で、データの同期を継続します。テストや本番時に、EC2を展開します。展開の際にAWS用に変換処理が実行されます。 Q6: インターネット接続は必須か？ 必要な場合の具体的な要件は？ A: 必須です。CloudEndureポータルはインターネット上にあり、そこへのOutBound通信が必要です。また、移行元からReplicationサーバーへのデータ伝送にインターネットを選択した場合には、ReplicationサーバーへのInbound通信も発生します。VPNやDirect ConnectでAWSへ接続する場合には、データ伝送時にインターネット接続は不要ですが、制御のためにCloudEndureポータルとの通信は必須です。具体的には、下図の破線円で示した①②③④がインターネット接続部分になります。 インターネットと接続する３か所（①②③）については次の通信要件があります。④についてはAWSのAPIを呼ぶためのユーザと権限等の設定が必要です。 ネットワーク要件の詳細は次の“CloudEndure Documentation”の“Network Requirements”を参照下さい。 Q7: エージェントの負荷による業務影響はどの程度か？ A: システムのパフォーマンスに目立った影響を与えることもありません（以前存在していたAWS社のHPより抜粋） Q8: エージェントのインストール後にOS再起動が必要か？ A: 不要です。 Q9: 切り替え時のダウンタイムはどの程度の時間が必要か？ A: Q2にも記載したが、5~10 数分が目安です。 Q10: 移行が出来ないような事例はありましたか？ A: 今回の検証ではありませんでした。ただ、EC2の制限により1台のインスタンスに20個程度までしかEBSを接続出来ません。そのためEC2の制限以上のDISKを1サーバに接続している場合は移行できません。移行元でDISK数を集約出来ればCloudEndureでの移行が可能になります。 　　参照　https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/volume_limits.html Q11: ユーザ側でする作業は何がありますか？ A: 主に以下の作業があります。 環境準備：インターネット接続のためのネットワーク変更、無償ライセンスの取得、AWSアクセスキー準備 移行対象の準備：移行対象の決定、エージェントのインストール、移行後の各種ライセンス準備 データ同期中：　進捗の確認 切り替え時：　移行対象の停止、移行に伴う各種設定変更、動作確認 Q12: どれくらいの移行期間が必要でしょうか？ A:　1台のサーバを移行するための時間は、主に次の要素で決まります。 移行元のDISK読み取り性能 移行元からReplicationサーバまでのネットワーク転送性能 ReplicationサーバのDISK書き込み性能 移行準備、テスト、本番までの待機時間 　CloudeEndureは、300台程度(※1)までは同時移行が管理可能なツールです。 　ネットワーク帯域の確保のうえ、複数サーバを並行移行することで、短期間で移行が可能です。 (※1)300台程度：CloudEndure内のプロジェクトを分けることでそれ以上の管理は可能 Q13: CloudEndureの利用期間（エージェントのインストール後90日間）は、サーバ単位か？ また、90日が過ぎた場合、移行は可能か？ A: 90 日の無料期間後、ユーザーのマシンではレプリケートが停止し、新しいターゲットマシンは起動できなくなります。90 日の無料期間内に移行を完了させることができなかった場合でも、新しい CloudEndure Migration アカウントを使用して該当するマシンに CloudEndure エージェントを再インストールすることにより、引き続き無料で移行できます。そうすることで追加の 90 日の無料期間中、レプリケーション、テスト、移行を実行できるようになります。 Q14: データの転送性能は？帯域制御等の機能がありますか？ A: データの転送性能は、16MB/秒～43MB/秒と検証結果はばらつきがありました。（例：1.1TBが19時間）また、ネットワーク帯域幅調整オプションを使用すると、ネットワークトラフィックを調整し、帯域幅の輻輳を最小限に抑えることができます。ソースマシンから TCP ポート1500のステージング領域に送信されるデータの転送速度を制御する場合は、このオプションを有効にします。データ転送速度は Mbps 単位で設定できます。設定は、 Setup & Info > REPLICATION SETTINGS. ページにて行います。詳しくは、次を参照下さい。 　 https://docs.cloudendure.com/#Defining_Your_Replication_Settings/Defining_Replication_Settings_for_AWS/Defining_Replication_Settings_for_AWS.htm Q15: データ転送が途中で中断した場合、途中から再開可能か？ A: ソースマシンのコンテンツのブロックレプリケーションが開始され、コンテンツがステージング領域にコピーされます。レプリケーション中は復旧ポイントが作成されるため、切断時に最後のポイントからレプリケーションを続行できます。 　　　　参照資料：https://docs.cloudendure.com/#FAQ/FAQ/Replication_Related.htm Q16: 物理サーバからAWSへ移行する場合、デバイスドライバーなどは自動調整されますか？ A:　本番用マシンの起動準備ができると、マシンは CloudEndure Migration によって自動的にソースインフラストラクチャから AWS インフラストラクチャへと変換され、AWS でネイティブに起動し、実行できるようになります。 Q17: 複数サーバの同時移行が監視可能とのことだが、どのような監視項目がありますか？ A:複製対象マシン名毎のDISK容量、DISK*複製の進捗率、DISK複製完了までの残り時間*、STATUS（(!)エラー有無、?注意必要/否、?データ複製完/未、?ターゲットコンピュータの起動完/未）と、Test mode／Cutover modeの状況が一覧で確認可能です。また、詳細画面ではターゲットコンピュータ作成後のインスタンスID、IPアドレス等が確認可能です。 Q18: CloudEndure MigrationとDisaster Recoveryとの違いは？ A: Migrationは90日の期間内でAWSへ移行するための一時的なツールです。一方のDisaster Recoveryでは、対象マシンをAWSにあるステージング領域にレプリケートし続けます。災害発生時には、数十分のうちに、完全にプロビジョニングされた状態の、数百台のマシンを自動で起動するように、CloudEndure Disaster Recovery を設定できます。また、DRサイトからメインサイトへのFailBackにも対応。 Q19: 移行がサポートされないアプリケーションやファイルシステム等、既知の制限がありますか？ A: CloudEndure Migration は、ERPパッケージや、一般的なデータベースもサポートしています。 既知の制限については、例えば次のような条件があります。 WindowsのGPT パーティションとDynamic ディスクをサポートしていません。 XFS5 ルートまたはブートファイルシステムを使用する Linux マシンはサポートされていません。 EC2の制限以上のDISKを接続している（通常は20個程度が上限）場合はサポートされません。 　サポートOSの詳細については、次を参照下さい。 　　　https://docs.cloudendure.com/#Getting_Started_with_CloudEndure/Supported_Operating_Systems/Supported_Operating_Systems.htm Q20: ツールの利用手順書やマニュアルが日本語でありますか？また、どこにありますか？ A: マニュアルは英語のみが現在提供されています（2021年2月時点）。 　　マニュアルは次のURLを参照下さい。 　　　　 https://docs.cloudendure.com/ 　　2021年7月現在、CloudEndureを使う前に、AWS Application Migration Service (AWS MGN) の利用が推奨されています。詳しくは次のURLを参照下さい。 　　　　 https://aws.amazon.com/jp/application-migration-service/ Q21: ツールの使い方やエラー時の問い合わせ先はAWS Supportか？それとも他にありますか？無償か？ A:　AWS Supportへ問い合わせ可能です。AWS Supportのプランに応じて費用が変わります（有償）。（CloudEndureのための追加費用はかかりません） 以上です。移行の参考になれば幸いです。

はじめに 「AWSでデプロイしたはいいけど、デザインを修正したくなったよー」という人に向けた記事です。 デプロイ後の修正を反映させるには masterにpushする まずはローカル環境で修正したファイルをGitHubのmasterブランチにpushします。 $ git push origin master git cloneしたディレクトリにpullする EC2インスタンスが開始されていることを確認してから、sshコマンドで接続します。 $ ssh -i 秘密鍵.pem ec2-user@ipアドレス デプロイ時にgit cloneしたディレクトリに移動してpullします。 $ git pull origin master アセットをプリコンパイルする 修正がCSSなどの場合、アセットファイルをプリコンパイルする必要があります。 簡単にいうと、JavaScriptやCSSのアセットを通信量削減のためにギュッとまとめる仕組みです。 開発環境ではこの仕組みが自動で働いてましたが、 本番環境では行われないため手動で行います。 $ rails assets:precompile RAILS_ENV=production インスタンスを再起動して確認 EC2インスタンスを再起動し、きちんと反映されていればオッケーです。

注意 この記事は Slack の在籍状況を DB 等に保存し、そこから勤務時間帯を分析するという企画です。 Slack では 1 つのアカウントで複数のワークスペースを管理することができるため、オンライン状態でも趣味のコミュニティにいた、なんてこともあります。 決して 「Slack がオンライン = 仕事している」ということではない ので、あくまで参考程度にお願いします。 目次 Part I: データ取得編 (Slack API) Part II: データ保存編 (AWS Lambda/CloudWatch) <- 今回はここ！ Part III: データ分析編 (AWS CloudWatch/スプレッドシート) 概要 今回は API を定期実行して結果を保存する仕組みを構築するセクションとなります。 今回は AWS のサービスを使用します。 Lambda で API を実行する関数を作り、それを CloudWatch で定期実行してログを出力、後に CloudWatch Logs Insights で解析を行う方針とします。 前提条件 AWS アカウントを持っている Python をインストールしている 手順 Lambda 関数を作成する Lambda -> Create function -> Author from scratch と選択し、関数名は slack-users-getPresence 、ランタイムは Python 3.8 を選択します。 パッケージを作成・アップロードする 今回は Python で簡単にリクエストを作成できる requests ライブラリ を Lambda にアップロードしてからコードを書きます。 ローカルにて好きなディレクトリを作成し、その中に移動しておいてください。 ディレクトリの中に requests ライブラリをインストールします。 pip install requests --target . lambda_function.py を作成し、以下のコードを書いておきます。 lambda_function.py import json def lambda_handler(event, context): # TODO implement return { 'statusCode': 200, 'body': json.dumps('Hello from Lambda!') } これらのパッケージを zip で圧縮します。コマンドで実行する方は以下を実行します。 作成したディレクトリを zip にするのではなく、ディレクトリの中身だけを zip にしてください！ zip -r ../package.zip . zip ができたら、 Lambda 側で作成した関数を開き、 Code タブから Upload from -> .zip file と進みます。 そして先ほどの zip をアップロードしてください。 関数を記述する lambda_function.py の中身を以下のように編集します。 lambda_function.py import requests import json def lambda_handler(event, context): # request url = 'https://slack.com/api/users.getPresence' headers = {'Authorization': 'Bearer xoxb-1234-56789abcdefghijklmnop'} payload = {'user': event['member_id']} r = requests.get(url, headers=headers, params=payload) r_json = r.json() # time tz = timezone(timedelta(hours=+9)) dt = datetime.now(tz) output = { 'time': dt.strftime('%Y-%m-%d %H:%M'), 'presence': r_json['presence'], } # to CloudWatch print(json.dumps(output)) return { 'statusCode': 200, 'body': json.dumps(output), } xoxb-* の部分をトークンに置き換えてください。 本来、トークンなどの情報は Secrets Manager 等で管理し、アクセスするのが安全かと思いますが、今回はコストを抑えて気軽に試していただくため、あえてベタ書きとしています。 Lambda の動作テストをする 関数を作成したら Deploy をクリックし、 Test タブに移動します。 テストイベントを作成する画面が出てきますので、以下のようにイベントを作成します。 W1234567890 は前回 Slack のプロフィールからコピーしたユーザ ID に置き換えてください。 { "member_id": "W1234567890" } Test ボタンをクリックしてテストしてみましょう。以下のような結果が表示されれば成功です！ アクティブ状態 { "statusCode": 200, "body": "{\"time\": \"2021-07-28 04:11\", \"presence\": \"active\"}" } 離席状態 { "statusCode": 200, "body": "{\"time\": \"2021-07-28 04:12\", \"presence\": \"away\"}" } Log output にも同様の結果が出力されていることを確認しておいてください。 CloudWatch に定期実行イベントを登録する CloudWatch へ移動し、左側のメニューから Events -> Rules と進み Create rule をクリックします。 設定項目は以下のように設定します。 Event Source Schedule Fixed rate of 1 Minutes Targets Lambda function Function*: slack-users-getPresence Configure version/alias: Default Configure input: {"member_id": "W1234567890"} Configure details をクリックして次へ進み、以下のように設定します。 Name: slack-presence-manager Description: How long does that boss work? Let's investigate. State: Enabled Create rule をクリックします。 作成が完了すると以下のようにリストに slack-presence-manager が追加されています。 定期実行イベントが動作していることを確認する 念のため 5 分ほど放置して、 CloudWatch の Log groups にログが出力されていることを確認しましょう。 Logs -> Log groups と進み、 /aws/lambda/slack-users-getPresence を選択します。 Log streams タブが選択されていることを確認し、 Search all をクリックすると、ログを見ることができます。 以下のように 1 分ごとに JSON 形式のログが出力されていれば成功です！ 次回予告 今回はここまでです。 次回は CloudWatch に蓄積されたログを集計し、いよいよ気になるあの上司が何時まで仕事をしているのか、視覚的に分析します。お楽しみに！ 勤務時間帯を分析する 本日のメインイベントです。 CloudWatch の Log insights でログを整形して CSV に変換した後、スプレッドシートに取り込んで日付を縦軸、時間帯を横軸にしたヒートマップのようなものを作ってみましょう。 ※この作業をするにあたり、 CloudWatch の定期実行イベントを数日動作させてログを蓄積させておくと有効な結果が得やすいかと思います。

概要 表題通り、Node.jsでDynamoDBを操作する記事です。 基本情報 操作TBL ディレクトリ構成 ~/develop/study/aws/node/dynamo $ tree . ├── crud │ ├── OlympicCreateItem.js │ ├── OlympicDeleteItem.js │ ├── OlympicGetItem.js │ └── OlympicUpdateItem.js ├── data │ └── olympicData.json └── migration ├── OlympicCreateTable.js └── OlympicLoadData.js 3 directories, 7 files 事前準備 TBL作成(OlympicCreateTable.js) var AWS = require("aws-sdk"); AWS.config.update({ region: "ap-northeast-1" }); var dynamodb = new AWS.DynamoDB(); var params = { TableName : "Olympic", KeySchema: [ { AttributeName: "Id", KeyType: "HASH"}, //Partition key { AttributeName: "Country", KeyType: "RANGE" } //Sort key ], AttributeDefinitions: [ { AttributeName: "Id", AttributeType: "N" }, { AttributeName: "Country", AttributeType: "S" } ], ProvisionedThroughput: { ReadCapacityUnits: 10, WriteCapacityUnits: 10 } }; dynamodb.createTable(params, function(err, data) { if (err) { console.error("TBL作成失敗：", JSON.stringify(err, null, 2)); } else { console.log("TBL作成成功：", JSON.stringify(data, null, 2)); } }); olympicData.json [ { "Id": 1, "Country": "日本", "Medal": { "GoldMedal": 11, "SilverMedal": 11, "BronzeMedal": 11 } }, { "Id": 2, "Country": "アメリカ", "Medal": { "GoldMedal": 10, "SilverMedal": 8, "BronzeMedal": 7 } }, { "Id": 3, "Country": "中国", "Medal": { "GoldMedal": 5, "SilverMedal": 5, "BronzeMedal": 5 } } ] TBL作成の実行結果 ~/develop/study/aws/node/dynamo/migration $ node OlympicCreateTable.js TBL作成成功： { "TableDescription": { "AttributeDefinitions": [ { "AttributeName": "Country", "AttributeType": "S" }, { "AttributeName": "Id", "AttributeType": "N" } ], "TableName": "Olympic", "KeySchema": [ { "AttributeName": "Id", "KeyType": "HASH" }, { "AttributeName": "Country", "KeyType": "RANGE" } ], "TableStatus": "CREATING", "CreationDateTime": "2021-07-29T10:20:05.059Z", "ProvisionedThroughput": { "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 10, "WriteCapacityUnits": 10 }, "TableSizeBytes": 0, "ItemCount": 0, "TableArn": "arn:aws:dynamodb:ap-northeast-1:696770525325:table/Olympic", "TableId": "5e5fb4bf-a314-496e-ad61-40387663f17f" } } データのロード(OlympicLoadData.js) var AWS = require("aws-sdk"); var fs = require('fs'); AWS.config.update({ region: "ap-northeast-1", }); var docClient = new AWS.DynamoDB.DocumentClient(); console.log("データのロード開始"); var Countries = JSON.parse(fs.readFileSync('../data/olympicData.json', 'utf8')); Countries.forEach(function(country) { console.log(country) var params = { TableName: "Olympic", Item: { "Id": country.Id, "Country": country.Country, "Medal": country.Medal } }; docClient.put(params, function(err, data) { if (err) { console.error("ロード失敗", country.Id, ". Error JSON:", JSON.stringify(err, null, 2)); } else { console.log("ロード成功:", country.Id + country.Country); } }); }); データのロード ~/develop/study/aws/node/dynamo/migration $ node OlympicLoadData.js データのロード開始 { Id: 1, Country: '日本', Medal: { GoldMedal: 11, SilverMedal: 11, BronzeMedal: 11 } } { Id: 2, Country: 'アメリカ', Medal: { GoldMedal: 10, SilverMedal: 8, BronzeMedal: 7 } } { Id: 3, Country: '中国', Medal: { GoldMedal: 5, SilverMedal: 5, BronzeMedal: 5 } } ロード成功: 3中国 ロード成功: 1日本 ロード成功: 2アメリカ CREATE文 OlympicCreateItem.js var AWS = require("aws-sdk"); AWS.config.update({ region: "ap-northeast-1", }); var docClient = new AWS.DynamoDB.DocumentClient(); var table = "Olympic"; var params = { TableName:table, Item:{ "Id": 4, "Country": "ドイツ", "Medal": { "GoldMedal": 7, "SilverMedal": 7, "BronzeMedal": 7 } } }; docClient.put(params, function(err, data) { if (err) { console.error("Unable to add item. Error JSON:", JSON.stringify(err, null, 2)); } else { console.log("Added item"); } }); READ文 OlympicGetItem.js var AWS = require("aws-sdk"); AWS.config.update({ region: "ap-northeast-1", }); var docClient = new AWS.DynamoDB.DocumentClient(); var table = "Olympic"; var params = { TableName: table, Key:{ "Id": 1, "Country": '日本' } }; docClient.get(params, function(err, data) { console.log(params) console.log(data) if (err) { console.error("Unable to read item. Error JSON:", JSON.stringify(err, null, 2)); } else { console.log("GetItem succeeded:", JSON.stringify(data, null, 2)); } }); UPDATE文 OlympicUpdateItem.js var AWS = require("aws-sdk"); AWS.config.update({ region: "ap-northeast-1", }); var docClient = new AWS.DynamoDB.DocumentClient() var table = "Olympic"; var params = { TableName:table, Key:{ "Id": 1, "Country": '日本' }, UpdateExpression: "set Medal.GoldMedal = :g", ExpressionAttributeValues:{ ":g":17, }, ReturnValues:"UPDATED_NEW" }; console.log("Updating the item..."); docClient.update(params, function(err, data) { if (err) { console.error("Unable to update item. Error JSON:", JSON.stringify(err, null, 2)); } else { console.log("UpdateItem succeeded:", JSON.stringify(data, null, 2)); } }); DELETE文 OlympicDeleteItem.js var AWS = require("aws-sdk"); AWS.config.update({ region: "ap-northeast-1" }); var docClient = new AWS.DynamoDB.DocumentClient(); var table = "Olympic"; var params = { TableName:table, Key:{ "Id": 4, "Country": 'ドイツ' }, }; console.log("Attempting a conditional delete..."); docClient.delete(params, function(err, data) { if (err) { console.error("Unable to delete item. Error JSON:", JSON.stringify(err, null, 2)); } else { console.log("DeleteItem succeeded:", JSON.stringify(data, null, 2)); } });

勉強前イメージ リザーブドインスタンス的なやつ？ 調査 Savings Plans とは 1年または、3年契約期間中、特定1時間あたりの使用量を契約することで、 その使用量に対して割引を受けられる料金体系です。 例えば、1時間20ドル使用する契約を購入した場合、以下の費用で使用することができます。 20ドルまでの使用量 → 大幅な割引が適応される 20ドル以上の使用量 → オンデマンドの費用 割引率はEC2インスタンスでは最大72%、Fargatreでは最大52%、 lambdaでは最大17%の割引を受けることができます。 Savings Plans のタイプ Compute Savings Plans 柔軟性があり、最大66%削減できるプランです。 インスタンスファミリーやタイプ、リージョンやOSに関わらずEC2インスタンスに適応されます。 EC2インスタンスだけでなく、Fargateやlambdaにも適応されます。 EC2からFargatehの移行へ関しても割引対象となります。 例としてCompute Savings Plansでの購入の画面になります。 期間と時間単位のコミット、支払いオプションを選択します。 EC2 Instance Savings Plans 特定のリージョン内の特定のインスタンスファミリーに適応されます。 最大の72%の割引が適応され、OSやサイズに関わらず自動でコストが削減されます。 リージョン間の移動やインスタンスファミリーの変更は対象外ですが、 リージョンとインスタンスファミリーさえ決まっていればお得なプランになります。 こちらはEC2のみで、Fargateとlambdaに関しては対象外になります。 以下が例としてEC2 Instance Savings Plansでの購入画面になります。 Compute Savings Plansとは違い、リージョンとインスタンスファミリーの選択肢が増えました。 リザーブドインスタンスとの違い Savings Plans と リザーブドインスタンスとの違い Savings Plans → 一定のリソースを一定時間使用する事 で、購入した分の割引を受けることができる。 リザーブドインスタンス → 特定のインスタンス・インスタンスファミリーを使用する事 で、購入した分の割引を受けることができる。 例えばSavings Plansで10ドルの契約をしていたとして、実際のEC2は20ドル毎時しようしていたとすると Savings Plans では割引を受けることができないが、 リザーブドインスタンス では、指定のインスタンスを使用していれば割引を受けることができます。 勉強後イメージ 一定の処理量を使用することで 割引を受けることができる のが Savings Plansってことか。 ただ、lambdaとかforgateとかも使用してるなら色々使えて良いかもしれない。 参考 柔軟に低価格でAmazon EC2を使用できる Savings Plansとは AWSのリザーブドインスタンスとは？適用のされ方や注意点について解説

はじめに 吐いて捨てるほど世間にあふれているansibleのインストールですが まともにやったことないので自分のためにメモとして残す。 インストール方法 によると。 epelリポジトリ追加 ansibleインストール の２手で終わるそうだ。。。はやい。 インストール手順 epel リポジトリを追加 #sudo amazon-linux-extras install epel　←AWS上で実行する場合はコッチを実行する # yum install epel-release ←後でわかるがこっちではうまくいかない ansible をインストール # yum install ansible やってみる epel リポジトリ追加前のリポジトリディレクトリを記念撮影 epelリポジトリ追加、いざやってみるとNGだった。 sudo amazon-linux-extras install epel AWSの場合は↑↑を実行することで同様のことができるようだ。 仕方ないので言われたとおりにやってみる。 無事終わったようだ。レポジトリをみてみる。 epel.repoとepel-testing.repo が増えた。 あと、amazon2-extras.repoの容量が増したっぽいぞ。 ansible インストール こちらは素直にyumだけでいけた！epelさすがです。 バージョン確認もちゃんとできてばっちりですね。 ansibleの最低限のセットアップ sshdの設定変更 これはsshクライアント側の話になるわけだけれども EC2にデフォルトで用意してもらっているsshdだと ・ssh接続の度にパスフレーズの確認をする っていう状態なのでこれをなんとかしたい。 によると、以下の要領で修正してあげたらよい。 /etc/ssh/sshd_config PermitRootLogin yes を PermitRootLogin without-password に修正 修正完了したら、sshdをリロード systemctl reload sshd.service ssh接続するにあたって、 1. 公開鍵は、~/.ssh/authorized_keyに追記していること 1. 秘密鍵は、~/.ssh/id_rsaで保管していること を確認したうえで、接続確認するときは ssh [ユーザ名]@[接続先IPアドレス] 今回の場合だと、、、 ssh ec2-user@172.19.176.92 結果がこちら。これで接続元からのssh接続確認（＝ansibleサーバからansibleサーバへのssh接続確認）は完了。 ansible-repoの作成 最低限というと語弊があるけど、実行環境はわかるようにしておく。 ホームディレクトリの配下に”ansible-repo"を作成する cd ~ mkdir ansible-repo cd ansible-repo hostsファイルの作成 ansibleで接続先を指定する場合、hostsファイルにあらかじめ登録されている必要がある。 このhostsファイルは通常、実行時のカレントディレクトリ上にあるhostsファイルを探すそうなので、 今回は実行環境であるansible-repo配下にhostsを置いておく。 あと、今は自サーバしかないので自サーバのIP（今回の場合だと172.19.176.97)を追記する。 実際の結果がこちら 試し打ち いろんな書籍ではplaybook.ymlをつくってどうのこうのと言っているが 実際はplaybook.ymlを作らなくても実行できる。 ってことでこれをやってみる。 ansible -i hosts <ip_address> -m ping ansible -i hosts 172.19.176.97 -m ping 結果がこちら。無事成功！ 脱線：/etc/ansible/ansible.cfgのデフォルト設定はどーなってるの？ せっかくなので、デフォルトの/etc/ansible/ansible.cfg を丸ごと残す。 [root@ip-172-19-176-97 ansible-repo]# cat /etc/ansible/ansible.cfg # config file for ansible -- https://ansible.com/ # =============================================== # nearly all parameters can be overridden in ansible-playbook # or with command line flags. ansible will read ANSIBLE_CONFIG, # ansible.cfg in the current working directory, .ansible.cfg in # the home directory or /etc/ansible/ansible.cfg, whichever it # finds first [defaults] # some basic default values... #inventory = /etc/ansible/hosts #library = /usr/share/my_modules/ #module_utils = /usr/share/my_module_utils/ #remote_tmp = ~/.ansible/tmp #local_tmp = ~/.ansible/tmp #plugin_filters_cfg = /etc/ansible/plugin_filters.yml #forks = 5 #poll_interval = 15 #sudo_user = root #ask_sudo_pass = True #ask_pass = True #transport = smart #remote_port = 22 #module_lang = C #module_set_locale = False # plays will gather facts by default, which contain information about # the remote system. # # smart - gather by default, but don't regather if already gathered # implicit - gather by default, turn off with gather_facts: False # explicit - do not gather by default, must say gather_facts: True #gathering = implicit # This only affects the gathering done by a play's gather_facts directive, # by default gathering retrieves all facts subsets # all - gather all subsets # network - gather min and network facts # hardware - gather hardware facts (longest facts to retrieve) # virtual - gather min and virtual facts # facter - import facts from facter # ohai - import facts from ohai # You can combine them using comma (ex: network,virtual) # You can negate them using ! (ex: !hardware,!facter,!ohai) # A minimal set of facts is always gathered. #gather_subset = all # some hardware related facts are collected # with a maximum timeout of 10 seconds. This # option lets you increase or decrease that # timeout to something more suitable for the # environment. # gather_timeout = 10 # Ansible facts are available inside the ansible_facts.* dictionary # namespace. This setting maintains the behaviour which was the default prior # to 2.5, duplicating these variables into the main namespace, each with a # prefix of 'ansible_'. # This variable is set to True by default for backwards compatibility. It # will be changed to a default of 'False' in a future release. # ansible_facts. # inject_facts_as_vars = True # additional paths to search for roles in, colon separated #roles_path = /etc/ansible/roles # uncomment this to disable SSH key host checking #host_key_checking = False # change the default callback, you can only have one 'stdout' type enabled at a time. #stdout_callback = skippy ## Ansible ships with some plugins that require whitelisting, ## this is done to avoid running all of a type by default. ## These setting lists those that you want enabled for your system. ## Custom plugins should not need this unless plugin author specifies it. # enable callback plugins, they can output to stdout but cannot be 'stdout' type. #callback_whitelist = timer, mail # Determine whether includes in tasks and handlers are "static" by # default. As of 2.0, includes are dynamic by default. Setting these # values to True will make includes behave more like they did in the # 1.x versions. #task_includes_static = False #handler_includes_static = False # Controls if a missing handler for a notification event is an error or a warning #error_on_missing_handler = True # change this for alternative sudo implementations #sudo_exe = sudo # What flags to pass to sudo # WARNING: leaving out the defaults might create unexpected behaviours #sudo_flags = -H -S -n # SSH timeout #timeout = 10 # default user to use for playbooks if user is not specified # (/usr/bin/ansible will use current user as default) #remote_user = root # logging is off by default unless this path is defined # if so defined, consider logrotate #log_path = /var/log/ansible.log # default module name for /usr/bin/ansible #module_name = command # use this shell for commands executed under sudo # you may need to change this to bin/bash in rare instances # if sudo is constrained #executable = /bin/sh # if inventory variables overlap, does the higher precedence one win # or are hash values merged together? The default is 'replace' but # this can also be set to 'merge'. #hash_behaviour = replace # by default, variables from roles will be visible in the global variable # scope. To prevent this, the following option can be enabled, and only # tasks and handlers within the role will see the variables there #private_role_vars = yes # list any Jinja2 extensions to enable here: #jinja2_extensions = jinja2.ext.do,jinja2.ext.i18n # if set, always use this private key file for authentication, same as # if passing --private-key to ansible or ansible-playbook #private_key_file = /path/to/file # If set, configures the path to the Vault password file as an alternative to # specifying --vault-password-file on the command line. #vault_password_file = /path/to/vault_password_file # format of string {{ ansible_managed }} available within Jinja2 # templates indicates to users editing templates files will be replaced. # replacing {file}, {host} and {uid} and strftime codes with proper values. #ansible_managed = Ansible managed: {file} modified on %Y-%m-%d %H:%M:%S by {uid} on {host} # {file}, {host}, {uid}, and the timestamp can all interfere with idempotence # in some situations so the default is a static string: #ansible_managed = Ansible managed # by default, ansible-playbook will display "Skipping [host]" if it determines a task # should not be run on a host. Set this to "False" if you don't want to see these "Skipping" # messages. NOTE: the task header will still be shown regardless of whether or not the # task is skipped. #display_skipped_hosts = True # by default, if a task in a playbook does not include a name: field then # ansible-playbook will construct a header that includes the task's action but # not the task's args. This is a security feature because ansible cannot know # if the *module* considers an argument to be no_log at the time that the # header is printed. If your environment doesn't have a problem securing # stdout from ansible-playbook (or you have manually specified no_log in your # playbook on all of the tasks where you have secret information) then you can # safely set this to True to get more informative messages. #display_args_to_stdout = False # by default (as of 1.3), Ansible will raise errors when attempting to dereference # Jinja2 variables that are not set in templates or action lines. Uncomment this line # to revert the behavior to pre-1.3. #error_on_undefined_vars = False # by default (as of 1.6), Ansible may display warnings based on the configuration of the # system running ansible itself. This may include warnings about 3rd party packages or # other conditions that should be resolved if possible. # to disable these warnings, set the following value to False: #system_warnings = True # by default (as of 1.4), Ansible may display deprecation warnings for language # features that should no longer be used and will be removed in future versions. # to disable these warnings, set the following value to False: #deprecation_warnings = True # (as of 1.8), Ansible can optionally warn when usage of the shell and # command module appear to be simplified by using a default Ansible module # instead. These warnings can be silenced by adjusting the following # setting or adding warn=yes or warn=no to the end of the command line # parameter string. This will for example suggest using the git module # instead of shelling out to the git command. # command_warnings = False # set plugin path directories here, separate with colons #action_plugins = /usr/share/ansible/plugins/action #become_plugins = /usr/share/ansible/plugins/become #cache_plugins = /usr/share/ansible/plugins/cache #callback_plugins = /usr/share/ansible/plugins/callback #connection_plugins = /usr/share/ansible/plugins/connection #lookup_plugins = /usr/share/ansible/plugins/lookup #inventory_plugins = /usr/share/ansible/plugins/inventory #vars_plugins = /usr/share/ansible/plugins/vars #filter_plugins = /usr/share/ansible/plugins/filter #test_plugins = /usr/share/ansible/plugins/test #terminal_plugins = /usr/share/ansible/plugins/terminal #strategy_plugins = /usr/share/ansible/plugins/strategy # by default, ansible will use the 'linear' strategy but you may want to try # another one #strategy = free # by default callbacks are not loaded for /bin/ansible, enable this if you # want, for example, a notification or logging callback to also apply to # /bin/ansible runs #bin_ansible_callbacks = False # don't like cows? that's unfortunate. # set to 1 if you don't want cowsay support or export ANSIBLE_NOCOWS=1 #nocows = 1 # set which cowsay stencil you'd like to use by default. When set to 'random', # a random stencil will be selected for each task. The selection will be filtered # against the `cow_whitelist` option below. #cow_selection = default #cow_selection = random # when using the 'random' option for cowsay, stencils will be restricted to this list. # it should be formatted as a comma-separated list with no spaces between names. # NOTE: line continuations here are for formatting purposes only, as the INI parser # in python does not support them. #cow_whitelist=bud-frogs,bunny,cheese,daemon,default,dragon,elephant-in-snake,elephant,eyes,\ # hellokitty,kitty,luke-koala,meow,milk,moofasa,moose,ren,sheep,small,stegosaurus,\ # stimpy,supermilker,three-eyes,turkey,turtle,tux,udder,vader-koala,vader,www # don't like colors either? # set to 1 if you don't want colors, or export ANSIBLE_NOCOLOR=1 #nocolor = 1 # if set to a persistent type (not 'memory', for example 'redis') fact values # from previous runs in Ansible will be stored. This may be useful when # wanting to use, for example, IP information from one group of servers # without having to talk to them in the same playbook run to get their # current IP information. #fact_caching = memory #This option tells Ansible where to cache facts. The value is plugin dependent. #For the jsonfile plugin, it should be a path to a local directory. #For the redis plugin, the value is a host:port:database triplet: fact_caching_connection = localhost:6379:0 #fact_caching_connection=/tmp # retry files # When a playbook fails a .retry file can be created that will be placed in ~/ # You can enable this feature by setting retry_files_enabled to True # and you can change the location of the files by setting retry_files_save_path #retry_files_enabled = False #retry_files_save_path = ~/.ansible-retry # squash actions # Ansible can optimise actions that call modules with list parameters # when looping. Instead of calling the module once per with_ item, the # module is called once with all items at once. Currently this only works # under limited circumstances, and only with parameters named 'name'. #squash_actions = apk,apt,dnf,homebrew,pacman,pkgng,yum,zypper # prevents logging of task data, off by default #no_log = False # prevents logging of tasks, but only on the targets, data is still logged on the master/controller #no_target_syslog = False # controls whether Ansible will raise an error or warning if a task has no # choice but to create world readable temporary files to execute a module on # the remote machine. This option is False by default for security. Users may # turn this on to have behaviour more like Ansible prior to 2.1.x. See # https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user # for more secure ways to fix this than enabling this option. #allow_world_readable_tmpfiles = False # controls the compression level of variables sent to # worker processes. At the default of 0, no compression # is used. This value must be an integer from 0 to 9. #var_compression_level = 9 # controls what compression method is used for new-style ansible modules when # they are sent to the remote system. The compression types depend on having # support compiled into both the controller's python and the client's python. # The names should match with the python Zipfile compression types: # * ZIP_STORED (no compression. available everywhere) # * ZIP_DEFLATED (uses zlib, the default) # These values may be set per host via the ansible_module_compression inventory # variable #module_compression = 'ZIP_DEFLATED' # This controls the cutoff point (in bytes) on --diff for files # set to 0 for unlimited (RAM may suffer!). #max_diff_size = 1048576 # This controls how ansible handles multiple --tags and --skip-tags arguments # on the CLI. If this is True then multiple arguments are merged together. If # it is False, then the last specified argument is used and the others are ignored. # This option will be removed in 2.8. #merge_multiple_cli_flags = True # Controls showing custom stats at the end, off by default #show_custom_stats = True # Controls which files to ignore when using a directory as inventory with # possibly multiple sources (both static and dynamic) #inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo # This family of modules use an alternative execution path optimized for network appliances # only update this setting if you know how this works, otherwise it can break module execution #network_group_modules=eos, nxos, ios, iosxr, junos, vyos # When enabled, this option allows lookups (via variables like {{lookup('foo')}} or when used as # a loop with `with_foo`) to return data that is not marked "unsafe". This means the data may contain # jinja2 templating language which will be run through the templating engine. # ENABLING THIS COULD BE A SECURITY RISK #allow_unsafe_lookups = False # set default errors for all plays #any_errors_fatal = False [inventory] # enable inventory plugins, default: 'host_list', 'script', 'auto', 'yaml', 'ini', 'toml' #enable_plugins = host_list, virtualbox, yaml, constructed # ignore these extensions when parsing a directory as inventory source #ignore_extensions = .pyc, .pyo, .swp, .bak, ~, .rpm, .md, .txt, ~, .orig, .ini, .cfg, .retry # ignore files matching these patterns when parsing a directory as inventory source #ignore_patterns= # If 'true' unparsed inventory sources become fatal errors, they are warnings otherwise. #unparsed_is_failed=False [privilege_escalation] #become=True #become_method=sudo #become_user=root #become_ask_pass=False [paramiko_connection] # uncomment this line to cause the paramiko connection plugin to not record new host # keys encountered. Increases performance on new host additions. Setting works independently of the # host key checking setting above. #record_host_keys=False # by default, Ansible requests a pseudo-terminal for commands executed under sudo. Uncomment this # line to disable this behaviour. #pty=False # paramiko will default to looking for SSH keys initially when trying to # authenticate to remote devices. This is a problem for some network devices # that close the connection after a key failure. Uncomment this line to # disable the Paramiko look for keys function #look_for_keys = False # When using persistent connections with Paramiko, the connection runs in a # background process. If the host doesn't already have a valid SSH key, by # default Ansible will prompt to add the host key. This will cause connections # running in background processes to fail. Uncomment this line to have # Paramiko automatically add host keys. #host_key_auto_add = True [ssh_connection] # ssh arguments to use # Leaving off ControlPersist will result in poor performance, so use # paramiko on older platforms rather than removing it, -C controls compression use #ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s # The base directory for the ControlPath sockets. # This is the "%(directory)s" in the control_path option # # Example: # control_path_dir = /tmp/.ansible/cp #control_path_dir = ~/.ansible/cp # The path to use for the ControlPath sockets. This defaults to a hashed string of the hostname, # port and username (empty string in the config). The hash mitigates a common problem users # found with long hostnames and the conventional %(directory)s/ansible-ssh-%%h-%%p-%%r format. # In those cases, a "too long for Unix domain socket" ssh error would occur. # # Example: # control_path = %(directory)s/%%h-%%r #control_path = # Enabling pipelining reduces the number of SSH operations required to # execute a module on the remote server. This can result in a significant # performance improvement when enabled, however when using "sudo:" you must # first disable 'requiretty' in /etc/sudoers # # By default, this option is disabled to preserve compatibility with # sudoers configurations that have requiretty (the default on many distros). # #pipelining = False # Control the mechanism for transferring files (old) # * smart = try sftp and then try scp [default] # * True = use scp only # * False = use sftp only #scp_if_ssh = smart # Control the mechanism for transferring files (new) # If set, this will override the scp_if_ssh option # * sftp = use sftp to transfer files # * scp = use scp to transfer files # * piped = use 'dd' over SSH to transfer files # * smart = try sftp, scp, and piped, in that order [default] #transfer_method = smart # if False, sftp will not use batch mode to transfer files. This may cause some # types of file transfer failures impossible to catch however, and should # only be disabled if your sftp version has problems with batch mode #sftp_batch_mode = False # The -tt argument is passed to ssh when pipelining is not enabled because sudo # requires a tty by default. #usetty = True # Number of times to retry an SSH connection to a host, in case of UNREACHABLE. # For each retry attempt, there is an exponential backoff, # so after the first attempt there is 1s wait, then 2s, 4s etc. up to 30s (max). #retries = 3 [persistent_connection] # Configures the persistent connection timeout value in seconds. This value is # how long the persistent connection will remain idle before it is destroyed. # If the connection doesn't receive a request before the timeout value # expires, the connection is shutdown. The default value is 30 seconds. #connect_timeout = 30 # The command timeout value defines the amount of time to wait for a command # or RPC call before timing out. The value for the command timeout must # be less than the value of the persistent connection idle timeout (connect_timeout) # The default value is 30 second. #command_timeout = 30 [accelerate] #accelerate_port = 5099 #accelerate_timeout = 30 #accelerate_connect_timeout = 5.0 # The daemon timeout is measured in minutes. This time is measured # from the last activity to the accelerate daemon. #accelerate_daemon_timeout = 30 # If set to yes, accelerate_multi_key will allow multiple # private keys to be uploaded to it, though each user must # have access to the system via SSH to add a new key. The default # is "no". #accelerate_multi_key = yes [selinux] # file systems that require special treatment when dealing with security context # the default behaviour that copies the existing context or uses the user default # needs to be changed to use the file system dependent context. #special_context_filesystems=nfs,vboxsf,fuse,ramfs,9p,vfat # Set this to yes to allow libvirt_lxc connections to work without SELinux. #libvirt_lxc_noseclabel = yes [colors] #highlight = white #verbose = blue #warn = bright purple #error = red #debug = dark gray #deprecate = purple #skip = cyan #unreachable = red #ok = green #changed = yellow #diff_add = green #diff_remove = red #diff_lines = cyan [diff] # Always print diff when running ( same as always running with -D/--diff ) # always = no # Set how many context lines to show in diff # context = 3

概要 Amazon Linux 2 でTimezoneを変更する方法を記載しておきます。 設定 現在がUTCで表示されているかを確認します。 [root@ip-10-0-0-141 ssm-user]# date Fri Jul 29 15:18:56 UTC 2021 timedatedctlコマンド経由で変更します。 [root@ip-10-0-0-141 ssm-user]# timedatectl set-timezone Asia/Tokyo crondに対しても変更を反映するために再起動しておきます。 [root@ip-10-0-0-141 ssm-user]# systemctl restart crond.service JSTで表示されるかを確認します。 [root@ip-10-0-0-141 ssm-user]# date Fri Jul 30 00:20:56 JST 2021 補足 /etc/sysconfig/clock ファイルは存在していないようです。 [root@ip-10-0-0-141 ssm-user]# cat /etc/sysconfig/clock cat: /etc/sysconfig/clock: No such file or directory

コンピューティングサービス Amazon Elastic Compute Cloud（EC2） AWS上で仮想サーバーを提供するサービス 作成された仮想サーバーをEC2インスタンスという 構築の流れ 1. Amazon Machine Image（AMI）の選択 EC2インスタンスはAMIと呼ばれるイメージファイルから起動する 標準提供のAMI or ベンダーから提供されたAMIをAWS Marketplaceから利用 2. インスタンスタイプの選択 vCPU（仮想CPU）とメモリ容量の組み合わせがパッケージ化している中から自由に選択する vCPUとメモリ容量のバランスによって、インスタンスファミリーと呼ばれるグループに分かれている 3. インスタンスの詳細設定 EC2のインスタンスを構築するネットワーク情報／IAMロールを設定する 4. ストレージの設定 EC2インスタンスに接続するストレージを選択する EBSやインスタンスストアを選択する EBS（Elastic Block Store） EC2と共に使用するための、長期記憶用のブロックストレージサービス インスタンスストア ホストコンピュータに物理的に接続されたディスク上にある、一時記憶用のストレージ 5. タグの追加 EC2インスタンスやストレージにタグを追加して、運用の効率化／課金の振り分けを行う 6. セキュリティグループの設定 EC2へのアクセスを制限するためのファイアウォール機能 AWSではセキュリティグループでアクセス制御するのが一般的 7. キーペアの設定 EC2インスタンスへのログインは公開鍵認証方式を採用している 公開鍵と秘密鍵を発行する 公開鍵：AWSが管理 秘密鍵：ユーザーが管理し、ログイン時に使用する 秘密鍵を紛失した場合は、新たにキーペアを発行して別のEC2インスタンスを起動する 秘密鍵を紛失すると構築したEC2インスタンスにログインできなくなるため注意が必要 Amazon Machine Image（AMI） EBSのスナップショットとEC2インスタンスの構成情報から成り立っている OSには各種Linux／Windowsサーバー／Amazon Linuxが利用可能 Amazon Marketplaceで用意されているサードパーティ製のAMI or ユーザー自身で作成したAMIを利用する Auto Scalingの起動設定にAMIを指定することで、同じ設定のEC2インスタンスを必要な時に必要な分だけ自動構築できる 動作しているEC2インスタンスと同じ環境を別リージョンに複製する場合 AMIをコピーして複製先のリージョンを指定 新しいリージョンに複製されたAMIからEC2インスタンスを起動する AMIの種類 EBS-Backedインスタンス EBSをOSのルート領域として利用したEC2インスタンス 不揮発性のため、インスタンスが停止してもデータは永続化する Instance Store-Backedインスタンス インスタンスストアをOSのルート領域として利用したEC2インスタンス 揮発性のため、インスタンスが停止したらデータは削除される EC2インスタンスのライフサイクル 状態 内容 課金対象 pending インスタンス起動前 対象外 running インタンス起動中 対象 stopping インスタンス停止準備中 対象外 stopped インスタンス利用不可／再開は可 　対象外 shutting-down インスタンス削除準備中 対象外 terminated インスタンス完全削除／再開不可 対象外 EBS-Backedインスタンスでは停止処理が可能 Instance Store-Backedインスタンスでは停止状態に遷移できない ユーザーデータとインスタンスメタデータ ユーザーデータ EC2インスタンス初回起動時に一度だけスクリプトを実行できる機能 AMIからEC2を起動するとき、最新のコンテンツを反映する場合などに利用する インスタンスメタデータ EC2インスタンス自身に関するデータで、実行中のインスタンスを設定／管理するために利用する リンクローカルアドレスにブラウザ or cURLコマンドでアクセスして取得する インスタンスID プライベートIPv4アドレス パブリックIPv4アドレス ローカルホスト名 公開鍵 AWS Lambda Lambda関数と呼ばれるアプリケーションコードをデプロイしただけで実行できるサーバーレスなサービス Lambdaへの連携イメージ ExecutionRole LambdaにアタッチされたIAMロール LambdaはIAMロールに従って各AWSサービスにアクセスするため、アクセス制御設計が必要になる ロギング Lambda関数の処理結果はCloudWatch Logsに保存される ・Lambdaと名前がついているが、実際はAmazon CloudFrontの機能の一つ ・アプリケーションユーザーに最も近い場所でコードが実行されるため待ち時間が短縮される Amazon API Gateway APIの作成／配布／保守／監視／保護を簡単に行えるサービス サーバー管理の必要がないため、Lambdaと組み合わせることでサーバーレスアプリケーションを実装できる API GatewayとLambdaとの連携イメージ コンテナ関連のサービス Amazon Elastic Container Service（ECS） 複数の仮想環境（コンテナ）を管理し、起動／削除／監視を行えるコンテナオーケストレーションサービス Dockerコンテナを簡単に実行／停止／管理できる 仮想化の種類 ハイパーバイザー型仮想環境 サーバーへ直接インストールし、仮想マシンを稼働 ハードウェアを直接制御できる コンテナ型仮想環境 ホストOS上にDocker等をインストールして仮想環境を構築する 一台のサーバーで多くのコンテナを稼働できる ECS構築手順 1. クラスター作成 EC2インスタンスを論理グループ化する インスタンスタイプ／インスタンス数／EBSストレージ容量を設定 2. タスク定義 Dockerイメージの格納先の設定 メモリ使用料の制限 ネットワーク／ストレージ／ヘルスチェックに対する項目の設定 3. ELBの設定 トラフィックをコンテナ全体に分散して処理するためにElastic Load Balancingの設定を行う 4. サービス設定 クラスター上で起動するコンテナ数／最大数を設定する Amazon Elastic Kubernetes Service（EKS） Kubernetes向けのコンテナオーケストレーションサービス インスタンス数やEBSストレージの容量を定義すると、状況をモニタリングしながら定義した状態になるように自動管理する 負荷の増減に対しても、自動スケーリングしてくれる Kubernetes 分散されたホスト上でDockerなどのコンテナを利用するためのオーケストレーションツール AWS Fargate コンテナ向けのサーバーレスコンピューティングエンジン 手動でコンテナを管理する場合 コンテナイメージのビルド ECSインスタンスの定義とデプロイ コンピューティングリソース／メモリリソースのプロビジョニングと管理 アプリケーションを別々の仮想マシンに分離させる アプリケーションとインフラの両方を別々に実行して管理 Fargateを利用すれば、コンピューティングリソース／メモリリソースの定義やアプリケーションの実行／管理を行うだけで良い スケールを含むコンテナの管理をFargateに任せることができる その他のコンピューティングサービス Amazon Elastic MapReduce（EMR） 大量のデータを迅速／容易にかつコスト効果よく処理するためのWebサービス データの分散処理環境の構築と分散処理が容易に行うことができる VM（Virtual Machine） Import／Export VM Import オンプレ環境に作成した仮想サーバーのマシンイメージをEC2インスタンスにインポートするサービス VM Export VM ImportでAWS上にインポートされたEC２インスタンスをオンプレ環境で動作する仮想サーバーのマシンイメージにエクスポートするサービス Amazon LightSail アプリケーションやWebサイトを素早く構築できるように、仮想サーバー／ストレージ／データベース／ネットワークなどの環境と構成できるオールインワンなコンピューティングサービス 参考