[分散] リソースとトランザクション: 可観測性の基本的な二重性

シグマン：私の名前はベン・シグマンです。私はLightstepの共同創設者兼CEOです。ここで私が話しているのは、リソースとトランザクション、つまり可観測性の基本的な二重性です。私はキャリアのほとんどを可観測性に関する仕事に費やしてきました。キャリアの初期には、Google で 9 年間を過ごし、Google の分散トレース システムである Dapper と、高可用性監視およびメトリック システムである Monar に携わりました。そしてもちろん、Lightstep は可観測性にも重点を置いています。ここに来るまでに長い時間がかかりました。私はこれまでとは異なる方法で可観測性について考えるようになりました。それが今回の講演のテーマです。

取引

トランザクションとは何ですか?右側には、あるシステムの図が表示されます。私たちは、より大規模なマイクロサービス アーキテクチャ、クラウド ネイティブ アーキテクチャであるこの銀行口座サービスの観点からいくつかのことをお話しします。このプレゼンテーションの取引は、必ずしも銀行取引のように見えるわけではありません。これは、リクエスト全体ではなく、システムのある部分から別の部分に伝播するリクエストのみを指します。これが、戻ってきて達成しようとしていたことをすべて完了するまでに実行される作業のすべてです。トランザクションとは、エンドユーザーが人間であっても、場合によっては Twilio などであっても、アプリケーション内で実際に「エンドユーザーのために何かを行う」ものです。おそらく、Twilio のエンド ユーザーは、実際にはスクリプトを実行する単なる別のプログラムなのでしょう。トランザクションはユーザーまたは顧客に価値を提供します。

現在、特にクラウド ネイティブでは、トランザクションが分散されます。必ずしもそうである必要はありませんが、通常はそうなります。それらはさまざまな粒度で記述できます。ここで私が言いたいのは、同じトランザクションを、エンドユーザーのワークフロー全体のような非常に粗い粒度で記述できるということです。たとえば、Lyft、Uber などのライドシェア アプリの場合、乗車をリクエストするプロセス全体が 1 つのトランザクションと見なされる可能性があります。これが唯一の粒度レベルです。 HTTP リクエストなど、サービス間の個々のリクエストについて、より細かく検討する必要がある場合があります。これを、物事を説明するために使用したい粒度にするか、一部またはすべてのローカル関数呼び出しについてさらに詳細に知りたいと思うかもしれません。そこで私は、理論的には、その 1 つのトランザクションを完了するためにシステム全体で発生したすべての CPU 命令の観点からトランザクションを調べることができると想定しました。これらはすべてトランザクションをモデル化する有効な方法です。もちろん、このリストを書き進めていくと、このレベルの粒度で物事を記録するコストがますます高くなります。実際、この値が非常に高くなると、かなりのオーバーヘッドが発生し、トランザクションに影響を及ぼし始めます。理論的には、これらは異なる粒度です。トランザクションを記述するために使用されるテレメトリは、通常、トレースと構造化されたログです。構造化ログはテキスト ログ ステートメントに似ていますが、明示的なキー値属性を持ちます。これらのことについてはここで説明されています。銀行口座リクエストには、リクエスト サイズ プロパティ、いくつかの HTTP パス、ステータス コード、レイテンシなどがあることがわかります。これらは、このモデルにおけるトランザクション フラグメントの理論的な特性です。

また、最終的にはトレースがログ記録に取って代わることになると思います。これには時間がかかりますが、トランザクションの場合、トレースがログ記録に代わることになります。ここで、トレース モデルが単純な単一プロセス ログ記録よりもはるかに柔軟であることを示して、この理由を説明します。ここでは 2021 年について話しているわけではありませんが、これはむしろ可観測性に焦点を当てたものです。これはログ記録ステートメントです。 22 行目には疑似コードがあります。これらのログ ステートメントはそれぞれ独自のテーブルを定義します。ここでの構造は一連のキーを定義し、リクエストのサイズ、パス、ステータス、およびレイテンシがすべてここに反映されます。これらの列がこのテーブルの列になります。次に、ローカル状態または他の場所から取得された値があります。この値のセットがテーブル内の行になります。

追跡は取引間のつながりに過ぎない

