OpenTelemetry 第1回 : エッジとの距離を短縮
Fastly がお客様から選ばれる理由のひとつは、エンドユーザーとの距離が近く、数ミリ秒でリクエストを処理できることにあります。しかしこのことは、Fastly がお客様のシステムの「前面」すなわち「外部」にあるかのように感じる原因にもなり得ます。Fastly が本当にお客様のアプリケーションアーキテクチャの一部であると実感していただくには、システム全体を一か所で同時に観測できることが重要です。この実現に役立つ新しい標準が OpenTelemetry です。undefined
人々が Web 用の分散型アプリケーションの構築を始めた当時は、アプリケーションアーキテクチャのあらゆるコンポーネント、すなわち、物理サーバー、オペレーティングシステム、サーバーソフトウェア、データベース、そしてコードを作成する必要がありました。
しかし現在では、サーバーレス革命によってこれらのほぼすべてが抽象化されました。クラウド機能を使用してコードを書くことも、SaaS プロバイダーからデータベースプランを購入し、何もインストールしなくても数秒後にコードからクエリを送信することもできます。
そのため、より多くの場所、すなわちますます一時的になるプラットフォーム上でコードを実行し始めることができます。コードを実行する環境を簡単にプロビジョニングできる場合は、その環境が数秒しか続かないとしても気にもならないでしょう。しかし、それによって新たな課題が提起されます。それは、誰のためにどこで何を実行したのか、そしてさらに重要なこととして、何か問題が発生した場合に、何がどこでなぜ発生したのかを、どのように追跡できるかということです。
新聞社の Webサイトを配信するために設計された、次のようなマイクロサービスアーキテクチャを想像してみてください。
これは比較的シンプルなアーキテクチャですが、それでもいくつか興味深い機能を備えています。
Fastly の2つのレイヤーにより、グローバルに分散されたリクエストが、コアインフラストラクチャに近い地点に集められます (Fastly ではこれをオリジンシールドと呼んでいます)。
リクエストの中には、ひとつのエッジロケーションで完全に処理されるものもあれば、エッジロケーションから Fastly 以外のサービスへの直接のコールが含まれるものもあります。
コアクラウドプラットフォーム上で実行されているゲートウェイサービスは複数のマイクロサービスと通信します。
これらのマイクロサービスの一部は「不透明」なベンダーの SaaS サービスである場合や、お客様独自のマイクロサービスである場合がありますが、中には Fastly が前面に配置されているものや、Fastly によってホストされているものもあります。
複数のベンダー、不明で把握できない数のレイヤー、不透明なサービス、明らかな循環参照…。とても恐ろしい状況です。しかし、これらすべてのコンポーネントが OpenTelemetry (OTel) を使用していれば、このシステムを介して処理の流れ全体を一度に可視化して把握できるようになります。
さらに、OpenTelemetry を使用すると、システム内のすべてのコンポーネントをインストルメント化できるだけでなく、特定の可観測性ソリューションベンダーに縛られることを回避できます。上図のトレースは、Honeycomb によってレンダリングされたものです。Honeycomb は本当に優れたサービスですが、お好みで Lightstep や New Relic を使用することも、Zipkin などのオープンソースの自己ホスト型ツールを使用して独自の分析を行うことも可能です。これらはすべて、同じテレメトリ形式を理解できます。
この例では、Google App Engine のインスタンス内で発生しているスパンが Fastly のエッジサーバーからのスパンによってネストされていることが分かります。オープンスタンダードである OpenTelemetry のメリットは、トレースデータを任意のシステムで任意の言語で生成でき、同じコレクターが理解して分析できることです。また、ほとんどの言語でライブラリが存在します。たとえば私のデモでは、NodeJS 向けの標準インストルメント化機能を使用しており、これが ExpressJS アプリケーションからスパンを自動的に取得します。
OpenTelemetry と Fastly
Fastly のエッジネットワークでアプリケーションを実行するには、VCL プラットフォームを使用する方法と Compute@Edge を使用する方法の2種類があります。いずれの場合も OpenTelemetry データを取得できますが、以下のようにプロセスが異なります。
VCL サービスの場合、Fastly のリアルタイムログと HTTPS エンドポイントを使用して、JSON 形式の OpenTelemetry トレースを、HTTP を介して OTLP データを受け取るように設定された OpenTelemery コレクターに送信します。
Compute@Edge の場合、Compute@Edge プロジェクトで OpenTelemetry を使いやすくするために Fastly が構築した、JavaScript 用の Fastly OpenTelemetry ライブラリを使用します。
これらのアプローチは両方とも、多くの業界や国にわたる Fastly の大手のお客様によってすでに使用されています (たとえば、私は最近、Wired、GQ、Vogue などを発行している Condé Nast と、同社のテレメトリの活用に共同で取り組んでいます)。これらのお客様は、オンプレミステクノロジー、クラウドコンピューティング、ベンダーの PaaS や SaaS、サーバーレスサービス、フロントエンドの単一ページアプリケーション、ネイティブアプリケーションを組み合わせた、複雑で多彩なアーキテクチャを採用しています。
このようなデジタル時代の複雑なマシンのコンポーネントはすべて、ゆっくりですが確実に、OpenTelemetry という同じ言語を使い始めており、マシンを構成するシステム全体を流れる各トランザクションやリクエストに関して一つのストーリーを生成するのに貢献しています。
私たちは、大半のお客様が Fastly 以外にも複数のプラットフォームを使用していることを理解しています。また、お客様が Fastly だけを使用するようになることを望んでいるわけでもありません。Fastly があらゆる問題に対するベストソリューションになることはありません。Fastly が OpenTelemetry を気に入っているのは、お客様が構築したいアーキテクチャの一部として Fastly の機能をさらに活かすことが可能になるためです。OpenTelemetry には、次のようなメリットがあります。
Fastly を含む特定のベンダーに縛られる必要がない
ニーズに合った、あらゆる分析ツールやインサイトツールが利用できるようになる
お客様のシステムアーキテクチャにおける主要コンポーネントとして Fastly の機能を活かせる
VCL サービスや Compute@Edge サービスから OpenTelemetry を抽出する方法や、Fastly が独自の Fiddle ツールをモニタリングするために OpenTelemetry を使用しているケーススタディの詳細については、近いうちに別のブログ記事でご紹介します。
OpenTelemetry に関する全4回にわたるブログシリーズの記事をぜひご覧ください。
