DevOps 測定: モニタリングとオブザーバビリティ

優れたモニタリングは、チームのパフォーマンスを高める重要な要因となります。DevOps Research and Assessment（DORA）の調査では、継続的デリバリーに欠かせない多くの技術手法の 1 つとして、包括的なモニタリングとオブザーバビリティ ソリューションが示されています。

DORA の調査では、これらの用語は次のように定義されています。

モニタリングは、チームがシステムの状態を監視して把握できるようにするツールや技術的なソリューションです。モニタリングでは、事前に定義した指標やログの収集を行います。

オブザーバビリティは、チームがシステムのデバッグを積極的に行えるようにするツールや技術的なソリューションです。オブザーバビリティでは、事前に定義されていないプロパティとパターンの調査を行います。

適切なモニタリングとオブザーバビリティを行うには、次のものが必要になります。

  • システム全体の状態に関するレポート（システムが機能しているか、システム リソースが不足していないか）
  • ユーザーが体験しているシステム状態に関するレポート（ユーザーがシステムの停止を知っているか、操作上の問題が発生しているか）
  • 主なビジネス指標とシステム指標のモニタリング
  • 本番環境のシステムの状態を確認してデバッグできるツール。
  • これまで認識できなかったこと（知らないことを知らない状態）を確認できるツール。
  • 本番環境にあるインフラストラクチャの問題（サービス間のやり取りを含む）のトレース、確認、診断に役立つツールやデータへのアクセス。

モニタリングとオブザーバビリティの実装方法

モニタリングとオブザーバビリティのソリューションは、次の目的を実現できるように設計する必要があります。

  • サービスの停止や低下の兆候を示す指標を提供する。
  • サービスの停止や低下、バグ、不正行為を検出する。
  • サービスの停止や低下、バグ、不正行為に対するデバッグをサポートする。
  • キャパシティ プランニングとビジネス目的で長期的な傾向を把握する。
  • 変更や追加機能による想定外の影響を明らかにする。

他の DevOps 機能と同様に、ツールをインストールしただけで目的を達成できるわけではありません。ツールが役に立つこともあれば、かえって妨げになることもあります。モニタリング システムは組織内の 1 人または 1 つのチームに制限すべきではありません。すべてのデベロッパーがモニタリングを習熟することで、データドリブンな意思決定を行う文化が生まれます。また、システム全体のデバッグ性が向上し、システム停止の影響を減らすことができます。

効果的なモニタリングとオブザーバビリティを実現するには、いくつかの重要な指標があります。まず、モニタリングにより、現在の状況を把握し、被害が拡大する前に原因を突き止める必要があります。サービス停止や低下に関する重要な指標は復元時間（TTR）です。TTR を左右する要因は、停止しているサービスとそれを最短で復元するためのパスを迅速に把握する能力です（原因となっている問題をすぐに修正できるかどうかは関係ありません）。

システムの状態をモニタリングする方法としては、ブラックボックスとホワイトボックスの 2 つがあります。ブラックボックス モニタリングではシステムの内部状態とメカニズムを確認しませんが、ホワイトボックス モニタリングではこれらの情報を収集します。

詳細については、Site Reliability Engineering の「Monitoring Distributed Systems」をご覧ください。

ブラックボックス モニタリング

ブラックボックス（または合成）モニタリング システムでは、ユーザーが行うのと同じ方法で入力データが対象のシステムに送信されます。モニタリング プロセスでは、公開 API への HTTP 呼び出しや、公開エンドポイントへの RPC 呼び出しなどを行います。また、レンダリングするウェブページ全体を呼び出すこともあります。

ブラックボックス モニタリングはサンプリング ベースの方法です。ユーザーのリクエストを処理するシステムをブラックボックス システムでモニタリングします。ブラックボックス システムでは対象システムの境界もモニタリングできます。この場合、外部 API メソッドを調査します。また、ユーザーの実際の操作に近づけるため、複数のリクエストを組み合わせることもできます。たとえば、特定の API で読み取りを 100 回実行し、書き込みは 1 回しか実行しないこともあります。

サンプリングの信頼性を高めるために、このプロセスをスケジューリング システムで制御し、適切な入力頻度を維持することもできます。システムには検証エンジンも必要です。検証エンジンは、レスポンス コードのチェックや正規表現による出力の照合を行うシンプルなものもあれば、ヘッドレス ブラウザでダイナミック サイトをレンダリングするものや、DOM ツリーを走査して特定の要素を探すものもあります。特定のプローブの結果（合格または失敗）が出たら、レポートとアラートに使用できるように、その結果とメタデータを保存する必要があります。失敗したスナップショットとコンテキストは問題の診断に役立ちます。

