オブザーバビリティにおける生存者バイアス

第二次世界大戦中、数学者エイブラハム・ウォールドは、任務から戻った航空機が受けた射撃による損傷パターンから、航空機のどの部位の装甲を補強すべきかを特定するという問題に取り組みました。普通であれば、損傷した部分が航空機の弱点領域だと考えるでしょう。しかしウォールドはその考えを否定しました。なぜなら、その航空機は生還したからです。彼は、追撃された航空機にこそ、本当の弱点を示す未知のデータがあると考えました。実際、生還した航空機の損傷パターンは、損傷しても問題ない領域を示していたのです。

_{^{McGeddon氏作、CC BY-SA 4.0、https://commons.wikimedia.org/w/index.php?curid=53081927}}

オブザーバビリティが注目される中、私たちは当たり前のように「生還した」データのみに基づいて対応を判断しています。しかし実際には、環境内で把握できることだけに注意を払っているとバイアスに陥ってしまいます。今日では多くのツールが、オーケストレーション、マイクロサービス、ハイブリッドクラウドの状況把握に役立つグラフや情報を提供しています。しかしそれらの情報だけで十分なのでしょうか。本当に必要なインサイトが得られているのでしょうか。

コナン・ドイルの小説『ボヘミアの醜聞』の中でシャーロック・ホームズは「君は見ているだけで、観察していない」と指摘しています。このブログ記事では、生存者のみを基準に判断し全体の観点を見落とす生存者バイアスについて考察します。

ここ数年、アーキテクチャの複雑化と抽象化が急速に進んでいます。モノリシックなアプリケーションはクラウドネイティブのアプリケーションに置き換えられ、シングルスレッド、3層構造の環境は大規模で柔軟かつ複雑なマイクロサービスアーキテクチャに進化しつつあります。

ここで明らかになったことが1つあります。抽象化はさまざまな方法で私たちの仕事を楽にしてくれますが、アプリケーションや環境の状況を把握しようとすると突然難しくしなることです。そのとき私たちは、世界を支えるのが亀ならば、それを支えるのも亀、その下も永遠に亀が続くという無限後退に陥りがちです。

この傾向は、テクノロジーの導入方法の変化によって顕著になっています。私たちは今、テクノロジーの進化に対応するために、抽象化をいたるところに取り入れています。

今日では、多数のホストを持ち、複数のクラウドを同時に利用できます。そこでは、さまざまなプログラミング言語で書かれたサービスが、それぞれに異なるフレームワークを使用しています。私たちは柔軟なコンピューティング環境を手に入れ、データニーズは無限に広がり、どこまでも拡大し続けています。

例としてKubernetesについて考えてみましょう。Kubernetesは最も先進的なコンテナオーケストレーションシステムであり、複雑なコンテナ化アプリケーションでよく利用され、パブリッククラウドでは圧倒的な存在感を示し、その機能は絶えず進化しています。しかし、抽象化は簡素化というメリットだけでなく以下のような課題ももたらします。

• 複数の抽象化層が階層状になって追跡が困難：コンテナ、ポッド、クラスター、ノード、ネームスペースなど
• 存在がエフェメラル(一時的)：コンテナがスピンアップしてから数秒でスピンダウンすることがある
• ワークロードの配置が動的：どこにあるのか見つけられない
   

これらに加えて、Dockerコンテナ、基礎となるアプリケーションサービス、サードパーティのサービス、通信プロトコルの構造の違いにより、課題はさらに複雑になります。さらにその結果として、分散したサービスのパフォーマンスをエンドツーエンドで監視することが難しくなるという課題も生じます。この複雑な環境で、リクエストがアプリケーションにたどり着くまでの道のりを手探りで調査することはまず不可能です。

また、オブザーバビリティを把握するためのテレメトリデータが1日あたり数百テラバイトを超すことも珍しくありません。メトリクスの集計は非常に有効な手段ですが、根本原因をすばやく特定し、相応の高さのカーディナリティを得るには、タグ、カテゴリ、基礎となるインフラの情報を追加する必要があります。一方で分散トレーシングなら、複数のスパンを生成できます。平均では1回のリクエストにつき約8のスパンが生成されます。たとえば、1秒あたり500件のリクエストが発生するシンプルなeコマースサイトがあるとします。この場合、4000のスパンが生成され、そのそれぞれに重要なデータが含まれます。特に、外れ値や、想定外のまれなイベントに関するデータは貴重です。

これらはシグナルに含まれるノイズのように思えますが、実はすべてのノイズに重要なシグナルが隠されています。ここでついに、冒頭の生存者バイアスの話題がオブザーバビリティの考え方に関係してきます。 

ノイズを削減する方法は(少なくとも理論的には)たくさんあります。  たとえば、サンプリングによってテレメトリを絞り込むことができます。または、バンドパス手法によって通過できる集計データを制限することもできます。デジタル信号の量子化ノイズを除去する方法もあります(ほぼ不可能ですが)。

しかし、いずれの方法にも問題があります。それは、削減するのは「ノイズ」であることが前提となっている点です。マイクロサービスやリクエストドリブンなアプリケーションでは、どのデータもノイズではありません。そのため、いずれかの方法でデータを削減すると、それは文字どおり「データ」を削減することになります。そうなると、オブザーバビリティを活用して知ろうとしている状況自体を知るのが難しくなります。いわば「未知の未知」状態です。

一部の分散トレーシングツールでは、サンプリングが使用されます。この場合、トレースの5～10%が分析対象になり、残りは破棄されます(ヘッドベースサンプリング)。もう少し賢いツールでは、トレースの完了を待ってから、注目すべき点があるトレースが分析され、注意が必要だと判断された結果だけが返されます(テイルベースサンプリング)。しかし、オブザーバビリティの目標が「未知の未知」を発見、分析、解消することであるなら、返された結果だけを見ることは、結局、バイアスに陥っていることになります。 

外れ値を正確に特定したいのであれば、役に立ちそうなデータもそうでないデータもすべて把握する必要があります。そうすれば、生存者のみを基準にして判断を下すことなく、弱点を明らかにして改善につなげることができます。有意義なベースラインを設定して真の異常を特定すれば、航空機の安全を保つことができるのです。

逆に、すべてのデータを把握できなければ、リクエストに基づく有用なサービスマップを作成することも、過去のデータのトレンドを追跡することもできません。

しかし、そこで疑問が湧きます。「どのみちメトリクスがあればわかるのでは？」

その答えは複雑です。分析の前にランダムなサンプリングを行う場合、特にトレースデータについては、有効なREDメトリクス (比率、エラー、期間)数は得られません。そうなるとやはり、「未知の未知」を無視して、見えているものだけに基づいてシステムを運用することになります。

さらに悪い結果も考えられます。航空機の例では、損傷パターンに対する最初の反応は、損傷の激しい部分を補強すれば生存確率が上がるはずだというものでした。しかし、装甲を追加すると重量が増して動きが鈍くなり、逆に生存確率が下がる可能性があります。その意味でも、生存者バイアスを受け入れれば反対の結果を生みだすことになります。

ここで、航空機の例をREDダッシュボードに当てはめてみましょう。サンプリングのアプローチでは、期間のメトリクスはきれいな曲線の正規分布を描きます。そのため、95パーセンタイルや99パーセンタイルの外れ値を見逃してしまいます。グラフは完璧ですが、顧客は不満でしょう(少なくとも一部は)。  

メトリクスの完全な集計が得られたとしても、その基礎となるデータが欠けていれば問題につながります。同じアプローチを例にとると、この場合、期間について非常に頻度の少ないスパイクを確認できます。メトリクスから問題が検出され、アラートが生成されるかもしれません。外れ値が見つかったとして問題になるのは、「そのトレースが記録されているか？」ということです。アニメ『フューチュラマ』で登場人物(ロボット)のベンダーが検査官ナンバー5に関するファイルを探しまわったときのように、苦労したあげく何もないことを発見するだけに終わるでしょう。賢明なサンプリングシステムがその外れ値を捕らえたとしても、その時間帯に起きていたことや、顧客の要求処理の正常な進行状況、関連インフラの正常動作と比較できなければ意味はありません。 

実際、答えはきわめてシンプルです。あらゆるデータを常にリアルタイムで効率的に提供してくれるインストルメンテーションツールを選ぶことです。これにより、データの誤認や欠落の落とし穴を避けることができます。そのデータを、REDベースでも独自の基準でも任意のダッシュボードで表示して、アプリケーションと環境の状況を完全に可視化し、データをドリルダウンして根本原因を探ることができればさらに良いでしょう。つまり、何が重要で何を知るべきかは、ツールプロバイダーの基準にただ従うのではなく、自分で判断すべきだということです。

そこでぜひ、現行のオブザーバビリティテクノロジーを見直してみてください。実際に把握しているのはシステムの状況の一部だけではないでしょうか。生存者バイアスは確かに存在します。そして、人は目で見たものから簡単に初期判断を下しがちであるため、そのバイアスに容易に陥ってしまいます。バイアスのかかっていないオブザーバビリティデータを手に入れて、アプリケーションが「墜落」することのないよう安全を確保しましょう。

関連情報

 

• オブザーバビリティ調査レポート
• Kubernetes上のマイクロサービスの監視