Day 13: ロードバランサーとオートスケーリング：高可用性なサービスを構築しよう 📈
皆さん、こんにちは！30日集中講座、Day 13へようこそ。
昨日、ECS on Fargateを使ってコンテナをAWS上で動かすことに成功しましたね。しかし、昨日の構成には2つの大きな課題がありました。
- 単一障害点: 1つのタスク（コンテナ）しか動いていないため、そのタスクが停止するとサービス全体が停止します。
- スケーラビリティ: アクセスが増加しても、自動でコンテナ数が増えるわけではありません。
今日の講座では、これらの課題を解決するAWSの強力なサービス、Application Load Balancer (ALB) と ECS Auto Scaling を使って、高可用性とスケーラビリティを備えたサービスを構築する方法を学びます。
1. なぜロードバランサーが必要なのか？
ロードバランサーは、複数のサーバーやコンテナにトラフィックを分散させるための仕組みです。特にApplication Load Balancer (ALB) は、HTTP/HTTPSリクエストを、ターゲットとなるECSタスクに振り分けます。
- 単一のエンドポイント: 複数のタスクがあっても、ユーザーはALBの単一のURLにアクセスするだけで済みます。
- 高可用性: ALBは、正常なタスクにのみトラフィックを転送します。タスクがダウンしても、ALBが自動で検知し、トラフィックを切り離してくれるため、サービスの可用性が向上します。
- 動的なIPアドレス: タスクのIPアドレスは再起動するたびに変わりますが、ALBはECSサービスと連携して、動的に変化するタスクのIPアドレスを自動で追跡してくれます。
2. ステップ・バイ・ステップ：ALBとECSサービスの連携
ECSサービスにALBを設定する手順は以下の通りです。
ステップ2-1: ターゲットグループの作成
ターゲットグループは、ALBがトラフィックを転送する先のグループです。
- AWSコンソールでEC2サービスに移動し、「ターゲットグループ」から 「作成」 をクリックします。
- ターゲットタイプは 「IP addresses」 を選択します。ECS on Fargateでは、各タスクが独立したENI（Elastic Network Interface）を持つため、このターゲットタイプを選ぶ必要があります。
- プロトコルはHTTP、ポートはコンテナのポート
5000を指定します。 -
ヘルスチェック設定: ALBがタスクの状態を監視する設定を行います。
-
ヘルスチェックパス:
/healthまたは/ -
成功コード:
200 -
間隔:
30秒 -
タイムアウト:
5秒 -
正常しきい値:
2回連続成功 -
異常しきい値:
2回連続失敗
-
ヘルスチェックパス:
ステップ2-2: ロードバランサーの作成とリスナー設定
- EC2コンソールの「ロードバランサー」から、「Application Load Balancer」 を作成します。
- ネットワークマッピング: ALBはインターネットからのアクセスを受けるため、パブリックサブネットを選択します。
-
セキュリティグループ:
-
ALB用SG: インバウンドルールで、ポート
80（HTTP）と443（HTTPS）を**CIDR0.0.0.0/0**から許可します。 -
ECSタスク用SG: インバウンドルールで、コンテナのポート
5000をALB用セキュリティグループからのみ許可します。これにより、ALB経由でない直接アクセスを遮断できます。
-
ALB用SG: インバウンドルールで、ポート
ステップ2-3: ECSサービスにALBを関連付ける
- ECSコンソールで、サービスを**「更新」**します。
- 「ロードバランシング」セクションで、先ほど作成したALBを選択します。
- 「コンテナのロードバランサー設定」で、コンテナ名とターゲットグループを選択します。
設定を保存すると、ECSはサービスにロードバランサーを自動的に紐付け、タスクをALBのターゲットグループに登録してくれます。
3. オートスケーリングでスケーラビリティを確保
ALBでトラフィックを分散できるようになったら、次はコンテナ数を自動で調整するオートスケーリングを設定します。
ECSオートスケーリングの仕組み
ECSサービスは、ターゲット追跡スケーリングポリシーを使って、CPU使用率やリクエスト数といったメトリクスに基づいてタスク数を自動で増減させることができます。スケーリングには数分の時間がかかるため、急激なアクセス増に備えて最小タスク数を余裕を持たせておくと安心です。
推奨スケーリング設定例
- ECSコンソールのサービス詳細画面で、「オートスケーリング」タブに移動します。
-
スケーリング設定:
-
最小タスク数:
2（可用性確保のため） -
最大タスク数:
3（検証中はコストを抑えるため）
-
最小タスク数:
- スケーリングポリシーとして「ターゲット追跡スケーリングポリシー」を選択します。
-
メトリクスとして「CPU使用率」を選択し、目標値を
70%に設定します。
この設定により、CPU使用率が70%を超えた場合、ECSは自動でタスクを増やし、70%を下回った場合は減らしてくれます。
4. まとめと今日のハンズオン
- ALBは、タスクへのトラフィックを分散し、サービスを単一障害点から守ります。
- ECSオートスケーリングは、トラフィックの増減に応じてタスク数を自動で調整し、サービスのパフォーマンスを維持します。
これで、皆さんのコンテナサービスは、外部からのアクセスを安全に受け付け、トラフィックの変動に自動で対応できる、高可用性かつスケーラブルなサービスへと進化しました。
【今日のハンズオンチェックリスト】
- ALBとターゲットグループが作成できた
- セキュリティグループが適切に設定できた
- ECSサービスとALBの連携が完了した
- ヘルスチェックが正常に動作している
- オートスケーリング設定が完了した
- 負荷分散が動作することを確認した
【トラブルシューティング】
-
ALB経由でアクセスできない場合:
- タスク用セキュリティグループが、ALB用セキュリティグループからのアクセスを許可しているか確認しましょう。
- ALBのリスナーとターゲットグループのポート設定が一致しているか確認しましょう。
-
タスクが
unhealthyと表示される:- 原因: ヘルスチェックの設定ミス。
- 確認点: アプリケーションがポート5000でリッスンしているか、ヘルスチェックパスが存在するか、セキュリティグループでポート5000が開いているか。
次回の予告
Day 14: 第2週のまとめ：簡単なWebアプリをECSでデプロイしてみる
それでは、また明日お会いしましょう！