Amazon Web Services ブログ

さまざまな AWS ネイティブサービスを使用して Amazon ECS をスケーリングしよう!

コンテナはアプリケーション開発を加速し、環境間でのデプロイの一貫性を高めるため、組織のプロダクティビティとアジリティを向上させることができます。Amazon Elastic Container Service (Amazon ECS) などの AWS コンテナサービスは、アプリケーションの管理を簡素化し、イノベーションとビジネスニーズに注力できるようサポートします。

顧客体験はすべての組織にとって、アプリケーションのパフォーマンスを測る上で最も重要な指標です。さまざまなリクエストのパターンに対して、エンドユーザーへの信頼性と一貫性のある体験を維持することは、すべての組織が直面する課題です。ベストプラクティスとして、Amazon ECS サービスでタスクの望ましい数を自動的に増やす (スケールアウトする) ことや、減らす (スケールインする) ことができます。これにより、トラフィックの急増に対して手動でリアルタイムに対応する必要がなくなります。オートスケーリングを活用し、実際に必要なリソースにのみ支払うことで AWS サービス利用時の使用量とコストを適切に制御することができます。

AWS では、Amazon ECS サービスをオートスケーリングするための複数の機能を利用できます。適切なオプションを選択することで、アプリケーション全体の信頼性が向上し、運用コストと複雑さが軽減され、エンドユーザエクスペリエンスが向上します。この投稿では、まず AWS Application Auto Scaling について学び、これを使って Amazon ECS サービスのオートスケーリングを設定する方法を説明します。次に、アプリケーションオートスケーリングに使用できる Amazon ECS Service ConnectAWS Distro for OpenTelemetry (ADOT) についても説明します。

アプリケーションのオートスケーリング

サービスのオートスケーリングを使用すると、お使いの Amazon ECS サービス内のタスク数を自動的に増減できます。Amazon ECS はこの機能を提供するために、Application Auto Scaling サービスを利用しています。デフォルトでは、Amazon ECS は Amazon CloudWatch に CPU とメモリの使用状況を公開します。これらの CloudWatch メトリクスまたはその他のカスタムメトリクスを使って、サービスをスケーリングできます。Amazon ECS サービスのオートスケーリング機能では、以下のようなオートスケーリングの種類がサポートされています。

  • ターゲット追跡スケーリングポリシー – 特定のメトリクスのターゲット値に基づいて、サービスが実行するタスク数を増減できます。例えば、CPU 使用率が 75% を超えた場合はサービスにタスクを追加し、CPU 使用率がターゲット値の 75% を下回った場合はタスクを削除するというスケーリングポリシーを定義できます。時には、アプリケーション固有のメトリクス (リクエスト数など) や、他の AWS サービスが公開したメトリクスに基づいてスケーリングしたい場合もあるでしょう。その際は、算術演算や関数を用いて、ターゲット追跡ポリシーで使用するメトリクスをカスタマイズできます。カスタムメトリクスに基づくオートスケーリングの詳細については、こちらの記事を参照してください。次のスクリーンショットはターゲット追跡スケーリングポリシーの設定例を示しています。

Sample target tracking scaling policy

  • ステップスケーリングポリシー – アラームの閾値超過の程度によって異なる一連のスケーリング調整を行うことをステップ調整と呼びます。これに基づいて、サービスが実行するタスク数を増減できます。ステップスケーリングでは、メトリクスのしきい値と、追加または削除するリソース量を選択できます。例えば、CPU 使用率が 50% から 75% の場合はタスクを 2 つ増やし、25% 未満の場合は 2 つ減らすというスケーリングポリシーを定義できます。次のスクリーンショットは、ステップスケーリングポリシーの設定例を示しています。

Sample step scaling policy

  • スケジュールされたスケーリング – サービスで実行されるタスクの数を、日付と時刻に基づいて増減させることができます。例えば、ピーク時にサービス中のタスク数を増加させ、オフピーク時にタスク数を減らすよう、スケジュールを設定できます。スケジュール設定に基づくスケーリングは、AWS コマンドラインインターフェース (AWS CLI) で設定できます。スケジュール設定に基づくスケーリングとスケーリングポリシーを組み合わせて使うと、事前のスケーリングアプローチと事後のスケーリングアプローチの両方のメリットを得られます。スケジュールされたスケーリングアクションを実行した後、スケーリングポリシーが容量をさらにスケーリングする必要があるかどうかを判断します。これにより、アプリケーションの負荷に対応するのに十分な容量を確保できます。

