Dapr 可観測性分散トレース

アプリケーションを構築する場合、システムの動作を理解することは、アプリケーションを操作する上で重要な部分です。これには、アプリケーションの内部呼び出しを観察し、パフォーマンスを測定し、問題が発生したときにすぐに見つけることができることが含まれます。これはどのシステムにとっても難しいことですが、複数のマイクロサービスで構成される分散システムでは、複数の呼び出しで構成されるフローが 1 つのマイクロサービスで開始され、別のマイクロサービスで継続される可能性があるため、さらに困難になります。可観測性は本番環境では非常に重要であり、開発中にボトルネックを理解し、パフォーマンスを向上させ、マイクロサービス全体で基本的なデバッグを実行するためにも役立ちます。

アプリケーションに関する一部のデータは基盤となるインフラストラクチャから収集できますが (メモリ消費量、CPU 使用率など)、その他の意味のある情報はアプリケーション認識レイヤー (一連の重要な呼び出しがマイクロサービス全体でどのように実行されるかを示すレイヤー) から収集する必要があります。これは通常、開発者がアプリケーション内でこれを検出するためのコードを追加する必要があることを意味します。通常、インストルメント化されたコードは、収集されたデータ (トレースやメトリックなど) を外部の監視ツールまたはサービスに送信し、この情報を保存、視覚化、分析できるようにします。

この部分のコードはアプリケーションのコアロジックではないため、当然ながら開発者にとって新たな負担となり、監視ツールの API を理解したり、追加の SDK を使用したりする必要が生じることもあります。このようなツールは、アプリケーションの移植性の課題を増大させる可能性もあります。アプリケーションがデプロイされる環境に応じて、アプリケーションには異なるツールが必要になる場合があります。たとえば、クラウドプロバイダーによって提供される監視ソリューションは異なり、オンプレミス展開ではローカルソリューションが必要になる場合があります。

可観測性を高めるために使用されるシステム情報はテレメトリと呼ばれ、4 つの主要なカテゴリに分類できます。

分散トレースは、分散ビジネス通信に参加しているサービス間のトラフィックに関する洞察を提供します。
メトリックは、サービスのパフォーマンスとリソース消費に関する洞察を提供します。
ログ記録により、コードの実行方法やエラーが発生したかどうかを把握できます。
ヘルスエンドポイントは、サービスの可用性に関する情報を提供します。

Dapr 可観測性アーティファクトは、Dapr コントロールプレーンを構成する Dapr サイドカーおよび Dapr システムサービスによって生成されたトラフィックを自動的にキャプチャすることにより、アプリケーションから可観測性を切り離します。このモジュールは、複数のサービスにわたる単一の操作のトラフィックを相関させます。また、パフォーマンスメトリック、リソース使用率、システムの健全性も公開されます。テレメトリデータはオープンスタンダード形式で公開されるため、選択した監視バックエンドに情報を送信できます。そこで、この情報を視覚化し、照会し、分析することができます。

Dapr は抽象化するため、アプリケーションは可観測性がどのように実装されているかを認識しません。開発者は、コアビジネスロジックに関連しないコードのこの部分をどのように実装するかについて心配する必要はありません。 Dapr を使用すると、開発者は監視機能の構築ではなくビジネスロジックの構築に集中できます。可観測性は Dapr システムレベルで構成され、異なるチームによって作成され、異なるテクノロジースタックを使用して構築された場合でも、さまざまなサービス間で一貫性が保たれます。

仕組み

Dapr のサイドカーアーキテクチャは、組み込みの観測機能を実装します。サービスが通信すると、Dapr サイドカーがトラフィックを傍受し、トレース、メトリック、およびログ情報を抽出します。テレメトリデータはオープンスタンダード形式で公開されます。デフォルトでは、Dapr は OpenTelemetry と Zipkin をサポートします。

Dapr は、さまざまなバックエンド監視ツールにテレメトリデータを公開できるコレクターを提供します。これらのツールは、分析とクエリのために Dapr テレメトリデータを提示します。図 10-1 は Dapr の可観測性アーキテクチャを示しています。

dapr 可観測性アーキテクチャ

サービス A がサービス B の操作を呼び出し、その呼び出しはサービス A の Dapr サイドカーからサービス B のサイドカーにルーティングされます。
サービス B が操作を完了すると、応答が Dapr サイドカーを介してサービス A に送り返されます。すべてのリクエストと応答について、利用可能なすべてのテレメトリデータを収集して公開します。
構成されたコレクターはテレメトリデータを取り込み、監視バックエンドに送信します。

ただし、可観測性サポートの追加は、前に紹介したパブリッシュ/サブスクライブや状態管理コンポーネントなどの他の Dapr ビルディングブロックの構成とは異なることに注意してください。ビルディングブロックを参照する必要はありませんが、コレクターと監視バックエンドを追加する必要があります。上の図は、異なる監視バックエンドと統合された複数のコレクターを構成できることを示しています。

