1 分散システム、なんですぐ死んでしまうん？ 耐障害性を高めたいあなたのための レジリエンスパターン入門 SRE NEXT 2026 発表資料 Mitsuhiro Shibuya @m4buya Mercari, Inc. 

2 Mercari, Inc. Marketplace SRE ● バックエンドエンジニアだったが、なりゆきでReliability に身をささげる人生に ● メルカリに入社したのは7年くらい前 ● 一度退職したが、出戻ってきました ● SRE NEXT立ち上げ期にコアスタッフしてました ● SREcon26 Americasで登壇してきたよ！ mshibuya (@m4buya) 

3 分散システム、なんですぐ死んでしまうん？ アジェンダ レジリエンスパターンの紹介と分析 実装戦略: Service Mesh vs アプリケーションライブラリ メルカリにおけるレジリエンス実践 2. 3. 4. 1. まとめ 5. Timeout, Retry, Request Heading, Circuit Breaker, Load Shedding, Graceful Degradation 

4 分散システム、なんですぐ死んでしまうん？ アジェンダ レジリエンスパターンの紹介と分析 実装戦略: Service Mesh vs アプリケーションライブラリ メルカリにおけるレジリエンス実践 2. 3. 4. 1. まとめ 5. Timeout, Retry, Request Heading, Circuit Breaker, Load Shedding, Graceful Degradation 

5 分散システム、 なんですぐ死んでしまうん …？ 

6 分散システム、多くの理由によりそもそも死にやすい あなたの分散システム、死にやすくないですか？ 構成・規模に起因する複雑さ ネットワークに起因する不安定さ 多様かつ複雑な故障モード 結果、局所的な問題が全体に波及する「カスケード障害」を起こしやすい 

7 レジリエンスパターンでカスケード障害を止めよう ✏ この発表では「レジリエンスパターン」を分散システムにおける カスケード障害を止めるための、主にネットワークリクエストを中 心に適用される実装パターン と定義します。 ● Google SRE本で言えば、特に21章「過負荷への対応」 と22 章「カスケード障害への対応」の中心的テーマ ● 書籍「Release It!」においてStability Patternsとして紹介さ れているうちのサブセットに相当 “分散システムは常にどこかが少しずつ壊れている” ➡「壊れない」から「壊れても派手には壊れない」への転換 

8 分散システム、なんですぐ死んでしまうん？ アジェンダ レジリエンスパターンの紹介と分析 実装戦略: Service Mesh vs アプリケーションライブラリ メルカリにおけるレジリエンス実践 2. 3. 4. 1. まとめ 5. Timeout, Retry, Request Heading, Circuit Breaker, Load Shedding, Graceful Degradation 

9 今日取り上げるレジリエンスパターンのリスト パターン 救うもの 犠牲・コスト どのレベル？ Timeout UX・リソース エラー増 全レベル Retry 成功率 レイテンシ・負荷増 呼び出し元 Request Hedging テイルレイテンシ リクエスト・負荷増 呼び出し元 Circuit Breaker 過負荷時の遮断 機能停止 呼び出し元で遮断 Load Shedding 過負荷時の遮断 リクエスト拒否 入口・呼び出し先中心 Graceful Degradation コア価値を維持 機能・UXを落とす 要体験レベルでの考慮 

10 Timeout: 成功率を犠牲にユーザー体験・リソースを守る 分散システムで発生する「遅延・応答なし」に対す るセーフガードとなる。 Timeoutの２つの役割 : ● ユーザー体験を守る (fail-fast) ○ ユーザーは無限には待てない。失敗とし て知らせてあげるほうがまし ● リソース枯渇からシステムを守る ○ 「待つこと」は貴重なシステムリソースを 消費する 

11 Timeout Propagationの重要性 上流で設定されたTimeoutの残り時間を伝播し て、下流のTimeoutを制約していく仕組み なぜ必要か？ ● 上流がもう諦めてしまったら、その処理を続 けることは単純にリソースの無駄 ● 他レジリエンスパターンへの安全弁としても 働く 例: gRPCにおけるDeadline Propagation 

12 Retry: 負荷・レイテンシと引き換えにまれな失敗を減らす 分散システムの失敗の多くは一時的で、少し待って やり直せば成功する見込みが高い。しかし全体のレ イテンシを増やすし、ちゃんとやらないと負荷を上げ るので諸刃の剣 Exponential Backoff + Jitterが基本 気をつけるべきポイント : ● 冪等性の担保 ○ 作成系(POST)リクエストに注意 ● Retry Stormを防ぐには 

13 Retry Storm: Retryそのものが招くカスケード障害 素朴にRetryを実装してしまうと、階層間や並 列処理においてRetryが増幅され、下流に爆発 的な負荷を与えてしまう Retry Budgetが有力な対策となる ● 階層間を超えたリクエスト全体としての Budget ○ Timeout propagationでも近い効 果は得られる ● 呼び出し先保護のためのBudget 

