【AWS】ECSのクラスターの目的と作成の流れ #AWS

AWSでDockerを扱うサービスである、ECS（Elastic Container Service）のクラスターの目的と作成方法について。

ECSのクラスターとは？
クラスターを使ったサービスの流れ
クラスターの作成
ECSのクラスターテンプレートの選択
クラスターの設定
サービスの作成
デプロイメントの設定
ネットワーク構成
サービスの作成
ELB（ロードバランサー）の修正
ページの表示

ECSのクラスターとは？

AWSの説明では、タスクリクエストを実行できる１つ以上のコンテナインスタンスのリージョングループ。

実用例だと、一つのプロジェクトに対し、一つのクラスターを作り、中にサービスとして、ステージング環境や開発環境をいれる。

各サービスの中にはタスクを作って、タスクの中で必要なコンテナを定義している。

▼クラスター、サービス、タスク、コンテナの関係

ECSでクラスターを作成する場合は、単にクラスターを作成するだけでなく、サービスの作成、ロードバランサーの設定、デプロイ方法の指定も行う。

クラスターを使ったサービスの流れ

複数のサービスを一つのロードバランサーで切り分ける場合のAWSの設定方法について。

・サービスの構造

クラスターはプロジェクトを管理しやすくするためのグループといった位置付け。

その中にproductionやstagingといったサービスを作成する。

実際のサービスの根幹となるコンテナはタスクの中に定義する。このタスクをサービスの上に乗っける。

・ネットワーキングの構造

ユーザーがFQDN（sub.example.com）を入力すると、該当するエイリアスコードからホストドメインにつなげる。

ホストドメインにはロードバランサーが設定されており、渡されたFQDNに結び付けられたコンテナにトラフィックを送る。

コンテナはリクエストに応じて、DBなど必要な別のコンテナと連携してレスポンスを返す。

クラスターの作成

1. ECSのクラスターテンプレートの選択

どの仮想サーバーでコンテナを起動するか選択する。

タイプ	内容
ネットワーキングのみ	Fargate起動タイプを使用してタスクを実行する
EC2 Linux + ネットワーク	Linux コンテナを使用した EC2 起動タイプを使用してタスクのクラスターを起動する
EC2 Windows + ネットワーク	EC2 起動タイプと Windows コンテナを使用してタスクのクラスターを起動する

Fargateは運用管理をAWSが行ってくれるメンテ・保守不要のサーバー（サーバーレス）

2. クラスターの設定

サービスを起動するためのクラスターを作成する。クラスター自体の作成は超簡単。

2-1. クラスター名（必須）

最大 255 文字の英字 (大文字と小文字)、数字、ハイフン、アンダースコアを使用できる。

2-2. ネットワーキング（任意）

クラスター用に新しいVPC（Virtual Private Cloudの略。仮想プライベートクラウド）を作成する場合はチェックを入れる。

▼作成する場合
クラスター専用のVPCを作成する場合は、CIDRブロック、サブネットを設定（デフォルトでも可）する。

2-3. Tags（任意）

クラスターの説明をKV（key-value）形式で記載できる。

クラスタ作成後にTagsタブから確認できる。

2-4. CloudWatch Container Insights（任意）

チェックマークを入れるとCloudWatchと連携して、CPUやメモリの使用状況のログが確認できるようになる。

▼ECSクラスターのCloudWatch例

2-5. クラスターの作成

右下の「作成」ボタンをクリックしてクラスターを作成する。

以上でクラスターの作成は完了。

3. サービスの作成

作成したクラスターの中にサービスを作成していく。

サービスを作成するにはECSのタスク定義で、コンテナの起動時の設定が完了している必要がある。

・ECSでタスク定義する方法

3-1. サービスを作成するクラスターの選択

作成したクラスターを選択する。

サービスタブの中で、左下の「作成」ボタンをクリックする。

3-2. 起動タイプの選択