これを説明して明確にするために、運用環境で実行されているコードがこの理論上のテーブルにデータを入力するため、このログ ステートメントが用意されています。もちろん、このデータをすべて MySQL やそれに類するものに接続したり、Elastic、Splunk などに必ず接続したりすることを提案しているわけではありません。ログステートメント自体によって記述された理論的なテーブルがあり、それをそのようにモデル化できるというだけです。場合によっては、ツールを使用してこれらのテーブルに対してクエリを実行できます。トレースの素晴らしい点は、これらのログ記録システムにより、柔軟な結合が非常に困難または不可能になったり、非常に高価になったり、不可能になったりすることです。分散トレースはシステム全体に接続します。繰り返しになりますが、これがシステム アーキテクチャである場合、私たちが行うことは、すべての構造化イベントの接続を有効にすることです。ログと呼ぶか、トレース スコープと呼ぶかは、実際には重要ではありません。まだトランザクションを記述中です。トレース コンテキストを使用して、これらすべてのサービスからの構造化イベントを 1 つの大きなテーブルに結合します。ここでは、さまざまなサービスの列が色分けされたテーブルがあり、サービス A、B、D も接続されています。各分散トランザクションはこのテーブル内の行を表します。

これは非常に強力です。この概念モデルで考えることができれば、あらゆる種類の分析を実行して、サービス境界を越えた列間の相関関係を見つけることができるからです。これにより、あるサービスの動作が別のサービスの特定の動作にどのように影響するかを理解できるようになります。具体的には、サービス A のスタックの最上部に顧客 ID フィールドがあり、銀行口座サービスへのレイテンシが高いときに、特定の顧客が関与する割合が高くなる場合があります。すると、顧客が作業負荷をどのように変更したか、あるいは何をしたかといったことがわかります。こうした種類の接続は、実際には、サービス境界を越えて原因と結果を理解するための非常に重要なメカニズムです。分散トレースがなぜそんなに話題になっているのか疑問に思っている方のために、このモデルでは、分散トレースは実際には構造化されたログ ステートメントの連結にすぎません。次に、一連のセマンティック関数とクエリ関数が続きます。それはビジネスです。

リソースとは何ですか?

次に、リソースについて説明します。リソースとは何ですか?リソースとは、トランザクションが作業を実行するために消費するものです。この定義の副作用は、リソースが定義上有限であるということです。 Amazon の請求書はリソースです。再び、さまざまな粒子があります。 Kafka クラスターは、Kafka トピックのスループットを介して限られた負荷しかサポートできません。荷物の最後まで来て、それをすべて消費してしまうと、状況は急速に悪化する可能性があります。結果的に、多くのプッシュバック、高レイテンシ、リクエストのドロップなどが発生します。同様に、CPU の使用率も、正常ではなくなるまではまったく正常です。サービスの CPU が飽和状態になると、当然のこととして実行していたすべての処理が機能しなくなります。さらに悪いことに、プロセスのメモリ使用量がクラッシュしてしまいます。たとえば、個々のミューテックスについて非常に細かく話すこともできます。ロックの競合が多ければ、読み取りロックに 180 ナノ秒かかることになりますが、ロックの競合が多ければ、100 万倍の時間がかかる可能性があります。これも問題を引き起こす可能性があります。これらはすべてリソース タイプです。リソースは、トランザクション間で存続し、トランザクション間で共有できるため、リソースです。リソースの共有は非常に重要です。リソースを共有しないと、システムのコストが非常に高くなるためです。マルチテナント、マルチリクエスト環境で実行することの全体的な利点は、リソースをより有効に活用し、トランザクション間でリソースを共有できることです。それがリソースです。

もう少し視覚的にわかりやすくするために、マイクロサービス、Kafka クラスター、ミューテックスのボックスを描きました。これは完全に物語っています。これらの健康状態を測定するには、もっと良い方法があるはずです。リソースについては、ある時点でそのリソースがどれだけ残っているかを考慮する必要があります。リソース消費の指標です。 CPU 使用率が急激に上昇し、RAM 使用率も急激に上昇することがわかります。コンシューマー レイテンシまたはプロデューサー レイテンシは Kafka クラスターの健全性の指標であり、ミューテックスの取得を待機する時間はミューテックスの健全性の指標であることがわかります。どのリソースにも、何らかの健全性指標があります。ここで強調したいのは、これらは個々の取引の成功または失敗を示す指標ではないということです。もちろん、CPU とメモリの使用量がピークに達すると、トランザクションに問題が発生します。これはリソースの健全性を示すことを目的としています。これがなぜ重要なのかについて説明します。さらに、リソースには多数のタグもあります。これは実はとても重要なのです。

