ブラスト半径：実際に必要な復旧戦略を判断する方法
すべてのインフラ変更にはリスクが伴います。小さなリスクもあれば、ビジネス全体を停止させるものもあります。問題は変更を行うかどうかではありません。変更は避けられません。問題は、何かがうまくいかなかったときに、どれだけ復旧に備えているかです。
チームが復旧計画について議論するとき、会話は往々にして技術的な選択肢に直行します。ロールバックすべきか？スナップショットから復元すべきか？別の環境にフェイルオーバーすべきか？しかし、復旧戦略を選ぶ前に、もっと基本的な問いに答える必要があります。この変更が失敗した場合、どれほど深刻な事態になるのか？
ここで登場するのが「ブラスト半径」です。
ブラスト半径の実際の意味
ブラスト半径は、爆発物工学から借用したシンプルな概念です。インフラにおいては、変更が失敗したときに被害がどの程度広がるかを表します。ブラスト半径が広いほど、影響を受けるリソース、ユーザー、システムが多くなります。狭いほど、復旧は容易になります。
2つのシナリオを考えてみましょう。
1つ目は、チームが単一の開発用データベースインスタンスのセキュリティグループルールを更新する場合です。変更が間違っていれば、開発チームはしばらくそのデータベースにアクセスできなくなります。面倒ですが、影響は限定的です。復旧計画は、古い設定を再適用するだけで済みます。
2つ目は、チームが本番トラフィックをすべて処理するメインのロードバランサーを変更する場合です。その変更が壊れた場合、すべてのユーザーがアクセスできなくなります。カスタマーサポートは問い合わせで溢れ、営業は停止し、会社の評判は傷つきます。ブラスト半径は計り知れません。
同じ「設定を変更する」というアクションでも、結果はまったく異なります。
変更前にブラスト半径を見積もる方法
インフラに触れる前に、自問してください。この変更が失敗した場合、誰が、あるいは何が影響を受けるのか？
答えは通常、いくつかのカテゴリに分類されます。
- 1台のサーバーまたはコンテナ
- 1つの環境（ステージングや単一のアベイラビリティゾーンなど）
- 1つのリージョン
- インフラ全体
一部のリソースは、本質的にブラスト半径が狭いです。個々のインスタンス、コンテナ、サーバーレス関数は、通常、システムのごく一部にしか影響しません。1つのインスタンスが停止しても、他のインスタンスがトラフィックを処理し続けます。復旧は簡単です。
一方、本質的にブラスト半径が広いリソースもあります。DNSゾーン、プライマリロードバランサー、本番データベース、VPCやサブネットの設定、サービスメッシュのコントロールプレーンなどは、1つのミスで複数のシステムを麻痺させる可能性があります。これらのリソースには、特別な注意、より徹底した復旧計画、そして多くの場合、より厳格な承認プロセスが必要です。
ブラスト半径は固定ではない——設計によって小さくできる
多くのチームが見逃している点があります。ブラスト半径は単に見積もるものではなく、設計によって積極的に削減できるものだということです。
すべてのトラフィックを処理する1つの巨大なロードバランサーではなく、システムの特定の部分をそれぞれ処理する複数のロードバランサーに分割します。本番データベースの設定を直接変更するのではなく、まず1つのレプリカで変更をテストします。新しいバージョンを全ユーザーに一度にデプロイするのではなく、トラフィックの1%から始めるカナリアデプロイメントを使用します。
これらは単なるデプロイ戦略ではありません。ブラスト半径を削減するテクニックです。変更が影響を与えるユーザーやシステムの数を制限するたびに、復旧がよりシンプルかつ迅速になります。
復旧戦略とブラスト半径のマッチング
ブラスト半径を理解すれば、復旧戦略の選択が明確になります。実際の関係は以下の通りです。
以下は、ブラスト半径に適した復旧戦略を選択するための判断ツリーです。
ブラスト半径が狭い場合（単一インスタンス、コンテナ、関数）： 古い状態を再適用するだけで十分なことがほとんどです。「元に戻して再デプロイ」以上の正式な復旧計画は必要ないかもしれません。
ブラスト半径が中程度の場合（1つの環境、1つのリージョン、または関連するリソースのグループ）： スナップショット復元またはステートファイルのロールバックがより適切です。影響範囲が広く、より多くの人が影響を受けるため、文書化された手順が必要です。
ブラスト半径が広い場合（本番データベース、メインロードバランサー、DNS、ネットワーク設定）： セカンダリ環境へのフェイルオーバーが必要になる可能性が高いです。復旧計画はリハーサルされ、テストされている必要があります。複数のチームが自分の役割を把握している必要があります。変更を行う前であっても、承認ゲートが必要になる場合があります。
多くのチームが犯す間違いは、すべてに同じ復旧アプローチを使用することです。DNS変更をコンテナイメージの更新と同じように扱います。それは、マッチ棒とガソリン火災に同じ消火器を使うようなものです。
ブラスト半径はコミュニケーションツールでもある
ブラスト半径の見積もりは、純粋に技術的なものだけではありません。誰がその変更について知る必要があり、誰が承認する必要があるかという点も含みます。
ブラスト半径が狭い変更は、チームチャットでの簡単な通知で済むかもしれません。ブラスト半径が広い変更には、運用、セキュリティ、プロダクトマネージャー、場合によってはエグゼクティブリーダーシップとの調整が必要です。ブラスト半径が広いほど、変更が行われる前により多くのステークホルダーが情報を共有し、関与する必要があります。
これは官僚主義の問題ではありません。障害の影響を受ける人々が、変更の計画方法と復旧の進め方について発言権を持つようにするためです。
次のインフラ変更前の実践的チェックリスト
インフラ変更を適用する前に、この簡単なチェックリストを実行してください。
- この変更が失敗した場合のブラスト半径は？
- 影響を受けるユーザー、システム、ビジネスプロセスは？
- ブラスト半径は許容範囲内か、それとも設計によって削減できるか？
- このブラスト半径に合った復旧計画があるか？
- 適切なステークホルダーに情報が伝えられ、関与しているか？
- 復旧計画はテストされ、文書化されているか（誰かの頭の中だけではないか）？
これらの質問に明確に答えられない場合は、まだ変更を行わないでください。リスクを理解し、対応を準備するために時間をかけてください。
まとめ
ブラスト半径は理論上の概念ではありません。どれだけ注意を払う必要があるか、どの復旧戦略が実際に意味を持つかを判断するための実用的なツールです。すべてのインフラ変更の前に、被害がどの程度広がるかを自問してください。そして、それに応じて準備してください。1つのコンテナに影響する変更には、すべてのユーザーに影響する変更と同じ復旧計画は必要ありません。それらを区別して扱うことで、インフラはより安全になります。