分散リンク トレースの使用方法は?

この記事はWeChatの公開アカウント「Invincible Coder」から転載したもので、著者はInvincible Coderです。この記事を転載する場合は、Wudi Coder の公開アカウントにご連絡ください。

2021年も心構えを整え、引き続き価値ある技術コンテンツをご提供してまいります。今後、私が執筆する技術コンテンツは、主に DevOps、Kubernetes、Service Mesh などの「クラウド ネイティブ」技術に関するものになる予定です。私がこうしたコンテンツを好んで書く理由は、一方では私自身の興味があり、他方では近年、Kubernetes を基盤とする「クラウドネイティブ」な技術体系が主流になってきたからです。開発者として、ビジネス コードの開発にのみ注力し、プログラム動作の基本的な環境とアーキテクチャ システムに関する十分な知識と理解が不足していると、成長と進歩につながりません。

もちろん、役に立つプログラミングテクニックや、プログラミング言語に関連する技術（Java 並行プログラミング、I/O、ネットワークなど）など、プログラミング技術に関する内容は引き続きお伝えしていきますが、市場で何度も書かれて繰り返されている技術的な内容や、さまざまなチキンスープ記事については書かないように努めます。皆様の時間を無駄にしないために！

はい、もうナンセンスはやめましょう！今回は「分散リンクトレーシング」の内容を紹介します。現在マイクロサービス アーキテクチャを採用しているほとんどの企業にとって、従来のマイクロサービス システムであれ、新世代のサービス メッシュ マイクロサービス アーキテクチャであれ、分散リンク トレーシングは必須です。紹介する具体的な内容については、この記事は完全に理論に関するものではなく、理論から実践へと操作できるように皆様を導くことを目的としています。そうすることでのみ、技術的なレベルから真に深い理解と認識を得ることができるからです。

分散リンク トレーシングの概要

分散リンクトラッキングシステムを詳しく紹介する前に、まずリンクトラッキングとは何かを理解する必要があります。このコラムの前のセクションで監視システムを紹介したところから、監視システムの観測データは主に統計指標、ログ、リンク追跡の 3 つの側面から得られることがわかります。これらのデータは、リクエスト レベルと集約レベルの 2 つのタイプに分けられます。

リクエスト レベルのデータは、主に HTTP 呼び出し、RPC 呼び出しなどの実際のリクエストから取得されます。この記事で紹介するリンク トラッキングは、このタイプです。集約レベルは、インターフェース要求のメトリック、または QPS、CPU 使用率、その他の値などの一部のパラメータ データの集約です。ログおよび統計インジケータ データは、実際のリクエストまたはシステム自体の診断中に記録された情報から取得される可能性があるため、リクエスト レベルまたは集計レベルのいずれかになります。

リンク トラッキングに関しては、その主なロジックは、要求されたリンクの完全な動作を記録し、リンク クエリ、パフォーマンス分析、依存関係、トポロジ マップなどの分散リンク トラッキング関連機能を視覚的な形式で実装できるようにすることです。次の図に示すように:

上の図では、マイクロサービス システム内のインターフェース呼び出しに関与するマイクロサービスが 2 つあり、それらの呼び出し関係は A->B->C であると想定されています。サービス B は Redis などのサードパーティ サービスとの呼び出し関係も持っており、サービス C も MySQL データベース サービスを呼び出す必要があります。したがって、実際にリンク トラッキングが行うことは、インターフェイス応答結果、時間消費など、完全なリンク A->B (B->Redis)->C (C->MySQL) の詳細な呼び出し情報を詳細に記録することです。

では、この通話リンクのデータはどのように記録されるのでしょうか?次に、上記の呼び出しチェーンを例として、リンク追跡情報の具体的な構成と伝送形式を分析し、分散リンク追跡システムの原理と概念をさらに理解します。具体的なロジック図は次のとおりです。

上図に示すように、分散リンクトラッキングで監視する対象は、繰り返し呼び出しによって生成されるリンクです。図の 1-8 は完全なリンク (Trace) を示しており、システムはそれを一意の識別子 (TraceId) を通じて記録します。リンク内の各依存呼び出しは、呼び出しトレース情報 (Span) を生成します。最初に生成される Span はルート Span と呼ばれます。後続の Span では、前の Span の識別子 (Sid) が Span 情報の親 ID (Pid) として使用されます。