以下では、いくつかのテレメトリタイプの可観測性について説明します。

分散トレース

分散トレースは、分散アプリケーション内のサービス間を流れるトラフィックに関する洞察を提供します。交換された要求メッセージと応答メッセージのログは、問題のトラブルシューティングを行うための重要な情報源です。さらに難しいのは、同じビジネストランザクションに属するメッセージを統合することです。

Dapr は、統一された標準 W3C Trace Context を使用して関連情報を関連付け、完全なリクエストとレスポンスに同じコンテキスト情報を挿入します。

W3C トレースコンテキストの例

上の図は、W3C トレースコンテキスト標準の例を示しています。

サービス A はサービス B の操作を呼び出します。サービス A が呼び出しを開始すると、Dapr は一意のトレースコンテキストを作成し、それを要求に挿入します。
サービス B は要求を受信し、サービス C で操作を呼び出します。Dapr は、受信要求にトレースコンテキストが含まれていることを検出し、それをサービス C の送信要求に挿入して伝播します。
サービス C はリクエストを受信して処理します。 Dapr は、受信要求にトレースコンテキストが含まれていることを検出し、それをサービス B への送信応答に挿入して伝播します。
サービス B は応答を受信して処理します。次に、新しい応答を作成し、送信応答に挿入してトレースコンテキストを伝播し、サービス A に戻ります。

次の図に示すように、一緒に属する要求と応答のセットはトレースと呼ばれます。

トレースとスパン

上記のトレースが、多くのサービスにわたって発生する一意のアプリケーショントランザクションを表していることに注目してください。トレースはスパンのコレクションであり、各スパンはトレース内で実行される単一の操作または作業単位を表します。スパンは、単一のトランザクションを実装するサービス間で送信される要求と応答です。

次に、テレメトリデータを対応する監視バックエンドに公開する方法について説明します。

Zipkinの使用

Zipkin は、テレメトリデータを取り込んで視覚化するオープンソースの分散トレースシステムです。 Dapr は Zipkin のデフォルトサポートを提供します。

Dapr がセルフホストモード (dapr init) で初期化されると、複数のコンテナーがローカル Docker にデプロイされます。 docker ps コマンドを実行すると、ローカルで実行されているすべてのコンテナを表示できます。 Zipkin コンテナが起動して実行されていることを確認し、実行されているポート (デフォルトでは 9411) をメモします。

ジップキン容器

Zipkin コンテナサービスが実行されていない場合は、次のコマンドを使用して起動できます。

 ➜ docker run --name dapr_zipkin -d -p 9411 : 9411 openzipkin / zipkin

この時点で、ブラウザで http://localhost:9411 を介して Zipkin Web ページに実際にアクセスできます。ダッシュボードでは、Dapr 可観測性ビルディングブロックを通じて記録されたテレメトリデータを検索および表示できます。

Zipkinダッシュボード

詳細なテレメトリデータを表示するには、検索結果の [表示] ボタンをクリックしてください。

ジプキンショー

ローカル自己拡張管理モードでは Zipkin 構成が実行されていないことがわかります。サービス要求が Dapr サイドカーを通過すると、対応するテレメトリデータが Zipkin で利用できるようになります。これは、テレメトリデータを収集するために、自己拡張管理モードで Zipkin がデフォルトで有効になっているためです。関連する構成は $HOME/.dapr/config.yaml にあり、内容は次のとおりです。

 apiバージョン: dapr .io / v1alpha1
 種類: 構成
メタデータ:
 名前: daprConfig
 仕様:
 トレース:
 サンプリングレート: "1"
 ジプキン:
 エンドポイントアドレス: http : //localhost:9411/api/v2/spans

したがって、Kubernetes モードで Zipkin をトレースバックエンドとして有効にする場合は、Configuration オブジェクトを別途作成する必要があります。

まず、Dapr 構成ファイルを使用して、Dapr ランタイムのトレース機能を有効にする必要があります。以下は、トレースを有効にする dapr-config.yaml という構成ファイルの例です。

 apiバージョン: dapr .io / v1alpha1
 種類: 構成
メタデータ:
 名前: appconfig
 仕様:
 トレース:
 サンプリングレート: "1"
 ジプキン:
 エンドポイントアドレス: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"

設定ファイルはローカル設定とほぼ同じであることがわかります。唯一の違いは zipkin.endpointAddress のアドレスです。 sampleRate プロパティは、トレースを公開する間隔を指定します。この値は、0 (トレースを無効にする) から 1 (すべてのトレースを公開する) までの範囲でなければなりません。たとえば、値が 0.5 の場合、トレースは一定期間ごとに 1 回公開されることを意味し、公開トラフィックが大幅に削減されます。ここで、zipkin.endpointAddress は、Kubernetes クラスターで実行されている Zipkin サーバーを指します。 Zipkin のデフォルトポートは 9411 です。リソースオブジェクトを適用するだけです。

 ➜ kubectl apply -f dapr -config .yaml