私の意見では、これらのタグや属性の用途は多岐にわたります。もちろん、理解して分解したいだけです。このような急増が見られる場合は、地域別、クラスター ID 別などでグループ化するとよいかもしれません。それはいいです。時系列データベースではこれを実行できるはずです。さらに重要なのは、これらのタグはリソースやトランザクションについて通信するための共通言語であるということです。理想的には、トランザクションがリソースにまたがる場合、トランザクションは何らかの方法でそのリソースに注釈を付けます。トランザクション データからリソース データへ、またはその逆へ接続する方法として使用できます。これは非常に強力なものです。これについては、後で実際の例を挙げて説明します。

リソースも階層構造である

粒度にはさまざまなレベルがあり、階層もあると言いました。これはトランザクションにも当てはまりますが、ここではこれを強調することがより重要だと思います。多数のマイクロサービスを持つ Kafka クラスターがある場合があります。これらの仮想マシンの中には、多数の仮想マシンが存在します。これらのロックの中には、ミューテックス ロックが多数あります。これらも上がったり下がったりします。リソース環境内には階層があり、これらのヘルス インジケーターがあります。

相互依存

ビジネスについてはすでに話し合いました。これらはクライアントが本当に関心を持っている仕事です。トランザクションに何かを実行させ、トランザクション間で共有されるリソースについてはすでに説明しました。これらは相互に依存しています。以下にこれらのリソースのチャートを示します。これらの緑の曲線は、これらのリソースに出入りするトランザクションとその作業の実行を示すことを目的としています。この例では、トランザクションが異なる HTTP エンドポイントに送信されていることがわかります。今回は、さまざまな Kafka のトピックについて説明します。この例では、リーダーとライターがミューテックスをロックしようとしています。トランザクションにはさまざまな種類があり、トランザクションがリソースにまたがる場合は、そのリソースの識別子で注釈を付ける必要があります。このトピックが Y リクエストの場合、トランザクションはさまざまな粒度のスキーマに基づいており、リソースとトランザクションがどのように相互作用するかを理解したい場合は、Kafka インスタンス状態のリージョンとクラスター ID を使用してトランザクションに注釈を付けることが非常に重要です。または、このエンドポイントの場合、トレース内のトランザクションにホスト名やコンテナ ID、サービス名、バージョンなどの注釈を付けることができます。同様に、リソース内のタグを使用してトランザクションをフラッシュし、これら 2 つの世界間のマッピングとして機能することもできます。ここに例があります。緑色のものは基本的に痕跡です。そして、リソース内には通常、それらのリソースの健全性を表すメトリック テレメトリ、時系列統計があります。いつもではありませんが、通常はそうです。

リソースとトランザクションは完全に相互依存しています。これは非常に重要な問題です。つまり、リソースが正常でない場合、トランザクションは大きな影響を受けます。トランザクション数が多すぎると、リソースに大きな影響が出ます。実際、継続的インテグレーションというトピックに関して私が最も気にしていることの 1 つは、ワークロードがわからないと、コードが正しいか間違っているかさえわからないことです。それは完全な幻影だと思います。 CIは素晴らしいと思います。もちろん、Lightstep でも CI を使用しています。少なくともシステム ソフトウェアやバックエンド ソフトウェアの場合、コードが正しいかどうかを知る唯一の方法は、現実的なワークロードでコードを実行することです。ワークロードは実際にはセマンティクスの一部であるため、リソースの構成方法、さらにはリソースの設計および実装方法に関するすべての調整は、トランザクションの実際のワークロードに大きく依存します。単に何かもっと必要かもしれないということではなく、実際には別のものが欲しいかもしれないということです。人々が MySQL をそんなに嫌っているのは好きではありません。以前は特定の種類のデータに少し嫌悪感を抱いていましたが、データが 1 台のマシンに簡単に収まり、リレーショナル セマンティクスのみが必要な場合は、最適です。いくつかのコピーの問題を除けば、実際には何も問題はありません。同様に、本当に地球規模で安価なものを望むなら、このモデルから離れて別の方法を取る必要があります。また、トランザクション ワークロードを考慮するまで、設計の観点やコードの観点からリソースが正しいか間違っているかを判断することはできません。可観測性は、ワークロードがリソースの健全性にどのように影響するか、またその逆を理解する最も簡単な方法の 1 つです。