タスクを実行する仮想サーバ−の種類を選択する。選択しない場合はEC2がデフォルトとなる。

3-3. タスク定義

ECSのタスク定義で作成した項目を選択する。

タスク定義を内容を変更して複数作った場合は、使用する番号（リビジョン）を選択する。

▼ECSのタスク定義

3-4. サービス名

作成するサービスにつける名前を指定する。
クラスターを選択した時に、表示されるためわかりやすい名前にする。

↓ 表示例

▼Point
クラスターの名前でどのプロジェクトかは判定可能なため、サービスの名前は各サービスの環境の名前をつけるとわかりやすい。

例

・クラスター名： test-app
・サービス名１： production
・サービス名2: staging

3-5. サービスタイプとは？

タスクが失敗したときの対応方法を指定する。スケジュール戦略と呼ばれる。

サービスタイプ（スケジュール戦略）は①REPLICA戦略と②DAEMON戦略の２つがある。

Fagateを選択した場合は、REPLICA戦略のみとなる。（DAEMONはサポート外）

・REPLICA戦略
クラスター全体で必要数のタスクを配置して維持。

・DAEMON戦略
指定したすべてのタスク配置制約を満たすクラスター内のアクティブなコンテナインスタンスごとに、1 つのタスクのみをデプロイ。

3-6. タスクの数

サービスタイプがレプリカの時のみ選択する。

上で指定したタスク定義で起動したインスタンス（コンテナ）のうち、クラスターで実行状態を保つ数を指定する。

起動するコンテナが１つのみの場合は１となる。複数のコンテナを起動し、起動状態を保ち続ける場合は、その数を記載する。

なお、デーモンの場合は、クラスターのコンテナインスタンス数に自動的に設定。

3-7. 最小ヘルス率と最大率

ローリングアップデートのみ選択可能なオプション。

実行中のサービスをローリング更新するときに、サービスが維持するタスクの数を割合で指定する。

最小ヘルス率とは？

RUNNING状態に保つ必要のあるサービスのタスクの下限数を％で指定したもの。

例えば必要なタスクが４つのサービスで、最小ヘルス率を50％とした場合、スケジューラーが新しいタスクを実行する時に、２つのタスクを停止して、クラスターの容量を開放する。

最小ヘルス率はデフォルトで100％。

最大率

最大ヘルス率の略。RUNNINGまたはPENDING状態で使用できるサービスタスクの上限数を指定できる。

例えば必要なタスクが４つのサービスで、最大率が200%の場合、スケジューラは4つの古いタスクを停止する前に、4つの新しいタスクを開始することができる。

最大ヘルス率のデフォルト値は 200% です。

Blue/Greenデプロイタイプの場合

実行中のサービスの更新がBlue/Green (CODE_DEPLOY) の場合は、最小ヘルス率・最大ヘルス率の値はデフォルト値に設定される。

最小ヘルス率： 100%
最大ヘルス率： 200%

つまり、本番環境のサービスを改修してローンチするときに、既存のタスクは停止せず起動したままの状態で、新しいサービスを起動する。

この方法であれば、新しいサービスに問題があった場合にすぐに古いサービスに戻すことができる。容量は使うが安全な更新。

3-8. Deployment circuit breaker

ローリングアップデートのみ選択可能なオプション。

サービスの更新に失敗した場合に、自動で昔の正常だったサービスに戻してくれる便利機能。

＞https://aws.amazon.com/jp/blogs/news/announcing-amazon-ecs-deployment-circuit-breaker-jp/

Blue/Greenの場合は自動的にRollbackしてくれるため設定不要。

というか、ローリングアップデートの設定で、デフォルトの最小ヘルス率： 100%、最大ヘルス率： 200%、Deployment circuit breakerが有効でrollbackがオンになっているデプロイをBlue/Greenと呼ぶ。

4. デプロイメントの設定

サービスを更新したときに、新しいサービスの起動方法を指定する。

4-1. Blue/Green