もちろん、Zipkin サービスも手動でデプロイする必要があります。対応するリソースリストファイルは次のとおりです。

 種類: デプロイメント
apiバージョン: アプリ/ v1
 メタデータ:
 名前: ジプキン
名前空間: デフォルト
ラベル:
 サービス: ジプキン
仕様:
 セレクター:
 マッチラベル:
 サービス: ジプキン
テンプレート：
 メタデータ:
 ラベル:
 サービス: ジプキン
仕様:
 コンテナ:
 - 名前: ジプキン
画像: openzipkin / zipkin - slim
 imagePullPolicy : IfNotPresent
 ポート:
 - 名前: http
 コンテナポート: 9411
 プロトコル: TCP
 ---
 種類: サービス
APIバージョン: v1
 メタデータ:
 名前: ジプキン
名前空間: デフォルト
ラベル:
 サービス: ジプキン
仕様:
 タイプ: NodePort
 ポート:
 - ポート: 9411
 ターゲットポート: 9411
 ノードポート: 32411
 プロトコル: TCP
 名前: ジプキン
セレクター:
 サービス: ジプキン

ここでは、openzipkin/zipkin-slim コンテナイメージを使用します。 Zipkin サービスは、ポート 32411 を介してアクセスできる Zipkin Web フロントエンドを公開します。また、上記のリソースリストを直接適用します。

 ➜ kubectl apply -f zipkin .yaml

デプロイが完了したら、Pod のステータスをチェックして、アプリケーションが正常にデプロイされたかどうかを確認できます。

 ➜ kubectl ポッドを取得- l サービス= zipkin
 名前準備完了ステータス再起動年齢
zipkin - f5c696fb7 - 94 mqz 1 / 1 実行中0 3 分9秒
➜ kubectl get svc -l サービス= zipkin 
 名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
zipkin NodePort 10.102 .75 .84 < なし> 9411 : 32411 / TCP 30 秒

デプロイが成功すると、http:<node-ip>:32411 から Zipkin Web ページにアクセスできるようになります。

ジプキンウェブ

次にテレメトリデータを公開できます。起動時に各 Dapr サイドカーでテレメトリデータを発行する必要があることに注意してください。これを行うには、アプリケーションに dapr.io/config アノテーションを追加する必要があります。

ここでも、tutorials/distributed-calculator ディレクトリにあるクイックスタートの例を使用して説明します。

 ➜ git clone [ - b < dapr_version_tag > ] https://github.com/dapr/quickstarts.git
 ➜ cd チュートリアル/ 分散- 計算機

この例は、Dapr のメソッド呼び出しと状態の永続化機能を示す分散計算機です。各操作は、異なる言語/フレームワークで記述されたサービスによって実行されます。

追加: Go muxアプリケーション
乗算: Python フラスコアプリケーション
部門：Node Expressアプリケーション
減算: .NET Core アプリケーション

フロントエンドアプリケーションは、React で記述されたサーバーおよびクライアントで構成されます。ソースコードのアドレスは、React calculator です。

分散計算機

上の図は、このサンプルアプリケーションの各コンポーネントの構成とサービスアーキテクチャを示しています。

deploy/ ディレクトリにある go-adder.yaml などのマイクロサービスのデプロイメントマニフェストを見てみましょう。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: addapp
 ラベル:
 アプリ: 追加
仕様:
 レプリカ： 1
 セレクター:
 マッチラベル:
 アプリ: 追加
テンプレート：
 メタデータ:
 ラベル:
 アプリ: 追加
注釈:
 ダップル。 io / 有効: "true"
 dapr .io / アプリ- ID : "addapp"
 dapr .io / アプリ- ポート: "6000"
 dapr .io / config : "appconfig"
 仕様:
 コンテナ:
 - 名前: 追加
画像: ghcr .io / dapr / サンプル/ 分散計算機- go : 最新
環境:
 - 名前: APP_PORT
 値: "6000"
 ポート:
 - コンテナポート: 6000
 imagePullPolicy : 常に

上記のリソースリストでは、dapr.io/config アノテーションを通じて appconfig 構成ファイルの使用を指定しています。この構成ファイルでは、テレメトリデータを取得するために Zipkin サービスが使用されます。このアノテーションは他のマイクロサービスでも使用されるため、アプリケーションがデプロイされると、Zipkin は対応するテレメトリデータを取得できます。

dapr.io/config の後に指定される Configuration オブジェクトは、現在のアプリケーションと同じ名前空間に存在する必要があることに注意してください。

