アプリケーションのオブザーバビリティを担保するために
次に「2. 計測する指標の選定」の解として挙げられた、Metrics、Events、Logs、Tracesといった指標についても解説していく。
Eventsは、ある特定時刻に発生したアクションを記録したものだ。すべてをEventsのデータとして記録し、必要に応じて集計できればいいのだが、イベントの頻度や種類が多すぎると計算リソースが足りなくなってしまう。そのため、ある特定の属性ごとに定期的に集約した測定値をMetricsとして保存する。
Eventsは構造化データであるため、異なるシステム間で転送する際にコストがかかることがある。そこで、よりシンプルなタイムスタンプつきのテキストメッセージとしてデータを扱っているものがLogsだ。一方、アプリケーションの処理に着目して、一連の処理にどれくらい時間がかかり、どんな事象が発生したのかを記録するものがTracesである。
田中氏は、New Relicが各種のデータをどのような仕組みで取得しているのかについて説明していった。New RelicのKubernetes統合は、オープンソースソフトウェアを適切に活用していること、そしてNew Relic自身の製品もオープンソースとして公開されていることなどが述べられる。また、New Relicの技術特性上、「3. 動的に変化するクラスターへの追随」で述べられた課題も解決されているという。
さらに「4. アプリも対象とした運用」を実現するための、アプリケーションのオブザーバビリティを獲得する方法について田中氏は述べていく。具体的には、以下の3つの要素を満たすことが重要だという。
「満たすべき要素の1つ目は『計測すべき指標の選定』です。アプリケーション中心のオブザーバビリティを採用する場合は、アプリケーションパフォーマンスモニタリングツールを導入してMELTを取得しましょう。
2つ目は『動的なインフラ環境との関連づけ』です。Kubernetesクラスター上で動くアプリケーションの場合、アプリケーションを構成するPodが消えたり再構築されたりします。インフラ環境の変動と関連づけてアプリケーションのメトリクスを取得する必要があるのです。
3つ目は『協調して動くアプリ同士の関連づけ』です。Kubernetesクラスター上で動くアプリケーションは、マイクロサービスアーキテクチャに基づいて構築されるケースが多い。つまり、アプリケーション同士がどのように連携しているか（Context）の情報も、アプリケーションのオブザーバビリティを獲得するためには重要です」（田中氏）
最後に、New Relicがこれら3つの要素をどのように実現しているのか、田中氏は順に解説していった。
「セッションのまとめとして、New RelicのPrincipal Product Marketing ManagerであるJeremy Castileがブログに書いた言葉を引用させてください。『マネージドで自動化されたソリューションのおかげで、問題を特定しMTTRを削減するために、チームが必要とするテレメトリーデータへのアクセスを民主化することができます』と彼は述べました。
これは分散トレーシングをテーマとしたブログに記載された内容ですが、Kubernetesクラスターのオブザーバビリティにおいても同じことがいえます。つまり、マネージドかつ自動化されたプラットフォームを用いることで、多くの人々がオブザーバビリティを獲得できることが重要なのだと、私たちは考えています」（田中氏）