サービスのオートスケーリングは Amazon ECS サービスを簡単にスケーリングできる仕組みで、AWS マネジメントコンソール、AWS CLI、AWS SDK を使ってスケーリングを設定できます。

スケーリングポリシーは、クールダウン期間をサポートしています。これは、スケーリングアクションが有効になるまでの待機秒数です。スケールアウト時にタスクは継続的に増加しますが、スケールイン時にはタスクが慎重に減少します。アプリケーションの可用性を守るために、クールダウン期間が終了するまでスケールイン活動はブロックされます。

次の図は、ターゲット追跡スケーリングポリシーの動作例を示しています。

Target tracking scaling policy

Application Auto Scaling の料金

この機能を使用するための追加料金はかかりません。アプリケーションを保管および実行するために作成する AWS リソースの料金のみがかかります。利用したリソースに対してのみ課金され、最小利用料金はありません。

Amazon ECS Service Connect

Amazon ECS Service Connect は、アプリケーションコードの変更なしに、シームレスなサービス間接続性と、リッチなトラフィックテレメトリを提供します。これは、Amazon ECS 内にサービスディスカバリとサービスメッシュの両方を構築することで実現されます。Service Connect 構成を使用すると、Amazon ECS は新しいタスクを起動するたびに、サイドカープロキシコンテナを各タスクに自動的に注入します。Amazon ECS はこの構成を自動的に管理します。

低レイテンシーが要件で、新規クライアント数、受信リクエスト数、エラー率、失敗した TLS 接続数などのメトリクスを監視する必要がある場合は、Amazon ECS Service Connect の設定をお勧めします。Amazon ECS Service Connect は、トラフィックのルーティングと管理のために、サービスメッシュの集中管理アーキテクチャを使用します。Amazon ECS Service Connect によって作成されるトラフィック監視のためのメトリクスは、Amazon ECS コンソールから直接確認でき、これらのメトリクスは CloudWatch にも送信されます。一度 CloudWatch でメトリクスを利用できるようになれば、それらを使って Amazon ECS サービスタスクのオートスケーリングを設定することができます。

以下は、Amazon ECS Service Connect を通じて提供され、最も一般的に使用されるメトリクスです。また、完全なリストはこちらになります。

ActiveConnectionCount クライアントからのアクティブな同時接続の総数
NewConnectionCount クライアントから確立された新しい接続の総数
TargetResponseTime アプリケーションのリクエスト処理レイテンシ
ClientTLSNegotiationErrorCount TLS 接続が失敗した総数
HTTPCode_Target_5XX_Count HTTP レスポンスコード 500 から 599 の数

Amazon ECS Service Connect を使用すると、AWS Cloud Map が提供する名前空間を使って論理名でサービスを参照および接続でき、ロードバランサーをデプロイして構成することなく、Amazon ECS タスク間でトラフィックを自動的に分散できます。さらに、Amazon ECS コンソールには、運用の利便性向上と簡易なデバッグのための、リアルタイムのネットワークトラフィックメトリクスを表示できる便利なダッシュボードが用意されています。次の図では、Amazon ECS Service Connect でのリクエストの流れと、メトリクスが CloudWatch に公開される様子を示しています。

ECS Service Connect – life of a request

以下のスクリーンショットは、Service Connect によって測定されたトラフィックの状況を示すトラフィックヘルスビューを示しています。このビューには、Service Connect を経由するアクティブな接続数と、サービス内のすべてのタスクに対する応答の HTTP ステータスコードが表示されます。Amazon ECS Service Connect は、インフラストラクチャのプロビジョニング、コードのデプロイ、サービスの監視のために、AWS CloudFormationAWS Cloud Development Kit (AWS CDK)AWS CopilotAWS Proton で完全にサポートされています。

ECS Service Connect traffic health

Amazon ECS Service Connect の料金

Amazon ECS Service Connect によるサービスディスカバリ、接続機能、トラフィックテレメトリについての追加料金はありません。Amazon ECS Service Connect エージェントが消費するリソース分のみの料金がかかります。お勧めとしては、Service Connect コンテナに 256 CPU ユニットと 64 MB のメモリを追加することです。これは別途設定するものではありませんが、タスク割り当て時に考慮されます。アイドル時の消費は約 100 CPU ユニットと 40 MB のメモリです。

AWS Distro for OpenTelemetry (ADOT)