サンプルアプリケーションを直接デプロイします。

 ➜ kubectl apply -f デプロイ/

デプロイメントが完了したら、dapr configurations コマンドを使用して、現在のクラスター内のすべての構成情報を表示できます。

 ➜ dapr 構成- k - A
 名前空間名トレース- 有効メトリクス- 有効作成日
デフォルトのappconfig true true 1 分2022-09-20 17 : 01.21

構成情報はダッシュボードでも確認できます。

dapr 構成

アプリケーションがデプロイされたら、Pod のステータスを確認します。

 ➜ kubectl ポッドを取得する
名前準備完了ステータス再起動年齢
addapp - 84 c9764fdb - 72 mxf 2 / 2 実行中0 74 m
 計算機- フロントエンド- 59 cbb6658c - rbctf 2 / 2 実行中0 74 m
 分割アプリ- 8476 b7fbb6 - kr8dr 2 / 2 実行中0 74 m
 multiplyapp - 7 c45fbbf99 - hrmff 2 / 2 実行中0 74 m
 減算アプリ- 58645 db87 - 25 tg9 2 / 2 実行中0 62 m
 ➜ kubectl でサービスを取得
名前タイプクラスタ- IP 外部- IP ポート( S ) 年齢
addapp - dapr ClusterIP なし< なし> 80 / TCP 、 50001 / TCP 、 50002 / TCP 、 9090 / TCP 8 分29秒
計算機- フロントエンドLoadBalancer 10.110 .177 .32 192.168 .0 .54 80 : 31701 / TCP 8 分29秒
計算機- フロントエンド- dapr ClusterIP なし< なし> 80 / TCP 、 50001 / TCP 、 50002 / TCP 、 9090 / TCP 8 分29 秒
divisionapp - dapr ClusterIP なし< なし> 80 / TCP 、 50001 / TCP 、 50002 / TCP 、 9090 / TCP 8 分29秒
multiplyapp - dapr ClusterIP なし< なし> 80 / TCP 、 50001 / TCP 、 50002 / TCP 、 9090 / TCP 8 分29秒
subtractapp - dapr ClusterIP なし< なし> 80 / TCP 、 50001 / TCP 、 50002 / TCP 、 9090 / TCP 8 分29秒
zipkin NodePort 10.108 .46 .223 < なし> 9411 : 32411 / TCP 16 m

デプロイ後、calculator-front-end LoadBalancer サービスを通じて計算機フロントエンドアプリケーションにアクセスできるようになります。ここで割り当てる EXTERNAL-IP アドレスは 192.168.0.54 です。

電卓

計算機の使用中に生成されたログを表示するには、ブラウザのコンソールウィンドウを開き (F12 キーを使用) ます。ボタンをクリックするたびに、状態の永続性を示すログが表示されることに注意してください。

 水分補給状態:
 { 合計: "21" 、 次: "2" 、 操作: "x" }

また、完全な式が入力されるたびに (例: 126 ÷ 3 = )、ログにサービスへの呼び出しが示されることに注意してください。

 分割サービスの呼び出し

クライアントコードは Express サーバーを呼び出し、Express サーバーは Dapr を介してバックエンドサービスに呼び出しをルーティングします。この場合、nodejs アプリケーションでdivide エンドポイントが呼び出されます。

アプリケーションを操作すると、ネットワークリクエストが生成され、マイクロサービス間で呼び出しが行われます。つまり、この時点で、パラメータに対応するトレーステレメトリデータが取得され、Zipkin にアクセスしてデータを照会できるようになります。

Zipkinダッシュボード

詳細なテレメトリデータを表示するには、[表示] をクリックします。

ジプキンショー

Zipkin に加えて、Uber が作成したオープンソースの追跡システムである Jaeger など、他の監視バックエンドソフトウェアでも、テレメトリを Zipkin 形式でインポートできます。分散サービス間のトランザクションを追跡し、複雑なマイクロサービス環境のトラブルシューティングを行うために使用されます。たとえば、New Relic は、分散アプリケーションからの関連データをリンクしてシステムの全体像を提供できるフルスタックの可観測性プラットフォームです。これらを試すには、Dapr 構成ファイルで Jaeger または New Relic サーバーを指すエンドポイントアドレスを指定するだけです。以下は、テレメトリを Jaeger サーバーに送信するように Dapr を構成する構成ファイルの例です。 Jaeger の URL は Zipkin の URL と同じです。唯一の違いは、サーバーが実行されるポート番号です。

 apiバージョン: dapr .io / v1alpha1
 種類: 構成
メタデータ:
 名前: dapr - config
 名前空間: デフォルト
仕様:
 トレース:
 サンプリングレート: "1"
 ジプキン:
 エンドポイントアドレス: "http://localhost:9415/api/v2/spans"