FIB（Fault Isolation Boundary）とは？
久々の投稿になりますが、最近よく耳にするコントロールプレーン・データプレーンの考え方の根本思想かつ、AWSにおける重要な設計思想のひとつである FIB（Fault Isolation Boundary：障害分離境界） について紹介します。
はじめに
クラウドアーキテクチャを設計する際に、
「どこまでが同時に壊れうるのか？」を意識したことはあるでしょうか。
この問いに対して、AWSでは FIB（障害分離境界） という考え方で整理されています。
本記事では、AWSのホワイトペーパー「AWS 障害分離境界」をベースに、FIBの基本的な考え方と、その重要性について整理していきます。
FIBとは何か？
FIB（Fault Isolation Boundary）とは、
障害が発生した際に、その影響が閉じ込められる範囲
を指します。
AWSでは、サービスやインフラを設計する段階から、
- 障害が発生しても影響が境界を越えて広がらないこと
を前提とした設計が徹底されています。
言い換えると、FIBとは
「どの単位で壊れるように設計されているか」 を示す考え方です。
AWSにおける代表的なFIB
AWSでは、複数のレイヤーでFIBが定義されています。
1. アベイラビリティゾーン（AZ）
AZは、電源・ネットワーク・データセンター単位で分離された構成要素です。
AWSは、
- 1つのAZで発生した障害が、他のAZに波及しない
ことを前提に設計しています。
そのため、
- マルチAZ構成
- AZを跨いだ冗長化
といった設計は、FIBを活用した代表的なパターンと言えます。
2. リージョン
リージョンは、地理的にも論理的にも独立した単位です。
通常、
- あるリージョンの障害が、別のリージョンに影響することはない
ように設計されています。
このため、
- ディザスタリカバリ（DR）
- マルチリージョン構成
においては、リージョン自体が大きなFIBとして扱われます。
3. コントロールプレーンとデータプレーン
多くのAWSサービスは、以下の2つに分離されています。
- コントロールプレーン：リソースの作成・変更・削除（CRUD）
- データプレーン：実際の処理や通信
ここで重要なのは、
- コントロールプレーンに障害が発生しても、データプレーンは継続して動作する
という設計が取られている点です。
この考え方により、AWSは「静的安定性（Static Stability）」を実現しています。
なぜFIBを意識する必要があるのか？
実際のシステム障害では、
- 想定していなかった依存関係
- FIBをまたいだ設計ミス
によって、本来は局所的に収まるはずの障害が広がってしまうケースが少なくありません。
例えば、
- フェイルオーバー時に、IAMやRoute 53などのコントロールプレーン操作に依存している
- 障害時に新規リソースの作成が前提となっている
といった設計は、FIBの考え方を十分に考慮できていない典型例です。
FIBを活かす設計のポイント
AWSのホワイトペーパーでも繰り返し強調されているポイントを整理すると、次の通りです。
1. リカバリ時に「変更」を前提としない
障害時に、
- 新しく作る
- 設定を変更する
といった処理に依存する設計は不安定になりがちです。
事前に必要なリソースを準備しておくことで、
FIBの内部で復旧を完結させることが重要です。
2. データプレーン中心で設計する
コントロールプレーンは、
- 障害時には利用できない可能性がある
という前提で設計すべきです。
そのため、
- データプレーンのみでサービス継続・復旧できる構成
を目指すことが求められます。
3. FIBをまたぐ依存関係を減らす
以下のような境界をまたぐ依存は、障害の波及リスクを高めます。
- AZ間の依存
- リージョン間の依存
- グローバルサービスへの依存
これらを完全に排除することは難しいですが、
影響範囲を理解したうえで設計すること が重要です。
まとめ
FIB（障害分離境界）は、
- AWSにおける可用性設計の根幹となる考え方であり
- 高可用・高信頼なアーキテクチャを実現するための前提知識
と言えます。
「なぜAWSは高い可用性を実現できるのか？」
その背景には、FIBを前提とした設計思想があります。
単にマルチAZ構成を採用するだけでなく、
どこまでが同時に壊れうるのか
を明確に説明できることが、
クラウドアーキテクトに求められる重要なスキルではないでしょうか。