14 呼び出し先保護のための Retry Budget 呼び出し先をRetryで集中攻撃して過負荷に 追い込まないための対策 どこかRetry tokenを管理する場所を持って おき、Retryのたびにそれを消費する仕組み とする。tokenの発行速度をコントロールす ることでRetry回数を抑える仕組み 例えば、通常トラフィック数の10%分までしか Retryさせない、など 

15 Request Hedging: テイルレイテンシを減らす まれに発生するロングレイテンシを救うための手段。 リクエストを投げて一定時間が経過したら追加のリク エストをリスク回避(=hedge)として投げ、早く返って きたレスポンスを採用することで遅い方を待たずに後 続処理に移れる。Retryとも併用できる 注意点はRetryとほぼ同様: ● Jitterを適用する ● Retryと同じBudgetを適用すること 

16 Circuit Breaker: リクエストを失敗させ、負荷を下げる 過負荷に陥っている下流を呼び出し続けても成功す る見込みは薄い ● 下流の応答不能に巻き込まれないようにする ● 下流の負荷を減らし、回復余地を作る 動的な状態遷移を持つのがポイント 

17 Circuit Breaker: 遷移条件をどう設計するか？ ● 何を失敗とみなすか？ ○ タイムアウト率 ○ エラー率 ○ 連続失敗 ● しきい値をどう決めるか？ ○ 「このくらい失敗しているなら全失敗したほうがまし」なレベル ○ 率なら、最低サンプル数・Time-windowを定義してノイズを減らす ● フラッピングを防ぐには？ ○ 失敗3回でOpen, 5回連続成功でCloseのように条件に差をつける（＝ヒス テリシス） 

18 Load Shedding: リクエストを拒否し、負荷を下げる 自分自身が過負荷な状態にあることを判断した際 に、リクエストの受け入れを拒否することで負荷を下 げる働きをする。Circuit Breakerが呼び出し側で機 能するのに対しLoad Sheddingは呼び出される側 で機能する点が大きな違い 発表者個人の感覚では、Load Sheddingよりも Circuit Breakerのほうが使いやすい 気はする ● CBは具体的な過負荷の想定をせず使える ● CBはnetworkの問題も含めカバーできる 

19 Graceful Degradation: UXを犠牲にコア体験を守る エラー・高負荷時に、レスポンスの品質を落とすこと でユーザーにとっての本質的な価値提供を続けられ るようにする。高負荷時に「何もしない」選択肢を取れ るので、ある意味最強。Circuit Breakerなどの他パ ターンとの相性もいい 技術的判断では完結しないところが難しいポイント。 何がユーザーにとってのコア体験で、何が犠牲にして いいものなのかのビジネス判断を要する 

20 Graceful Degradation: 設計のポイント ● コア価値とは何か？ ● 何なら落としてもいいか？ ○ 機能を落とす : e.g. お勧めを表示しない ○ 品質を落とす : e.g. ページネーションの総ページ数を出さない ○ 古いデータを使う (SWR): キャッシュ済みの値を暫定値として使用 ○ 非同期で処理する : キューに逃がして後で処理する ○ 代替手段へフォールバック : e.g. 別の決済手段を案内する ● 何によってトリガーするか ○ エラー・リソース利用量・Circuit Breaker状態など ● ユーザーへの通知方法（しない選択も含め） ● Observabilityをどう確保するか 

21 分散システム、なんですぐ死んでしまうん？ アジェンダ レジリエンスパターンの紹介と分析 実装戦略: Service Mesh vs アプリケーションライブラリ メルカリにおけるレジリエンス実践 2. 3. 4. 1. まとめ 5. Timeout, Retry, Request Heading, Circuit Breaker, Load Shedding, Graceful Degradation 

22 実装戦略: Service Mesh vs ライブラリ レジリエンスパターンをうまく機能させるために欲しい要件は次の通り: ● 一貫性: システム全体に一様に適用でき、認知負荷を上げない ● 安全なデフォルト : 雑に入れても壊れにくい ● Observability: 保護手段が発動した際に一目でわかる 大きく２つの実装方法が考えられる: ● Service Mesh: ポリシーの一括適用・Observabilityに優れている ● アプリケーションライブラリ : 自由度が高い、Meshなしでも使える Meshが統制を効かせやすく、有力な選択肢 。組織や環境の制約を踏まえ、Mesh / Library / 両方のいずれかを選び、単一のおすすめ手段を確立するべき 