ブルー・グリーンと呼ぶ。直近では主流のデプロイ方法。

サービスの更新を安全に行うために、既存のサーバーに手を加えるのではなく、既存のサーバーはそのまま維持しながら、新しいサーバーを起動するデプロイ方法。

新旧のサービスで状態を比較し、異常があればエラーとして報告してくれる。

また、新しいサービスが起動しない場合は、自動で旧のサービスに戻るため、サービスが落ちる心配がない。

Blueが古いサービス、Greenが新しいサービスを指している。

4-2. ローリングアップデート

実行中のタスクを順々に停止して、順々に新しいサービスに切り替えていくデプロイ方法。

Blue/Greenよりも簡易的でスピーディな更新方法。

ただし、どれかのタスク更新で失敗した場合、更新済みのタスクと更新エラーのタスクが混在することになり、元に戻すのに手間がかかる。（このため、現在のトレンドはBlue/Green）

Deployment circuit breakerなど、より安全にサービスを更新する仕組みが用意されている。

ローリングアップデートの設定で、デフォルトの最小ヘルス率： 100%、最大ヘルス率： 200%、Deployment circuit breakerが有効でrollbackがオンになっているデプロイがBlue/Green。

4-3. Deployment configuration

デプロイ中にCodePlayが使用する条件を選択する。

旧サービスにアクセスしているトラフィックの何％ずつを新しいサービスに移行させるかの、％と経過時間を指定できる。

設定	内容
CodeDeployDefault.ECSAllAtOnce	すべてのトラフィックを、新しいコンテナに一度に移行。
CodeDeployDefault.ECSLinear10PercentEvery1Minutes	すべてのトラフィックが移行されるまで、1分ごとに10%を移行
CodeDeployDefault.ECSLinear10PercentEvery3Minutes	すべてのトラフィックが移行されるまで、3分ごとに10%を移行
CodeDeployDefault.ECSCanary10Percent5Minutes
最初にトラフィックの10%を移行。残りの90%は5分後にデプロイ
CodeDeployDefault.ECSCanary10Percent15Minutes	最初にトラフィックの10%を移行。残りの90%は15分後にデプロイ

基本的にはCodeDeployDefault.ECSAllAtOnceを選択。

4-4. CodeDeployのサービスロール

CodeDeployがBlue/Greenで自動更新する際に、ユーザーに変わってAWSに許可を与えるためのIAMロール。

CodeDeploy IAMロール（ecsCodeDeployRole）として設定する。

＞https://docs.aws.amazon.com/AmazonECS/latest/developerguide/codedeploy_IAM_role.html

5. ネットワーク構成

5-1. VPCグループの設定

タスク定義のネットワークグループがAWS VPCの場合に設定可能。

タスク定義のプラットフォームにFagateを選択している場合は、AWS VPCのため設定できる。

・クラスターVPC
タスクやサービスのサブネットとセキュリティグループを表すオブジェクト。

・サブネット
タスクやサービスに関連づけるサブネットワーク。

・セキュリティグループ
タスクやサービスに関連づけるセキュリティグループ。

デフォルトは新規で自動割り当て。既存のセキュリティーグループから選ぶことも可能。

・パブリックIPの自動割り当て
ENI（Elastic Network Interface）がパブリックIPアドレスを受け取るかどうか。

EnableかDisableで選択する。

5-2. ロードバランサーの設定

タスク間のトラフィックを分散させる。事前にEC2コンソールでロードバランサーを作成しておく必要がある。

ロードバランサーはApplication Load Balancer（HTTPやHTTPSを振り分ける）か、Network Load Balancer（超高性能タイプ）から選択できる。

ロードバランサーとRoute53のエイリアスレコード

ロードバランサーでタスク内のコンテナにアクセスするために、Route53のエイリアスレコードを作成しておく。

ネットワーキングの流れは、

リクエスト
↓
ロードバランサ
↓
コンテナ

となる。

