一体なぜ、Observability はこんなにも高価なのか?

今すぐ行動しましょう！期間限定オファー！オペレーターが待機しています！DevRel アドボケート / テクニカルエバンジェリスト / IT テイルスピナーとして次の冒険に挑む準備ができています。それが必要なことのように思われる場合は、メールまたはLinkedInで私に連絡してください。

私はこれまで 27 年間、監視と可観測性を専門としてきましたが、多くのツールや技術が登場しては消えていきました (RMon はいかがでしたか?)。また、登場しては定着したものも少なくありません (SNMP の終焉の噂は、これまでも、そしてこれからも、大いに誇張されたままです)。最近、この分野で最近改善された機能の 1 つである OpenTelemetry (このブログでは、以降「OTel」と略します) を研究しています。最近、OTel に飛び込むことを決意したことについて書きました。

ほとんどの場合、私はこの旅を楽しんでいます。しかし、オブザーバビリティに関してしばらく前から存在していた問題があり、それは OTel が解決していない問題です。この記事のタイトルはこの問題をほのめかしていますが、私はもっと明確に述べたいと思います。まずは比較ショッピングから始めましょう。

町中のベンダーを怒らせる前に、これらは大まかで大まかな高レベルの数字であることを明確にしておきたいと思います。詳細を確認したい場合は価格設定ページにリンクしています。また、以下に示す価格は、実際の運用環境で見積もりを取得した後に実際に支払う価格を必ずしも示すものではないことを承知しています。

• New Relicの料金

  • 送信するデータごとに 1 GB あたり 35 セントかかります。
  • …価格ページでは特に明確には書かれていないが

  
  

• Datadog には実に豊富なオプションリストがありますが、大まかに言うと、次のような料金がかかります。

  • ホストあたり15～34ドル

  • 60¢ – ネットフローレコード100万件あたり1.22ドル

  • ログレコード 100 万件あたり 1.06 ～ 3.75 ドル

  • 100万スパンあたり1.27～3.75ドル

    
    

• Dynatrace の価格設定ページには、Datadog とほぼ同じくらい長いリストが掲載されていますが、いくつかの重要な項目は次のとおりです。

  • 100,00メトリックあたり15セント

    • 保持のために1ギガあたり1日あたり0.07セント追加

  • ログ1ギガあたり2セント

    • 彼らを維持するために、1日あたり1ギグあたり0.07セントをプラス
    • 問い合わせたギグごとにプラス 0.035 セント

  • イベントはログと同じレートです

  • 1,000スパンあたり0.014セント

    
    

• Grafana はオープンソースであり、インストールとホスティングという面倒な作業を喜んで引き受けるのであれば、実質的にすべてを無料で提供してくれることに留意する必要があります。ただし、価格設定は次のようにまとめることができます。

  • 1,000 メトリックにつき 8.00 ドル（1 分あたり最大 1 件）
  • ログとトレースは1ギガあたり50セント、保存期間は30日間

このリストは網羅的でも完全でもありません。多くのベンダーを除外しましたが、それは消費量に基づいた価格設定がないからではなく、同じようなものになるからです。上記のベンダーについても、ここでの詳細は完全ではありません。企業によっては、消費量 (取り込み) に対して課金するだけでなく、データの保存に対しても課金し、さらにデータのクエリに対しても課金します (New Relic がそうです)。企業によっては、サービス レベルを選択するように促し、選択しない場合は、その月の使用量の 99 パーセンタイルに基づいて推定料金を請求します ( Datadog がそうです)。

価格設定ページに記載されている内容が最終的な決定事項ではないことは、誰も驚くことではありません。これらの企業の中には、現在でも「消費量に基づく価格設定」の概念の解釈を再定義することを検討しているところもあり、状況がさらに不透明になる可能性があります (New Relic がまたあなたを見ています)。

そうは言っても、私はあえて断言しますが、これらの価格帯のそれぞれは非常に低く、「取るに足らない」という言葉でさえ大きすぎるほどです。

つまり、本番環境のワークロードが価格表を満たすまでです。その時点で、これらの小さな数字がすぐに実際のお金に加算されます。

