# 非致命的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]]) - **「非致命的エラー」概念は Uber の RPC 伝播分析より10年早く、エラーハンドリングコードのバグとして定量化されていた**: [[@2024__PACMCAS__The Tale of Errors in Microservices]] は「上位リクエストに伝播しない RPC エラー」をレイテンシ・リソース消費の観点から分析するが、[[@2014__OSDI__Simple Testing Can Prevent Most Critical Failures - An Analysis of Production Failures in Distributed Data-Intensive Systems]](Yuan+, OSDI'14)は同じ「非致命的エラー(non-fatal error)」という用語を、可用性への影響という逆の軸で扱う——**壊滅的障害の92%は、ソフトウェアが明示的に検知した非致命的エラーの誤処理(無視・過剰catchによるabort・未実装のTODO)に起因する**。両者を並べると、非致命的エラーは「正しく無視すればコストのみの問題」(Uber の文脈)と「誤って無視すれば壊滅的障害の主因」(Yuan+ の文脈)という**二面性**を持つことが分かる。Uber 論文が測る「エラーが上位に伝播するかどうかの二極分布(29% vs 63%)」は、Yuan+ が指摘する「開発者はエラーをほぼ全数チェックしているが処理を誤る」という観察と補完的で、**エラーが伝播するか否かの設計判断そのものより、伝播させない選択をしたコードの正しさ**が壊滅的障害の分水嶺になる。(Source: [[@2014__OSDI__Simple Testing Can Prevent Most Critical Failures - An Analysis of Production Failures in Distributed Data-Intensive Systems]], [[@2024__PACMCAS__The Tale of Errors in Microservices]]) ## 未解決の問い - Yuan+ OSDI'14 が定量化した「非致命的エラーの誤処理」(空のcatch・過剰catch・TODO放置)と、Uber の「非致命的RPCエラー」(伝播しないエラー)は、同じコードベース上でどの程度重複するか。前者は「誤って処理された結果、実は致命的だった」エラーを扱い、後者は「意図通り非致命的だった」エラーを扱うため、両者は排他的な可能性がある。 - 非致命的エラーを「設計上の意図」(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) - [[@2014__OSDI__Simple Testing Can Prevent Most Critical Failures - An Analysis of Production Failures in Distributed Data-Intensive Systems]] — 非致命的エラーの誤処理が壊滅的障害の92%を占めると定量化した先行実証研究(OSDI 2014)