ホワイトボックス モニタリング

モニタリングとオブザーバビリティは、ワークロードからモニタリング システムに送信されるシグナルに依存します。最も一般的な要素としては、指標、ログ、トレースの 3 つがあります。一部のモニタリング システムではイベントを追跡して報告します。イベントは、システムでのユーザーの操作やシステム自体の状態の変化を表します。

指標はシステム内で測定された値で、そのシステムの状態を測定可能な方法で表します。ほとんどの指標は数値で、カウンタ、分布、ゲージの形をとるのが一般的です。文字列のほうが適切な場合もありますが、指標に数値が使用されるのは、統計情報の作成や可視化で数値計算が必要になるためです。

ログは、特定の時点における特定の作業の状態を表す追記専用のファイルと考えることができます。このようなログには「User pushed button X」という文字列のみが含まれている場合もありますが、イベントの発生時間、処理を行ったサーバー、環境要素などのメタデータから構成された構造化データが含まれている場合もあります。構造化データをログに書き込めないシステムでは、必要に応じて [timestamp] [server] message [code] のような半構造化データが生成される場合があります。ログエントリは、log4j、structlog、bunyan、log4net、Nlog などのクライアント ライブラリを使用して作成されます。ログ処理では、非常に信頼性の高い方法で統計情報が生成されます。ログ処理システム自体にバグがある場合でも、保存された不変のログに基づいて再処理が可能なため、信頼できる統計情報を取得できます。また、ログをリアルタイムで処理し、ログベースの指標を生成することもできます。

トレースはスパンで構成されています。これは、分散システムでイベントやユーザーのアクションを追跡するために使用されます。1 つのスパンがサーバーからのリクエストのパスを示し、同じ親を持つもう 1 つのスパンが同時に実行されていることもあります。これらのスパンが 1 つのトレースを形成します。多くの場合、トレースはプロファイリング ツールと同じようなウォーターフォール グラフで可視化されます。これにより、システム内で複数のサーバー、キュー、ネットワーク ホップで費やされた処理時間を把握できます。一般的なフレームワークである OpenTelemetry は、OpenCensus と OpenTracing から構成されています。

指標、ログ、トレースを測定対象のサーバーまたは隣接するエージェントからモニタリング システムに送信し、システムの状態を確認または推測できます。

インストルメンテーション

モニタリング システムを利用するには、システムのインストルメンテーションを行う必要があります。つまり、内部状態を公開するには、システムにコードを追加する必要があります。たとえば、単純なプログラムに別のサービスへの接続のプールが含まれている場合、そのプールのサイズと未使用の接続数をいつでも追跡できるようにする必要があります。そのためには、接続プールのロジックに、接続の確立と破棄、受け渡しのタイミングを記録するコードを追加する必要があります。たとえば、これらの処理が行われるたびに、ログエントリの記録やイベントの生成を行います。また、キューサイズのゲージを増減することもできます。接続の確立時やプールの展開時にカウンタをインクリメントする方法もあります。

相関

指標はアプリケーションだけでなく、基盤となるシステム（JVM、ゲスト OS、ハイパーバイザ、ノード OS、ハードウェア自体など）からも収集されます。時間とともにワークロード間で共有される指標が増加していきます。たとえば、複数のアプリケーションを実行しているマシンでディスクの使用量を監視しているときに、監視対象のシステムと直接関係のないデータが収集されることもあります。共有システム上のアプリケーション間で問題を関連付けることで、要因（遅いディスクなど）を特定しやすくなります。1 つのアプリケーションから基盤となるシステムの指標にドリルダウンし、類似した影響を受けるアプリケーションをすべて表示できれば、非常に効果的です。

分散システムの場合、さまざまな場所でオブザーバビリティを測定し、その結果をまとめて表示できるようにする必要があります。たとえば、フロントエンドとデータベースの場合もあれば、ユーザーのデバイスで実行されているモバイルアプリ、クラウド ロードバランサ、一連のマイクロサービスの場合もあります。最近のオブザーバビリティ ツールでは、すべてのソースのデータを 1 か所にまとめる機能があることが基本的な要件になっています。

コンピューティング

システムのさまざまなソースからデータを収集した後、さまざまな領域で統計情報を生成し、集計を行います。たとえば、ユーザーのコホート、コンピューティング フットプリントのリージョン、ユーザーの地理的位置などで集計を行います。この統計情報を未加工のイベントに基づいてリアルタイムで作成できることは大きな利点ですが、必要になるストレージやコンピューティング時間の点ではコストが増大する可能性があります。