逸話の複数形

私は何人かの友人にこの質問をして、現実世界で値段に驚いた経験があるかどうか尋ねました。いつものように、友人たちは期待を裏切りませんでした。

「数年前、Fargate をメインに使用して、New Relic と Datadog の詳細な価格比較を行いました。ログの送信を開始するまでは New Relic の方が大幅に安かったのですが、その後 Datadog は突然、APM を使っても 30～40% 安くなりました。[しかし] ホストあたりのコストも考慮されるため、サーバーレスで何かを実行しない限り、APM はあまり魅力的ではありません。Kubernetes で使用したいと思っていましたが、非常に高価で、経営陣は Fargate のサービスにかかるコストを信じようとしなかったため、通常は 2～3 か月ごとに数字を示していました。」__– Evelyn Osman、enmacc プラットフォーム責任者

「私が覚えているのは、請求書を見たときの CFO の顔だけです。」__ – この引用は実に壮大なものですが、匿名を希望する人物です。

そしてもちろん、（観測可能性の分野では今や悪名高い） 6,500万ドルのDatadog請求書の犯人は誰かという謎もあります。

最初のステップは、問題を認めることです

昔々 (つまり 2000 年代初頭)、監視 (可観測性という言葉はまだ使われていませんでした) における課題は、必要なデータを特定し、そのデータをシステムに渡してもらい、クエリ、表示、アラートなどで使用できる (効率的であることは言うまでもありません) 方法でそのデータを保存する方法でした。

コストのほとんどがそこにかかっていました。システム自体はオンプレミスで、ハードウェアを購入すれば実質的に「無料」でした。その結果、可能な限り収集し、永久に保持することが慣例となりました。そして、テクノロジーが変化したにもかかわらず、多くの組織の考え方は変わっていません。

Grafana ソリューション アーキテクトの Alec Isaacson 氏は、顧客との会話は次のようなものになることがあると述べています。

「私は最も重要なシステムから 5 秒ごとに CDM メトリクスを収集しています。なぜなら、ずっと昔、システムが遅いときに誰かが怒鳴られたことがあり、メトリクスではその理由がわからなかったからです。」

現在、監視および観測データ (「テレメトリ」) の収集は比較的簡単ですが、個人としても組織としても、私たちは問題の枠組みを変えていません。そのため、私たちは利用可能なすべてのデータを取得し続けています。考えられるすべてのタグとスパンでコードを計測します。ログ メッセージがある場合は、それを送信します。ハードウェア メトリックは、コンテキストを提供するため、取得した方がよいでしょう。ネットワーク テレメトリ (NetFlow、VPC フロー ログ、ストリーミング テレメトリ) がある場合は、それも取得します。

しかし、私たちはそれをどうするかについて考える時間を取ることはありません。オスマンさんの経験がその結果を物語っています。

「[彼らは]監視で何をしているのか全く分かっていませんでした[…]すべての計測とログ記録が有効になっていて、その後「念のため」長期間保存されていました。つまり、彼らは途方もない金額を浪費していたのです。」

これを、私たちが（多かれ少なかれ）断ち切った別の悪い習慣に結び付けると、クラウドへの「リフト アンド シフト」（多くの場合、より正確には「リフト アンド シット」と表現されます）の初期の頃、私たちはアプリケーションを丸ごと移行しただけでなく、プラットフォームが提供する最大のシステムに移行しました。なぜでしょうか。それは、古いオンプレミスのコンテキストではサーバーを 1 度しか要求できなかったため、投資を将来にわたって保証するために、入手できる最大のものを要求したからです。この決定は、おかしなほどナイーブだっただけでなく、恐ろしく高価で、「エラスティック コンピューティング」の仕組みを理解し、新しいパラダイムに合わせてアプリケーションを再構築するのに全員が数年かかりました。

同様に、私たちが利用できるテレメトリ データをすべて収集する余裕はなく、さらに、たとえお金に問題がなかったとしても、そのデータに関する計画がないことを私たちは認識し、認めるべき時が来ています。

