AWS Cloud Map

AWS Cloud Map は、アプリケーションを構成するリソースに人間が読める論理名を付けて登録し、その実体の場所を動的に発見できるようにするマネージドなサービスディスカバリです。マイクロサービスやデータベース、キュー、その他の API エンドポイントといったリソースを名前で抽象化し、アプリ側は名前を頼りに最新の接続先を取得できます。

解決する課題

クラウドのワークロードでは、リソースの実体が頻繁に入れ替わります。オートスケーリングでコンテナやインスタンスが増減し、デプロイのたびに IP アドレスやポートが変わり、障害復旧で別の場所に立ち上がることもあります。このような環境で、接続先を設定ファイルや環境変数に直接書き込む方式には次のような課題があります。

• IP アドレスやポートが変わるたびに設定を書き換える必要があり、変更の追従が運用負担になる。
• どこに何があるかという情報が各アプリにばらばらに散らばり、信頼できる単一の情報源が存在しない。
• 障害が起きているインスタンスへ問い合わせが向かってしまい、自前でヘルスチェックと振り分けを作り込む手間が生じる。
• リソースの種類が DNS で表現しにくいもの（特定の URL や任意のメタデータを持つ対象）だと、DNS だけでは登録・発見がうまく扱えない。

Cloud Map は、リソースに論理名と任意の属性を付けて中央のレジストリに登録し、アプリがその名前で最新の場所を問い合わせられるようにすることで、これらを解決します。実体が入れ替わっても名前は変わらないため、アプリ側のコードや設定を変えずに、常に有効な接続先へ到達できます。

主要概念と用語

• 名前空間: 登録するサービス群をまとめる論理的な入れ物。発見方法に応じて種類があり、DNS で公開してパブリックに解決させるもの、VPC 内のプライベート DNS として解決させるもの、DNS を介さず API でのみ問い合わせるものがある。名前空間ごとに対応する Route 53 のホストゾーンが作られる場合がある。
• サービス: 名前空間の中で、同じ役割を持つインスタンス群をまとめた単位。たとえば「注文サービス」「在庫サービス」のように、発見する対象の論理名にあたる。
• サービスインスタンス: サービスに登録される個々の実体。IP アドレスやポート、あるいは任意のメタデータ（属性のキーと値の組）を持ち、これが実際の接続先になる。
• 属性とカスタムメタデータ: サービスインスタンスに付与できる任意のキーと値。バージョンや環境、リージョンといった情報を持たせ、発見時の絞り込みに使える。
• DNS ベースの発見: サービスに対して DNS のレコードが作られ、アプリは通常の名前解決でインスタンスを取得する。レコードの種類により、IP を返すか、ポートを含む情報を返すかが変わる。
• API ベースの発見: DNS を使わず、専用の API を呼び出してインスタンス一覧を取得する方式。属性で絞り込んだり、健全なものだけを取得したりといった柔軟な問い合わせができる。
• ヘルスチェック: 登録したインスタンスの健全性を判定する仕組み。Route 53 のヘルスチェックを使う方法と、外部のチェック結果を反映するカスタムヘルスチェックの方法がある。健全でないインスタンスを発見結果から除外できる。

仕様・制限・クォータ

設計時に意識すべき性質は次のとおりです。具体的な上限値はリージョンや時期で変わりうるため、定性的に把握し、正確な数値は公式ドキュメントとサービスクォータの画面で確認してください。

• 1 つのアカウント・リージョンに作成できる名前空間の数、1 つの名前空間に登録できるサービス数、1 つのサービスに登録できるインスタンス数には、それぞれアカウント単位のクォータがある。
• 名前空間の種類（パブリック DNS、プライベート DNS、API のみ）は作成時に決まり、その種類に応じて発見方法と作られるリソースが変わる。
• DNS ベースの発見では、レコードに設定する TTL の値が、実体の変化が発見側へ反映されるまでの遅れに影響する。短くすると追従は速くなるが問い合わせは増える。
• DNS で扱える表現には限りがあるため、任意のメタデータを伴うリソースや DNS で表しにくい対象は、API ベースの発見が適している。
• カスタムヘルスチェックを使う場合、健全・不健全の状態は外部から API で報告する必要があり、報告がない間の扱いに注意する。
• API の呼び出し回数にはスロットリングがかかりうるため、発見の頻度が高い場合はクライアント側でのキャッシュを考慮する。

内部の仕組み

Cloud Map は、登録（レジストレーション）と発見（ディスカバリ）の二つの流れで成り立ちます。

登録側では、まず名前空間を作り、その中にサービスを定義します。アプリやオーケストレーターは、起動したインスタンスを IP やポート、属性とともにそのサービスへ登録します。コンテナ環境では、この登録をプラットフォーム側が自動で行うことが多く、たとえば ECS のサービスディスカバリ連携を有効にすると、タスクの起動・停止に合わせて Cloud Map への登録と削除が自動的に行われます。

発見側では、名前空間の種類に応じて二通りの取得経路があります。DNS ベースの名前空間では、サービスに対応する DNS レコードが管理され、アプリは通常の名前解決で接続先を得ます。プライベート DNS の名前空間は VPC 内のリゾルバーを通じて解決され、パブリックの名前空間はインターネットから解決できます。API ベースでは、アプリが専用 API を呼び出してインスタンス一覧を直接取得し、属性での絞り込みや健全なインスタンスのみの取得といった条件を付けられます。

ヘルスチェックを構成している場合、不健全と判定されたインスタンスは発見結果から除外されます。これにより、DNS であれ API であれ、アプリは原則として正常に応答できる接続先だけを受け取れます。実体が入れ替わっても、登録・削除とヘルス判定がレジストリに反映されるため、名前を頼りにする限りアプリは最新の状態に追従できます。

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

