(レポート)BDT312: ポストサーバーの世界におけるアプリケーションモニタリング:データコンテキストが重要な理由 #reinvent

丹内です。掲題のレポートをします。

スピーカー

Kevin McGuire - Director of Engineering, New Relic

背景

AWS LambdaやECSがそうであるように、コンピューティングレベルは近年拡充の一途をたどっています。
そうなると問題になるのが、このセッションのタイトルである「モニタリング」です。

「コンピューティングレベル」

セッションではこの単語が度々出ていました。
聞き慣れない単語ですが、要は計算機の使い方の区分であるようです。

• オンプレ
  • ハードウェア専有
• Amazon EC2
  • インスタンスという単位で計算機リソースを使う
• Docker / Amazon ECS
  • インスタンス内で複数のサービスを動かす
  • 実装上、計算機リソースはcgroupsで区切られており、小さなVMと言える
• AWS Lambda
  • ECSよりも短いライフサイクルで計算機リソースを使う

コンテナ(計算機リソースを使用する単位とします)の生存時間と、コンテナの総数をグラフにしたものが以下の図です。

生存時間の短いコンテナの数が非常に多いことから、Lambda Functionの形での計算機リソース使用が増加しているのがわかります。

各レイヤのモニタリング

ところで、これらのレイヤの監視はどう行えば良いでしょうか？
EC2単位ではNewRelicが使えます。
Dockerコンテナの場合は、サービスごとにaggregateして表示・監視したりしますが、基本的にはEC2と同様です。
ではLambdaはどうするかというと、実はまだ明確なプラクティスがあるわけではないのですが、CPUやメモリなどさらに細かい単位でaggregateすることで、ライフサイクルが非常に短いコンテナで有意な監視ができるのではないか、とのことでした。
実はこの辺りのプラクティスがNewRelicに実装されているわけではないので、「興味はあるが手探り」という状態らしいです。

モニタリングにおけるコンテキスト

モニタリングを行う、または異常検知の際は、この「コンピューティングレベル」を意識する必要があります。
どのレベルかがわからなければ、データがあっても適切な判断を行えないからです。 このことから、モニタリングにおけるコンピューティングレベルはコンテキストと呼べます。
NewRelicなどのモニタリングツールは、AWSのコンテキストをうまく知らなければなりません。

NewRelicのLambda対応は十分ではありませんが、EC2インスタンスにおいては、NewRelicは柔軟に表示のグルーピング単位(≒ コンテキスト)を設定することができるので、使いこなしておけば、今後の進化に素早く対応できるでしょう。

感想

Lambdaを実戦投入する際にモニタリングが問題になるという意識が無かったので、それを自覚できて良かったです！ EC2/ECS/Lambdaを使い分けるにあたり、アプリの実装だけでなく、運用周りも考えなければならないと思いました。