OpenTelemetry (OTEL) コレクターには、CloudWatch などさまざまなデータソースにデータをエクスポートするコンポーネントが含まれています。OpenTelemetry は、オープンソースのテレメトリ収集プロジェクトで、様々なアプリケーションやインフラストラクチャからデータを収集して単一の出力形式で提供します。AWS Distro for OpenTelemetry Collector (ADOT コレクター) は、AWS がサポートしている OpenTelemetry コレクターで、AWS から配布およびサポート提供されています。このコンポーネントにより、テレメトリデータを CloudWatch やその他のサポート対象な監視ソリューションに送信できます。

Amazon ECS で ADOT を利用してオブザーバビリティを有効にするには、以下の 2 つのステップが必要です。

  1. 一度の計装で関連ログ、メトリクス、トレースを 1 つ以上のモニタリングソリューションに送信できます。プログラミング言語用のエージェントを有効化すれば、コードを変更せずに自動計装を使用できます。
  2. 以下の 2 つの方法のうち、いずれかを使用して ADOT Collector をデプロイします。
    1. サイドカーパターン(タスク内のアプリケーションコンテナとは別のコンテナに ADOT Collector をデプロイする方法)
    2. Amazon ECS サービスパターン(独立した Amazon ECS サービスとして ADOT Collector をデプロイする方法)

ADOT コレクタは ECS メタデータエンドポイントをスクレイピングし、コンテナの CPU、メモリ、ネットワーク、ディスク使用量などのメトリクスを収集します。ADOT を CloudWatch と統合することで、これらのメトリクスを CloudWatch コンソールから直接収集、分析、可視化できます。次の図は、ADOT SDK を使用してアプリケーションを計装する方法、ADOT コレクタによるメトリクスのスクレイピング方法、および CloudWatch EMF エクスポーターによるメトリクスの CloudWatch への送信方法に関するハイレベルのフローを示しています。

ADOT - data flow diagram

ADOT コレクターには、メトリクスを収集するためのデフォルト設定が備わっています。このデフォルト設定により、メトリクスパイプラインで AWS EMF エクスポーター (awsemfexporter) が有効になります。これは OTEL メトリクスを CloudWatch が受け付ける形式のバッチログに変換してから CloudWatch に送信します。CloudWatch コンソールからは、ログをクエリできるほか、ダッシュボードで可視化したり、メトリクスアラームを作成することができます。

ECS で実行しているアプリケーションが CloudWatch に送信できるメトリクスのタイプを、カスタマイズすることもできます。例えば、以下のメトリクスを収集できます: ecs.task.memory.utilized (タスクのメモリ使用量)、ecs.task.memory.reserved (タスクの予約メモリ量)、ecs.task.cpu.utilized (タスクの CPU 使用量)、ecs.task.cpu.reserved (タスクの予約 CPU 量)、ecs.task.network.rate.rx (タスクのネットワーク受信量)、ecs.task.network.rate.tx (タスクのネットワーク送信量)、ecs.task.storage.read.bytes (タスクのディスク読み取りバイト数)、ecs.task.storage.write.bytes (タスクのディスク書き込みバイト数)。

これらのメトリクスが CloudWatch で利用できるようになると、Amazon ECS サービスタスクのオートスケーリング設定にこれらのメトリクスを使用することができます。

AWS Distro for OpenTelemetry の料金

AWS Distro for OpenTelemetry の利用には料金はかかりません。CloudWatch に送信されるトレース、ログ、メトリクスの料金のみが課金されます。CloudWatch は前払い料金やサービス最低料金がなく、利用分のみを支払えばよいサービスです。詳細は CloudWatch の料金ページをご確認ください。

まとめ

この記事では、Amazon ECS サービスをスケールするために利用可能な、AWS ネイティブなスケーリングオプションについて学びました。さまざまな規模の企業が、高い信頼性で一貫した顧客体験を維持する戦略の一環として、この方法を採用し、 Amazon ECS サービスをスケールできます。適切なメカニズムは、デプロイの敏捷性、事前/事後/予測スケーリングや、料金などの観点から決まります。

詳細については、AWS Well-Architected フレームワークAmazon ECS でアプリケーションを実行する際のベストプラクティスAmazon Elastic Container Service のセキュリティを参照してください。私たちにお手伝いできることがあれば、AWS サポートおよび AWS アカウントチームにご連絡ください。

本記事は、Scale your Amazon ECS using different AWS native services! (2024 年 3 月 8 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。