分散トレーシング技術について

About me
Mahito Ogura (小倉真人<m.ogura@ntt.com>)
NTTコミュニケーションズ 技術開発部
業務：クラウドや分散システムの調査検証
● コムウェア入社（H21）2014年に異動で現職
● インフラ構築（Chef, Ansible）
● アプリケーション開発（Ruby）
● OpenStackとか分散ミドルとかコンテナ
● 採用のお手伝いとか各種イベント業, etc...

はじめに
現代のサービスは複雑化され、そのシステムは大規模に分散することが多い。
特にサービスの機能ごとに分けて作り、それらを疎結合させるMicroservicesアーキテク
チャの流行もあり、機能ごとに開発チームが異なることや、開発言語が違うことが増え、
サービス内部はより分散し複雑化している。
分散し複雑化したサービスにおいて機能ごとの関係性を把握することは難しく、エラーや
性能問題などが起きた際にその原因特定が非常に難しくなる。
こうした問題に取り組むべく、分散されたサービス内のリクエストをトレース可能な、分散
トレーシング技術が現在注目を浴びている。

分散トレーシングの歴史
2003年「Magpie: Online Modelling and Performance-aware Systems」
2007年「X-Trace: A Pervasive Network Tracing Framework」
2010年「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」
以降、Dapperの論文を元にZipkinやDapperとZipkinをベースにしたappdash、HDFSや
HBaseに使われているHTraceなどのOSSが開発される。
また、最近では分散Tracingの仕様やAPIを取りまとめたOpenTracingが登場し、
OpenTracingの仕様を実装したライブラリや、上記OSSのOpenTracing対応が進められて
いる。

インターネットサービスはしばしば複雑に実装され、大規模に分散したシステムとなって
いることがある。
これらのシステムはソフトウェアモジュールの集合であり、各ソフトウェアモジュールは、
開発チームが異なることや、開発言語が異なること、そして何千台のマシンの複数のレ
イヤにまたがることがある。
こうした環境においてシステムのしくみの理解や、性能問題の原因特定は難しく、一度
問題が起きると解決に至るまでに膨大なコストがかかることがある。
こうした問題を解決するために、各システムの挙動や性能を把握することができる分散
トレーシング技術が注目を集めている。
なぜ分散トレーシングが注目されているか

参考：OpenStackのアーキテクチャ

分散トレーシングに必要なしくみは次の2つ
● 分散トレーシングのしくみ（ライブラリ含む）
● トレースの結果をモニタリングするためのしくみ
また、トレーシングがシステムの性能に影響を及ぼさないよう、
一部の処理だけをトレースするためのサンプリングレートを設定するしくみを
設けている分散トレーシングツールも存在している（ex.Zipkin, OpenTracing）
分散トレーシング

Trace：Span全体のStartからFinishまでを含むSpanの集合体
Span：ひとつのサービス（境界）内の処理。以下の情報が含まれる
分散トレーシング(OpenTracing)用語解説 -1/2-
Trace
Span

オプション
● Span Tags
● Span Logs
● References
○ 他Spanとの関係性
分散トレーシング(OpenTracing)用語解説 2/2
必須
● Operation Name
● Start / Finish Timestamp
● Span Context
○ Baggage Items
○ tarace / span ID

以下例では、Traceは8つのSpanから構成されている。
各Spanの間には関係性があり有効巡回グラフ（DAG）で表すことができる。
Spanの関係図（DAG）

SpanとReferenceについて
ChildOf Reference：
親Spanが依存する子Spanとの関係（例：RPC, SQL）
FollowsFrom Reference：
親Spanが依存しない子Spanとの関係（例：非同期処理）

分散トレーシングのユースケース
● プログラム内の関数レベルのトレース
● サーバのエンドポイントのトレース
● クライアントコールのトレース
● 分散環境におけるデータの分散 / 転送
● イベントのロギング
● メッセージバス（MQ and Pub/Sub）シナリオのトレース