相互依存性に関しては、アプリケーションのクライアントはトランザクションのみを考慮します。つまり、停電が発生し、誰かがレポートを作成しようとしている場合、特に技術に詳しくないエンドユーザーの場合、リソースが不足しているという事実をまったく気にしないことになります。それは彼らの問題ではない。これはあなたの問題であって、彼らの問題ではありません。彼らは自分の業務を正しく処理し、妥当な時間内に戻ってくることだけを気にしています。正確であるということは、これがバグではないことも意味します。クライアントやエンドユーザーが気にするのは、正確性とレイテンシの 2 つであり、それ以外はあまり重要ではありません。これをどのように行うかはあなた次第です。オペレーターとして制御できるのはリソースだけです。 DevOps や SRE を含むオペレーター別。ソフトウェアの重要な点は、私たちがそこに座ってクライアントから事実を受け取り、何かを記入し、それから人間として何らかの作業を行うわけではないということです。私たちは自動化ソフトウェアを作成しています。そのソフトウェアはリソース上で実行されます。

一般的に、オペレーターはリソースに主に焦点を当てます。リソースこそがオペレーターが実際に制御できるポイントだからです。エンドユーザーはトランザクションのみを気にします。エンドユーザーとオペレーターもこのように相互依存しています。エンドユーザーの行動があまりにも急速に変化すると、オペレーターのリソースに問題が生じる可能性があります。当然のことながら、オペレーターがリソースの健全性を損なうような操作を行った場合、エンド ユーザーに影響を及ぼすことになります。このように、エンドユーザー、オペレーター、トランザクション、リソースはすべて相互に依存しています。彼らの間にはこのような関係があるのです。エンドユーザーと開発者、または開発者とオペレーターも完全に相互依存しています。それはとても興味深いことだと思いますし、少なくとも私にとっては、それは深い意味のあることだと思います。エンドユーザーとトランザクション、オペレーターとリソース、これらが彼らが制御し、対処できるものであるため、彼らはそれについて考える傾向があります。これらは実際には、ワークロード自体で交差する完全に異なる平面です。

DevOps エンジニア/SRE は何をするのですか?

私たちは一体何をしているのでしょうか?それは質問のようですね。タグによって集約されたテレメトリの種類、メトリック、トレース間でこれら 2 つの側面を変換し、自動的に変換できる必要があります。これは、リソースごとにリソースの不足や健全性の問題を調べ、状況がどのように変化しているかを理解するために方向転換できる方法です。あるいは、非常に遅いトランザクションやエラーを返すトランザクションから始めて、それに関係するリソースを特定することもできます。これは、レイテンシが高いということは、データベース、Kafka キューなど、競合状態にあるリソースであることがほとんどだからです。そして、なぜこのようなことが起こったのかを理解するには、ワークロードがどのように変化したかを把握する必要があります。たとえば、誰かが新しいコードをリリースしてデータベース呼び出しの回数が 100 倍に増加し、それがデータベースの速度低下の原因になったなどです。これは興味深いことです。トランザクションが遅いときに切り替えて、競合しているリソースを見つけ、誰かが負荷を 100 倍に増やしたことに気付くことがよくあります。同様に、トランザクションからリソースへ、またはトランザクションからリソースへ、さらにリソースへも続きます。現時点では、メトリクスとトラッキングをフロントエンドに統合していますが、実際にそれを実現するにはデータ レイヤーで統合する必要があるため、非常に困難です。データは実際には非常に異なっているため、これは非常に難しいデータ エンジニアリングの問題です。メトリックは通常、時系列統計として表され、トレースは通常、ログにまたがるかどうかに関係なく、構造化されたイベントとして表されます。いずれにしても、基本的には統計ではなく、構造化されたイベント データのセットです。切り替えるのは難しいです。タグはそれを実現する方法です。

最後に、私はこれを15年間続けており、常にそれについて考えています。これを使用するのに専門家である必要はありません。それは直感的で、人々の日常のワークフローにこれらの洞察をもたらすものである必要があります。これを行わなければ、相互依存の問題への対処に大きく失敗したことになります。

サービスレベル目標 (SLO)

