「CloudMapとECS Service Connectの名前解決比較してみた」というタイトルでLTしました
はじめに
こんにちは。コンサルティング部の津谷です。
8/28(木)に行われたJaws-UG東京支部のランチ会でLTしてきました。（だいぶ時間が空いてしまいましたが,,,）
登壇資料
登壇資料はこちらになります。
参加した感想
他の方のLTを聞けるというのが大きな勉強でした。
- 自分の知らないAWSサービスや領域を知るきっかけになる
- 業務で困っていることをどういう風に解決したかといった現場の声が聴ける
自分視点の話だと、ブログで実践したことや業務で触れた技術をアウトプットする場として最適だと思いました。
わかりやすく人に説明するということは自分自身が深く理解していないと難しいので、LTまでの過程でより解像度が上がった気がします。
登壇内容
以前、CloudMapを使ったDNSクエリの名前解決は検証していました。
そこで浮かび上がったのは、「Service Connectでの名前解決と何が違うのだろう」という疑問でした。
せっかくなので、Service Connectも試してみてアウトプットしてみようと思いました。
ECSのようなコンテナサービスでは、スケーリングによってホストの情報が切り替わります。そのたびに、名前解決設定を手動で入れるのは大変です。そんな時に変化したリソース情報を動的にとってきて、DNSに反映できたら楽ですよね。
CloudMapでは名前空間を作成すると、Route53にプライベートホストゾーンが作られます。サービスを名前空間に登録してあげると、サービスレジストリという情報庫にサービスの情報を登録してくれます。
CloudMapはこのサービスレジストリの情報を参照してきて、プライベートホストゾーンにサービスのIP情報を格納します。Route53や、マイクロシステムを作るうえで真っ先に候補に挙がるECSなどとネイティブに結合してくれているので便利なサービスです。
一方、Service ConnectはECSに特化したマイクロシステム間通信を実装します。
アプリケーションを起動するタスクを定義した場合、Service Connectを有効化すると同タスク内にEnvoyプロキシコンテナーがサイドカー構成として立ち上がります。このプロキシコンテナがCloudMapによしなに情報を渡してくれるため、リクエスト元としては、名前解決を意識的に行う必要がありません。
CloudMapの機能を内包しているものの、自分としては内部でどういう風に名前解決しているのか気になったので調べたところ、アプリコンテナのホストファイルにプロキシへの経路が記載されていました。つまり、コンテナがEnvoyプロキシへ名前解決をフォワードして、プロキシ側でCloudMapへ情報を渡して名前解決をしているんです。
詳しくは、スライドを見てみてください。
さいごに
定期的にアウトプットの機会を増やすことで、忘れていた知識を思い出したり、新しい知識を定着させることができると実感しました。また機会があれば積極的に参加してみようと思います。
