AWS Cloud Map でサービスディスカバリを実現 - マイクロサービス間の動的な名前解決
DNS ベースと API ベースの 2 方式でマイクロサービスのエンドポイントを動的に検出する。ECS・EKS との統合でサービスの登録・解除を自動化する手法を紹介します。
Cloud Map の概要
Cloud Map はアプリケーションリソースのサービスディスカバリを提供するサービスです。マイクロサービスアーキテクチャでサービス A がサービス B を呼び出す際、サービス B のエンドポイントをハードコードせず、Cloud Map に問い合わせて動的に解決します。DNS ベースと API ベースの 2 種類のディスカバリ方式を提供し、ECS や EKS と統合してサービスの登録・解除を自動化します。
DNS と API ディスカバリ
DNS 名前空間はサービスを DNS レコードとして登録し、service-b.my-namespace.local のような DNS 名で解決します。既存のアプリケーションは DNS クエリでサービスを検出でき、コード変更が不要です。HTTP 名前空間は DiscoverInstances API でサービスインスタンスを取得し、カスタム属性 (version=v2、environment=prod) でフィルタリングできます。ECS サービスディスカバリはタスクの起動時に Cloud Map にインスタンスを自動登録し、タスクの停止時に自動解除します。Route 53 ヘルスチェックで異常なインスタンスを検出し、ディスカバリ結果から除外します。
ECS と EKS との統合
ECS サービスで Cloud Map を有効にすると、タスクの起動・停止に連動してサービスインスタンスが自動的に登録・解除されます。 DNS ベースのディスカバリでは Route 53 に SRV または A レコードが作成され、クライアントは DNS 名でサービスを解決します。 API ベースのディスカバリでは DiscoverInstances API でヘルスチェック済みのインスタンス一覧を取得し、クライアント側でロードバランシングを実装します。 EKS では AWS Cloud Map MCS Controller を使い、 Kubernetes Service を Cloud Map に自動同期できます。ヘルスチェックは Route 53 ヘルスチェックまたはカスタムヘルスチェック (アプリケーションが UpdateInstanceCustomHealthStatus API を呼び出す方式) を選択できます。 サービスディスカバリの構成パターンを網羅的に学ぶなら、技術書 (Amazon)を参照してください。
Cloud Map の料金と運用
Cloud Map の料金はリソースの登録数と API コール数で決まります。DNS クエリは Route 53 の標準料金が適用され、DiscoverInstances API は 100 万リクエストあたり 1 ドルです。インスタンスの登録・解除が頻繁に発生するオートスケーリング環境では API コール数が増加するため、クライアント側でキャッシュを実装してコストを抑えます。名前空間の設計では、環境 (dev/staging/prod) ごとに名前空間を分離し、サービス名は環境間で統一することで、アプリケーションコードの環境依存を排除します。CloudWatch メトリクスで DiscoverInstances の呼び出し回数とレイテンシを監視し、異常な増加を検知します。
サービスレジストリとしての役割
Cloud Map は、どのサービスがどこで動いているかを記録する登録簿 (レジストリ) として機能します。マイクロサービス構成では、サービスのインスタンスが増減し、配置先も動的に変わるため、固定のエンドポイントを前提にできません。Cloud Map に現在稼働中のインスタンスを登録しておけば、呼び出す側は常に最新の所在を問い合わせて解決できます。サービスメッシュのような上位の仕組みと組み合わせる場合も、この登録簿が土台になります。サービスの所在を一元管理することで、動的な環境でも安定した呼び出しを実現します。
ヘルスチェックの設計
ディスカバリの結果に異常なインスタンスが混ざると、呼び出しが失敗してしまいます。Cloud Map はヘルスチェックと連動し、健全なインスタンスだけを返すように設計できます。ネットワーク経由で状態を確認する方式と、アプリケーション自身が自らの健全性を報告する方式があり、要件に応じて選びます。コンテナ環境では、タスクの起動・停止に連動して登録と解除が自動化されるため、停止したインスタンスへ振り向けられる事故を防げます。健全性の判定基準とチェック間隔を適切に設定し、障害時に素早く切り離せるようにします。
コンテナ以外やハイブリッドでの利用
Cloud Map は ECS や EKS との統合が手軽ですが、それ以外のリソースも登録できます。API を使えば、EC2 インスタンスやオンプレミスのサーバー、外部のエンドポイントを手動またはプログラムから登録し、同じ仕組みで名前解決の対象にできます。これにより、コンテナと従来型のサーバーが混在する環境でも、サービスの所在を一元的に扱えます。移行期にあるシステムや、ハイブリッド構成のアプリケーションで、新旧のコンポーネントを統一的に発見できる点は、段階的な近代化を進めるうえで役立ちます。
障害時の挙動と設計上の注意
サービスディスカバリを使う際は、解決結果のキャッシュと鮮度のバランスに注意します。DNS で解決する場合、TTL が長すぎると古いインスタンス情報が残り、停止済みの宛先へ接続を試みる恐れがあります。逆に短すぎると問い合わせが増え、コストやレイテンシに影響します。クライアント側で適切にキャッシュしつつ、ヘルスチェックで異常を素早く除外する設計が要点です。登録・解除が頻繁なオートスケーリング環境では API 呼び出しが増えるため、キャッシュ戦略を工夫して負荷とコストを抑え、安定したサービス間通信を維持します。
まとめ
Cloud Map の導入は、ECS サービスディスカバリとの統合が最も手軽な入口です。ECS サービスで Cloud Map を有効にするだけで、タスクの起動・停止に連動したサービス登録が自動化されます。既存のアプリケーションが DNS で名前解決している場合は DNS 名前空間、カスタム属性によるフィルタリングが必要な場合は HTTP 名前空間を選択します。名前空間の設計では、環境 (dev/staging/prod) ごとに分離し、サービス名は環境間で統一することを推奨します。