ツールを選択してインストルメンテーションを計画する際は、カーディナリティと次元数を考慮する必要があります。指標収集のこの 2 つの要素は、システムの監視機能に大きな影響を与える可能性があります。

カーディナリティでは、システム内の一意の値を測定します。たとえば、cpu-utilization のようなフィールドでは 0～100 の範囲が必要です。ただし、ユーザー固有の ID を追跡している場合は識別子がすべて一意のため、100 万人のユーザーが存在すると 100 万個のカーディナリティを持つことになります。これは大きな違いになります。

次元数では、タイムスタンプと一緒に複数の値を記録します。これは、モニタリング システムで単純な時系列データベースを使用しているのと同じです。たとえば、requests-sent カウンタの場合、カウンタの値を記録するとその時点までに送信されたリクエストの数が {time=x, value=y} のように記録されます。構造化ログのように、環境データも一緒に記録することもできます。その場合は {time=x, value=y, server=foo, cluster=123, environment=prod, service=bar} のようになります。高いカーディナリティと高い次元数を組み合わせると、必要なコンピューティング能力とストレージが劇的に増大し、モニタリングが想定どおりに機能しない可能性があります。生成されたデータとメタデータをモニタリング システムに動的に書き込む場合は、この点をよく理解しておく必要があります。

学習と改善

停止やエラーから学習し、システムの運用を改善していくことが重要です。見直しや事後調査で訂正処置を作成するプロセスは確立されています。このプロセスに従ってモニタリングの改善を行います。変化の激しい組織では、全員がモニタリング システムを迅速かつ効率的に更新できるようにする必要があります。モニタリング構成は重要です。コードの開発や配布と同様に、レビューと承認で変更を追跡する必要があります。この重要な部分を制御しながら、広範なアクセスを可能にする最初のステップとしては、バージョン管理システムを利用するのがよいでしょう。自動化を行い、自動化パイプラインでモニタリング構成をデプロイすると、構成の有効性を維持し、一貫した方法で適用することが可能になります。モニタリング構成をコードとして扱うことで、こうした改善はすべてデプロイの自動化プロセス（理想的にはチームの他のメンバーが使用しているのと同じシステム）を通じて実現できます。

モニタリングとオブザーバビリティを実装する際の一般的な問題

組織でモニタリングとオブザーバビリティのシステムを開発する際に、簡単に利用できるプラグアンドプレイ ソリューションはありません。モニタリング システムでは、測定するコンポーネントを十分に理解し、システムのインストルメンテーションを行うコードを直接操作する必要があります。モニタリングの担当者は複数にし、システムに対して責任を複数のチームで分担するようにしてください。これにより、単一障害点を防ぐだけでなく、組織全体でシステムを理解して、改善していくことが可能になります。モニタリングとオブザーバビリティをデベロッパーの基礎知識に含める必要があります。モニタリング システムの変更が運用チーム、NOC、その他の類似したチームにのみ許可されていることがよくありますが、このような状況は回避し、CD パターンに従ったシステムに切り替えるべきです。

モニタリング システムでアラートを作成する一般的なアンチパターンは、可能性のあるすべてのエラー条件を列挙して、それぞれに対してアラートを作成することです。これは、原因に基づくアラートといいますが、このような方法はできる限り避けなければなりません。代わりに、症状に基づくアラートを使用します。この方法では、ユーザー向けのシステムで症状が発生した場合、あるいはその兆候が見られる場合にのみアラートを生成します。ユーザー向けでないシステムは引き続き監視し、ユーザー側で症状が発生していない場合には担当のエンジニアに直接アラートを送信しないようにします。この「ユーザー」には組織内のユーザーを含めることもできます。

アラートを生成する場合は、アラートの配信方法を検討する必要があります。アラートにはオンコール エンジニアへの複数の経路が必要です。たとえば、SMS、専用のモバイルアプリ、自動音声通話、メールなどです。通常は、メールの配信リストを使用してチーム全体にメールで送信します。その結果、責任の分散でアラートが無視される可能性があります。また、SN 比の低さも問題になります。実用的でないアラートや対応の必要がないアラートが大量に発生すると、いわゆるアラーム疲れの状態に陥り、本当に重要で、対応が必要なアラートを簡単に無視してしまう可能性があります。アラートの一部をミュートまたは抑止する手段は、適度に行われるように慎重に管理する必要があります。

