オールドスクールな監視から最新のオブザーバビリティへ

「オールドスクールな」という言葉には、明らかに2つの異なる意味があります。一方では、まったく古びていない（そして今後も古びることのない）、王道の定番であることを指し、他方では、時代遅れの、古くさい、時流にそぐわないものを示唆します。

筆者はこれまでpingとSNMPの領域で経験を積んできたので、言いづらいことではありますが、「オールドスクールな監視」は、明らかに後者のカテゴリーに属します。その当時、企業が提供するエクスペリエンス（ここではそれをサービスと呼びましょう）の測定は、たとえできたとしても、そう簡単なことではありませんでした。全体として、サービスの各部分から得たデータに基づくユーザーエクスペリエンスを推測しようとすることに終始していました。CPU、メモリ、データベースのメトリクスを測定し、あとはこれらのメトリクスが、サービスが本当に顧客を満足させているかどうかを判断するのに充分なデータを反映していることを願うばかりでした。この「オールドスクールな」考え方では、推測的な洞察を充分に積み上げれば、ユーザーの実際のエクスペリエンスの全体像を得られるはずでした。

このアプローチの問題点は、これでは全体像を得ることができないということです。今回のブログでは、最新でより完全なオブザーバビリティへの移行方法をさらに理解するため、どのように考えたら良いか、再構築の方法を紹介します。

新たな時代の、新たな監視方法

「これがずっとやってきたやり方だから」は、今日の監視とオブザーバビリティの可能性に向けて、順応や改善を避ける言い訳には決してなりません。

ちなみに、オブザーバビリティ（可観測性）の特性のひとつは、システムの外部アウトプットから内部オペレーションを理解する能力です。「観測できる」システムでは、こちらから尋ねることなく何が行われているかが示されるのです。これが、昔ながらの監視と最新のオブザーバビリティの機能の違いを端的に表す一例です。監視（モニタリング）とは、システムの現在のステータスについて繰り返し尋ね続ける行為です。一方で、オブザーバビリティとは、システムが通常のオペレーションを中断することなく、現在のステータスを出力することを意味します。

さらに良いことに、オブザーバビリティでは、アプリケーションの計装がかつてなく簡単になっています。アウトプットがメトリクスであれ、イベントやログ、トレースであれ、最新のオブザーバビリティソリューションには、APIからエージェントまで、既存のコードに焦点を合わせる多様な方法があります。これにより、各自のニーズに最も適合する形でオブザーバビリティを自由に組み込み、拡張することができます。

「オールドスクールなメトリクスはもはや不要なのか」と思われる前に、これは「どちらか」ではなく「どちらも」必要な状況であるということをはっきり述べておきたいと思います。それらの下位レベルのデータポイントは、役に立つだけではなく、必要なものでもあります。

もしSANアレイ（※ストレージシステム）内のHDDドライブでエラーが生じ始めたら（完全に障害を起こすまでに数週間かけて状況が進行する不具合だったとして）、トレースやユーザーエクスペリエンスの監視では決して根本原因は解明されません。そのような「上からの視点」では、ストレージの問題やネットワークデバイスのメモリモジュールの問題、サーバーのドライバ破損、もしくはコンテナオーケストレーションシステムに使用されているイメージファイルの設定ミスでさえも、区別できないかもしれません。この種の洞察に関しては、まだまだ従来の監視テクニックや技術が必要なのです。

オブザーバビリティの例

では、オブザーバビリティの実例はどんなものなのか見てみましょう。

次の例のWebPortalアプリケーションでは、顧客からの問い合わせの上昇といった問題が発生しているようです。単一のロケーションから5分おきに実行した外形監視の結果ではなく、本番環境において実際に何が起こっているのかを理解する必要があります。次のステップでは、New Relicツールを利用して何が起こっているのかを確認します。

ロードアベレージの平均値は通常よりやや高い上昇となっているものの、0.06ポイントはまったく致命的ではありません。一方で、その他のステータスは通常通りです。

数年前でさえ、ここが問題解決のスタート地点です。たったこれだけのデータセットでは、どんな問題が隠れているのかはほとんど示されていません。

しかし今では、メトリクスだけでなく、さまざまなテレメトリオプションをサポートする堅牢なツールがあります。アプリケーショントレーシングとは、実際のユーザー環境でコードがどのように動作しているかを追跡する行為です。一連のツールセットにこれを持っていることで、以下のようなものが見られるようになります。

上の図のような支援機能があれば、何が起きたのか、それはいつなのか、さらにはその原因まで簡単に確認できるようになります。小さな灰色の点は何でしょうか？それらは「デプロイメントマーカー」と呼ばれ、コードが変更され本番環境にデプロイされたタイミングを示しています。トレースからのテレメトリは、詳細で有意義かつ具体的なため、より掘り下げて特定のトランザクションを確認できます。

ここから皆さんは、browse/plans.jspの7秒間もかかっているトランザクションを調査するか、もしくはその名の通りのoops.jsp（おおっと！）の98.16%のエラーレートを調査するかを判断できます。

しかし、これをお見せしているのは、アプリケーションパフォーマンス監視（APM）を紹介するためではなく、リアルタイムのパフォーマンスメトリクスが、アプリケーション内の問題の特定および調査方法を完全に変えることを示すためです。

しかしこれは、従来のメトリクスが完全に無用になるということではありません。先ほども述べた通り、問題の原因は単に物理メモリの不具合やデータベーステーブルの破損なのかもしれないのです。ここで示唆するのは、APMやトレースで可視化される顧客体験を優先させて、詳細を掘り下げる必要がありそうなケースを判断できるということです。

必要かどうかではなく、いつ使うか

