Monitoring in the time of Cloud Native — Part 4

クラウドネイティブにおけるモニタリングーPart 4

今回からクラウドネイティブにおけるモニタリングに関しての記事をご紹介していきたいと思います。

とても長い文章になるので、いくつかに分けて投稿していきたいと思います。

今回はデータと情報についてです。

Data and Information

ホワイトボックスモニタリングと可観測性の本当の違いは、データと情報の違いです。情報の正式な定義は以下の通りです。

『データは単なる正確な事象のことです。情報の塊のことですが、情報そのもののことではありません。データが加工される、整理され、きちんと構成され、情報が意味のあるものになり、役に立つものになります。そうなったものを情報と呼びます。情報というのは、データのためのコンテクストを提供するものです。 』

モニタリングと可観測性の違いは、システムの内部から報告されたものであるかどうか、もしくはブラックボックスとして扱われたシステムを通して集められたものであるかどうかの差ではありません。私の考えとしては、その違いはその起源を原動力にしているところではなく、その使用方法にあると思っています。つまり、そのデータがところからきたのかということよりも、それを使ってどうするのか、どのように簡単に目的を達成できるかというところに違いがあるということです。

ホワイトボックスモニタリングはデータの素晴らしいソースです。可観測性は必要に応じてこのデータから適切な情報を早く簡単に見つけられるということを指します。可観測性は本番システムのビヘイビアについて何の情報が必要かどうかということであり、この情報にアクセスできるかどうかに関することです。この情報が事前に加工されているかどうか、もしくはオンザフライのそのデータから取り出せるかどうかということはあまり大きな問題にはなりません。加工するためにどのように計画を立てるか、未処理のデータの使用かということでもありません。私たちが集めているこの未処理のデータには、色々な使い方があります。

• 自分たちが集めているデータを重要度の高い結果を持つ明示的な障害のためのルックアウト上で使えます。―差し迫った停止、言い換えれば回避、もしくはfirefight（銃撃戦？）であり、その症状をベースとしたアラートのためのデータを使っている場合です。

• このデータをサービスの全体的なヘルスを知るために使うこともできます。概要という定義で考える場合です。

上記２つの場合、「モニタリング」に分類されます。

• 事前に予測できない生もしくは暗示的な障害モードをデバッグするときにこのデータを使います。このケースでは、システムをデバッグするデータを使います。

• また私たちは通常の安定した状態での本番システムでのビヘイビアをより理解するためにプロファイリングのような目的のためにそのデータを使うこともあります。この場合、今の段階で存在しているままのシステムを理解するためのデータを使います。

• またどのように現在他のサービスに依存しているかを理解したいと思っています。私たちのサービスが他のサービスに影響を受けているかどうか、もしくは別のサービスのパフォーマンスの低下にかかわっているかどうかを理解できるようになります。この場合、依存関係分析のためにこのデータを使います。

• また、より野心的になり、システムが今すぐ機能することを確認するだけでなく、システムのビヘイビアを理解するためのデータを確保して、明日だけでなく、そのライフサイクル全体にわたってシステムの進化と維持に取り組むこともできます。 明日の問題を解決することが今日の私たちの目的ではないということは事実ですが、それでもなおその問題の存在を知ることは重要です。問題が急に起こることほど悪いことはありません。ただ、それをより早く可視化できれば、もっとうまく解決することができたことに気づいたのです。今日の既知のハード障害モードを予測し、それらを「モニタリング」できます。しかし、その明日の既知のハード障害モードは今日の明示的な方法でそれ自身を表示することはほとんどありません。それらはシステムによって示される微妙なビヘイビアから、しつこく求められる必要があります。それは、特定の異常な状況か、もしくはまれに起こる特定のトラフィックパターンの下か、懸念の原因ではない状況か、もしくはすぐに起動できる状況の間に求められる必要があります。

すべて目的は異なります。いくつかを最適化することもできますし、もしくはすべてを最適化してもよいでしょう。ホワイトボックスモニタリングは重要なコンポーネントです（ともすれば一番重要なコンポーネントでもあります）。先ほど述べた目的を達成するために役に立つものですが、それ自体は可観測性ではありません。

組織によって「モニタリング」に必要な条件は異なります。ある組織にとっては、依存関係分析が「モニタリング」の重要な部分となります。また、他の組織にとっては、セキュリティー監査がなくてはならないモニタリングの役割かもしれません。このように、可観測性はスペクトラムになっていて、サービスが進化すると同時に継続的に進化するものなのです。

「可観測性」とは対照的に「モニタリング」に当てはまる事項は、受動的に行うことと、能動的に行うことを区別することです。

もう一度言いますが、これは組織によって異なります。しかし、２つの目的で差別化することは重要だと思っています。データから積極的に収集する情報は常に必要であり、それは、デバッグのタイミングと同時に収集する情報や積極的に収集されたデータからの分析とはことなります。

しかし、このスペクトラムはオペレーション対開発の責任をベースにしても区別することができます。すぐに呼び出しに対応できるものとして「モニタリング」を見ています。強制的にデベロッパーとソフトウェアエンジニアを必要とするものを可観測性とみています。

なお、このスペクトラムの中では、因果関係があることに注意する必要があります。多くの場合、みなさんが1つのレイヤー（エラー率やリクエスト期間のようなメトリック）で「モニター」するのは「症状」であり、原因はスペクトルのいくつかのレイヤーにあります。

だいたいのメトリック（増加するエラー率や応答時間）やトレース（ダウンストリームサービスCからのリクエストの確実なタイプのためにサービスBが遅い）が報告する症状を伴うスタートにかかわる問題をトラブルシューティングすることができることで問題を鳥観図的な見方をすることができます。そして、根本的な原因を見つけるまで、そして必要な情報に最終的に到達するまで、理論を確証または無効化するために繰り返し検索し、それによって繰り返しごとに検索スペースを削減します。

この流れをくんで次の話にうつりたいと思います。

Observability isn’t just about data collection

データから情報を抽出しようと思うなら、データにアクセスする必要があり、可観測性はデータ収集だけではありません。一度データを保有すると、答え/情報をこのデータから簡単に得られることが重要になってきます。

未処理データは前処理された情報よりも順応性が高いのは事実ですが、実際に必要になるまで情報の処理を延期し、他のオーバーヘッド、つまり収集、保存、オンザフライ処理などのオーバーヘッドが発生します。理論的には、可観測性の目標に到達できる限り実装の詳細は重要ではないと述べることは非常にうまく聞こえるかもしれませんが、収集するデータを最適に処理および保存する方法は、必要に応じて考える必要のある重要なことになります。 好循環を確立し、維持するという夢を実現するならば。 データ収集の時に支障が出る時と同様に、データの使いやすさも重要な関心事になります。

そして最後に、可観測性の最も重要な側面はデータの収集や処理ではないということを覚えておいてください。データを自由に使用できるだけでは問題は解決しません。問題解決には、エンジニアリングの直観とドメインエクスペリエンスが必要で、データの適切な質問をしてデータの真相を究明することができます。実際、例え全てのツールを自由に利用できたとしても、優れた観測性は、エンジニアリングの優れた直感とドメインの知識がなければ不可能です。そして、この記事で言いたいことが、みなさんに上手に伝わればうれしいです。より良い洞察を得ることを可能にするシステムを構築する方法をお話するので、みなさんの参考になればと思います。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。