指標を可視化するモニタリング ダッシュボードを作成するときに、完璧さを求めすぎ、キュレーションに必要以上に時間をかけている場合があります。これは、前述の「原因に基づくアラート」の誤りと似ています。機能性の高いチームでは監視対象のシステムを迅速に変更しています。ダッシュボードのキュレーションに時間をかけていると、ダッシュボードが完成したときには不要なものになっていることもあります。代わりに、チームメンバーが自分のニーズに合うダッシュボードや可視化ツールをすばやく作成できるようにすることが重要です。

顧客獲得率や収益トラッキングなど、製品またはエグゼクティブ向けの指標を、運用ダッシュボードやサービスの正常性を示すダッシュボードに表示していることもあります。これらは、いずれも非常に重要な指標ですが、区別する必要があります。これらは別々に管理することを強くおすすめします。

モニタリングとオブザーバビリティの測定方法

組織にモニタリングとオブザーバビリティのシステムを実装すると、いくつかの内部指標を追跡して現在の状態を確認できます。ここでは、毎月の調査で追跡する項目について説明します。これらは、事後調査やアラートログを自動的に分析して確認することもできます。

  • モニタリング構成に対する変更。1 週間にモニタリング構成を含むリポジトリに対して pull リクエストまたは変更がどのくらい行われているか。その変更がモニタリング システムに push される頻度はどのくらいか。（毎日、バッチ処理、すぐに PR）
  • 「時間外」のアラート 夜間にアラートを処理する割合はどのくらいか。24 時間 365 日対応のサポートモデルを導入しているグローバル企業では問題になりませんが、潜在的な問題が十分に検討されていない兆候を示している可能性があります。夜間に定期的にアラートが発生すると、チームがアラートの疲れや燃え尽き症候群の状態に陥る可能性があります。
  • チーム間でのアラートのバランス。複数のチームが同じサービスを担当している場合、アラートはチーム間で均等に分散され、処理されているか。そうでない場合、その理由は何か。
  • 偽陽性。対応しなかったアラートや「想定内」とマークされたアラートはどのくらいあるか。実用的でなく、障害の予測に役立たないアラートは削除する必要があります。
  • 偽陰性。アラートが通知されなかったシステム障害や、予想よりも遅れたアラートはどのくらいあるか。事後調査で新しいアラート（症状に基づくアラート）を追加する頻度はどれくらいか。
  • アラートの作成。1 週間に作成されるアラートの数はどのくらいか（合計、重大度、チーム別など）。
  • アラートの確認。決められた期限（5 分、30 分など）内に確認されたアラートの割合はどのくらいか。アラートが 2 番目の担当者に通知された場合、アラート フォールスルーなどの指標と統合または追跡される場合があります。
  • アラートのミュートとミュート期間。1 週間にミュートまたは抑止されたアラートの数はどのくらいか。このプールに追加された数と削除された数はどのくらいか。アラートのミュートに期限が設定されている場合、最初に想定した期限よりもが延長されたミュートの数はどのくらいか。ミュートの平均時間と最大時間はどのくらいか（「無期限になったミュートはどのくらいか」という質問もよいかもしれません）
  • 実用的でないアラート。意味のないと思えるアラートの割合はどのくらいか。これは、エンジニアがアラートの意味を把握できない場合や、既知の問題が原因で、特定のアクションをすぐに実行できなかったことを意味します。このようなアラートは疲弊の原因となります。
  • 操作性: アラート、ランブック、ダッシュボード。ダッシュボードに表示されるグラフの数はどのくらいか。グラフあたりの線の数はどのくらいか。チームはグラフの意味を理解できているか。新しいエンジニアに役立つ説明は表示されているか。ユーザーが必要な情報を取得するために、何度もスクロールする必要があるか。エンジニアがアラートからハンドブック、ダッシュボードに効率的に移動できるか。エンジニアに適切な指示が伝わるようなアラート名になっているか。これらの項目は、チーム内で定期的に評価されているかもしれません。
  • MTTD、MTTR、影響。結論として、検出までの時間、解決までの時間、影響が問題になります。停止がユーザーに影響を及ぼした時間に影響を受けているユーザーの数を掛けて、AUC（Area Under the Curve）で測定することを検討してください。これは、ツールを使用すると正確に測定できます。

これらの指標の一部またはすべてを追跡することで、モニタリングとオブザーバビリティのシステムが組織内でどの程度機能しているかを把握できるようになります。これらの測定値を製品別、運用チーム別、またはその他の方法で分類すると、製品の状態だけでなく、プロセスやメンバーの状態も分析できます。

次のステップ