では、変わった点は何かというと、それは従来の監視やオブザーバビリティテクニックが必要かどうかではなく、それらをいつ使用すべきかです。

監視とオブザーバビリティの核心は、一連の対象からの計測データを一貫して収集することにあります。その他のアラートやレポート、ダッシュボードなどは、単にそもそも観測データを収集することからのうれしい副産物に過ぎません。

では、もし今すべてのデータを収集しているのなら、オールドスクールな監視から最新のオブザーバビリティへの移行で変わらなければならないのは何なのでしょうか？一言で言えば、それは「視点」です。

最新のオブザーバビリティへの移行のために、古いツールを手放す必要はありません。その代わり、自分たちの「古い視点」や「思考」を手放す必要があります。肝心なこと、すなわちサービスを使用している人々のエクスペリエンスの測定から始めるのです。このレベルでの失敗は「現実の」失敗であり、早急な対応が必要になります。

その対応には、利用できるリソースを増やしたり、最新コードでのコンテナの再デプロイのような自動化も含まれます。これらの自動化した対応で問題を解決できない場合、はじめて人間が直接関与する必要が出てきます。

ここが、下位レベルの情報が必須になるケースです。なぜなら、一旦すべての標準的な自動化が容易な対応が実行されれば、問題はスタックの深い部分にある可能性が高いからです。しかし、問題が発生した後でデータを収集するのでは明らかに非効率です。データはずっと収集されていなければならないのです。

最新のオブザーバビリティソリューションを実現する方法

「OK、了解。で、どうすればいいんだろう？今あるものをすべて捨てて、ゼロから最新のオブザーバビリティソリューションを組み立てるべき？」という疑問の声が聞こえます。ありがたいことに、答えはNOです。

現状の監視ソリューションにオブザーバビリティを追加する必要はあるものの、同じことをするツールを持つのは時間や労力、そしてお金の無駄になりかねません。以下のマイルストーンが設定されたプロセスのご検討をお勧めします。

1. オブザーバビリティの能力を追加する
2. ツールを統合する
3. 入力を簡素化する

オブザーバビリティの能力を追加する

現在の環境に欠けている最新のオブザーバビリティの構成要素を特定しましょう。能力が完全に欠落しているのか、追加は可能だがコスト（時間、労力、実際の費用）が足りないのか、などを検討します。

これは、プロセスにおいて、何が必要かを合理的に検討し、かつ将来的に何が起こりうるかをよく考慮するためのポイントです。見過ごしてしまった必須の能力を後から追加するのは、現時点で必要かつ今後必要になっていきそうなソリューションを選択するよりもずっと大変です。

例えば、もしメトリクス、ログ、イベント、トレースを組み合わせて潜在的な根本原因を特定できる機械学習を用いた能力を特に購入しないのであれば、今後もそういう能力をまったく必要としないという絶対の確信がなければなりません。

一度ツールを選択したら、それをインストールして運用を開始し、その能力と運用、管理についてチーム全体にトレーニングを実施しましょう。これには、自社組織の優先順位に従い、最も適切な新ソリューションの組み合わせを特定することも含まれます。その自然なシナジーを見つけ出すことが、早い段階で成功し、新規ツールの価値を確立するための最良の方法です。

ツールを統合する

ソリューションをインストールしたら、バラバラのデータを表示する数多くのディスプレイで構成される、モグラ叩きのようなダッシュボード群をやめるときです。その代わりに、すべてをひとつに統合するのです。ここで、新しいオブザーバビリティソリューションのデータを（古い）既存の監視ツールに取り込もうとするのは、誤った選択であることをお伝えします。

堅牢な最新のオブザーバビリティソリューションには、ツールや言語ごとのエージェント、データコネクター、カスタムインテグレーション、APIなど、データを取り込むための複数の方法があります。どの監視ツールを使っていたとしても、オブザーバビリティテレメトリと併せてそれらのデータを表示させる方法が、ほぼ間違いなくあります。

これを行うメリットは、低レベル、高レベルの情報を隣り合わせて、互いに同じ文脈に沿った形で表示できることです。これにより、顧客体験の可視化から始めて、そこから必要に応じてシステムやインフラストラクチャのデータを自然に確認していけるようになります。

入力を簡素化する

オブザーバビリティの山頂へと向かうこの旅路の最後の工程は、重複する入力の削除です。そう、とうとう愛着のある古いツールにさよならを告げるときが来たのかもしれません。しかし事実として、最新のオブザーバビリティソリューションは通常、低レベルもカバーすることができるのです。

この段階で、あなたとあなたのチームは、使用している可観測性ツールの能力を十分に理解しており、既存の監視ツールとの間でどの機能が重複しているか、そしてそのうちどれがあなたのニーズに合っているかを把握しているはずです。なので、今こそ、新規ツールの能力を使用するために、統合ではなく移行を開始するときです。

ここで一度振り返り、昔ながらのデータセットのどれがまだ必要かを自分に問い直すのにもよいタイミングです。アプリケーションとの顧客のやり取りが見えるようになった今、組織はネットワークパケット情報を必要としているでしょうか？それらやおそらく多くの他のメトリクスも、感謝を込めて手放すことができるでしょう。

過去を忘れずに前を向く

最新のオブザーバビリティは、ユーザー体験をあるべき地位、すなわち最優先に置くことを意味します。これには、目指すべきユーザー体験への正しい期待を理解し、設定することも含まれます。もし体験が期待を下回っているなら、さらなる洞察を集中させるのです。

最新のオブザーバビリティ技術とツールは、ついにIT実践者が常に望んでいたアプリケーションへの視点を得られる能力を提供できるようになりました。今私たちがすべきことは、頂上へ到達するまでの過程で得てきたすべてを見失うことなく、自分たちの視点を移すことなのです。