koyama's blog

ByteDanceといえばTikTokの運営で知られている中国のIT企業である．この記事ではByteDanceのマイクロサービスアーキテクチャで設計されたシステムを分析した論文を紹介する．Metaのシステムを紹介した論文を読んでいた際にこの論文を見つけた．

Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud – Wen – 2022 – Journal of Software: Evolution and Process – Wiley Online Library

Sec.1 イントロダクション

• これまでAlibabaやMetaがトレースデータの分析の論文を公開してきたが、これらにはマイクロサービスのワークフローまで言及されていない
  • Lifting the veil on Meta’s microservice architecture: Analyses of topology and request workflows | USENIX
  • Alibabaのマイクロサービスアーキテクチャで設計された巨大なシステムを分析した論文を読んだ
• この論文ではByteDanceのトレースデータの特徴の全体像を明らかにする。
  • トレースデータはRPCレイヤのトレース関数から収集されている。
• 主に以下の2つに着目する。
  • トレースログからワークフローの特徴を明らかにする。
  • ワークフローの構造をトレースツリーが生成される時点から合成していく。(アルゴリズムの提案)
    • (今回、ここは割愛する)

Sec 3. トレースデータの概要

以下はデータ収集のアーキテクチャの概要である。3つのパートから構成されている。

1. コンテナベースで動作するマイクロサービスアプリケーション
2. RPCレイヤベースのトレーシング
3. トレースログ・ファイルをトレースツリーへパース

Sec 3.1. コンテナベースで動作するマイクロサービスアプリケーション

• コンテナ仮想化を使って物理マシンを共有して複数のコンテナをデプロイしている。
• コンテナは動的にインスタンスへデプロイされる。
• コンテナ数とハードウェアリソースはどちらもオートスケーリングが有効である。

Sec 3.2. RPCレイヤベースのトレーシング

• 効率的にコンポーネント間(マイクロサービス間)の通信を開発し運用するために、コンポーネント間の通信には、eRPC(Embedded Remote Procedure Call)やgRPCのようなRPC frameworkを使っている。
• ByteDanceではRPC frameworkは、kitexという名前がつけられている。
• kitexはOpenTracing APIに似たトレーシング手法を実装に含んでいる。
• トレースの結果はログとして分散データベースに保存される。

Figure 2 – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

Sec 3.3. トレースログ・ファイルのパース

• 個別のコンテナで動くアプリケーションから出力されるSpanに対応するログを集めて、1件のトレースをつくり出す。

Figure 3 – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

Sec 3.4. データのクリーニング

• RPCベースのトレーシングは大半のコンポーネントをサポートしている。
• いくつかのコンポーネントでは計装がされていない。
• そのため計装がされないコンポーネントが原因で、dirty dataが生まれる。
• Figure 4 (A)のxが計装されていないコンポーネント(マイクロサービス)に対応する。
• Figure 4 (A)ではTrace XXとTrace YY(Node Nが起点)が別のトレースとして扱われる。

Figure 4 (A) – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

• この問題を解決するためにクリーニングを行う。
• データ収集のアーキテクチャをもとに、サービスメッシュレイヤー(例: NGINX)にルーティングされるユーザからのリクエストを見つける。
• 見つけたリクエストに、サービスメッシュレイヤーからのリクエストを表すラベルをつける。
• 別のマイクロサービスからのRPCの呼び出しには、RPCレイヤーからの呼び出しを表すラベルをつける。
• これの分析結果をFigure 4 (B)に示す。
  • X軸: spanにかかる時間(ms)
  • Y軸: 件数
• 壊れたSpan(broken client span)の時間粒度は、リーフSpan(leaf span)の時間粒度よりも大きくない。
• これは、ユーザーが開始したトレースでサブトレースを失った壊れたSpanは、leaf spanの近くにあることを意味している。
• ユーザーが開始したトレースの壊れたスパンは、サブトレースレコードをフィルター処理すると実行特性にほとんど影響を与えず、現在のワークフロートポロジの理解にも影響しない。

Figure 4(B) – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

Sec 3.5. データのボリューム

• トレース機能のカバレッジは78+%である。
• マイクロサービスモジュールのトレースカバレッジ率が最も高いToutiaoアプリケーションを主な分析対象として選択した。
• Toutiaoアプリケーションのドメインは、ニュースの表示である。
• このモジュールは、推薦や広告、eコマースやショートビデオを含む数万に及ぶ分析に関連している。
• 分析対象データには以下が含まれる。
  • 128,290,337のトレース
  • 3,388のマイクロサービスからの17,332種類のルートスパン
  • 16,284のマイクロサービスからの36,260の機能インターフェイスのRPC呼び出し