SLO は便利なツールです。ここでは、リソースとトランザクションのコンテキストにおける SLO について簡単に触れたいと思います。 SLO はホットな話題です。私はSLOを目標として考えています。これらは、リソースのセットにスコープが限定されたトランザクションの目標です。リソースとトランザクションは、SLO について考えるのに非常に適した方法です。 「サービス レベル目標」という用語について、多くの人がサービスとはマイクロサービスを意味すると想定していると思います。それは真実ではない。私のように年配の人の場合、電話を取ると発信音が聞こえ、サービス レベルは 99.99% 程度になります。マイクロサービスである必要はありません。サービス レベルは、トランザクションがどの程度信頼できるかを示します。それは、あまり頻繁に間違いが起きない、または速い、あるいは何かしたという意味ですか。リソース セットのコンテキストでサービス レベルを確認したいとします。実はここでマイクロサービスが登場します。Kafka キューやデータベースなど、他のものにも SLO を設定できます。このように、SLO は、一方ではトランザクションとリソース、他方ではオペレーターとエンドユーザーという 2 つの二重性の間の契約を表すことができます。これは、SLO がこれら 2 つの異なる世界をつなぐ上でなぜそれほど重要かつ不可欠であるかを考えるエレガントな方法だと思います。

これは実際にはどのように見えるのでしょうか?

これまで私が述べてきたことはすべて理論的なものであることは承知しています。私は、これらの用語を使用して、実稼働システムにおける実際のイベントの動作例を示すことにしました。製品のスクリーンショットがいくつか表示されますが、デモなどではありません。これは、特に Kafka の停止中にこれが実際にどのように機能するかを概念的に説明するためのものです。

以下は、Kafka キュー、そして実際には Lightstep 独自の内部システムに対するコンシューマーのレイテンシを示すダッシュボードのグラフです。それは、インシデントや顧客への顕著な影響を必要とするような停止ではありませんでしたが、何が起こっているのかを人々が必死に把握しなければならないような停止であることは確かでした。 10:45 の時点ではすべて正常であることがわかります。それから彼らは悪くなった。典型的な例は、Kafka 自体が分散システムであるということです。消費者として何かをするのに非常に遅くなっているため、これは明らかに間違ったリソースです。 Kafka キューからデータを取得するまでに長い時間待つ必要があります。何をしようとしているのですか? 1 つの選択肢としては、グループ化して、さまざまな方法でフィルタリングしてみることだと思います。私たちが本当に知りたいのは、このリソースに何が起こったのかということです。このリソースでは多くの取引が行われており、その多くは実際にここにあります。また、ここで取引が行われます。この期間と今回の期間の間で取引に何が変わりましたか? Kafka のコードは変更されていないため、それが手がかりになるかもしれないので、オペレーターとして知りたいのはそれです。作業負荷が変わりました。これをクリックできるようにしたらどうでしょう。ここでクエリを確認できます。

この変更をクリックすると、この変更の原因は何だったのかがわかるはずです。次に、UI に移動して、キューが満たされていない例外を確認します。これが適切に動作するための基準です。もう一度、これら 2 つの期間がどのようになっているかを確認するためにズームインします。私たちが本当にやりたいのは、統計的に、ここの取引があちらの取引とどう違うのかを理解することです。私たちは、Kafka が不満を抱いているだけでなく、ワークロードがこことそこでどのように異なるのかを理解しようとしています。美しいのはラベルがあることです。 Kafka キューには名前があります。関係する発表者の名前が記載されています。 Kafka キューを介したトレースにもこれらのタグが付けられます。実際にこのリソースからワークロードを結合して、この質問に答えることができます。先ほど述べた大きな SQL テーブルに戻ると、この特定の Kafka キューのトレースを調べてみましょう。これは大きなテーブル内の列だからです。これら 2 つの異なる時間枠で特定のコホートを追跡し、この回帰に関連する他の要因を理解しましょう。

私たちが確認したのは、さまざまな顧客を抱えるこのマルチテナント システムにおいて、製品 ID 1753 を持つ 1 人の顧客が、全トレースの 0.8% から全トレースのほぼ 16% に増加したということです。これは、ベースラインと回帰の間の約 20 倍の増加です。これは本当に興味深いですね。一部のクライアントは作業負荷を大幅に変更しましたが、それはまさに私が望んでいることです。問題は、顧客タグの位置が高すぎることです。 Kafka キューにさえありません。リソースから分散トランザクション トレースに移行することによってのみ、特定の顧客 ID がこの回帰に関係していることを自動的に理解できます。スケールアップすることで、より詳細な情報が得られます。つまり、約 20 倍に拡大するのです。その後、ご希望であれば、サンプル トレースを調べて、その顧客が実際に何をしているかを正確に確認することもできます。