• コンテナのサービスディスカバリに使う: ECS や EKS のように動的にスケールするワークロードでは、プラットフォームの連携機能で登録を自動化し、サービス間通信を論理名で行う。設定の直書きを排除でき、デプロイのたびの書き換えが不要になる。
• 健全なインスタンスだけを返す: ヘルスチェックを構成し、不健全なインスタンスを発見結果から除外する。アプリ側の独自リトライ実装に頼らず、レジストリの段階で正常な接続先に絞れる。
• 属性で論理的に振り分ける: バージョンや環境などの属性を付け、API ベースの発見で絞り込む。カナリアや段階的なロールアウトで、特定条件のインスタンスだけを選ぶ用途に向く。
• 名前空間で境界を分ける: 環境（本番・検証）やドメインごとに名前空間を分け、発見の範囲と命名の衝突を整理する。
• 発見結果をキャッシュする: API ベースで頻繁に問い合わせる場合、クライアント側で適切な期間キャッシュし、呼び出し回数とレイテンシを抑える。DNS ベースでは TTL の設計で同等の効果を得る。

運用・監視

• API 呼び出しの追跡: Cloud Map に対する操作は CloudTrail に記録されるため、誰がいつ名前空間やサービス、インスタンスを変更したかを監査できる。
• メトリクスの監視: 発見 API の呼び出し状況やスロットリング、ヘルスチェックの状態を CloudWatch のメトリクスで監視し、異常時にアラームを上げる。
• ヘルス状態の確認: 不健全と判定されているインスタンスが増えていないか、カスタムヘルスチェックの報告が滞っていないかを定期的に確認する。発見結果が空になる事象の多くは、背後のインスタンスやヘルス報告の問題に起因する。
• 構成のコード化: 名前空間とサービスの定義を Infrastructure as Code で管理し、命名や属性の設計を一貫させ、意図しない構成変更を検知できるようにする。
• 棚卸し: 不要になったサービスインスタンスが登録に残り続けると、古い接続先が返る原因になる。登録解除が確実に行われているかを点検する。

コスト

Cloud Map の料金は、おおむね次の要素で構成されます。具体的な単価はリージョンや時期で変動するため、最新の料金ページで確認してください。

• 登録されているリソースの量: レジストリに登録するリソース（サービスインスタンスなど）の数や保持に応じた料金が発生する。
• 発見のリクエスト数: 発見 API の呼び出し回数に応じた料金がかかる。問い合わせ頻度が高いほど積み上がる。
• DNS 解決の料金: DNS ベースの発見では、関連する Route 53 のホストゾーンやクエリに対する料金が別途関係しうる。
• 設計上の考慮: 発見結果を適切にキャッシュし、過剰な API 呼び出しを避けることで、リクエスト課金を抑えられる。使われていないインスタンス登録を放置しないことも無駄の削減につながる。

セキュリティ

• IAM による制御: 名前空間やサービスの作成・更新・削除、インスタンスの登録・登録解除、発見 API の呼び出しといった操作は IAM のポリシーで制御する。アプリには発見に必要な最小限の権限だけを与える。
• プライベート名と公開範囲: プライベート DNS の名前空間は VPC 内に閉じて解決されるため、内部サービスの発見をネットワーク的に隔離できる。パブリック名前空間はインターネットから解決可能になる点を意識し、内部用途で誤って公開しないようにする。
• 監査: CloudTrail でレジストリへの操作を記録し、不審な登録変更を検知できるようにする。
• メタデータの取り扱い: サービスインスタンスの属性に機密情報を入れない。発見結果として返りうるため、接続に必要な範囲の情報に留める。

Well-Architected の観点

運用上の優秀性の柱の観点が中心です。リソースの場所を中央のレジストリに集約し、実体の入れ替わりに名前で追従できるため、設定の手作業による書き換えを排除し、デプロイやスケールに伴う変更を自動化しやすくなります。あわせて、信頼性の柱の観点ではヘルスチェックによって健全なインスタンスだけを返し、障害インスタンスへの到達を避けられる点が寄与します。コスト最適化の柱の観点では、発見呼び出しのキャッシュ設計と不要な登録の棚卸しが無駄の削減につながります。

試験で問われるポイント

関連サービス・比較

DNS の権威サービスである Amazon Route 53 と、サービスディスカバリの Cloud Map は役割が近接しており、混同されがちです。Route 53 はドメイン名と DNS レコードを管理する基盤であり、Cloud Map はその上でリソースの登録と発見を抽象化し、属性や API ベースの問い合わせまで扱える点が異なります。

ハンズオン / CLI例

次は、プライベート DNS の名前空間を作り、サービスを定義し、インスタンスを登録して発見するまでの基本的な流れの例です。VPC やインスタンスの値は自分の環境に置き換えてください。名前空間の作成は非同期に進むため、状態の確認をはさみます。

# VPC 内で解決されるプライベート DNS 名前空間を作成する
aws servicediscovery create-private-dns-namespace \
  --name internal.example.local \
  --vpc vpc-0123456789abcdef0

# 名前空間が作成されたら、その中にサービスを定義する
# DNS の A レコードで IP を返す構成の例
aws servicediscovery create-service \
  --name orders \
  --namespace-id ns-0123456789abcdef0 \
  --dns-config "RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]"

# 起動したインスタンスをサービスへ登録する
aws servicediscovery register-instance \
  --service-id srv-0123456789abcdef0 \
  --instance-id orders-1 \
  --attributes AWS_INSTANCE_IPV4=10.0.1.20

# API ベースで健全なインスタンスを発見する
aws servicediscovery discover-instances \
  --namespace-name internal.example.local \
  --service-name orders \
  --health-status HEALTHY