# ブラスト半径(Blast Radius) ## 定義 あるコンポーネントの障害・変更・メンテナンスが**波及する影響範囲**を表す概念。もとは爆発物の被害推定用語だが、分散システム・SRE の文脈では「あるサービスが停止したとき、どのサービスが影響を受けるか」の範囲を指す。 ## 重要性 マイクロサービスアーキテクチャではサービス間の依存が複雑に絡み合うため、単純なサービス停止でも予期しない広範な影響が生じる。ブラスト半径を事前に把握することで: 1. **メンテナンス計画**: 影響を受けるサービスのオーナーへ事前通知 2. **障害優先度付け**: 影響範囲の大きい障害を優先対応 3. **アーキテクチャ改善**: 依存の集中するサービスの特定と分離 ## 推定方法 [[リアルタイム依存性マップ]](または[[サービストポロジ]])上で対象サービスを起点に**下流ノードの推移閉包**を取ることで推定できる。マルチホップ探索が必要なため高速グラフ DB が鍵となる。 ## 実装例 - [[Netflix]] Service Topology: [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]] — gRPC API とカスタムグラフ DB でサブ秒のブラスト半径クエリを実現 - [[Netflix]] Chaos Automation Platform(ChAP): 制御グループと可変グループへの分割、シャドートラフィック、100 ドルを超える高額トランザクションの除外、失敗リクエストの自動リトライという技法で実験の影響範囲を局所化する(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] §3.3.5) - [[LinkedIn]] [[LinkedOut]]: リクエストレベル(単一 API コール・特定ユーザコンテキスト)の粒度でクライアント側の故障シミュレーションを行い、対象母集団を同意した従業員・サービスアカウント・合成ユーザへ差し替えることでブラスト半径をゼロに近づける(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]] §7.4) ## 横断的知見 - **Netflix 社内で「ブラスト半径」概念は、事後の推定対象(Service Topology)と事前の実験設計原則(カオスエンジニアリング)という2つの独立した文脈で使われている**: [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]] はブラスト半径を「あるサービスが停止したときに影響を受けるサービスの範囲」として障害後・変更前に**推定する対象**として扱う。一方 [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] の [[Casey Rosenthal]](元 Netflix カオスチーム責任者)は「影響範囲を局所化する」をカオス実験の5原則の1つとして位置づけ、本番トラフィックの一部だけを対象範囲に設定することで検証の安全性を高め、精度向上→実験数増加という好循環を生み出す**事前の実験設計変数**として扱う。同じ企業・同じ概念が「測定対象(観測)」と「制御変数(実験設計)」という異なる役割で独立に登場しており、両者を組み合わせると「ブラスト半径を正確に推定できるほど、カオス実験で許容できる対象範囲を狭く精密に設定でき、実験数を安全に増やせる」という関係が見える。(Source: [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]], [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.7) - **SREの探求14章が抽象的に述べる「影響範囲局所化の好循環」を、3章はNetflix自身のChAP実装として具体化し、しかも局所化それ自体がシグナル検出を強化する副次効果を持つと明言する**: SREの探求14章のRosenthalは「検証精度が高まるほど並行実行数を増やせる好循環が生まれる」と抽象的に述べるにとどまるが(既出)、『カオスエンジニアリング ― 回復力のあるシステムの実践』3章は同じ原則を、制御グループ/可変グループへの分割・シャドートラフィック・100ドルを超える高額トランザクションの除外・失敗リクエストの自動リトライというChaos Automation Platform(ChAP)の具体的技法として記述する。さらに3章は「小さな可変グループのメトリクスは、小さな制御グループのものに比べて格段に目立つ」ため、影響範囲の局所化がブラスト半径を縮小するだけでなく信号検出そのものを強化する副次効果を持つと明言しており、これは Netflix Service Topology(gRPC API とグラフ DB によるブラスト半径のサブ秒推定)の存在理由——正確な推定があってこそ、局所化と検出強化の好循環が成立する——を裏付ける具体的な実装証拠になる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] §3.3.5, [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.7, [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]]) - **LinkedInの事例(7章)は、Netflixが体現する「量的な範囲の縮小」(ChAP・Service Topology)とは異なる、「対象母集団の質的な差し替え」によるブラスト半径ゼロ化という第三のパターンを示す**: 本ページはこれまで、ブラスト半径の縮小を「対象範囲を正確に推定し、狭く精密に設定する」(Netflix Service Topology・ChAP、既出)という一貫した量的枠組みで捉えてきた。[[LinkedIn]] の7章([[Logan Rosen]] 著)が示す [[LinkedOut]] のブラウザエクステンションは、これとは異なる戦略を採る——実メンバーのトラフィックのうち小さな部分集合を対象にするのではなく、対象母集団そのものを「同意した従業員」へ差し替えることで、影響範囲を「本質的にないに等しい」水準まで縮小する。自動実験も同様にサービスアカウント・合成ユーザという実メンバーでない母集団を対象にする。両者を合わせると、ブラスト半径局所化には「対象範囲を正確に推定してどれだけ狭くするか」(量的縮小、Netflix)と「そもそも誰を対象にするか」(質的な母集団の差し替え、LinkedIn)という独立した2つの設計軸があることが分かる。前者はブラスト半径の推定精度に依存するのに対し、後者は推定精度に関わらずゼロに近い保証を与えられる代わりに、実メンバーへの本番影響という検証したい対象そのものを犠牲にする。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]] §7.4.3–§7.4.4, [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]], [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.7) - **BSRS ch.8 の役割・場所・時間分離は、Netflix/LinkedIn が前提とする「局所化可能なアーキテクチャ」そのものを設計する、本ページ既出の知見より一段手前の設計問題を扱う**: 本ページがこれまで集約した知見はいずれも、既に存在するサービストポロジやリクエストルーティングの仕組みを使って、事後的または実験時にブラスト半径を「どれだけ狭く設定するか」(量的縮小、Netflix ChAP)、「誰を対象にするか」(質的な母集団の差し替え、LinkedIn)という、局所化の**運用**を扱ってきた。*Building Secure and Reliable Systems* 第8章の「影響範囲の制御」は、これらの局所化が成立するための**前提条件**——そもそもシステムが役割・場所・時間という独立した軸で区画化されているかどうか——を扱う。役割ごとに異なるサービスアカウントで実行されていなければ、1つのジョブの侵害はそのサービスアカウントが持つデータ全体に及ぶため、Netflix Service Topology のようにブラスト半径を精密に推定できたとしても、推定される範囲そのものが構造的に大きいままになる。両者を合わせると、ブラスト半径の縮小には「アーキテクチャを区画化する(設計時、BSRS ch.8)」→「区画化された構造の中でどこまで局所化するか決める(運用・実験時、Netflix/LinkedIn)」という順序依存の2段階があることが分かる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] ch.8 §Controlling the Blast Radius, [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]], [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]]) - **BSRS ch.8 は「不完全な区画化にも価値がある」と明言し、本ページが扱う量的縮小・質的差し替えのいずれとも異なる第三の価値づけを与える**: 本ページの局所化はいずれも、ブラスト半径を可能な限り小さく・ゼロに近づけることを目的とする。BSRS ch.8 はこれとは異なる角度から、境界を完全にカバーしきれない不完全なコンパートメントであっても、攻撃者がその境界を突破しようとする過程で失策を犯し、検知の機会を生むという価値を挙げる。これは「区画の大きさをどこまで縮小できるか」ではなく「区画が完全でなくても検知までの時間を稼げるか」という、局所化の効果を空間的な範囲でなく時間的な猶予として捉え直す視点であり、既存の Netflix/LinkedIn 事例には無い評価軸を加える。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] ch.8 §Controlling the Blast Radius) ## 未解決の問い - BSRS ch.8 の役割・場所・時間分離によって区画化されたアーキテクチャの上で、Netflix Service Topology のようなブラスト半径推定基盤を構築すると、推定の粒度や精度はどう変わるか。区画化されていないアーキテクチャに比べて推定コストが下がるという仮説は本ページの知見からは導けるが、実証した一次資料はまだ無い。 - Netflix の Service Topology(リアルタイム依存性マップ)は、カオスエンジニアリングの実験設計(対象範囲の設定)に実際に活用されているか。ブラスト半径の推定値を実験前の対象範囲選定に使うフィードバックループは存在するか。(Source: [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]], [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]]) - 3章のChAPが用いる「100ドルを超える高額トランザクションの除外」という基準は、Netflix固有のビジネス上の閾値である。ブラスト半径の局所化における金銭的・業務的な重大度の閾値は、他組織(例: Bradesco のような金融機関)ではどのような基準に置き換わるか。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] §3.3.5) - LinkedIn(7章)の「対象母集団の差し替え」によるブラスト半径ゼロ化は、Netflix Service Topology のようなブラスト半径推定インフラを必要としない。しかし、対象母集団を実メンバーへ拡大する段階(7章が将来課題として保留する部分)に進む場合、Netflix同様のリアルタイム依存性マップによる推定は必須になるのか、それとも LiX のセレクタによる粒度指定だけで十分なのか。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]] §7.4.2, [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]]) ## 関連 - [[影響範囲の制御]] — 役割・場所・時間の分離による、局所化が成立するための設計時の前提条件 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] — 区画化(コンパートメント化)というアーキテクチャ設計の観点からブラスト半径を論じる一次資料 - [[サービストポロジ]] / [[リアルタイム依存性マップ]] — ブラスト半径を推定する基盤 - [[カオスエンジニアリング]] — 「影響範囲を局所化する」原則としてブラスト半径を実験設計変数に使う - [[フォールトトレランス]] — ブラスト半径を小さくする設計上の対策 - [[Casey Rosenthal]] — カオス実験における影響範囲局所化の原則を提示した Netflix 元カオスチーム責任者 - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] — 「影響範囲を局所化する」原則の具体的な工学的実装(ChAP)を記述する一次資料 - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]] — リクエストレベルの故障注入と対象母集団の差し替えによるブラスト半径ゼロ化を記述する一次資料 - [[LinkedOut]] / [[LiX]] — LinkedIn のリクエストレベル故障注入・ターゲティングフレームワーク - [[LinkedIn]] — 本事例の実施組織 ## 出典 - [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]] - [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] — Casey Rosenthal, 「初めにカオスありき」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 14章(§14.7) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] — Casey Rosenthal, Nora Jones, 「原則の全体像」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 3章(§3.3.5) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]] — Logan Rosen, 「LinkedIn メンバーに対して配慮すること」, 同書, 7章(§7.4) - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 8.