私が明確にしたいのは、クエリを書かなくても、この感覚からこの感覚に移行できるということです。リソースから業務に移行するために専門家である必要はありません。さて、実際にそれを実行するのは非常に困難です。とにかく、一般的に言えば。可観測性に関する私の見解は、可観測性の焦点として、メトリック、ログ、トレースに重点を置くことはもうないということだと思います。これは単なる生データです。代わりに、オペレーターは、現在と同じように、SLO の観点からアプリケーションのパフォーマンスを把握し、リソースの健全性を把握できるようになります。そして、クエリを記述することなく、これら 2 つのものを自然に切り替えます。手を挙げたり実際の作業を行ったりすることなく、トランザクション ワークロードがリソースにどのように影響するか、リソースの健全性がトランザクション ワークロードにどのように影響するかを理解します。

要約する

トランザクションはリソースを使用してシステムを通過します。ユーザーはあなたのリソースを気にしません。同様に、DevOps では単一のトランザクションですべてを実行することはできません。少なくとも手動では、独自のリソースでのみ操作できます。可観測性における最も重要な疑問「この変化の原因は何だったのか？」に答えるには、リソースとトランザクションを自然に接続するシステムとプロバイダーを使用できる必要があります。それが私の取引の変更であったか、私のリソースの変更であったか。リソースとトランザクションのフレームワーク内で、可観測性はまさにその方向に向かっていると私は考えています。

質問と回答

しかし、データの保存にかかるコストについて言及されました。それは人々にとって常に非常に難しい会話だと思います。コストを最小限に抑えながら観察を最大限に高めるために、こうした会話をするための一般的なアドバイスはありますか?

シグマン：確かに今は問題ですね。このテーマについては言いたいことがたくさんあります。まず第一に、私たちはトランザクションについて話しているのか、それともリソースについて話しているのかを考えます。では、トレースやログのようなものについて話しているのでしょうか、それともメトリックのような統計的な時系列データについて話しているのでしょうか?なぜなら、これら 2 種類のテレメトリに関する会話は異なると思うからです。少なくとも私が Google にいた頃、Lightstep では、それが単なる二元論ではないことが分かりました。データは保存しますか、それとも保存しませんか?最初にサンプルを採取するんですか？ホストからそれを取得しますか? WAN 経由で集中管理しますか?どれくらい保存しますか？どのくらいの粒度で保存しますか?精度の面では、時間の経過とともにどのように低下​​しますか?この分野で組織が非常に成熟しつつあるのを見ると、テレメトリのライフサイクル全体にわたって、実際にはさまざまな答えが出ていることがわかります。これは非常に難しい質問だと思います。なぜなら、どの程度の粒度について話しているかによって決まるからです。

私が言いたい主な点は、組織が、ライフサイクル コストの最も大きな要素の 1 つであるネットワークを含むライフサイクル全体にわたってテレメトリ コストを分析する能力を持っていない場合、データを送信できないということです。他の最適化問題と同様に、ここから始める必要があります。率直に言って、多くの組織はそれを分析できていないと思います。アプリケーションのどの部分が長期的なテレメトリ コストを最も多く発生させているかを特定することはできません。それを行わない限り、最適化する方法はありません。そこから始めました。すでにこれを実行している人にとって、最も重要なことは、開発者 1 人あたりのコストを制御できることだと思います。たとえば、コードを 1 行追加すると、メトリックに過度のカーディナリティが追加されます。間違ったやり方をすると、年間数十万ドルの損失が発生する可能性があります。それをセンターで修正できるようになることが、次の大きな課題だと思います。単一の機器ラインによってプラットフォーム チームに無制限のコストが発生しないことを確認します。

しかし、すでに起こった出来事を画面上で共有した最後の例は本当に気に入りました。 Ben は Lightstep について言及しているので、それがどのように機能するかがわかります。私自身も使ってみました。特定の顧客がアクションを起こしてイベントをトリガーするのをいかに早く見つけられるかは驚くべきことだと思います。私自身、実稼働システムでのキャリアの中で、このようなことが何度も起こったことを知っています。非常に細かいレベルの粒度に非常に迅速に到達できることは非常に効果的です。

指定された 2 つの時間間隔間の重要な差異を出力できる Web インターフェイスは何ですか?それについて話したいですか？さまざまなインターフェースによって人々の作業がどのように改善されるかについて、あなたの考えをお聞かせください。これは大きなことだ。

