# 非致命的RPCエラー ## 定義 **非致命的 RPC エラー(non-fatal RPC error)**とは、マイクロサービスアーキテクチャにおいて、内部 RPC が失敗コードを返しても上位リクエストが成功する場合のエラー。逆に、内部 RPC のエラーが最終的に上位リクエストの失敗に伝播するものを**致命的エラー(fatal error)**と定義する。非致命的エラーはシステムの可用性には影響しないが、冗長な RPC 実行・レイテンシ上昇・リソース消費増大の主因となる可能性がある。([[@2024__PACMCAS__The Tale of Errors in Microservices]]) ### 代表的な発生原因 1. **コーディングパターンの非効率**: 試行順に DB を呼び出す「if-チェック」イディオム(先発する候補が失敗してから次に進む) 2. **廃止されたフィーチャーのコード残存**: 使われなくなった RPC 呼び出しがコードに残り、常に失敗する 3. **デカップルド設計によるメモ化欠如**: 同一リクエスト内で複数の呼び出し元が同じ API を重複して呼び出し、各々が独立して失敗する 4. **並列フェッチの設計**: 相互排他的なデータストアに並列クエリを投げ、一方が常に ENTITY_NOT_FOUND を返す ## 横断的知見 - **エラーカウントによる優先付けは機能しない**: 最も多発するエラー(例: ENTITY_NOT_FOUND 42.46%)でも、クリティカルパスに乗っているとは限らない。Uber の分析では約 50% のエラーがクリティカルパス外であり、このエラーを排除してもレイテンシには影響しない。従来の AIOps における「エラーレートが高い API から調べる」というアプローチは非致命的エラーの文脈では不十分であることが実証された。(Source: [[@2024__PACMCAS__The Tale of Errors in Microservices]]) - **マイクロサービスの回復性デザインが非致命的エラーを可視性の外に追いやる**: サービスオーナーは個別のエラーレートを監視するが、システム全体での累積効果は見えない。これは[[自動化のアイロニー]]が述べる「自動化(回復性)が問題を除去するどころか見えにくくする」と同型の構造である。レジリエンスがヒューマンオペレータの監視を困難にするという逆説は、ソフトウェア設計レベルでも現れる。(Source: [[@2024__PACMCAS__The Tale of Errors in Microservices]]) - **回復力の分布はバイモーダル**: API はほぼ「常に上位に伝播させない(29%)」か「常に伝播させる(63%)」かの二極に分かれ、混合型は 8% に過ぎない。この二極化は「よく設計された大規模システムでは予測可能性が重要」という一般化を支持する。(Source: [[@2024__PACMCAS__The Tale of Errors in Microservices]]) ## 未解決の問い - 非致命的エラーを「設計上の意図」(best-effort)と「コーディング上の非効率」に自動で分類できるか。早期バイルアウトを「削除すべきエラー」と誤認識する LR Estimator の偽陽性問題に直結する - Uber 以外のマイクロサービスシステム(Meta、Netflix 等)でも同様の分布(ENTITY_NOT_FOUND 42% 等)が観察されるか。エラー分類の普遍性を検証する必要がある - リクエストレベルキャッシング(get-user の重複呼び出しを排除する解)の導入コストを最小化する RPC フレームワークの改修パターンはあるか ## 関連 - [[分散トレーシング]] — 非致命的エラーの検出・分析基盤 - [[Fault Localization]] — クリティカルパス上の障害の特定 - [[根本原因分析]] — コーディングパターンの非効率を根本原因として特定するアプローチ - [[テレメトリ]] — スパン・トレースを path-oriented データとして活用 - [[Uber]] — 研究の主な舞台 - [[Jaeger]] — トレーシング計装基盤 ## 出典 - [[@2024__PACMCAS__The Tale of Errors in Microservices]] — 非致命的 RPC エラーを定義し定量化した初の大規模実証研究(Proc. ACM Meas. Anal. Comput. Syst., 2024)