認めましょう: あなたの問題にも問題がある

ここで少し OTel について考えてみましょう。OTel に移行する主な理由の 1 つ (おそらく最大の理由) は、ベンダー ロックインの苦痛を永久に取り除くことです。これは前回のブログ投稿で取り上げた内容で、最近友人からも次のような意見が寄せられました。

OTel は、「ああ、すごい！ ベンダー x に縛られて、このコードをすべてリファクタリングするには何百万ドルもかかる」といった問題の多くを解決します。「ああ、ベンダーを切り替えるの？ よし、エンドポイントを更新しよう…」という問題とは対照的です。 – Matt Macdonald-Wallace、ソリューション アーキテクト、Grafana Labs

はっきり言って、OTel はこの問題を解決するのに素晴らしい仕事をしており、それ自体が素晴らしいことです。しかし、OTel には、人々がすぐには気づかない、あるいはまったく気づかない欠点があります。その問題は、前の問題をさらに悪化させます。

OTel は、すべてのデータ (メトリック、ログ、トレースなど) を取得し、収集して、必要な場所に送信します。ただし、OTel は必ずしも効率的に実行するわけではありません。

例1: ログメッセージ

syslog から直接取得した以下のログ メッセージを見てみましょう。そうです、古き良き RFC 5424 です。80 年代に誕生し、2009 年に標準化された、誰もが認めるネットワーク メッセージ プロトコルの「おしゃべりな人」です。私は、中規模のネットワークが 1 時間あたり 400 万件以上の syslog メッセージを生成するのを見たことがあります。そのほとんどはまったく役に立たないくだらないものでしたが、これらのメッセージはどこかに送信され、途中で何らかのシステムによって処理 (または破棄) される必要がありました。これが、私がずっとsyslog とトラップの「フィルタリング システム」を提案してきた理由の 1 つです。

メッセージの量に関する細かい点はさておき、一部の IT 担当者にとっては、場合によっては、それらのメッセージの一部に価値があります。そのため、それらも考慮 (および収集) する必要があります。

 <134>1 2018-12-13T14:17:40.000Z myserver myapp 10 - [http_method="GET"; http_uri="/example"; http_version="1.1"; http_status="200"; client_addr="127.0.0.1"; http_user_agent="my.service/1.0.0"] HTTP request processed successfully

