何を監視すべきか？4つのメトリクス(L.E.T.S.)で始めましょう。

ソフトウェア監視とは、どのように行えばよいのでしょうか。 

「多数のツールに投資したが、いったい何に注目したらいいのか。グラフが多すぎて何が何やらわからない」

ソフトウェア監視の話をしていると、こんな声を耳にしたことがあるはずです。メトリクスのあまりの多さに、干し草の山から針1本を探すような感覚に陥ります。情報が整理されたダッシュボードがあったとしても、何が重要なのか分かりにくいという根本的な問題は残ります。出発点として最適なのは、4つの「ゴールデンシグナル」、すなわちレイテンシー、エラー、トラフィック、サチュレーション(Latency、Errors、Traffic、Saturation：L.E.T.S.)を利用することです。これら4つのシグナルが、ソフトウェアとインフラの状態を把握するためのかなり汎用的な枠組みとなります。 

しかもこれは、ソフトウェアとは無関係なことにも応用できるのです。気になったら、ぜひ続きをお読みください。

L.E.T.S.とは？ 

ソフトウェア以外の例を想定して、ゴールデンシグナルの実力をご紹介しましょう。大人気のレストランを経営していると考えてください。経営は好調のように見えますが、改善やコスト削減のためにどこに注目すべきかが分かりません。そこで、計測を始めることにします。計測する対象を、どのように決めればよいでしょうか。L.E.T.S.を適用して考えてみましょう。

• レイテンシー：お客様に料理を提供するのに、どれくらいの時間がかかっていますか？
• エラー：料理を作れないことや、料理を無償で提供しなければならないことは、どのくらいの頻度で発生していますか？
• トラフィック：何人のお客様が(いつ)来店していますか？
• サチュレーション：同時に何食分を作って提供できていますか？

これらの重要メトリクスを監視することにより、ビジネスの規模拡大や変更の影響について十分な情報を得たうえで意思決定が行えるようになります。 

レイテンシーは、料理人や給仕の増員、設備の増強が必要かどうかを判断する際に役立ちます。 

エラーは、研修、人員配置、設備の改善による成果を計測するために役立ちます。 

トラフィックは、必要な人員数や、人員が最も多く必要な時間帯、少なくてよい時間帯を知るために役立ちます。また、来客数のトラフィックを計測していると、拡張すべきときが来たときに決断しやすくなります。

サチュレーションは、シフトの問題や、人気メニューを同時に作る場合の問題の他、効率に関して気づいていなかった問題を見つけるために役立ちます。

このようなことは、レストランオーナーであれば直感的に判断できるかもしれません。しかし、これらのメトリクスを計測しないと、確実には把握できないでしょう。

以上の基本的な概念は、複雑な仕組みを持つもの全般(例えば架空のレストラン)を把握するための基礎となります。そして、これが本当に真価を発揮するのは、複雑なソフトウェアアーキテクチャを監視するときです。 

マイクロサービスの時代にあって、ソフトウェアシステムのあらゆる要素について専門知識を備えることは現実的ではないでしょう。複雑なシステムで問題が発生して基本的なトラブルシューティングを行う場合は、L.E.T.S.の概念が基礎となります。

特定のサービスに精通していないITアナリストでも、レイテンシー、エラー、トラフィック、サチュレーションを使えば、複数のシステムが接続された環境でも問題を特定しやすくなります。

• 「データベースのレイテンシーが、通常よりもかなり高いようだ。このデータベースはオンプレミスかus-east-1か、どちらだろう？」
• 「前回のデプロイ後から、エラーが急増している。ロールバックすべきだ」
• 「ロードバランサーのところで、トラフィックが途絶えている。証明書の期限が切れているのか？」
• 「サチュレーションが、通常より急速に上昇している。間もなく、ストレージ不足になる」

このような基礎知識があれば、迷路の細部を掘り下げることになる前に、既知の障害点を速やかに確認できます。まだこのような計測方法を確立できていない場合は、ぜひこの続きもお読みください。

^{図1-1.Splunk APM。Hipster Shopにおけるチェックアウトから決済までのL.E.T.S.メトリクスがハイライトされています。エラー率15%は詳しく調べるべきです。}

L.E.T.S.を取得しましょう

必要最小限の4つのメトリクスに関する概念的な枠組みについては、ご理解いただけたと思います。このL.E.T.S.は、どこから取得するのでしょうか。分散トレーシングで主に扱うのは、システム上を行き交うリクエストのレイテンシー、エラー、トラフィックです。トレーシングデータ(APMデータとも呼ばれます)をSplunk APMなどのソリューションに送れば、すぐにこれらのメトリクスの取得を始められます。とても簡単なことです。しかし、まだサチュレーションが残っています。 

サチュレーションはどちらかというと、ソフトウェアや設計の意思決定に関わるものです。いくつか、例を考えてみましょう。

• そのソフトウェアはCPUバウンドでしょうか？特定のタイミングで、一定のCPU性能を必要としますか？
• メモリーはどうですか？メモリー使用量が増加し、メモリー不足のクリーンアップによるクラッシュが起き、障害の原因となっていませんか？
• 心配なのはストレージですか？データベース、ネットワークディスク、あるいはローカルディスクが一杯になりそうですか？
• トラフィックすべてに対応できる、十分な数のホスト(コンテナやVMなど)を実行していますか？

ご利用の環境内のどのアプリケーションについても、上記のいくつかに対する答えは「いいえ」なのかもしれません。しかし、時間をかけてこれらを検討して、障害の原因となり得るリソースの制約やサチュレーションを洗い出せば、グラフを整理してトラブルシューティングを迅速化するのに役立ちます。「既知の既知」を知ることで、実際の問題に集中できるようになり、本筋から外れることが少なくなるでしょう。

質問への答え

「何を監視すべきか？」の答えは簡単です。L.E.T.S.を監視しましょう。注目すべきは、マイクロサービス間やデータセンター間、さらには個々のソフトウェアコンポーネント間のレイテンシー、エラー、トラフィックです。また、インフラパターンが共通する複数のマイクロサービス(EC2上でDynamoDBを使用するJVMや、PythonベースのCloud FunctionsとCloud SQLデータストアなど、反復される組み合わせ)にこの手法を適用すると、大量になりがちなダッシュボードやアラートを最小限に抑えられます。例えば、共通するインフラごとのL.E.T.S.グラフを1つのダッシュボードにまとめることが可能です。すべてのメトリクスに例えばservicenameなどの属性を含めることで、1つのダッシュボード内で簡単にフィルタリングできるようになり、マイクロサービスの膨大なフットプリントにすばやく目を通せます。同様に、基本のL.E.T.S.とインフラパターンに注目することで、アラートも最小限に減らすことができます。これについては、また別の機会にお話しします。

次のステップ

Splunk Observabilityに熟練している方も、トライアルを始めた方も、始めようかと検討中の方も、次のステップは同じです。L.E.T.S.の原則を念頭に置けば、ソフトウェアとインフラのオブザーバビリティ推進をすぐに軌道に乗せることができます。

Splunk Observability Cloud製品スイートの無料トライアルをぜひお試しください。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。