# The Tale of Errors in Microservices ## 日本語要旨 マイクロサービスアーキテクチャにおける非致命的 RPC エラー(致命的障害にはつながらないが上位リクエストが成功するエラー)の大規模実証研究。Uber の 6,000 超のマイクロサービスと 1,900 のユーザー向けエンドポイント、110 億 RPC を解析。非致命的エラーの蔓延・レイテンシへの影響を定量化し、これを優先度付けして除去するための**レイテンシ削減推定器(LR Estimator)**を提案。最終的にアプリ起動エンドポイントの P99 レイテンシを 30% 削減した事例を示す。 ## 論文情報 - 著者: I-Ting Angelina Lee(Washington University in St. Louis)、Zhizhou Zhang(Uber Technologies)、Abhishek Parwal(Uber Technologies)、Milind Chabbi(Uber Technologies) - 掲載誌: Proc. ACM Meas. Anal. Comput. Syst.(PACM CEAS)、Vol. 8、No. 3、Article 46、2024 年 12 月 - DOI: https://doi.org/10.1145/3700436 ## 問題設定 マイクロサービスは**回復性(resiliency)**を前提に設計されており、下位 RPC が失敗しても上位リクエストが成功できる。この設計により、非致命的エラーは「無視できるもの」として放置されがちである。しかし、研究上の疑問として以下を設定した: 1. 非致命的エラーはどの程度蔓延しているか 2. それらはエンドポイントのレイテンシにどう影響するか 3. どのエンドポイントが改善を最も必要とするか エンドポイントのオーナーが個別のエラーレートを監視していても、システム全体への影響は「グローバルな視点」なしには把握できない。 ## 提案手法 ### レイテンシ削減推定器(LR Estimator) **基本アイデア**: 「すべての非致命的エラー RPC がゼロ時間に短縮された場合」という仮想実行トレースを計算し、エンドポイントが得られるレイテンシ削減量の上限を推定する。 **維持する不変条件**: 1. **誤り消去(Error Elimination)**: エラー RPC の実行時間をゼロとする 2. **親スパンの仕事保持(Parent Work Retention)**: 親スパンが子を起動するまでに行った最小仕事量はそのまま保持する 3. **時間シフト(Time Shift)**: 先行スパンの終了が早まれば、後続スパンの開始も同量だけ早まることができる 4. **直列関係の維持(Series Relationship)**: 元の実行順序(直列関係)は仮想実行でも維持する **アルゴリズム**: `SpanTimeReduction` と `HypoSpanEndTime` が相互再帰で動作。深さ優先でスパン木を走査し、メモ化で重複計算を排除。トレース 10K スパンでも 1.5ms 以内で処理可能。計算量 O(N²)。 ## 新規性 - **非致命的エラーを定量化した最初の大規模研究**: 既存研究(Seemakhupt+ 2023 等)は RPC エラーの種類を列挙するに留まり、レイテンシへの影響や優先度付けはなされていなかった - **エラーカウントだけでは不十分という実証**: エラー数が多くてもクリティカルパス外なら影響ゼロ(図 12: 約 50% のエラーはクリティカルパス外) - **LR Estimator による仮想実行時間の理論的に正確な推定**: クリティカルパスのシフトを考慮した推定(単純なエラースパン長の合算ではない) - **本番環境での検証**: 推定が実際の 30% 削減と一致 ## 実験設定 - **データ**: Uber の 1,300 エンドポイント(7 日間)、110 億 RPC、1.7M トレース、360 億スパン - **計装**: Jaeger(< 1% のアダプティブサンプリング) - **解析軸**: 非致命的エラーの蔓延度・エラー種別・深さ・伝播長・回復力分布・レイテンシ相関 ## 実験結果 ### エラーの蔓延(観察 1〜5) | 指標 | 値 | |---|---| | 失敗リクエスト率 | 0.65% | | 非致命的エラーを含むリクエスト率 | 29.35% | | 非致命的エラーを経験したエンドポイント割合 | 84%(1,120/1,341) | | エラーの多い RPC 種別 1 位 | ENTITY_NOT_FOUND: 42.46% | | 2 位 | ABORTED: 23.18% | | API 回復力分布 | バイモーダル(常に停止 29% / 常に伝播 63% / 混合 8%) | ### レイテンシへの影響(観察 6〜9) | 指標 | 値 | |---|---| | 非致命的エラーありリクエストのスパン数(中央値比) | 1.9 倍 | | 非致命的エラーありリクエストのレイテンシ(中央値比) | 1.8 倍 | | 非致命的エラーありリクエストの P99 レイテンシ比 | 2.9 倍 | | Tail-1% レイテンシを 10% 以上削減できるエンドポイント数 | 132 | | 50% 以上削減できるエンドポイント数 | 26 | ## 考察 - 非致命的エラーはマイクロサービスの設計上の「当然の副産物」ではなく、コーディングパターンの非効率に起因するものが多い - クリティカルパス分析なしにエラーカウントで優先度を付けると的外れな最適化につながる - LR Estimator は上限推定のため過大評価する場合もある(トレース精度の問題・早期bailoutの誤認識など) ## ケーススタディ 1. **アプリ起動(App Launch)**: 廃止済みフィーチャーの残存コード(pool-provider RPC)を検出・除去 → P99 レイテンシ 30% 削減 2. **ユーザーカスタマイズ(get-stores-view)**: ログインしていないユーザーへの get-user の重複呼び出し → リクエストレベルキャッシングが解決策だが実装コストが高い 3. **並列フェッチ(fetchInfo)**: 2 つのデータストアへの並列クエリで、どちらかが常にエラー返却 → 50% の無駄な仕事 ## 強み - 110 億 RPC という類を見ない規模の実証データ - 理論的に正しい推定アルゴリズム(正確性証明あり)と実用的な計算量(1.5ms/10K スパン) - 3 つのケーススタディで推定の実用性を実証 ## 弱点・課題 - Uber 特有の広く深いコールグラフが前提(浅いモノリス寄りシステムでは定量的結果が異なる可能性) - LR Estimator は最適化の上限推定にとどまり、実際に削減可能かは人間の調査が必要 - トレース精度(Jaeger タグ付けのミス)が推定精度に直接影響 ## 関連 - [[分散トレーシング]] — Jaeger を基盤としたトレース解析 - [[Fault Localization]] — クリティカルパス分析を通じた RPC 障害箇所特定 - [[根本原因分析]] — コーディングパターンの非効率を根本原因として特定 - [[テレメトリ]] — スパン/トレースを path-oriented データとして活用 - [[Uber]] — 本研究の実施企業 - [[I-Ting Angelina Lee]] — 筆頭著者 - [[Milind Chabbi]] — 最終著者(Uber Technologies)