Amazon ECS タスクのステータス変更をNew Relic Logsに連携して予期せぬタスク再作成を検知する

はじめに

以前、こちらのPostで、コンテナオーケストレーションを利用して本番環境で信頼性の高いコンテナアプリケーションを稼働させるためには「コンテナの状態変化を継続的に見ていくことが大切」と解説しました。本Postでは、Amazon ECSタスクのステータス変更をNew Relicを使って観測するための具体的な手順を紹介します。

構成

Amazon ECSタスクのステータス変更はAmazon Event Bridgeで検知することができるので、Event Ruleを作成し、Amazon Kinesis Data Firehose経由でNew Relic Logsに連携します。

実現手順

それでは作ってみましょう。といっても、こちらのRepositoryにCloudFormation templateを公開していますので、これをデプロイするだけです。このRepositoryをCloneして、AWSマネジメントコンソールのCloudFormationメニューから新規Stack作成を行います。

なお、このStackのパラーメーターには、New RelicのIngests insert keyが必要になります。キーの作成方法は公式ドキュメントを参照してください。New RelicのAPI Keys画面にアクセスすると、右側に小さくこのキーを作成するためのリンクがありますので、ここから当該キーを作成し、クリップボードにコピーしておきます。

CloudFormationのパラメーターに、コピーしておいたキーを貼り付けます。

あとは画面に従ってStackをデプロイすると、数分でプロビジョニングが完了します。前述した構成に必要なリソースが作成されていることがわかります。

データを確認する

この状態でAmazon ECSのタスクの起動や停止が発生すると、New Relic Logsからその情報を確認することができるようになります。New Relic Logsの画面からdetail-type:"ECS Task State Change"で検索することで、そのログを抽出することができます。

例えば、タスクの停止を検知したイベントを抽出すると、そのタスクが停止した理由を確認することができます。

タスクの再作成が継続的に行われていることを能動的に検知する

アプリの新バージョンをデプロイした場合は古いタスクが停止されますし、スケールインした場合は不要なタスクは停止されます。つまり、タスクの停止という挙動自体はよくあることです。しかしながら、予期せずにタスクの再作成が繰り返されている場合はそれを検知しなければなりません。そんな時は、New Relic Logsに取り込んだデータに対して、以下のようなクエリを実行することで、タスク定義のバージョンごとに、時系列でタスクの停止回数を描画することができます。

FROM Log SELECT count(*) FACET detail.taskDefinitionArn , detail.stoppedReason WHERE detail.desiredStatus = 'STOPPED' and detail.lastStatus = 'STOPPED' and detail.stoppedReason not like 'Scaling activity initiated by%' TIMESERIES 5 minutes

意味深な理由でタスクの再作成が複数回発生していることがひと目でわかりますね。この例では、nru-petclinic-ecs-demo-app:14というタスク定義でイメージのpullに失敗し続け、タスクが起動できずに停止され、Amazon ECSがタスクの再作成を試みている状態であることがわかります。

まとめ

いかがでしたか？Amazon ECSのタスクのステータス変更をNew Relic Logsに連携することで、簡単に予期せぬタスクの再作成が繰り返されている状態を検知できます。これで、コンテナ定義の不備による起動失敗や、メモリ使用量の超過によるOOMKilled、ヘルスチェックの失敗など、様々な要因で発生し得るタスクの不安定な挙動を把握できるようになります。

コンテナオーケストレーションを使用するとコンテナの状態が常に変わり続けるため、その全てを追いかけ続けるのは困難を極めます。だた、異常の傾向を可視化することでいち早く問題に気づき修正に繋げることができれば、より安定したサービスレベルを提供することができるようになるでしょう。

本PostがAmazon ECSにおけるコンテナアプリケーション監視の一助になれば幸いです。