・エイリアスレコードの作成手順

5-3. ロードバランサー用のコンテナを設定

指定したタスクの中で定義したコンテナが選択できる。（コンテナが１つの場合は選択肢は１つ）

↓ 追加ボタンをクリック

・プロダクションリスナーポート
HTTP（80）かHTTPS(443)を選択。

指定したロードバランサーで設定してあるリスナーを選ぶ。

▼ロードバランサーのリスナーの例

▼80番ポートの設定例

ここでは、80番ポートにアクセスした場合、443番にリダイレクトする指定になっている。このため、プロダクションリスナーポートは443を選択。

・テストリスナー
ロードバランサーでルーティングする前に飛び先のアプリケーションをテストする。

不要の場合はチェックを外す。

5-3. ロードバランス用のコンテナを設定

ロードバランサーでトラフィックを接続するための、コンテナにターゲットグループを作成する。

▼ターゲットグループの名前
既存、または新規作成する。

▼ターゲットグループのプロトコル
コンテナの開放ポートに繋ぐ。80番を開けている場合はHTTPにする。

▼パスパターン
ロードバランサーのIF文で、〇〇のパスならの部分に当たる。

スラッシュ以下のパスしか入力できないため、FQDN（サブドメ）を入力したい場合は、ここはダミーを設定しておき、別途ロードバランサーで設定する。

▼評価順
if文を処理をかけていく順番。番号が小さい条件から検証していく。

5-4. ヘルスチェックパスの設定

ヘルスチェックを実行するパスを設定する。
ロードバランサーで（ELBコンソール）で設定する。

5-5. ２つめのターゲットグループの作成

デプロイの方法でBlue/Greenを選択した場合は、ターゲットグループを２つ入力する必要がある。

新しいGreenのターゲットグループ２にアクセスしたときにエラーが発生した場合、Blueのターゲットグループ１にトラフィックを戻すため。

▼パスパターン
選択不可。ターゲットグループ１のパスパターンを継承する。

5-6. Auto Scaling

CloudWatchでアラームがでた場合に、オートスケーリングするかどうか。

Auto Scallingする場合は、最小・最大タスク数などを選ぶ。

6. サービスの作成

作成ボタンを押すと、５つのサービスが一気に作成される。

ロードバランサーのターゲットグループ１
ロードバランサーのルール
ロードバランサーのターゲットグループ２
サービスの作成
Blue/Green デプロイメント（CodeDeploy）

※注意
それぞれが別々のサービス上に作成されるため、ミスがあった場合は、全てを削除する必要がある。

↓　サービスを表示

以上でクラスターの作成が完了。

7. ELB（ロードバランサー）の修正

5-3のロードバランス用のコンテナを設定ではFQDNを入力することができずダミーを入力したため、ELBコンソールから入力内容を修正する。

ELB（ロードバランサー）から指定のロードバランサーを選択し、ルールを表示する。

先ほどダミーで登録したルーティングが追加されている。

上の鉛筆マークをクリックしてこれを編集する。

FQDNを入力したいため、ホストヘッダーを選択する。

修正が完了したら、右上の「更新」をクリックして完了。

ロードバランサーの注意点

バランサーはユーザーとサービスを繋ぐためとても重要。

間違って既存のルーティングを変更したり削除してしまうと、サービスにアクセスできなくなってしまうため注意が必要。

Route53とバランサーはサービスの根幹で、他のサービスともつながっている場合も多いため注意すること。

8. ページの表示

以上でAWS上での設定が完了。

クラスターで該当のプロジェクトを確認したときに、RUNNINGになっていればOK。指定したURLを入力すればページを開くことができる。

ページはイメージの中で定義したルーティングやビューに従う。

ページが表示されない場合は、ヘルスチェックでサーバーが動いているか確認するなどの方法がある。（別途設定が必要）

▼ヘルスチェックの例

以上。

【AWS】ECSのクラスターの目的と作成の流れ

目次