同様に、リンクが実行されると、Span 情報はプロセス内またはプロセス間でコンテキスト内で渡されます。各リンク呼び出しによって生成されたトレース情報は、Span データ チェーンを通じて連続的に接続することができ、各 Span に添付されたログ情報 (アノテーション) が呼び出しチェーンの監視と分析のデータ ソースとなります。これが分散リンクトラッキングの基本原理です。

この時点で、「これほど大量のデータを監視すると、システム リソースが大量に消費されるのではないか」という疑問が生じるかもしれません。実際、ほとんどのリンク追跡システムには、システムによって収集されるリンク情報の割合を制御するためのサンプリング レートと呼ばれる設定があり、それによってシステムのパフォーマンスが向上します。多くの場合、大量のリンク情報は同一であり、比較的時間がかかり、エラーが多いリンクにのみ焦点を当てる必要があるかもしれませんが、100％を収集する必要はありません。

スカイウォーキング入門

先ほど、リンクトラッキングとは何かを基本原理の観点から説明しました。次に、最も人気のある分散リンク追跡システムである SkyWalking を紹介します。

SkyWalking は優れたオープンソース APM (アプリケーション パフォーマンス管理) システムであり、リンク トレースやリンク分析などの分散トレース機能を提供するだけでなく、パフォーマンス指標分析、アプリケーションとサービスの依存関係分析、サービス トポロジ分析、アラームなどの一連のアプリケーション パフォーマンス監視関連機能もサポートしており、問題を効果的に特定するのに役立ちます。

データ収集の観点から見ると、SkyWalking は、Java、.NET Core、NodeJS、PHP、Python などのさまざまな言語をサポートする非侵入型エージェント プローブや、サービス メッシュ アーキテクチャのサポートなど、さまざまなデータ ソースと形式をサポートしています。具体的な構造は以下の図の通りです。

上図に示すように、SkyWalking の中核は、リンク収集サーバー (Receiver Cluster) と集約サーバー (AggregatorCluster) で構成されています。レシーバー クラスターは、バックエンド サービス全体へのアクセス ポイントであり、特にさまざまなサービス インジケーターとリンク情報を収集するために使用されます。

AggregatorCluster は、コレクターによって収集されたデータを要約および集約し、最終的に集約されたデータをデータベースに保存するために使用されます。一般的な ElasticSearch、MySQL、TIDB など、具体的なストレージ方法は多数あり、実際のニーズに応じて選択できます。これらの集約されたデータは、後でアラーム設定に使用できるほか、GUI/CLI などの可視化システムから HTTP 形式でアクセスして可視化することもできます。

さらに、データ収集ロジックの観点から、SkyWalking は複数の言語プローブとプロジェクト プロトコルをサポートしており、現在主流の分散テクノロジ スタックのほとんどをカバーできます。具体的には、次の 3 つのタイプがあります。

• メトリクス システム: 統計システム。 Prometheus から SkyWalking へのメトリック データの直接プルをサポートし、プログラム自体が micrometer を介してデータをプッシュすることもサポートします。
• エージェント: ビジネス調査。各種業務システムにプローブサービスを統合し、リンクトラッキング、つまりリンクデータ収集を行うことを指します。 SkyWalking は、Java、Go、.NET、PHP、NodeJS、Python、Nginx LUA など、複数の言語のプローブをサポートしています。さらに、gRPC または HTTP 経由のデータ転送もサポートしています。
• サービス メッシュ: SkyWalking は、新世代のマイクロサービス アーキテクチャ サービス メッシュの監視もサポートします。特定のサービス メッシュ プロトコルを介してデータ プレーンとコントロール プレーンからデータを収集し、サービス メッシュ リンク データを監視できます。

上記の内容では、SkyWalking の基本的な状況を簡単に紹介し、そのシステム アーキテクチャを簡単に分析します。実際、SkyWalking は過去 2 年間で急速に発展し、コミュニティも非常に活発になっています。マイクロサービス リンク トラッキングやアプリケーション パフォーマンス モニタリングの分野でますます広く使用されています。スペースの都合上、ここでさらに詳細を共有することは不可能です。興味のある読者は、公式文書やコミュニティを通じてさらに詳しく知ることができます。

SkyWalkingのインストールと展開

前回のコンテンツでは、分散リンク トレーシングの基本原理を紹介し、SkyWalking に焦点を当てました。当然、この記事がここで終わってしまうと価値がなくなります。なぜなら、正しいナンセンスをたくさん述べているだけであり、読んだ後に忘れてしまうからです。これは明らかに私の共有スタイルと一致しません。次に、実験的な観点から SkyWalking を試してみることにします。

