Amazon ECS Service Connect の内部的な動作 [re:Invent 2022 セッション]

概要

• re:Invent 2022 のセッション動画が続々と投稿されている中で気になったサービスのセッション動画を見て超絶ざっくりまとめていくというのやっていきます。
• セッション動画自体は大体1時間くらいのものが多いので、まあそれくらいは許容できるって人はセッション動画を見ていただくことを推奨します。
• 忙しくて見れません！！！という方は、こちらでキャッチアップいただければ幸いです。

※: 深夜テンションのノリと勢いで翻訳しているので、言い回しとか適当なのはご容赦ください。ww

Amazon ECS Service Connect: Simplified interservice communication

• コンテナによるマイクロサービスが流行っている今、サービスは増え続け、増え続けるとそれらサービス間の通信はめっちゃ複雑になるよ。管理が大変だぁ。
• だってそのサービスは、例えば Dev / Stg /Prdのように環境が複数あったり、１環境内でもあるマイクロサービスの１つのサービスがバージョン管理されてるかもしれないし、コンテナのオートスケーリングとかまで考慮したらと思うと・・
• だから俺ら(aws)は良いソリューションを出してきたんだぜ

• サービス間通信を実現するための方法としては3つあるぜ。それがこれだ。
  • Amazon ECS Service Discovery
  • Elastic Load Balancing (ELB)
  • AWS App Mesh

• Amazon ECS Service Discoveryは、めっちゃシンプルになん。めっちゃシンプルになん！！！
• まあ要は、AWS Cloud Map でプライベート名前空間を作成すると、Route 53 ホストゾーンが自動的に作成されるので、ECS がスケールアップまたはスケールダウンすると自動的に更新してくれるってことですねぇ。

はーんなるほど。
これだと、トラフィックテレメトリは提供してくれないと言ってますね。なので、メトリクスとロギングに関する実装は自分らで考え出す必要があるよーと。

• Elastic Load Balancing は、よくサービス間の相互接続で使われるやつっす。
• ECS 前段に LB おいているだけだから分かりやすいー
• 使い方は、LB にECSタスクをターゲットとして登録しておくだけ。
• スケーリングしても見てくれるし、トラフィックテレメトリも提供してくれる。DDos保護とかも。
• だけどだけど、VPC内のサービスに関しては、これらの機能はっているっけ？と。
• やりすぎ感半端ないからイケてないよねと言ってます。

• AWS App Mesh は、マネージドなサービスメッシュソリューション。
• Envoy をサイドカーに配置してプロキシとして使うやつね。
• しかも、ユーザに代わってメトリクスを収集してくれる
• んで、きめ細かいトラフィック制御もできると、例えば暗号化とか認証とかも。
• だけど柔軟すぎてちょー複雑。

そうだからこれらの良いところを組み合わせられんのかと考えた・・・
そして、生まれたのは「Amazon ECS Service Connect」

ふーー！Yeahh

• 使い方は、簡単よ。アプリケーションを作成した時にトラフィックが流れるエンドポイントを指定するだけよん
• 接続も簡単で、メトリクスもECSのマネコンかCloudWatchから見れるときた。

実際にやってみると

• まずは、サービスの名前を決めて、名前空間も定義する。
• クライアントは、サービス名と名前空間の組み合わせで接続するよん。
• ECSクラスターを跨いだ名前空間の指定もできるよん。
• VPCを跨いだ指定もできるよん。
• AWSアカウントを跨ぐのはできないよん。
• リージョン跨ぐのもできないよん。

• Reliablity も担保してるぜ！
• 例えば、トラフィックレベルのヘルスチェックをして異常検出の処理とかもやってる。
• エラーによる失敗が起きても再試行を自動でやってたりもする。

• ECS Service Connect 使うとゼロダウンタイムのデプロイもできるぜ。
• connectionドレインをサポートしている。
• アプリケーションが正常なエンドポイントに接続できるようにヘルスチェックとかサポートしているので、デプロイ時にタスク置き換えが発生しても、トラフィックの制御が入るのでということを言いたいらしい。

こう動くをこれから話すぜ。あとは頼んだ。でSDEの人がいろいろ語り始める。

• 実際にサービスコネクトを設定するときは下記のような設定を書くらしい。

• そして、基本的なECSでサービス作る時の動きを話してますねっ!(ケイスケホンダ風)

• ECSにリクエスト送ると、インスタンスが作成され、タスク定義をもとにタスクができると。

• んで、ECS Service Connect を有効にしているとこんな感じに、ECS Task に Service Connect Agent が追加されるらしい。

• そして、Service Connect Agent の中身は、Envoy と Agent の2つのコンポーネントがいる。

• Agent 側は、Envoy の正常性を監視し、常に稼働しているらしい。また、Envoyが提供するメトリクスをCloudWatch に 60秒間隔でPushしているらしい。

• 次に Service Connect にリクエストを送るとどうに動くのかを説明しています。
• フロントエンドがいてバックエンドがいてというサービスを仮定してます。
• ユーザはフロントエンドにリクエストをくるために前段の LB に対してリクエストが送られてくると、LB はフロントエンドのサービスに、フロントからバックエンドは直接通信してます。
• リクエストを受けると、LB は フロントエンドサービスが実行されているポートに送信。
• リクエストは、Service Connect に送信されるか、Service Connect Agentにリダイレクトされるように設定
• 下記の図が分かりやすいですね。

• 次は Reliable についてですね。

• 例えばバックエンド側のタスクが何かしらの原因で落ちた時に、フロント側のService Connect agent は、通信したけど死んでるタスクを検知して、別のエンドポイントへ自動的に再試行する。

• なるほど、バックエンド側のタスクがずっと例えば5XXを返す場合だと、Service Connect Agent が正常なルーティング先のリストから一時的にエンドポイントの情報を削除する動きとかもやってくれるらしい。

• 最後に Deployについて語っています。

• Deploy 時も Reliable で語っていた動作と一緒ですね。
• タスクの状況で例えばまだDepoly直後で正常稼働できないタスクがあった時も、検知して、接続を受け入れられないタスクのエンドポイントではなく、別のエンドポイントに対して再ルーティングするみたいですね。
• いやぁよくできている。

• このあと、価格や対応リージョン、後日あったワークショップの案内とかの話だったので、割愛。

まとめ

• Amazon ECS Service Connect は便利
• ワールドカップ期間中は寝れん。
• 以上！！

参考資料