Kubernetesアプリケーションのトレーシング

サンプルアプリケーションのデプロイ

サンプルアプリケーションは、恒例のsample1を使用します。サンプルアプリケーションのうち、バックエンドのarticle、accesscount、rankにJaegerクライアントライブラリを追加しています。Springアプリケーション向けのモジュールを用いることで、設定をするだけで典型的なトレースを実装できます。変更内容の詳細はGitLab.comのコミットログを参照してください。

トレーシングを有効にしたマニフェストでアプリケーションをデプロイします。今回使用するマニフェストも、Thinkit Kubernetes Sample1 Manifestsリポジトリのchapter9-distributed-tracingブランチとしてマニフェストを公開しています。リポジトリを前回までに既にcloneしている場合は以下のコマンドで取得できます。

git pull
git checkout chapter9-distributed-tracing

まだ取得していなかったり、上記のコマンドでエラーが出たりする場合^*2は、別のディレクトリに以下のコマンドで新しくcloneしても構いません。

*2 リポジトリ内のファイルを変更していると発生する場合があります。いろいろ試してみると理解も進むので、ぜひ今後も続けてください!

git clone --branch chapter9-distributed-tracing -- https://gitlab.com/creationline/thinkit-kubernetes-sample1-manifests.git

取得したリポジトリのルートディレクトリに移動し、以下のコマンドでサンプルアプリをデプロイします。

kubectl apply -k overlay/develop/

Jaegerの利用

各アプリケーションが起動したら、ダミーデータを作成します。まず、次のコマンドでarticleにport-forwardを行います(ポート番号の末尾が 8081 と 8080 で異なるので注意してください)。

kubectl port-foward service/article 8081:8080

別のターミナルを開き、リポジトリに移動して、以下のコマンドで記事のダミーデータを作成するスクリプトを実行します。

./scripts/post-sample-article.bash

作成されたダミー記事の内容がターミナルに表示されれば成功です(先ほど設定したport-forwardは[Ctrl]+[C]で停止して構いません)。アプリケーションへアクセスするため、以下のコマンドで新たにport-forwardを行います。

kubectl port-foward service/website 3000:3000

既にトレースデータは収集されているので、ユーザーのつもりになってブラウザでhttp://localhost:3000/にアクセスします(ダミーデータは実行ごとに変わるので記事のタイトルも異なります)。

さらに適当な記事を1つ開いてみましょう(このとき、バックエンドでarticleアプリはaccesscountアプリにアクセスがあったことを記録します)。

ここでもう1度JaegerのUIを開きます。先ほどと同様に、以下のコマンドでport-forwardを行います。

kubectl port-forward service/simplest-query 16686:16686

ブラウザでhttp://localhost:16686/にアクセスすると、下図のように表示されるでしょう。

左サイドバーのセレクトボックスServiceからarticleを選択して、サイドバーの下側にあるFind Tracesボタンをクリックします。articleをルートとするトレース情報が以下のように表示されます。

上図で1つ目に表示されているトレース名article: getArticleをクリックすると、トレースの詳細を見ることができます。先ほどブラウザで記事を開いたときにarticleアプリが呼び出されただけでなく、記事にアクセスがあったことをバックグラウンドでaccesscountに記事へアクセスがあったことを記録していることがわかります。また、articleのスパンがaccesscountへアクセスするスパンが終了する前に終了しています。これは、アクセス記録は記事を返すのには不要な処理のため、articleでaccesscountへのリクエストを非同期に実行して完了を待たないように実装されているためです。

もう少し複雑な例を見てみましょう。次の図は、記事データに加えてアクセス履歴も作成したあと、rankサービスからアクセスランキングを作成したときのトレースです。

Service & Operationの領域に1つのスパンが1行ずつ表示されます。上図では上から3つのスパンを展開しています。サイドバーのツリー構造によってスパン同士の呼び出し関係が表現されており、rankからarticleやaccesscountが呼び出される関係が見て取れます。また、それぞれのスパンがタイムライン上のバーで示されており、図のようにスパンを展開すればそれぞれに応じた情報がタグやログとして記録されています。

もちろん、この例で表示されているのはSpringアプリケーション向けのデフォルト実装によるものなので、デフォルト実装が作成するスパンをアプリケーション中で取得して情報を加えたり、途中で別のスパンを作成したりすることもできます。

おわりに

今回は、分散トレーシングを用いて複数のアプリケーションからなるシステムで、ユーザーからのリクエストを追跡する方法を実践してきました。

当然、分散トレーシングもこれだけでは十分ではありません。実際のシステムの問題は単一のリクエストから発生するとは限らず、同じコンテナがたまたま同時に処理していたリクエストがメモリを消費していた、ということ等も考えられます。CNCF配下のOpenTelemetryプロジェクトではトレース・メトリクス・ログの3つをテレメトリー(Telemetry)と呼び、これらを作成・管理するためのツールやライブラリなどを開発・管理しています^*3。これらのデータを連携させつつ使い分けることで前回も説明したオブザーバビリティが実現されると考えられています。

*3 OpenTelemetryプロジェクトはOpenTracingとOpenCensusが2019年に合流してできたので、ライブラリなどはまだそれぞれのリポジトリに残っているものも多いです。今回のサンプルアプリでもOpenTracingが開発したSpring向けライブラリを利用しています。

とはいえ、これらの標準化組織や公開されている標準仕様も、具体的に生成すべきデータを規定しているわけではなく、「どのようにデータを生成するか」「どう集めるか」「どう管理するか」といった点が標準化されているに過ぎません。実際にどのような情報を出力するかはアプリケーション開発者が作りこむ必要がありますし、保守・運用を担当する運用エンジニアとの協力がなければ必要十分な情報を生成・収集することはかないません。収集や管理はJaegerやPrometheusなどの既存のツールをうまく取り入れ、より重要な「このサービスにとって必要な情報は何か」といったサービス固有の点に集中して取り組むとよいでしょう。

最後になりますが、前回で扱ったPrometheusによるモニタリングとPromtail、Lokiによるロギング、今回扱ったJeagerによるトレーシングについて、クリエーションライン株式会社が開催しているKubernetesトレーニング オブザーバビリティ編ではより詳細な解説とハンズオンを提供しています。今回の記事を読んで実際に構築したいと考えている方や、不明点がある方はぜひご受講をご検討ください。