Amazon EC2 Container ServiceはDockerベースのアプリケーションをビルドし、実行し、そしてスケールすることを手助けしてくれます。以前の投稿(EC2 Container Service - 最新機能、お客様事例、その他)でお伝えしたように、簡単なクラスタ管理、高いパフォーマンス、柔軟なスケジューリング、拡張性、ポータビリティ、そしてAWSによる安全で効率の良い環境で動かすことでAWSとの連携ができるといった利点を受け取ることができます。
コンテナベースのアプリケーションはTaskから作られます。Taskは同じEC2インスタンス上で一緒に動く1つか複数のDockerコンテナのことで、インスタンスはクラスタとしてグループ化されます。インスタンスはタスクを実行するために利用されるリソースプールの様な形をとります。
このモデルは計測と監視に対する新しいチャレンジを生み出します。クラスタを適切なサイズ(大きすぎず、小さすぎず)に保つためには、個別のインスタンス毎ではなくクラスタ全体のメモリとCPUの利用率を見る必要があります。これは、CPUやメモリのサイズが様々に異なるEC2インスタンスが含まれるクラスタにおいては、よりチャレンジングな課題となります。
新しいClusterメトリクス
クラスタを正しく計測し監視しそしてスケールできるように、個別のインスタンスから収集されインスタンスのサイズとコンテナの設定を基準に正規化され、Amazon CloudWatchにレポートされる新しいメトリクスを導入します。AWSマネージメントコンソールでメトリクスを見ることもできますし、Auto Scalingのアクティビティを起動することもできます。
各インスタンスではECS Container Agentが動いています。これがインスタンス及びTaskレベルでのCPUとメモリのメトリクスを収集し、正規化のためテレメトリサービスに送ります。正規化処理ではクラスタ全体のCPUとメモリの利用を表現するための混合メトリクスが生成されます。これらのメトリクスによってクラスタ全体の利用率のイメージを持つことができます。
早速やってみましょう！私のクラスタはdefaultという名前で、1つのt2.mediumインスタンスを持っています。
この時点ではTaskは実行されておらず、クラスタはアイドル状態です。
全CPUを消費する様な設定で、2つのTaskを(Serviceとして)実行しました。
TaskがCPUを食い尽くしてそのメトリクスが集まるまで、庭で水やりをして少し休憩しました。戻ってくると、CPU利用率はこの様になっていました。
そこでもう1つのt2.mediumインスタンスをクラスタ内に立て、利用率を再度確認してみました。追加された処理能力によって、全体の利用率は50%に減少しました。
新しいメトリクス(CPU利用率とメモリ利用率)はCloudWatchを通じて利用可能で、アラームを作成するために使うこともできます。どの様に見えるかが以下の画像になります。
新しいServiceメトリクス
今年の初めの方で我々はEC2 Container Serviceがロングランニングアプリケーションと負荷分散をサポートしたことをアナウンスしました。Serviceスケジューラによって、ロングランニングアプリケーションとサービスが良好な状態で必要なレベルまでスケールしている様に保って管理することができます。CPUとメモリの利用率のメトリクスが収集され、サービス毎に処理されコンソールで見ることができます。
新しいClusterとサーバのメトリクスは既に利用可能で、今日から使いはじめることができます！
-- Jeff; (翻訳: SA岩永)
原文: New Metrics for EC2 Container Service: Clusters & Services