AWS Application Discovery Service

解決する課題

オンプレミスから AWS への移行で最初につまずくのが「いま自分たちが何を動かしているのか」を正確に把握することです。長年運用されたデータセンターでは、どのサーバーがどのスペックで動き、どのアプリケーションがどのサーバーに依存しているのかが、台帳と実態でずれていることが珍しくありません。この状態のまま移行計画を立てると、依存関係の取りこぼしや過大なリソース見積もりにつながります。Application Discovery Service は、対象環境のサーバー構成・性能実績・ネットワーク依存関係を自動で収集し、移行計画の土台となるインベントリを整える役割を担います。

• サーバーの台帳と実態がずれていて、正確な構成がわからない
• アプリケーションがどのサーバーに依存しているかを手作業では追えない
• 各サーバーの**実際の負荷（CPU・メモリ・I/O）**を把握して、移行先のサイジングに使いたい
• 何百台もの環境で、移行の波（ウェーブ）をどう分割するかを根拠を持って決めたい

主要概念と用語

• ディスカバリエージェント: 各サーバーに導入して構成・性能・プロセス・ネットワーク接続などを継続的に収集するソフトウェア。きめ細かいデータと依存関係を集められる
• エージェントレス（コネクタ/アプライアンス）型: 仮想化基盤に仮想アプライアンスを置き、VM の一覧やスペック、利用実績をエージェントなしで収集する方式
• 構成データ: サーバーのスペック、OS、稼働プロセスといった静的・動的な情報
• 性能データ: CPU・メモリ・ディスク・ネットワークの利用実績。移行先のサイジング根拠になる
• ネットワーク依存関係: サーバー間の通信の流れ。どのサーバーがどのサーバーと話しているかを可視化し、アプリケーション境界の把握に使う
• Migration Hub への集約: 収集データは Migration Hub に集約され、サーバーをアプリケーション単位にグルーピングして扱える
• データのエクスポート: 収集したインベントリや性能データを取り出し、外部での分析や見積もりに活用できる

仕様・制限・クォータ

• 収集方式は大きくエージェント型とエージェントレス型の2系統があり、対象環境（物理/仮想、OS）に応じて選ぶ
• 収集対象はサーバー構成・性能実績・稼働プロセス・ネットワーク依存関係など。方式によって取得できる粒度が異なる
• 収集したデータはMigration Hub のホームリージョンに集約され、そこで一元的に扱う
• インベントリや性能データはエクスポートして外部分析に回せる
• サポートされる OS・仮想化基盤、収集項目、各種の上限は時期によって変わるため、設計時に最新情報の確認が必要

内部の仕組み

Application Discovery Service は、対象環境にデータ収集の仕組みを配置し、そこから AWS 側へ情報を送る構成で動きます。エージェント型では各サーバーに導入したエージェントが、構成・性能・稼働プロセス・ネットワーク接続といった情報を継続的に収集して送信します。サーバー単位の細かいデータと、通信の流れに基づく依存関係まで把握できるのが特徴です。

エージェントレス型では、仮想化基盤に仮想アプライアンスを配置し、基盤側の情報をもとに VM の一覧・スペック・利用実績を集めます。エージェントを各サーバーに入れずに広く棚卸しできる一方、取得できる粒度はエージェント型より粗くなる傾向があります。いずれの方式でも、収集されたデータは Migration Hub に集約され、サーバーをアプリケーション単位にまとめて扱えるようになります。これにより、構成の可視化から移行計画の立案までを一つの場所で進められます。

設計パターン / ベストプラクティス

• まず棚卸し、それから計画: 移行に着手する前にディスカバリで現状を収集し、根拠を持って計画を立てる
• 依存関係を見てウェーブを切る: ネットワーク依存関係を可視化し、密に通信し合うサーバー群を同じ移行の波にまとめる
• 性能実績でサイジング: ピークではなく実際の利用実績をもとに移行先インスタンスを選び、過剰なサイジングを避ける
• 方式を使い分ける: 詳細が要るクリティカルなアプリはエージェント型、広く台数を押さえたい環境はエージェントレス型と組み合わせる
• 十分な期間データを取る: 月末処理など周期的な負荷を取り逃さないよう、ある程度の期間にわたって収集してから判断する

運用・監視

• 収集状況や対象サーバーの一覧は、Migration Hub のコンソールや APIでまとめて確認できる
• エージェント型では各エージェントの稼働状態を確認し、データ送信が止まっていないかを監視する
• 収集したインベントリや性能データはエクスポートして、見積もりや報告資料の作成に活用する
• データが集まらないサーバーがある場合は、エージェントの稼働やネットワーク経路、収集設定を確認する
• 収集は一度きりでなく、計画の精度を上げるために継続的に実績を蓄積していく運用が望ましい

コスト

• ディスカバリの収集機能そのものは追加料金なしで利用できることが多い
• 費用が発生し得るのは、収集したデータの保存や、他サービス（分析基盤など）と連携した場合の各サービス側の料金
• エージェントやアプライアンスを動かすオンプレ側のリソースは自社の環境コストに含まれる
• 収集データをエクスポートして外部で分析する場合は、その分析側のサービス料金に従う
• コストよりも、ここで得たデータで移行先のサイジングを最適化し、移行後のコストを抑えることに価値がある

セキュリティ

• ディスカバリの操作やデータ閲覧の権限は IAM で管理し、移行プロジェクトの関係者に最小権限を割り当てる
• 収集したサーバー構成・依存関係は環境の内部構造を表す機微な情報のため、アクセス権限を絞る
• エージェントやアプライアンスから AWS への通信経路を把握し、送信されるデータの範囲を管理する
• 操作の監査証跡は CloudTrail で記録し、誰がどの設定を変更・エクスポートしたかを追えるようにする
• エクスポートしたインベントリの保管先（オブジェクトストレージ等）にも、適切なアクセス制御を設定する

関連サービス・比較

収集結果の集約先である AWS Migration Hub とセットで使われます。Application Discovery Service が環境を調査してデータを収集する役割、Migration Hub がそのデータを集約して計画・追跡に使う役割という分担で、両者は組み合わせて利用するのが基本です。

ハンズオン / CLI例

# 収集したサーバー（構成アイテム）の一覧を取得
aws discovery list-configurations \
  --configuration-type SERVER

# 稼働中のディスカバリエージェントの状態を確認
aws discovery describe-agents

# サーバーをアプリケーション単位にグルーピングして作成
aws discovery create-application \
  --name "order-system" \
  --description "受注システムの移行対象グループ"

# 性能データを含むエクスポートを開始
aws discovery start-export-task \
  --export-data-format CSV