この記事は AWS Fargate Advent Calendar 2017 の16日目の記事です。
概要
AWS Fargate の登場により、EC2インスタンスやそのクラスタを意識せずともコンテナが実行できるようになりました。AWSさん曰く、”コンテナをデプロイする最も簡単な方法”ということです。すごいですね。一方で、コンテナを本番環境に導入すると"9ヶ月でコンテナ数が5倍に増加する"や"仮想マシンより9倍早く縮退するようなライフサイクルで利用される"といったレポート[^1] もありますので、より流動的になるインフラに対して運用時の可視性を確保するためにFargateのモニタリングについて考えてみました。
AWS Fargate で利用可能なモニタリング
AWS FargateはこれまでのAmazon ECSと同様にCloudWatch Logs と CloudWatch Eventsをサポートしているので、awslogsを通じてアプリケーションやミドルウェアのログはCloudWatch Logsに転送することが可能で、Fargate タスクの状態変化はCloudWatch EventsのトリガとしてSNSトピックやLambda関数を実行できます。
CloudWatch メトリクスは非常にシンプルで、ECSではクラスタ単位のメトリクスをモニタしていましたが、それがサービス単位のCPUとメモリのメトリクスのみになります。
Fargate 運用の可視性を確保するための要素
システム上で起こりうるあらゆる事象に対して可視性を確保するうえで、必要なデータを 5W1H的な分類で整理してみると以下のようになります。WHATはグラフ化できるような数値データ、WHYはログや状態を示すイベント、HOWはアプリケーションのトランザクショントレース(APM, Application Performance Monitoring)として、WHENとWHEREについては基本的にモニタリングのデータは時系列データでありタグ等のメタデータが付属するため共通するものなので割愛してます。( 例えば、この分類で車の運転のモニタリングを考えると、WHATは速度などの計器類のデータ、WHYはドライバーの操作ログ、HOWはドライブレコーダー、という感じです。どれが欠けても事故の調査は難しくなるし、全部無い=モニタリングしない、を想像すると恐ろしいですねw )
| Fargateの モニタリング |
WHAT | WHY | HOW |
|---|---|---|---|
| データのタイプ | メトリクス | ログ | トレース |
| 対応サービス | CloudWatch (メトリクス) |
CloudWatch Logs, Events |
(なし) |
| データの種類 | CPU, mem | アプリ, ミドル | (なし) |
| データの粒度 | サービス単位 | サービス単位, タスク単位 |
(なし) |
さてこうしてみると、Fargateがコンテナ環境のモニタリングにおいてトレースをサポートできていないのは痛いなぁと思うのと同時に、AWSのことだから割とすぐにX-RayがFargateをサポートするんだろなー...とか想像できます。[^2]
また、ログのサポートが整っている一方で、メトリクスはCPUとメモリだけでディスクI/OやネットワークI/Oが無い、サービス単位だけでタスク単位では見られない、などまだ手薄感がありますが、こちらは今時点はECSのモニタリングの仕組みを流用してるからかなー、Docker Stats API のFargate版みたいなのすぐ出ますよねぇ？とか思うわけです。[^3]
まとめ：Fargateはどうモニタリングするか
モニタリングのプロセスを分けて考えると、データ収集と保存-->可視化-->アラート-->分析-->ナレッジの蓄積、という感じになると思いますが、各プロセスについて以下のように対応を進めるのが良いかと思っています。
| Fargateの モニタリングプロセス |
対応サービス | メモ |
|---|---|---|
| データ収集と保存 | CloudWatch, Events, Logs |
ログも忘れず収集する |
| 可視化 | CloudWatch Dashboard |
意外と使われていない気がするけど 便利なので使ったほうがいいと思う |
| アラート | CloudWatch | Eventsも併用する |
| 分析 | CloudWatch Dashboard |
作り込めば問題分析に使えるので やはり使ったほうがいいと思う |
| ノウハウの蓄積 | (なし) | ポストモーテム用にDashboardの時間が 固定できればいいのになぁ |
BIツールやELKスタックを利用することがかなり普及していて重要なデータを可視化することが良いとは良く知られていると思いきや、モニタリングデータの可視化はそれほど重要視されていない気がしてやった人のみぞ知る、、、となっている気がするので、手近なところでCloudWatch Dashboardは取り組んで見る価値が十分あるんじゃないかなと思います。[^4]
[^1]: [「Docker採用の驚くべき8つの事実」](https://www.datadoghq.com/docker-adoption/) Datadogが毎年実施しているユーザー調査レポートです。コンテナのライフサイクルの短縮は毎年進んでいます。 [^2]: これについては、本当に何も知らず想像で言っていますが、、多分そうなるでしょう。 [^3]: Datadogは Fargateのローンチパートナーで3rdパーティのモニタリングツールとして[Fargateのリリース](https://aws.amazon.com/jp/blogs/news/aws-fargate-a-product-overview/)時に紹介されていますが、実際このAPIが無いとdocker-dd-agentがうまく仕事出来ないので困るのです。このAPIが出た際は記事を更新します。 [^4]: 可視化含めてモニタリングプロセスの劇的な改善をするのがDatadogの強みなのでご興味ある方は["無償トライアル"](https://www.datadoghq.com/)へGo！！,,,ご清聴ありがとうございました。