以下の内容は実際に実験操作が必要となります。地下鉄で不便な場合は、まず保存して、時間があるときに試してみるのもよいでしょう。

SkyWalking の展開には主にバックエンド OAP サーバーとフロントエンド UI が含まれ、実際のニーズに応じて物理マシン、仮想マシン、または Kubernetes クラスターに展開できます。環境の一貫性を示すために、SkyWalking のバックエンド サービスと UI をそれぞれ Kubernetes クラスターにデプロイすることを選択します。

SkyWalking をインストールする具体的な方法は、公式の Kubernetes デプロイメント ファイルを使用して Helm でインストールするか、Kubernetes デプロイメント ファイルを手動で書き込むことです。ここでは、学習のしやすさを考慮して後者の方法を使用します。具体的な手順は次のとおりです。

1) Kubernetes クラスターに名前空間を作成し、別の SkyWalking コンテナを実行します。コマンドは次のとおりです。

 #kubectl経由でKubernetesクラスターに接続し、名前空間コマンドを作成する
$ kubectl作成ns スカイウォーキング

コマンドを実行した後、名前空間が正常に作成されたかどうかを確認できます。コマンドは次のとおりです。

 # 名前空間の作成ステータスを確認する
$ kubectl get ns
名前ステータス 年齢
デフォルトアクティブ10d
 kube-node-lease アクティブ 10d
 kube-パブリックアクティブ 10d
 kube システム アクティブ 10d
 kubernetes-dashboard アクティブ 10d
スカイウォーキング アクティブ46

空中歩行空間がうまく構築されていることがわかります！

2) SkyWalking-UIとOAP ServerサービスのKubernetesデプロイメントファイルを作成する

特定の Kubernetes デプロイメント ファイルを作成するときは、SkyWalking-UI と OAP Server のコンテナ イメージを指定する必要があります。一般的に言えば、ソース コードを通じて手動でパッケージ化することも、公式にパッケージ化されたイメージを直接使用することもできます。デモンストレーションの便宜上、ここでは Docker 公式イメージ リポジトリにパッケージ化されたイメージを使用します。図に示すように:

上記の 2 つの画像に示すように、Docker Hub の公式イメージ リポジトリで、SkyWalking-UI と OAP Server の公式リリースされたコンテナー イメージ バージョンが見つかりました。次に、特定のデプロイメントファイルを作成します。

SkyWalking サーバーの Kubernetes デプロイメント ファイル (skywalking-aop.yml) を記述します。具体的な内容は以下のとおりです。

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前:oap
  名前空間: スカイウォーキング
仕様:
  レプリカ: 1
  セレクタ：
    一致ラベル:
      アプリ: oap
      リリース: スカイウォーキング
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: oap
        リリース: スカイウォーキング
    仕様:
      コンテナ:
        -名前:oap
          #OAPサーバーコンテナイメージとバージョン情報を指定します
          イメージ: apache/skywalking-oap-server:8.3.0-es7
          イメージプルポリシー: IfNotPresent
          ポート:
            - コンテナポート: 11800
名前: grpc
            - コンテナポート: 12800
名前: レスト
---  
 APIバージョン: v1
種類: サービス
メタデータ:
名前:oap
  名前空間: スカイウォーキング
  ラベル:
    サービス: oap
仕様:
  ポート:
    #安らかなポート
    - ポート: 12800
名前: レスト
     #rpc ポート
    - ポート: 11800
名前: grpc
    - ポート: 1234
名前: ページ
  セレクタ：
    アプリ: oap

上記は標準の Kubernetes デプロイメント ファイルです。ファイル内の関連命令の具体的な意味については、Kubernetes 関連の資料を参照してください。

SkyWalking-UI デプロイメント ファイル (skywalking-ui.yml) を記述します。具体的な内容は次のとおりです。

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: ui-deployment
  名前空間: スカイウォーキング
  ラベル:
    アプリ:ui
仕様:
  レプリカ: 1
  セレクタ：
    一致ラベル:
      アプリ:ui
  テンプレート：
    メタデータ:
      ラベル:
        アプリ:ui
    仕様:
      コンテナ:
        -名前: ui
          イメージ: apache/skywalking-ui:8.3.0
          ポート:
            - コンテナポート: 8080
名前: ページ
          環境:
            -名前: SW_OAP_ADDRESS
              値: oap:12800
 ---  
 APIバージョン: v1
