オブザーバビリティにおけるサンプリングの隠れたコスト

今日のソフトウェアは非常に複雑で、膨大な量のデータを生成します。シンプルなアプリケーションであっても数百のサービスで構成され、そのすべてからメトリクス、ログ、トレースが常時生成されます。また、トランザクションが発生するたびに、そのトランザクションに関する数キロバイトのメタデータが生成されます。トランザクションが同時処理される場合は、少数であってもデータの合計が1秒あたり数メガバイトになります。つまり、そのすべてのデータを活用するには、1日あたり300GBほどのデータを収集、分析しなければならない計算になります。アプリケーションを構成するサービスが増え、ユーザーが増えると、データ量はさらに増加します。ビジネスの状況について知るにはデータが必要です。顧客が自社のWebサイトにどのくらいの時間滞在しているか、いずれかのサービスのパフォーマンスが低下したらユーザーエクスペリエンスにどのような影響があるか、現在どこかで問題が発生していないかなど、知りたいことはたくさんあるでしょう。そのすべての疑問を明らかにするのがオブザーバビリティ(可観測性)であり、その基となるデータです。

大量のデータを活用する方法の1つが、すべてのデータをオブザーバビリティシステムに送信することです。これが最も簡単な方法であり、データの収集漏れも防げます。ただし、問題が2つあります。

1. コスト 
2. 能力
    

多くのオブザーバビリティツールでは、取り込むデータの量によって料金が決まります。つまり、取り込むデータが増えるほど料金が上がります。さらに厄介なのが、多くの場合、取り込むデータの量を事前に見積もる必要があり、実際のデータ量が想定を超えると追加料金を取られることです。そもそも十分な量のデータを扱えないツールも少なくありません。すべてのデータを取り込むのではなく「大部分のデータを取り込めばOK」というスタンスです。ビジネスの拡大とともに、生成されるデータ量が1秒あたりMB単位から、GB、さらにはTB単位に増えると、こうしたオブザーバビリティツールでは扱いきれなくなります。

その対策として多くのベンダーが推奨しているのが、データをサンプリングすることです。これはつまり「一部のデータを捨てる」ということです。また、多くのベンダーが、サンプリングを「費用を抑える方法」と謳っています。つまり、「取り込むデータが減れば、分析して保存するデータも減るので、その方が安くなりますよ」というわけです。しかし、一部のデータを捨てることが深刻な結果を招くこともあります。サンプリングを推奨するベンダーの多くは、そのような結果には配慮していません。現実のシステムが生成するデータ量に自社のツールが対応できないという理由で推奨しているだけです。

データをサンプリングすると、重大な問題を見落とす可能性があります。たとえば、ほとんどの時間は正常に稼働していて、ときどき短時間だけリクエストが爆発的に増加して遅延が5秒を超えるシステムがある場合、サンプリングの手法では遅延をすばやく察知できないか、場合によってはまったく気づかない可能性があります。想像してみてください。もしこの短時間に大口注文が殺到していたら？遅延のせいで顧客が注文を取り消していたら？取り消された各注文がすべて機会損失になるのです。アプリケーションの動作が不安定だったり遅かったりすると、ユーザーはSNSで不満を漏らし、それが組織の評判低下というさらなる損失につながることもあります。 

基本的に、サンプリングはオブザーバビリティとは矛盾するアプローチです。

サンプリングを推奨するベンダーは、一部のデータが失われる問題のさまざまな回避策を提案するかもしれませんが、基本的に、サンプリングはオブザーバビリティとは矛盾するアプローチです。システムの出力の一部でも故意に無視すれば、システムの状況を完全に把握することはできません。

実際に起こり得る例

では、例を挙げて説明しましょう。サンプリングベースのオブザーバビリティツールを販売するベンダーはよく、サンプリングしたデータポイントでもすべてのデータの平均値と同じインサイトが得られると説明しますが、これは間違いです。下の表は、注文処理サービスの呼び出し時間のメトリクス例を示します。この注文処理サービスでは、多くのサービスがそうであるように、ときどきリクエストが急増して処理が追いつかなくなり、呼び出し時間が長くなることがあります。

一番左の列には、すべてのデータが表示されています。その隣の列の上部には、ネイティブのサンプリングシステムによる解析結果が表示されています。このシステムでは、データが2つおきに抽出されて解析されます(サンプリングを使用するツールの多くはサンプリング率が33%をはるかに下回ります)。また、同じ列の下部には、ベンダーが言うところの「業界最先端」のサンプリングシステムにより、2つおきのデータに加えて、1000ミリ秒を超えたトランザクションを記録した結果が表示されています。

ご覧のとおり、サンプリングを使用するシステムでは、状況を正確に把握できません。どちらのシステムの結果も実際の結果とはずれがあり、メトリクスによっては38%近くも過小または過大に評価されます。多くのレガシーシステムでは指標として平均値が想定されていましたが、近年ではSLOやエラーバジェットを使用するのが一般的で、平均値は参考になりません。パーセンタイルを調べると、サービスの状況をより正確に把握できます。しかし、上の例でわかるとおり、サンプリングシステムではこちらも正確とは程遠い結果になっています。

インストルメンテーション(計装)のROIに対するサンプリングの影響

最後に、オブザーバビリティを得るためのアプリケーションのインストルメンテーションについて簡単にお話ししましょう。OpenTelemetryにネイティブ対応していないシステムを使用している場合は、通常、負荷の大きいエージェントをインストールし、すべてのアプリケーションを手動でインストルメントして、メトリクス、トレース、ログを送信するように設定する必要があります。OpenTelemetryにネイティブ対応したシステムを使用している場合でも、インストルメンテーションを設定し、適切なデータがすべてオブザーバビリティプラットフォームに送信されるかどうかを検証するために、ある程度の開発作業が必要です。

データがサンプリングされると、そうした苦労がすべて水の泡になります。サンプリングによって、オブザーバビリティプラットフォームの価値が下がると同時に、インストルメンテーションのROIも下がってしまいます。後で半分のデータが捨てられてしまうのであれば、何のためにお金と時間をかけてすべてのデータを収集するシステムを築くのでしょうか？まったく無意味な作業で、コストも無駄になります。肝心な時に重要なインサイトを見過ごすことになれば、役に立たないどころか逆効果にもなります。

データを一切捨てず、拡張性も備えたシステムをお探しであれば、ぜひSplunk Observability Cloudをチェックしてみてください。Splunk Observability Cloudの無料トライアルも
ご利用いただけます。

オブザーバビリティの概念については、『オブザーバビリティ(可観測性)ビギナーガイド』をご覧ください。

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