OpenTracingについて
OpenTracingは、一般的なプラットフォームに向けて、一貫したベンダ非依存なAPIを提
供することにより、開発者に容易にシステムへトレーサの追加、またはトレーサの切り替
えを行うことが出来るしくみを提供する、分散トレーシングの実装である。
また、OpenTracingは分散トレーシングとしてのOSSの実装以外にも、プラットフォーム固
有のトレーサーに向けた共通仕様も用意しており、他の分散トレーシングツールはこの
仕様を実装することで、OpenTracing互換のトレーサーとして実装することが出来るた
め、ユーザは設定の変更だけでトレーサの切り替えを行うことができる。

OpenTracing仕様を実装したトレーサー
● Zipkin：Twitter社が開発したトレーサー
● Jaeger：Uber社が開発したトレーサー
● Appdash：sourcegraph社がGo言語で開発した軽量なトレーサー
● LightStep：OpenTracing互換のトレーサー
● Hawkular：OpenTracing-Javaをサポート
● Instana：OpenTracingのJava, Node.js, Goをサポート
● sky-walking：OpenTracing-Javaをサポート
● inspectIT：OpenTracing-Javaをサポート
● stagemonitor：Javaのバイトコードからトレーシングを行う

Zipkin
GoogleのDapperを参考に作られた分散トレーシングシステム
分散システムのレイテンシ問題の
トラブルシューティングに必要な
データを収集し（Zipkin）、
システムの依存関係を参照するための
UI（Zipkin UI）を提供する
アーキテクチャは右図参照
● ReporterはTransportにデータを転送
● Transporはcollectorにデータを転送
● CollectorはStorageにデータを格納
参考：http://zipkin.io/pages/architecture.html

Jaeger
Uber社がGo言語で開発している分散トレーサーとそのUI
● 2017年9月にプロジェクトがCNCFにホストされることになった
Go言語で書かれた自前のモニタリングツールが用意されている
Go, Python, Node, JavaなどのTracerが用意されている
● Python 3には未対応

Architecture
出典：http://jaeger.readthedocs.io/en/latest/architecture/

分散トレースのしくみ（ex. HTTP Request）
HTTPヘッダに格納された親スパンの
情報をデシリアライズ(extract)
現在のSpanの情報をシリアライズして
HTTPヘッダに格納(inject)
Serialize span ID to a string
{trace_id}:{span_id}:{parent_id}:{flags}
出典：http://jaeger.readthedocs.io/en/latest/architecture/

sourcegraph社がGo言語で開発した軽量なトレーサー
Go言語で書かれた自前のモニタリングツールが用意されている
● 一応OpenTracingへの対応はしているとドキュメントに書かれている
● 開発の更新は2016/11で止まっている（2017/9/19時点）
● DAGの表示はできない
Go, Python, Ruby(サードパーティー）などのTracerが用意されている
● しかしながらRubyはOpenTracing未対応かつ壊れている可能性が高い
参考：Appdashを動かしてみた - Qiita
Appdash

LightStep
OpenTracing互換のTracer
● Go / JavaScript / Python / PHP / Ruby / Java / iOS / Android
MonitoringはSplunk/kibanaを利用する模様
詳細はLightStep社に問い合わせが必要

Hawkular
RedHatが支援している既存のモニタリングの課題を解決するためのツール
以下の４つの機能を有する
● Federated Alerting
● Distributed Tracing
● Metrics TSDB
● ManageIQ Provider
分散トレーシングについてはJaegerとコラボをすることでOpenTracing対応をしているらし
い。

サンプル（OpenStack Novaへの実装）
nova-computeがnova-schedulerにインスタンスの情報を同期する流れ
22
nova-compute
Queue
<conductor>
RabbitMQ
nova-conductor
Queue
<reply_xxx>
nova-scheduler
Queue
<scheduler>
①
②
③
① call to ”conductor” for DB access
② reply to ①
③ cast to ”scheduler”
Database

Jaeger UI上でのトレース結果
①
① call to ”conductor” for DB access
② reply to ①
③ cast to ”scheduler”
① + ②
②
③

● 分散システムの挙動やレイテンシの把握は難い
● 分散トレーシングの仕様としてOpenTracingがある
● OpenTracing実装として各種ツールがあるが、
現状はUber社が開発をしているJaegerがよさそう
● まだ全体的にドキュメントが足りておらずコードを
読まないとわからないことが多い
まとめ

Presentation by NTT Communications