Sec 4. ワークフローの特徴

Sec 4.1. DAGグラフ

あるトレース/ワークフローをグラフで表現するときに、いくつかのグラフで表現ができる。

• Calling Graph
  • コンポーネント同士の呼び出しをあらわす
  • ソースコードを形成する静的な依存関係をあらわす
  • 欠点: 以下の違いを上手く表現できない。
    • マイクロサービスBでマイクロサービスAからのリクエストを処理するスレッド
    • マイクロサービスCでマイクロサービスAからのリクエストを処理するスレッド
• Trace Graph
  • 実行中の依存関係を使いトレースログからグラフを構築する。
  • 独立したスレッドを分けて表現ができる。
  • 欠点: トレースグラフは時間の前後を反映できない。
• Time Dependency Graph
  • 時間の依存関係を反映できる。
  • トレースグラフの欠点を改善した。
  • このグラフを使っている。

Sec 4.2. 観測したワークフローの性質

(一番おもしろい話)

• これまで一般に無視していた性質を見つけた。
• これはマイクロサービスのベンチマークの設計にインパクトを及ぼす。
• 単一のサービスのワークフロー群はユーザーのリクエストによって多様になる。
• Figure 6では同一の関数(マイクロサービス)を起点にしたSpanの数(=あるマイクロサービスを起点にそれ以降で呼び出されるマイクロサービスの数)をあらわしている。
• 同一のマイクロサービスであってもSpanの数が違う。=>同一のマイクロサービスでもリクエストの内容によって呼び出すマイクロサービスが違う。

Figure 6 – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

• Figure 7では、あるマイクロサービスから別の並列で呼び出すときに、並列で呼び出せているかを可視化している。
• X軸: あるマイクロサービスが直接呼び出すマイクロサービス数
• Y軸: あるマイクロサービスが「並列で」直接呼び出すマイクロサービスの数(並列数)
• 左上から右下にかけては、呼び出すマイクロサービス数が増えたときに、それらの呼び出しを並列で実行できている。
• 右上は、呼び出すマイクロサービスが増えたときに、それらの呼び出しを直列で行っている。
• ほとんどでparallel_degree=2

Figure 7 – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

Sec 4.3. ワークフロー構造の不自然さ

4.3.1

• Figure 9 (A)
  • X軸: Spanの数
  • Y軸: 割合
• トレースのサイズはロングテール分布に従い、ほとんどのトレースレコードには少数のノードが含まれ、いくつかのトレースレコードには膨大な数のノードが含まれる。
• 65.04%のトレースレコードは、1つのSpanしか含まない。(1つのマイクロサービスしか呼んでいない)
  • これは、他のリモート コンポーネントからの支援を求めるのではなく、Web フレームワーク インターフェイス レイヤーによって多くのユーザー要求を満たすことができることを意味する。
• Spanの数が5未満のトレースの割合は90.84%に達する。
• スパンの数が 13 未満のトレースの割合は 95% に達する。
• Reverse Cumulative: 逆累積(分布曲線)

Figure 9 (A) – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

• Figure 9 (B)
  • X軸 深さ
  • Y軸 割合
• ツリー構造のほとんどは浅く、いくつかのツリーは深いという深さのロングテール分布がある。
• 深さ 0 のトレースは、スパンが 1 つしかないトレース(65.04%)
• 深さ 1 のトレースの割合は 26.06% に達するが、複数のスパンを持つトレースの合計割合は 34.96%
• 最大深さは 10で、最大 4 または 5 の深さを持つ呼び出しツリーは、ほとんどの条件 (99%) をカバーする。

Figure 9 (B) – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467

• Figure 9 (C)
  • X軸: マイクロサービス数
  • Y軸: 割合
• 親ノードによって開始されるリモート呼び出しの数は大きく異なる
• 大部分はいくつかの可能な値に限定されている
• 記録されたスパンの 55.46% には子がない
• 子が 3 個未満のスパンの割合は 90.36%、子が 5 個未満のスパンの割合は 95.46%
• スパンが持つ子の最大数は 118
• この大量のリモート呼び出しは、多くのリモート モジュールに依存する関数ではなく、モジュールの繰り返しによって発生

Figure 9 (C) – Wen Y, Cheng G, Deng S, Yin J. Characterizing and synthesizing the workflow structure of microservices in ByteDance Cloud. J Softw Evol Proc. 2022;34(8):e2467. doi:10.1002/smr.2467