目次
- 前回の記事
- ECSについて
- 本記事での前提
- クラスター作成
- タスク定義作成
- サービス作成
- ECSタスクへアクセス
- オートスケーリング設定
- 注意:セッション管理で発生した問題
1. 前回の記事
前回の続きからECSを構築していく
2. ECSについて
本記事では、ECRで管理されているイメージをECSで動かすための手順について記載する。
Q. ECSとは?
Elastic Container Service
コンテナを動かすためのサービス
4つの要素があり、階層的に管理されている
なお、類似するサービスでEKSが存在するが、今回は動かすシステムの規模を考慮して触れない
Q. KubernetesとEKS(Elastic Kubernetes Service)とは
Kubernetesは複数のコンテナを管理・連携させて動作させるためのツール
大規模なシステム向けとなり、EKSはKubernetesを使うためのサービス
3. 本記事での前提
今回は以下を例として、ECS以外の構築はすべて完了している前提で進める

(詳細はこの記事を参照:【計画】AWS ECS(CaaS)構成でWebアプリを構築する)
それでは次章から具体的な構築を進める
4.クラスター作成
基本はデフォルト通り入力し、インフラストラクチャがFargateになってることだけ注意する

Q. Fargateとは?
コンテナをサーバーレスで実行する環境
ほかの実行環境ではEC2(サーバー有)が存在するが、今回はサーバー管理をする理由はないためFargateにする
5. タスク定義作成
クラスターの次にタスクを定義する
ロールを指定する必要があるため、事前にロールを作成する
ロール作成
ECSのタスク用に"タスクロール"と"タスク実行ロール"を作成する
Q.タスクロールとタスク実行ロールの違い
タスク実行ロール:コンテナを「起動するための権限」
タスクロール:コンテナ内の「アプリが使う権限」
それぞれでユースケースとポリシーを設定する
Q. ユースケースとポリシーとは
ユースケース:誰がこのロールを使うか
ポリシー:何をしていいのか(権限)
●タスク実行ロール作成
タスク用の権限のため、信頼されたエンティティのユースケースでECSのTaskを指定する
許可の追加では、以下を指定する
-
AmazonECSTaskExecutionRolePolicy
ECSがコンテナを起動するために必要な最低限の権限セット -
AWSSecretsManagerClientReadOnlyAccess
SecretsManagerを参照する用の権限
●タスクロール作成
タスクロールでも信頼されたエンティティではECSのTaskをユースケースに指定する
許可は以下二つ
-
AmazonSSMManagedInstanceCore
Systems Manager(SSM)を利用するための権限 -
SecretsManagerReadWrite
Secrets Manager内のシークレットを参照・更新するための権限
タスク定義作成
特筆事項
-
起動タイプはAWS Fargate
-
条件付きタスクロールに、先ほどのロールを付与する
-
ログ収集はデフォルト設定にする
これでタスク定義の作成が終わり、コンテナ設定も作成される
次はサービスを作成していく
6.サービス作成
特筆事項
- 冗長化するため、必要なタスクは2にする
- ネットワーキングでは、別のAZに存在するPrivateサブネットを2つ指定する
- インターネットに公開しないのでパブリックIPはオフ
- ロードバランシングでターゲットグループを指定すると、その中にタスク用のIPアドレスが登録され、リスナーによってHTTP通信が転送されるようになる(別途、ALB等の設定は必要)
ヘルスチェックについて
サービスを作成すると、ターゲットグループのヘルスチェックが始まる
詳細はターゲットグループのページから見れる

内容について
30秒間隔で/loginパスにHTTPアクセスし、200コードが返るか確認する
- 5連続成功:正常と判断
- 2連続失敗:非正常と判断
Q. なぜ/loginを指定するのか
アクセスするのにセッション情報を必要とする場合、成功コードを取得できない
そのため初期ページを指定した
動作確認
※HTTPS・ドメイン付与はほかの設定が必要(以下参考記事)
ここから先はWeb公開の手順以外で、別途対応・確認した内容になる
7. ECSタスクへアクセス
Cloud Shell(ECS Exec+SSM経由)でECSタスクへアクセスできるようにする
まずは、ECSサービスを更新し、ECS Execを有効化し、再デプロイする

その後、ECSタスクからコンテナを選択し、接続ボタンを押下する

これでCloud Shellが開きアクセスできるようになった

RDSへのアクセスなどの場面で利用する
8. オートスケーリング設定
CPU使用率に応じて、タスク数を自動で増減できる設定を追加する
サービス画面の"サービスの自動スケーリング"を見て、"タスクの数を設定"を押す

今回は以下の内容で作成し、CPUの使用率70%をしきい値としてタスク数を増減させる

作成後CloudWatchを見ると、スケーリングログが確認できる

9. 注意:セッション管理で発生した問題
タスク数を2にしたら、セッション情報の保持で次のような問題が出た
タスクAでログインしセッション情報が保存される
↓
別ページへの遷移時、タスクBが割り当てられる
↓
タスクBにはログインセッションがないからログインページに戻される
対策として、ターゲットグループで維持設定を有効にしたところ、問題は解決した

Q. 解決した理由は?
同一ユーザーを同一タスクへ振り分け続けるようになったため
・セッション:ログイン情報等を保持し、タスク側で管理
・Cookie:セッションIDを保持、ブラウザで管理
ログイン時、ブラウザはCookie内のセッションIDを用いてセッション情報を参照する。しかし今回は、タスクごとにセッション情報が分かれていたため、別タスクへ通信されるとログイン情報を参照できなくなっていた。先ほどのチェックを有効化したことで、同一ユーザーが同一タスクへ継続して振り分けられるようになる。























