オブザーバビリティプラットフォームにより最適な運用を実現
田中氏ははじめに「New Relicはオブザーバビリティ（可観測性）プラットフォームである」と提唱した。オブザーバビリティとはどのような概念なのだろうか。
一般的に、システムの状態を観測する行為は、モニタリングという用語で表現されることが多い。これは、何かシステムにおかしな挙動が発生している場合に通知してくれること。いわばWhenやWhatを知らせるものである。一方のオブザーバビリティは、おかしな挙動が発生した根本原因まで特定し、対応策を検討できること。いわばWhyやHowを扱うものだ。
この前提をふまえ、田中氏は本セッションのテーマであるKubernetesクラスターのオブザーバビリティ向上の知見を解説していく。Kubernetesクラスターの運用においては、以下の4つの課題を解決する必要がある。
1. 運用ツールの設計・運用
サービスの可用性を支えるには、運用ツール自体の可用性も高くなければいけない。運用ツールをどのように設計・運用し、その目的を達成するか。
2. 計測する指標の選定
各Kubernetesクラスターのどんな指標を取得すべきか。
3. 動的に変化するクラスターへの追随
Kubernetesは自己修復性の特徴を持っており、クラスターの状態が動的に変化する。どのようにしてクラスターの動きに追随すべきか。
4. アプリも対象とした運用
Kubernetesはあくまでインフラ環境である。その上で動くアプリケーションの動作まで計測できてこそ、適切な運用となる。
「それぞれの課題について、当社は次のような解決策をご提示します。『1. 運用ツールの設計・運用』は、オブザーバビリティプラットフォームを活用できるのではないか。『2. 計測する指標の選定』については、Metrics、Events、Logs、Traces（4つの頭文字を取ってMELT）という指標を取得すべきではないか。『3. 動的に変化するクラスターへの追随』を行うには、DeploymentやDaemonSetといったKubernetesのオブジェクトに関連づけた計測が必要。『4. アプリも対象とした運用』は、アプリケーション中心のオブザーバビリティを採用することが有効ではないか。それぞれ、順に解説していきます」（田中氏）
まず田中氏は「1. 運用ツールの設計・運用」の課題について取り扱う。解決策として提示されたオブザーバビリティプラットフォームとは、指標となるデータの保持や可視化、アラートなどの機能を兼ね備えたプラットフォームのことだ。
オブザーバビリティプラットフォームには2つの特性が求められる。1つ目は多くの人が使えること。なるべく学習コストが低く、かつ必要に応じてどこからでもアクセスできなければならない。2つ目は運用コストが低いこと。運用に特別なスキルが不要なだけではなく、コストの予測が立てやすいことも重要である。「これら2つの特性を兼ね備えることを、オブザーバビリティの民主化と呼ぶことにしましょう」と田中氏は説明する。
オブザーバビリティの民主化を実現するには2つの方法がある。1つ目はできるだけ広く使われているツールを採用すること。例えば、CNCF Graduated Projectsのオープンソースソフトウェア（KubernetesやPrometheusなど）がこれに該当する。
2つ目はNew RelicのようなSaaSを利用すること。運用ツールそのものの開発・運用を、すべてSaaS側に任せることが可能になるためだ。コストの予測可能性はSaaSのプランにも依存するが、New Relicはその特徴も十分に兼ね備えている。
そして、民主化を実現する2つの方法はけして背反するものではなく、うまく組み合わせて適切な運用を実現することが重要だという。
アプリケーションのオブザーバビリティを担保するために
次に「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クラスターのオブザーバビリティにおいても同じことがいえます。つまり、マネージドかつ自動化されたプラットフォームを用いることで、多くの人々がオブザーバビリティを獲得できることが重要なのだと、私たちは考えています」（田中氏）