現状のログ メッセージは 228 バイトです。これは、毎日どころか、毎分収集するテレメトリのほんの一滴にも満たない量です。しかし、これから行うことでは、本当に同等の比較を行いたいので、これを JSON 化すると次のようになります。

 {  "pri": 134,  "version": 1,  "timestamp": "2018-12-13T14:17:40.000Z",  "hostname": "myserver",  "appname": "myapp",  "procid": 10,  "msgid": "-",  "structuredData": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0"  },  "message": "HTTP request processed successfully" }

これにより、ペイロードは空白なしで 336 バイト、空白ありで 415 バイトに増加します。比較のために、OTLP ログ メッセージの例を次に示します。

 { "resource": { "service.name": "myapp", "service.instance.id": "10", "host.name": "myserver" }, "instrumentationLibrary": { "name": "myapp", "version": "1.0.0" }, "severityText": "INFO",  "timestamp": "2018-12-13T14:17:40.000Z",  "body": { "text": "HTTP request processed successfully"  },  "attributes": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0"  } }

この (汎用的で最小限の) メッセージは 420 バイト (空白なし、すべて含めると 520 バイト) です。これはまだ小さいですが、それでも空白のある OTel バージョンは JSON 化されたメッセージ (空白あり) より 25% 大きく、元のログ メッセージの 2 倍以上の大きさです。

現実世界のデータを適用し始めると、事態はさらに膨れ上がります。ここでの私のポイントは、OTel がすべてのログ メッセージにこれを実行すると、これらの小さなコストがすぐに積み重なるということです。

例2: プロメテウス

現代の指標管理方法もインフレの影響を受けやすいことが判明しました。

• JSON 形式の典型的な Prometheus メトリックは 291 バイトです。
• しかし、同じメトリックを OTLP メトリック形式に変換すると、サイズは 751 バイトになります。

確かに、OTLP にはこの問題を軽減するバッチ処理機能がありますが、これは回線経由の転送にのみ役立ちます。宛先に到着すると、多くのベンダー (すべてではありませんが、ほとんどのベンダー) は保存する前にバッチ処理を解除するため、元のメッセージの 2.5 倍の大きさに戻ります。私の友人 Josh Biggley が言ったように、

「2.5 倍のメトリクスを取り込むには、そのコストを正当化するコンテキストについて語る素晴らしいストーリーが必要です。」

それはあなたではありません、OTel、それは私たちです。（しかし、それはあなたでもあります）

これらすべてが OTel に対して少し過度に批判的であるように思われるなら、説明させてください。私は OTel が驚くべき進歩であり、監視と可観測性に真剣に取り組む人は誰でもそれを標準として採用する必要があると心から信じています。これはユーザーにもベンダーにも当てはまります。ログ、メトリック、トレースの組み合わさったものを、宛先に関係なくコンテキストを維持しながら出力できる機能は、非常に貴重です。

(しかし…) OTel はソフトウェア エンジニアによって (そしてソフトウェア エンジニアのために) 設計されました。これは、データの移動、処理、保存のコストよりも、データの取得の難しさの方がまだ懸念されていた、過ぎ去った時代 (つまり「2016 年」) に生まれました。OTel は、設計上、ボリュームに偏っています。

このセクションのタイトルは冗談ですが、問題は OTel ではありません。本当に悪いのは私たちです。具体的には、テレメトリとの不健全な関係です。すべてのデータ ポイントを収集して送信することに固執すると、月末に受け取る高額な請求書について、私たち自身以外に責める人はいません。

このデータはあなたに喜びをもたらしますか?

観測可能性ソリューションに重労働を任せて、すべてのデータを統合インターフェースに転送するのは簡単です。監視および観測可能性ソリューションを（少なくとも名目上は）所有しているソフトウェア エンジニアであれば、これは簡単に実行できます。

これらのサービスの単なる消費者、つまり無実の傍観者であれば、さらに簡単です。このカテゴリに該当する人々としては、特定のサイロ (データベース、ストレージ、ネットワークなど) に密接に関係する人々、チケットを受け取ってサポートを提供するものの、計測機器や計測機器が接続されているツールには関与していないヘルプデスクおよび NOC チーム、または情報セキュリティのように監視や観測可能性と重なるものの、より専門的なニーズを持つチームなどがあります。

しかし、正直に言うと、セキュリティ エンジニアの場合、すでに存在し、何年もうまく機能してきた完璧な標準と比較して、 ログやメトリックを取り込むために 2 倍のコストを支払うことを正当化できるでしょうか。複数のツールを使用している可能性があるということですか。はい。しかし、私が (何度も ...

そのため、OTel または任意の可観測性ソリューションに全面的に取り組む前に、ROI について真剣に議論する必要があります。

<EOF> (今のところ)

過去には、市場ではシート (またはインターフェイス、シャーシ、CPU) 単位の価格設定から消費モデルへの移行が見られました。また、テクノロジが逆戻りするのを見てきました (携帯電話サービスが 1 分単位またはテキスト 1 件単位から、月額料金で無制限のデータに移行したように)。将来的には、監視と可観測性に関しても同様の振り子が逆戻りするのではないかと思います。しかし、今のところは、現在普及している価格設定システムと、監視の歴史の別の時点で生まれた、目の前を通過するテレメトリのあらゆるビット (およびバイト) を収集、送信、保存するという私たち自身の衝動の両方と戦わなければなりません。

もちろん、コストだけが要因ではありません。パフォーマンス、リスク、その他もろもろを考慮する必要があります。しかし、その中心にあるのは、私たちが自分自身に問いかけ始める必要があるということです。

• このデータを使って何をするのでしょうか?
• 誰が使うのでしょうか？
• どれくらいの期間保管する必要がありますか?

そしてもちろん、一体誰がそれを支払うのでしょうか?