こんにちは。大石（@se_o_chan）です。
AWS Top Engineerの申し込みが開始されました。昨年はTop Engineer に選出頂いたのですが、今年はいけるかな・・とそわそわしています。
さて、私はこの一年AWS移行PJの推進に従事していたのですが、AWSには移行を推進するためにいくつかのサービスが提供されています。
今回はそのうちの1つ、AWS Application Discovery Serviceを紹介します。
移行そのものではなく移行準備に役立つもので、少しマイナーなサービスかもしれませんが、上手く使うと非常に助かるケースはあると思います。どんな機能を持っているのか、どう使えばよいのか実際に試しながら整理します。
AWS移行のアプローチ
AWSは「AWS Prescriptive Guidance（AWS規範的ガイダンス）」という情報を提供してくれています。
Amazon Web Services (AWS) Prescriptive Guidance provides time-tested strategies, guides, and patterns to help accelerate your cloud migration, modernization, and optimization projects.
アマゾンウェブサービス（AWS）の規範的ガイダンスは、クラウドの移行、モダナイゼーション、および最適化プロジェクトを加速するのに役立つ、実績のある戦略、ガイド、およびパターンを提供します。
とても実践的な情報がたくさん掲載されており、その中でAWS移行へのアプローチを解説した記事があります。リンクはこちら。そこではAWS移行を3つのフェーズに分けています。「評価（Assess）」「計画（Mobilize）」「移行（Migate & Modernize）」です。※フェーズの日本語名は私の意訳です。
（出典）AWS Prescriptive Guidance
計画フェーズにおいては、まず移行対象とするワークロード（サーバ数、OS、ミドル、リソース使用状況）を正確に把握しておく必要があります。それによって移行方式や移行先サービスが変わってくるからです。移行対象のサーバが数台であれば問題にはなりにくいですが、数十～数百台規模で移行しようとすると現状把握だけで大きな労力となり得ます。そのときに役立つのがAWS Application Discovery Service（以下、ADS）です。
AWS Application Discovery Serviceの概要
AWS ADSはオンプレミスサーバの設定情報と使用状況を収集するツールです。Migration Hubと統合しており、収取したデータはMigration Hubコンソールを通じて確認できます。データ収集方法には下記の2種類があり、それぞれで対応している環境や得られる情報にやや違いがあるので、個々のユースケースに応じて選択することになります。
エージェントベース検出
オンプレミスサーバにADSエージェントをインストールします。VM、物理のどちらでも良いです。サポートされているOSはこちら。HTTPS（443番ポート）でインターネット上のADSエンドポイントへアクセスが発生します。プロキシ経由も可ですが、2023年2月現在Direct ConnectやSite-to-Site VPNを使った閉域通信はできません。主な収集データは次のとおりです。正式にはこちらのユーザーガイドを参照ください。
エージェントレス検出
VMWare vCenter環境にコレクタ―サーバをデプロイします。個々のVMにエージェントをインストールする必要がないので、vCenter自体を触ることができる かつ 対象VM数が多いならこちらの方が作業負荷は軽いです。ただし物理サーバには適用できないこと、VMWare以外のハイパーバイザーには対応していないこと、得られる情報がエージェントベース検出よりやや限定されることがデメリットです。主な取得データは次のとおりですが、正式にはこちらを参照ください。
試してみる
では実際に試してみて、機能を確認してみます。今回はエージェントベース検出で行います。
STEP1) IAMユーザ作成
ADSエージェント実行に使用するIAMユーザを作成します。AWSApplicationDiscoveryAgentAccessというAWS管理ポリシーがあるので、そのポリシーを付与した状態でIAMユーザを作成し、アクセスキーを払い出します。
STEP2) ADSエージェントインストール
まずWindows Serverの場合です。
ADSエージェントのインストーラをこちらからダウンロードし、オンプレサーバの任意の場所に配置しておきます。管理者としてコマンドプロンプトを開き、インストーラを配置した場所で次のコマンドを実行します。
.\AWSDiscoveryAgentInstaller.exe REGION="your-home-region" KEY_ID="aws-access-key-id" KEY_SECRET="aws-secret-access-key" /quiet
your-home-regionは連携したいMigration Hubがあるリージョン（東京ならap-northeast-1）を指定します。aws-access-key-idとaws-secret-access-keyはSTEP1で払い出したIAMユーザのアクセスキーとシークレットアクセスキーです。
また、上記コマンド実行時に次のオプションを設定することでプロキシ経由の通信にすることが出来ます。
- PROXY_HOST プロキシのホスト名
- PROXYSCHEME プロキシスキーム（httpまたはhttps）
- PROXY_PORT プロキシポート番号
- PROXY_USER プロキシユーザーネーム（認証付きプロキシの場合）
- PROXYPASSWORD プロキシユーザーパスワード（認証付きプロキシの場合）
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 curl -o ./agent.sig https://s3.us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz.sig curl -o ./discovery.gpg https://s3.us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/discovery.gpg gpg --no-default-keyring --keyring ./discovery.gpg --verify agent.sig aws-discovery-agent.tar.gz tar -xzf aws-discovery-agent.tar.gz sudo bash install -r your-home-region -k aws-access-key-id -s aws-secret-access-key
Windows同様、最後のインストール時に次のオプションをつけることでプロキシ経由の通信に切り替えられます。
- -d プロキシのホスト名
- -g プロキシスキーム（httpまたはhttps）
- -f プロキシポート番号
- -g プロキシユーザーネーム（認証付きプロキシの場合）
- -e プロキシユーザーパスワード（認証付きプロキシの場合）
STEP3) データ収集開始
AWSマネジメントコンソールからMigration Hubに移動します。左ペインの「検出 > データコレクタ」を選択すると、エージェントインストールが上手くいっていれば「検出エージェント」タブにサーバが表示されているはずです。
対象サーバにチェックを入れて「データ収集を開始」ボタンを押します。
STEP4) データ表示
続いて左ペインの「検出 > サーバー」からサーバーをクリックしてみます。
すると次のような情報が収集されています。CPU数やRAMサイズ、ディスクサイズのような基本的なサーバスペックが確認できますね。
パフォーマンス情報も取得されます。この情報はEC2のサイジング検討のインプットになります。現行のCPU数、RAMサイズを踏襲するようにサイジングしても良いのですが、せっかくなら必要最小限のスペックにしてコスト最適な移行を行いたいですね。
STEP5) EC2インスタンスタイプの推奨
そのEC2のサイジングですが、なんとMigration Hubがレコメンドしてくれる機能があります。左ペインの「評価 > EC2インスタンスのレコメンデーション」です。
レコメンデーションにあたって、2点設定を行います。
1つ目は「サイジングの設定」です。どういうロジックでサイジングするかを選択することが出来ます。
- 最大使用率 STEP4)で確認したパフォーマンス情報の最大（ピーク）CPU、RAM使用率に基づいてサイジングします。
- 現在のサーバー仕様 今のサーバスペックをベースにサイジングしますが、2つのオプションがあります。「ダイレクトマッチ」は収集したCPU数やRAMサイズをそのままサイジングに使います。「カスタムマッチ」はCPU、RAMそれぞれに現スペックの何％を想定してサイジングするかを指定できます。
- 平均使用率 パフォーマンス情報の平均CPU、RAM使用率に基づいてサイジングします。
- 使用率(%) 時系列使用率データのパーセンタイルを指定します。例えば「95パーセンタイル」としてすると、データ収集をし始めてから95%の時間帯をカバーできるスペックをベースにサイジングします。
2つ目の設定は「インスタンスタイプの設定」です。
リージョンやテナンシー（共有 or ハードウェア専有）、料金モデル（オンデマンド or リザーブド）の他に、レコメンドから除外するインスタンスタイプを指定できます。エンタープライズ環境で中～大規模に使っている場合、Savings Planでのカバレッジを上げるためにインスタンスファミリーを限定しているケースがあるのではないかと思います。そういう時に有効ですね。
「Export recommendations」ボタンをクリックするとcsvファイルで結果が出力されます。この例だとt2.smallになっていますね。
サーバ負荷はかからない？
本番運用しているサーバにエージェントをインストールするので、サーバに負荷はかからないのか心配になる方もいるかと思います（自分がそう）。実機で見てみましょう。今回試した環境は1vCPU、2G RAMの小さいサーバなのでエージェントの負荷が見えやすいと思います。
今回は23:32にデータ収集を開始し、エージェントは15分おきにポーリングしていますのでそのタイミングの負荷を見てみます。まず下記グラフはサーバ全体のCPU使用率（%）です。
流石にエージェントが動くタイミングで使用率が上がっているように見えますが、瞬間的なものでした。CPU負荷は大きくないと言えるでしょう。
次に空きメモリサイズ（MBytes）のグラフです。
元々メモリ使用率が高めのサーバだったのですが、エージェントが動き出して60～70MBくらい空きが減っているでしょうか。別のタイミングで見るとエージェントが使用しているメモリは15MBくらいだったのですが、数十MBくらいは消費されると見ておきたいですね。
最後にネットワーク転送量（Bytes/秒）です。
元々定期的に棘が立っているので分かりにくいですが、データ収集開始直後に20KB/秒（≒160Kbps）程度の通信が発生してからポーリングタイミングに転送がほぼ走ってないように見えます。ネットワーク負荷は無視できる程度と考えてよさそうです。
まとめ
AWS ADSを実際に使ってみて機能と負荷を確認しました。
エージェントのインストールも簡単でサーバ負荷も軽微と分かりました。
現行運用でIT資産管理ツールを導入していないなら、移行前にADSをインストールすれば精緻な情報から適切なEC2サイジングができそうです。
