直近のインフラ案件では、ECSでサービスを構成していることが多いですが、周辺でよく使われているサービスについて再度まとめさせていただこうと思っております。
Contents
ロードバランサー系
ECSでサービスを構成する場合、ロードバランサー(ALB)を使うことになることが一般的かと思います。
リスナー
具体的なトラフィックの監視で、ロードバランサーの窓口に当たるかと思い、以下の情報を定義します。
- ポート
- プロトコル:HTTP or TCPなど
- 紐づくロードバランサー
- 実際にポートを受けたとった時の転送先(後述するターゲットグループがメイン)
ターゲットグループ
リスナーから転送されたトラフィックの具体的な処理に該当します。
実際にはここがECSサービスの窓口となっていることが多いです。
またヘルスチェックも定義します。(30秒ごとに特定のhtmlファイルを叩いて、3回連続で200が返ってこないとエラーを返す、など)
ECS
実際のECSを動かす部分ですが、主にクラスター、サービス、タスクの3つを使うことが中心です。
クラスター
ECSの一番大きなグループになります。基本的にはこの中にサービスを入れて管理します。
サービス
実際のタスクの管理人のような位置付けだと思います。
サービスがなくてもタスクを起動することは可能ですが、その場合、ダウンして復活などをさせることができませんので、実質必須と言っていいと思います。
主に
- 紐づくロードバランサー(正確にはターゲットグループ)
- タスク実行数
- 実行コンテナの種類:EC2 or Fargateなど
などを定義します。
タスク
コンテナが実際に起動される部分です。
JSON形式で具体的に動かすコンテナのイメージやロール、ポート、ログ情報などを別途定義します。
以下がサンプルになります。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/example_task_definitions.html
CICD
ECSとは別なのですが、CICDはセットで組み込まれていることが大分ため、併せて説明をしてしまいます。
CodeBuild
ソースがcommitされた後の実際のソースとなる成果物をビルドする作業を、S3バケットに格納する、といった作業を行います。
CodeDeploy
デプロイの開始、管理、履歴管理などの一元管理が可能です。
特徴としては各環境のデプロイの自動化、ダウンタイムの最小化、履歴保存などが行えます。
CodePipeline
CICDのオーケストレーション自体のワークフローを管理するツールです。
ソース、ビルド、テスト、デプロイなどの可視化、管理などを行います。
周辺のリソース
eventBridge
各種のイベントが起こった時に検知して別サービスに繋ぐサービスです。
例えばS3にファイルが上がった際に、CodeBuildをトリガーにする、など各リソースの橋渡しを行います。
ApplicationAutoScaling
ECSで一定の負荷をがかかった時に、どの程度のタスク数を起動させるかなどの設定を行います。ECS専属ではなく、さまざまなサービスで使用可能のようです。
サービスディスカバリー
まだ正確にはわかっていませんが、動的に変化するサービスの場所(IPやポート)を自動検出し、サービス間の通信を容易にする仕組みのようです。