シグマン：それは社説でした。私はそれを見せたくなかったので躊躇しました。他に提示する方法がわかりません。何かを見せないと抽象的すぎる気がします。文字通りの質問に答えると、それは Lightstep の製品です。データ レイヤーで統合できるのであれば、他の場所で統合できない理由はありません。実際に行うのが難しいと思うのは、リソース メトリック データとトランザクション追跡データの統合をデータ レイヤーで行う必要があることです。ハイパーリンクだけでは実現できません。私が説明している接続は、実際には接続です。メトリック内のマークから数千のトレースのグループ上のマークに接続できる必要があります。これを実現するには、プラットフォーム レベルでデータ エンジニアリングを実行する必要があります。実際、オープンソースの世界のより多くのソリューションがこの方向に進むことを望んでいます。イベント解決への最短パスは、もちろん、時系列データとトランザクション データ間のタグをピボットできるようにすることです。サイロ化されたメトリクス ソリューションと、Web UI のようなサイロ化された追跡ソリューションから始める必要がある場合、統合はデータ レイヤーで実行する必要があるため、これは実際には難しい問題です。だからこそ、製品の観点から見ると非常に難しいのです。

しかし、私が働いていた会社では社内で作られたプラットフォームをいくつか見てきましたが、それが適切に機能するまでには何年もかかり、何度も繰り返し作業が必要だったので、決して簡単ではありませんでした。興味深いことの 1 つは、たとえば、このようなシステムにアクセスすると、突然モデルを変更する顧客がいるとします。これは良いことかもしれません。おそらく、彼らはすべての新規ユーザーにアプローチし、素晴らしい仕事をしているのでしょう。つまり、会社のビジネス部門などの他のチームに、「この顧客は本当に素晴らしい仕事をしているようです。このことを知っておくべきです。私たちがこれを行っているのをご存知でしたか?」と言うことができるのです。これにより、エンジニアリング チームは、非常に興味深く洞察に富んだデータを使用して、よりよい会話を行うことができるようになり、これも素晴らしいことだと思います。トレースにはどのようなツールが推奨されますか?常にサービス メッシュかそれに似たものになるのでしょうか、それともシステム内で個別に行う方が良いのでしょうか。

シグマン：はい。実際、私は 2017 年の KubeCon でサービス メッシュとトレースについて講演しました。サービス メッシュは役立ちますが、必ずしも解決策ではありません。サービス メッシュが実際に行うことは、サービス間の呼び出しのテレメトリを提供することです。トレースの最も難しい部分は、常に、このトレース ID コンテキストをサービスのエントリ ポイントから関数呼び出しを介してそのサービスの終了ポイントまで正常に伝播することです。サービスメッシュはこれとは何の関係もありません。サービス メッシュはサービス間の呼び出しのみを処理します。それはサービスにあり、追跡するのが最も難しい部分です。これは本当に役に立たない。サービス メッシュを使用すると、ポイントツーポイント データのセットが得られますが、コンテキスト伝播の問題を本当にうまく解決するには、OpenTelemetry に移行することを唯一推奨します。これは実際には、この問題をかなり包括的な方法で解決し、コンテキスト伝播を組み込み機能にする試みです。 OpenTelemetry はサービス メッシュとも統合されます。サービス メッシュの利点の 1 つはトレースの問題を解決することですが、実際にはそうではありません。トレース用のデータを追加しますが、分散トレースの核心であるコンテキスト伝播の問題は解決しません。

しかし、私が働いていた会社では社内で作られたプラットフォームをいくつか見てきましたが、それが適切に機能するまでには何年もかかり、何度も繰り返し作業が必要だったので、決して簡単ではありませんでした。興味深いことの 1 つは、たとえば、このようなシステムにアクセスすると、突然モデルを変更する顧客がいるとします。これは良いことかもしれません。おそらく、彼らはすべての新規ユーザーにアプローチし、素晴らしい仕事をしているのでしょう。つまり、会社のビジネス部門などの他のチームに、「この顧客は本当に素晴らしい仕事をしているようです。このことを知っておくべきです。私たちがこれを行っているのをご存知でしたか?」と言うことができるのです。これにより、エンジニアリング チームは、非常に興味深く洞察に富んだデータを使用して、よりよい会話を行うことができるようになり、これも素晴らしいことだと思います。トレースにはどのようなツールが推奨されますか?常にサービス メッシュかそれに似たものになるのでしょうか、それともシステム内で個別に行う方が良いのでしょうか。

