こんにちは。koarakkoです。皆さんサービス・ディスカバリしていますか？
re:invent期間中、サービス・ディスカバリのサービスがリリースしました。
以前からサービス・ディスカバリの機能はあったのですが、今回のリリースによってECS,Fargate,EKSを統合的に管理できます。
最終日にこちらのセッションを聴講してきましたので、Cloud Mapについて書きたいと思います。
AWS re:Invent 2018: [NEW LAUNCH!] Introducing AWS Cloud Map (CON366)
サービス・ディスカバリとは？
コンテナ環境では事前にDockerイメージをビルドしておき、それをアプリケーション環境にデプロイします。
機能拡張などでアプリケーションを変更する際は、稼働している環境に設定変更せず（イミュータブル）、都度新しいDockerイメージをデプロイします。
その結果、コンテナのIPアドレスがダイナミックに変更され、アプリケーション構成を把握するのが難しくなります。
この問題を解決する手段として、サービス・ディスカバリを利用します。
サービス・ディスカバリの機能
サービス・ディスカバリは、一般的に以下のことができます。
- 現状構成の把握
- ヘルスチェック
- アプリケーション間の接続性を向上
現状構成の管理
すべてのアプリケーションをサービス・ディスカバリによって、ECS,Fargaet,EKSの構築時に自動登録されます。
ヘルスチェック
サービス・ディスカバリは常に、アプリケーションのヘルスチェックを行っています。
何かアプリケーションに異常があれば、異常あったアプリケーションに対するエンドポイントを停止できます。
アプリケーション間の接続性を向上
アプリケーションはサービス・ディスカバリに登録されたエンドポイントにて名前解決を行うことで、APIリクエストなどを行うことができます。これにより、接続元アプリケーションは、接続先アプリケーションのデプロイのたびに変更されるIPアドレス、接続先アプリケーションの変更を気にする必要がなくなります。
構築
実際にnginxアプリケーションでサービス・ディスカバリを試してみたいと思います。
Cloud Mapにて名前空間を作成
名前空間、VPCを指定し、新規作成します。数分待つと作成完了します。
ECS(Fargate）でサービス・ディスカバリを設定
サービス作成時に、先程Cloud Mapで作成した名前空間を指定します。
Route 53にも自動登録されている
DNS名前解決も可能で、Route 53(プライベートDNS)にも自動登録されてます。
検証
digしてみる
ECSと同一VPC上のEC2から確認すると以下のように結果が返却されます。
# dig nginx.frontend.cloudmap +short
10.1.1.198
台数を増やす
ECSのタスクの台数を２台に増やします。
同様にdigすると、以下ように追加された１台が登録されていることが確認できます。
# dig nginx.frontend.cloudmap +short
10.1.1.198
10.1.2.39
最後に
今回は単純なサービス・ディスカバリの登録して名前解決するところを検証しました。
コンテナの構築時にIP addressが紐づけされるため、マイクロサービスにおけるサービス間の連携が容易になると感じました。
引き続き検証をしていきたいと思います。
以上