23 実装戦略: Meshの実装イメージ IstioでいうとこういったVirtual Service / Destination Ruleを設定するイメージ。 組織として「おすすめのデフォルト」と「変えてよい範囲」を決めることが大事で、 Helm/KustomizeやPolicy as Codeによってそれらのルールから逸脱しないこと を担保する apiVersion: networking.istio.io/v1 kind: VirtualService ... # timeout + retry timeout: 2s retries: attempts: 3 perTryTimeout: 500ms retryOn: 5xx,deadline-exceeded apiVersion: networking.istio.io/v1 kind: DestinationRule ... # インスタンス単位の自動隔離 / CBに近い効果 outlierDetection: consecutive5xxErrors: 5 interval: 5s baseEjectionTime: 30s 

24 実装戦略: ライブラリの実装イメージ 言語によっては、複数のパターンを提供するライブラリがあるのでそれを使うと統制し やすい（例: Java - Resilience4j）。そうでない言語の場合は複数のライブラリを組 み合わせる必要があり、それらのライブラリをwrapするなどなんらかの一貫性・統制 を確保する手段が必要。以下はGoにおけるコード例 func newConn(addr string) (*grpc.ClientConn, error) { retryOpts := []grpc_retry.CallOption{ grpc_retry.WithMax(3), grpc_retry.WithPerRetryTimeout(500 * time.Millisecond), grpc_retry.WithBackoff( grpc_retry.BackoffExponential(100 * time.Millisecond)), grpc_retry.WithCodes(codes.Unavailable, codes.DeadlineExceeded), } ... func New() *gobreaker.CircuitBreaker { st := gobreaker.Settings{ Name: "downstream-x", MaxRequests: 5, // half-openで通す試行数 Interval: 30 * time.Second, Timeout: 10 * time.Second, ReadyToTrip: func(counts gobreaker.Counts) bool { ... }, IsSuccessful: func(err error) bool { ... }, } return gobreaker.NewCircuitBreaker(st) } 

25 分散システム、なんですぐ死んでしまうん？ アジェンダ レジリエンスパターンの紹介と分析 実装戦略: Service Mesh vs アプリケーションライブラリ メルカリにおけるレジリエンス実践 2. 3. 4. 1. まとめ 5. Timeout, Retry, Request Heading, Circuit Breaker, Load Shedding, Graceful Degradation 

26 メルカリにおけるレジリエンス実践 : ケーススタディ 「ランキング表示」のための読み取りがキャッシュ更新のタイミ ングで一斉に発生し、DBが高負荷状態に。結果として、複数 の機能がまとめて不安定化。オークションタブが開けない・オー クション出品ができない状態へ DB過負荷によりオークションが機能停止 

27 この障害とレジリエンスパターンとの関わり ● ✅ Graceful Degradation: 効いた ○ 商品詳細画面側で、オークション情報を落と すことで通常出品された商品の閲覧を機能 させ続けることができた ● ❌ Timeout: 入ってなかった ○ ランキング生成のSQLクエリに実行時間上 限がなく、重いクエリが走り続けた ● ❌ Circuit Breaker: 入ってなかった ○ 過負荷時にリクエスト流入を止める手段がな く、長時間にわたり過負荷が継続 ➡ パターンはセットで効かせる設計が大事 

28 メルカリにおけるレジリエンスの現在地と今後 メルカリにおいてもこういったレジリエンスパターンの実装例は多くあり、広く活用され ている状態。ただし、それぞれがマイクロサービスやチームによっての個別最適で 入っており、全体的な統制は取れていない。それにより ● 局所最適化 : パターン同士の連携が弱く、組み合わせることで問題発生 ● 不安全な設定 : Retry Stormを誘発、不用意に開くCB ● Observability不足: CBの発動に気づかず障害復旧が遅れる といった課題を持っている。それらに対処するため、レジリエンス設計を標準化し、 Platformの機能の一部として広く開発者に提供することで課題を克服する取り組み が進行しつつある 

29 分散システム、なんですぐ死んでしまうん？ アジェンダ レジリエンスパターンの紹介と分析 実装戦略: Service Mesh vs アプリケーションライブラリ メルカリにおけるレジリエンス実践 2. 3. 4. 1. まとめ 5. Timeout, Retry, Request Heading, Circuit Breaker, Load Shedding, Graceful Degradation 

30 まとめ ● 分散システムは死にやすい。カスケード障害を防ぐ仕組みが必須 ● SRE本にあるようなレジリエンスパターンは我々にとっても有用 ● レジリエンスパターンはトレードオフを理解して使おう ● 実装初手はService Meshから。必要にあわせライブラリを足していく ● 全体最適には統一されたおすすめ手段・標準化が必須 レジリエンスパターンを使って あなたの分散システムを もっと堅牢にしていこう！ 

31 PR: メルカリでは SRE・DBREを絶賛募集中です！ ご清聴ありがとうございました ✨ 少しでもご興味のある方は お気軽に登壇者やスポンサー ブースまでお声がけください !!! Software Engineer (Site reliability) - Mercari Database Reliability Engineer (DBRE) - Mercari Software Engineer (Site Reliability) - Mercari Crossborder