シグマン：はい。実際、私は 2017 年の KubeCon でサービス メッシュとトレースについて講演しました。サービス メッシュは役立ちますが、必ずしも解決策ではありません。サービス メッシュが実際に行うことは、サービス間の呼び出しのテレメトリを提供することです。トレースの最も難しい部分は、常に、このトレース ID コンテキストをサービスのエントリ ポイントから関数呼び出しを介してそのサービスの終了ポイントまで正常に伝播することです。サービスメッシュはこれとは何の関係もありません。サービス メッシュはサービス間の呼び出しのみを処理します。それはサービスにあり、追跡するのが最も難しい部分です。これは本当に役に立たない。サービスメッシュを使用してポイントツーポイントデータのセットになりますが、コンテキストの伝播の問題を本当にうまく解決するために、私の唯一の推奨事項はOpentelemetryに移行することです。これは実際、この問題をかなり包括的な方法で解決し、コンテキストの伝播を組み込みの機能にする試みです。 Opentelemetryは、サービスメッシュとも統合されます。サービスメッシュの利点の一部は、トレースの問題を解決することですが、そうではありません。トレース用のデータを追加しますが、実際には分散トレースの核となるコンテキスト伝播問題は解決しません。

ただし、Opentelemetryにはまだ問題があります。あなたの考えは？

Sigman：私は管理委員会に参加しています。このプロジェクトを共同設立しました。それについて非常に偏見があります。これは確かに、多くの貢献者を持つという観点から非常に成功したプロジェクトです。先月だけで1,000人の貢献者がいたと思います。すべての主要なベンダーとクラウドプロバイダーがプロジェクトに購入し、人員配置などです。 Opentelemetryの唯一の問題は、その周りに非常に多くのアクティビティがあるため、プロジェクトを維持するのが困難であることです。それが非常に成功した理由は、それが非常に多くのパーティーに利益をもたらすからだと思います。これは、主要なインフラストラクチャプロバイダー、クラウドプロバイダー、観測可能性ベンダー、特にエンドユーザーにとって双方にとって有利な状況です。特定のベンダーやプロバイダーに縛られることなく、最終的に高品質のテレメトリを取得できるからです。この携帯性は非常に魅力的なものです。長い間、観察可能性のソリューションは、彼らが収集できるテレメトリの品質によって制限されてきたと思います。 Opentelemetryは本当にこの波に乗っているので、ソリューションの改善が見られます。 Opentelemetry、はい、それは非常にエキサイティングなプロジェクトです。私たちが本当に必要なのは、マイルストーンに到達できるように、プロジェクトで少し言えないことだと思います。いくつかの点で、それはそれ自身の成功の犠牲者です。それは間違いなく明るい未来を持っています。

しかし、今年締めくくったので、Opentelemetryのロードマップについて共有するものはありますか？あなたにとってエキサイティングなことはありますか？

Sigman：トレース、メトリック、ロギングの3つの柱は、観察性を意味します。私は自分の視点に固執します。彼らはテレメトリーにとって絶対に理にかなっているので、これらの3つの領域。追跡から始めます。それは基本的にこれまでのところです。インジケーターはまもなく公開されます。その後、ロギングが後で表示されます。標準とAPI統合の観点から、これは実際にはOpentelemetryが解決している3つの問題の中で最も重要ではないと思います。メトリックがそれを超えることができてうれしいです。また、PrometheusとPrometheusとOpentelemetryの間の相互運用性を確保するために、Prometheusコミュニティと頻繁に協力して、選択を余儀なくされません。これもとても良いことだと思います。この夏は安定しています。

ただし、分散トラッキングのパフォーマンスコストについては、別の一般的な質問があります。あなたの考えは？

Sigelman：潜伏の観点から見ると、分散追跡にはオーバーヘッドは必要ありません。リソースの占有の意味では、わずかな限界スループットオーバーヘッドが最小限に抑えられています。多くの場合、人々はこの問題を解決するためにサンプリングをすることができます。 Googleで書くのを手伝ったこの短く簡潔な紙は、パフォーマンスの測定を詳細に説明しています。統計的ノイズの観点から見ると、これは検出が困難であり、Dapperは100％の時間の100％を実行し、15年間実行されています。正しく行われた場合、これは間違いなくハイオーバーヘッドではありません。これはその魅力の1つです。

この記事は、WeChat Publicアカウント「Super Architect」から再現されています。下のQRコードからフォローできます。この記事を復刻するには、Super Architectの公式アカウントにお問い合わせください。