ECS Service Connect を雑にメモする
hassaku63サービス間通信を提供するモノ。Discovery と Service mesh を提供してくれる
VPC 内の DNS 設定には依存しない、サービス間の統一されたアクセス方法 (namespace) が提供できる。
メトリックやログの取得方法も提供できるらしいが、そこはこれ書いてる時点でイメージが沸いてない。
hassaku63公式ドキュメントの構成例より。
CloudMap による名前空間では、wordpress と mysql の2つのサービスが検出されている。それぞれが、AZ 分離した2つの Subnet ごとに1個ずつタスクが配置されている。
wordpress コンテナから mysql への接続は mysql のホスト名で行われる。Proxy を介しているのがポイントで、wordpress タスクの proxy はラウンドロビンで負荷分散をする。以前の障害情報も使って、接続するタスク (mysql) を選ぶ。その後、mysql 側の proxy が実際に同一タスク内の mysql につなぐ。
この接続構成は ECS, CloudWatch で検出できて、グラフとして可視化でき、どんなアプリケーションであっても同じ方法でメトリックを取得できる。
hassaku63用語整理
(1) port name
Task definition の設定項目っぽい。ポートマッピングの一部に名前をつけて、Service Connect だけがそれを使う
(2) client alias
Service connect の設定項目で、Endpoint(?) で使用されるポート番号を割り当てる。client alias には DNS 名が使えるっぽい。discovery name が ECS Service に供給されていない場合は、port name を Endpoint name として使うようになる。
Endpoint というのは task definition の同名パラメータを見ると良いらしい。Service に対して複数に割り当て可能。また、この設定は Service connect でのみ使うもの。
(3) discovery name
任意。task definition で指定されたポートに対して付けられる中間？の名前。CloudMap service の作成に使われる名前らしい。指定しないなら task definition のポートが使われる。
この名前は、1つの CloudMap namespace の中でユニークである必要がある。よって、discovery name を持たない Service connect 設定は1つしか使えない
(4) endpoint
URL のこと。Service Connect というサービスとしての endpoint を指している、AWS 用語としてのニュアンスが強いっぽい。ただ、実態としては task definition で自分自身以外の service に公開する名前を指す言葉として定義されている
http://blog:80grpc://checkout:8080http://_db.production.internal:99
(5) Service Connect service
ECS service における単一のエンドポイント。Service Connect の設定の一部で、Service Connect でのみ使われる。
(6) namespace
CloudMap namespace の短縮名または ARN。ECS task の論理的なグルーピングに使う。ひとつの ECS service は1つの namespace にしか所属できないが、同一アカウントかつ同一リージョンの ECS Cluster はまたぐことができる。
(7) client service
xxx
(8) client-server service
xxx
hassaku63Service Connect は同一 namespace 内の ECS service 間の接続に適したサービス。
Service connect で定義した同一の namespace の外にある ECS serviec または ECS 以外のサービスに関しては他の方法で接続する必要がある。
hassaku63
事例を使った説明の要約。以下は ChatGPT の出力
この説明を要約すると、ECS Service Connect を使ったサービス展開の手順と注意点が述べられています。
フロントエンドとバックエンドのデプロイ順序:
アプリケーションをパブリックに公開する場合、バックエンドサービスが先にデプロイされ、フロントエンドサービスが最後に作成されるようにする必要があります。これは、フロントエンドが先に公開されてしまい、バックエンドがまだ利用できない状態でエラーが表示されるのを防ぐためです。この順序を保証するために、CloudFormation の dependsOn を使用して、フロントエンドサービスがバックエンドに依存していることを示す必要があります。
Service Connect を使用したサービス接続の設定:
既存のフロントエンドサービスがあり、まだ Service Connect を使っていない場合、まずはバックエンドサービスに Service Connect 設定を追加します。DNS 名または clientAlias を使って接続先を指定します。この操作は新しいデプロイメントを作成するため、デプロイメントのロールバックが必要な場合には AWS Management Console や AWS CLI などを使って以前の設定に戻せます。バックエンドの動作が満足できたら、次にフロントエンドに同様の設定を適用します。
DNS ベースのサービスディスカバリーを使用している場合の注意点:
DNS ベースのサービスディスカバリーを使っている場合、フロントエンドやクライアントアプリケーションは、DNS キャッシュが更新されるまで、新しいエンドポイントに切り替わりません。通常、これには数時間かかります。
要するに、ECS Service Connect を導入する際は、サービス間の依存関係を適切に管理し、順序通りにデプロイすることで、エラーやダウンタイムを回避できるということです。また、ロールバックオプションが用意されており、既存の設定に問題があった場合に復元が可能です。
hassaku63
proxy はサイドカーとしてデプロイされる。ECS のユーザーから直接見えないが、task definition に追加される。
Service Connect を使うなら、かならず task definition に cpu/memory を指定する必要があり、
サイドカーに対して少なくとも 256 CPU unit, 64 MiB を追加で割り当てることが推奨。
Service Connect 用の設定にログに関するモノを追加可能。
ピーク時に 500 req/sec を超えるリクエストを受信すると予想されるなら、proxy コンテナに 512 CPU unit を追加することが推奨
作成するサービス数または起動するタスク数が大量（詳細はドキュメント）になる場合は割り当てるメモリを増設するのが推奨。
hassaku63いくつか制約があるっぽい
ローリングデプロイのみサポートしていることとか、特定のポリシー許可が必要だったり
hassaku63
実際に設定する必要がある場所の解説