ECSサービスのオートスケーリングとロードバランシング

ECS サービスで固定のdesired countを設定しても、トラフィックの変動には対応できません。過剰プロビジョニングではコストが無駄になり、過少プロビジョニングではパフォーマンスが低下します。ECS Service Auto Scalingは、CloudWatch メトリクスに応じてタスクの desired count を自動的に調整します。内部ではApplication Auto Scalingサービスを使用しており、DynamoDB、Aurora、ElastiCache でも同じフレームワークが使われています。ECS のサービスオートスケーリングでは、ターゲット追跡、ステップスケーリング、スケジュールスケーリングの各ポリシーをサポートしています。

スケーリングポリシーを追加する前に、Application Auto Scaling で ECS サービスをスケーラブルターゲットとして登録します。最小および最大タスク数、クラスター名、リソース ID としてサービス名を指定します。これにより、オートスケーリングが動作する範囲が設定されます。最小数によって常に基準となるキャパシティが確保され、最大数によって、過剰なスケーリングで Fargate のキャパシティや EC2 インスタンスを使い果たすことを防止できます。

ターゲット追跡は、ほとんどの ECS サービスで推奨されるオートスケーリングポリシーです。最も一般的なターゲットメトリクスはECSServiceAverageCPUUtilizationです。50～70%をターゲットに設定すると、ECS はその CPU 使用率を維持するようにタスクを追加または削除します。もう 1 つの有効なメトリクスがALBRequestCountPerTargetです。タスクあたりの ALB リクエスト数を追跡し、インスタンスあたりの目標リクエストレートを維持するようにスケーリングします。AWS は適切なクールダウン期間を設けて、スケールアウトとスケールインを自動的に処理します。

Application Load Balancer (ALB)を ECS サービスに関連付けると、実行中のすべてのタスクに HTTP/HTTPS トラフィックが分散されます。ALB のターゲットグループには、各タスクの IP（Fargate/awsvpc の場合）またはコンテナポート（bridge モードの場合）が登録されます。ECS は、新しいタスクの開始時にターゲットグループへ自動的に登録し、停止時に登録解除します。ALB は各タスクのヘルスチェックを実行し、異常なタスクについては、サービスが終了させる前にドレイン処理（接続を正常に終了）が行われます。

強力なパターンの 1 つは、ALB のパスベースルーティングを使用して、異なる URL パスを異なる ECS サービスへルーティングする方法です。1 つの HTTPS リスナーを持つ単一の ALB で、/api/orders/*を Orders ECS サービスへ、/api/users/*を Users ECS サービスへ、/api/products/*を Products ECS サービスへルーティングできます。それぞれが独立したスケーリング設定を持つ独自の ECS サービスによって処理されます。これにより、マイクロサービスごとに個別のロードバランサーを用意する必要がなくなり、コストを削減するとともに DNS 管理を簡素化できます。

ECS タスクが終了処理中（スケールインまたはデプロイ中）の場合、ALB はそのタスクをdrainingとして扱い、新しいリクエストのルーティングを停止しながら、処理中のリクエストが完了するのを待ちます。登録解除遅延（デフォルトは 300 秒、0～3600 秒で設定可能）は、ALB が接続を強制的に閉じるまで待機する時間です。リクエスト処理時間が短い ECS サービスでは、登録解除遅延を短く（30～60 秒）設定すると、デプロイやスケールインを高速化できます。WebSocket やファイルアップロードなどの長時間接続では、長めの遅延を維持してください。

CPU やメモリ以外にも、アプリケーションからカスタム CloudWatch メトリクス（キューの深さ、アクティブセッション数、ビジネス KPI など）を発行し、スケーリングの判断に利用できます。たとえば、各 ECS タスクが同時に 50 件のキューメッセージを処理できる場合、SQS キューの深さをカスタムメトリクスとして発行し、タスクあたり 50 メッセージを目標とするターゲット追跡ポリシーを作成します。これにより、アプリケーションの負荷と相関しない可能性があるインフラストラクチャメトリクスに頼るのではなく、ビジネスロジックに直接基づいてスケーリングできます。

EC2 Auto Scaling と同様に、ECS はタスクのスケールイン保護をサポートしています。実行中のタスクは、ECS API を通じて自身のスケールイン保護フラグを設定し、重要なジョブの処理中にスケールインで終了されるのを防止できます。これは、SQS ワーカーとして動作する ECS タスクに便利です。長時間のジョブをデキューしたワーカーは自身を保護し、ジョブを完了した後で保護を解除できます。この機能がない場合、スケールインによって処理途中のタスクが終了し、ジョブの重複やデータ損失が発生する可能性があります。

スケーリングメトリクスは慎重に選択してください。CPU 使用率はデフォルトであり、計算負荷の高いワークロードに適しています。メモリ使用率（ECSServiceAverageMemoryUtilization）はメモリ負荷の高いアプリケーションに有効ですが、メモリを増やすにはタスクを追加する必要があります。タスクが同時処理数ではなくタスクあたりのメモリによって制限されている場合は、タスク定義のメモリ割り当てを修正する方が適切なこともあります。ALBRequestCountPerTargetはユーザー体験に直接相関し、Web API で最も実用的なメトリクスです。タスクあたりの実際のリクエストレートに基づいてスケーリングします。

ECS Deployment Circuit Breakerは、失敗したデプロイを自動的に検出し、最後に安定していたバージョンへロールバックします。これがない場合、ヘルスチェックに失敗するコンテナを含む不適切なデプロイに対して、ECS が新しいタスクの起動を無期限に試み続ける可能性があります。サーキットブレーカーを有効にすると、検出期間内に新しく起動したタスクの一定割合がヘルスチェックに失敗した場合、ECS はデプロイを FAILED としてマークし、以前のタスク定義リビジョンへ自動的にロールバックします。これにより、不適切なデプロイによるサービス低下の長期化を防止できます。

本番環境に適したコンテナ化 Web API のアーキテクチャでは、Route 53がドメインをALBの DNS 名に解決します。ALB は HTTPS（ACM 証明書）を終端し、WAF ルールを適用して、リクエストをECS サービスのターゲットグループへルーティングします。3 つの AZ にまたがるプライベートサブネット内の Fargate タスクがリクエストを処理し、ECS Service Auto Scalingは ALBRequestCountPerTarget のターゲット追跡に基づいてタスク数を 2～50 の範囲で調整します。タスクはプライベートサブネット内のRDS AuroraおよびElastiCacheに接続します。すべてのログは CloudWatch Logs に送られ、メトリクスは CloudWatch ダッシュボードとアラームを駆動します。

このレッスンで学んだ AWS Solutions Architect (SAA-C03) の概念について、理解度を確認します。

このレッスンでは、ECS Service Auto Scalingが Application Auto Scaling を使用し、ターゲット追跡（CPU、ALB リクエスト、カスタムメトリクス）によって、設定した最小値と最大値の範囲内でタスク数を調整することを学びました。また、ALB のパスベースルーティングによって、URL パスを異なるターゲットグループへルーティングし、1 つのロードバランサーで複数の ECS マイクロサービスを提供できること、さらにDeployment Circuit Breakerによって、失敗したデプロイを自動的にロールバックし、サービス低下の長期化を防げることも学びました。これで ECS とコンテナのモジュールは終了です。次は AWS 上の Kubernetes である Amazon EKS について学習します。