種類: サービス
メタデータ:
名前: ui
  名前空間: スカイウォーキング
  ラベル:
    サービス: ui
仕様:
  ポート:
    - ポート: 8080
名前: ページ
      ノードポート: 31234
  タイプ: NodePort
  セレクタ：
    アプリ:ui

3) 記述したデプロイメントファイルに従ってKubernetesデプロイメントコマンドを実行する

前の手順で記述した Kubernetes リリース ファイルに従って、ここでは次のように記述したリリース ファイルに従ってデプロイメント コマンドを直接実行します。

 #リリースファイルの保存ディレクトリに入り、すべてのファイル展開コマンドを一度に実行します
kubectl を適用します。
デプロイメント.apps/oap が作成されました
サービス/OAPが作成されました
デプロイメント.apps/ui-deployment が作成されました
サービス/UIが作成されました

実行が完了したら、コマンドを使用して特定のデプロイメント ステータスを表示します。コマンドは次のとおりです。

 #スカイウォーキングスペースでポッドとサービスオブジェクトの実行状態を確認する
$ kubectlすべてを取得-n スカイウォーキング
名前準備完了 ステータス 再起動 年齢
pod/oap-5f6d6bc4f6-k4mvv 1/1 実行中 0 36時間
pod/ui-deployment-868c66449d-fffrt 1/1 実行中 0 36 時間
 
名前タイプ クラスター IP 外部 IP ポート 年齢
service/oap ClusterIP 10.110.112.244 <なし> 12800/TCP、11800/TCP、1234/TCP 36h
 service/ui NodePort 10.100.154.93 <なし> 8080:31234/TCP 36h 
 
名前準備完了最新利用可能年齢
デプロイメント.apps/oap 1/1 1 1 36時間
デプロイメント.apps/ui-deployment 1/1 1 1 36時間
 
名前希望現在の年齢
レプリカセット.apps/oap-5f6d6bc4f6 1 1 1 36時間
レプリカセット.apps/ui-deployment-868c66449d 1 1 1 36時間

デプロイされた SkyWalking サービスが正常に実行されていることがわかります。初めてのデプロイメントの場合、イメージをプルするプロセスが遅くなる可能性があります。デプロイメント プロセス中に問題が発生した場合は、Pod オブジェクトの実行ログを表示することもできます。次に例を示します。

 #aopの起動ログを表示できます
$ kubectl ログ pod/oap-5f6d6bc4f6-k4mvv -n スカイウォーキング

4) SkyWalking-UIのWebアクセスアドレスを確認する

上記の手順を実行すると、Kubernetes クラスターで SkyWalking-UI および OAP サーバー サービスが正常に実行されます。次に、SkyWalking-UI サービスのマッピング ポート (ポート 31234 は k8s デプロイメント ファイルで定義されています) を介して Web UI にアクセスします。たとえば、http://NodeIP:31234 からアクセスできます。

 #ここでのIPはKubernetesクラスタの外部に公開されるノードエントリIPです
http://10.211.55.12:31234/

Kubernetes クラスター ノード エントリの IP アドレスがわからない場合は、次のコマンドで表示できます。

 #SkyWalking-UI によってデプロイされた Kubernetes クラスター ノードの IP アドレスを照会する
$ kubectl ノードを記述します kubernetes
名前: kubernetes
役割: マスター
...
住所:
  内部IP: 10.211.55.12
  ホスト名: kubernetes
 ...

アクセス後のインターフェース表示効果は以下のとおりです。

上図の通り、SkyWalkingが正常に実行されていることがわかります。まだサービスにアクセスできないため、当面は監視データは表示されません。

追記

前述の通り、Kubernetes 環境に分散リンク追跡システムを導入することに成功しました。実験中に K8s 環境がない場合には、このコラムの関連記事を参照してください。そこでは、Kubernetes をインストールしてデプロイする複数の方法を紹介しました。

なお、サービスアクセスがないため、リンクトラッキングデータは当面見ることができません。ただし、スペースの都合上、Java マイクロサービスを SkyWalking に接続する方法については、これ以上紹介しません。しかし、このアクセス プロセスは、R&D 担当者である私たちにとって、マイクロサービス プログラムと分散リンク追跡システム間の統合と相互作用をさらに理解するための鍵となるため、非常に興味深いものです。この部分は、次の記事の続編として皆さんにお伝えします。それほど時間はかかりません。引き続きご注目ください！