Multi AZとOCIの考えるFault Domainの可用性の違いって何？

ksk_240
OCIは他のハイパースケーラーに引けを取らない素晴らしいクラウドサービスです！

■プロフィール

・OCI歴約6年
・金融業界向けにOCI導入を鋭意推進中！

初めに

昨今、特にエンタープライズ領域でOCIの社会的な認知度が高まってきている中、OCIとして独自のDCデプロイメントの考え方であるFault Domain(FD)について興味や懸念をもってお客様から説明を求められるケースが増えています。そんな中ここでは他のHyperscalerでは当たり前であるAvailability Zone(AZ)との考え方の違いとケースに応じた使い分けについて私見で語りたいと思います。

そもそもFault Domain（FD）って何？

Fault DomainとはOCI独自の構成単位でAD内のハードウェアやインフラのセットにしたものです。
1つのAD内は必ず3つのFDの組み合わせで構成されています。
言い換えるとFDは、同一のAvailability Domain(AD)内における物理的障害や計画メンテナンスの影響を局所的に抑えるための論理的な分割単位です。疑似的に1DC内にAZを3つ持ってます。
ところで、ご存じの方も多いと思いますが、実は日本のリージョン(東京/大阪)はシングルAD構成であり今後世界で展開される予定のリージョンも基本的にはシングルADでのデプロイメントになると推測します。
※現在のマルチAD構成のリージョン（us-ashburn-1/us-phoenix-1/uk-london-1/eu-frankfurt-1）2026年1月時点

他社クラウドにおける主なデータセンター障害の歴史

これまでに起きたPublic Cloudにおける代表的な大規模障害の例を以下に紹介します。 （チャッピーに聞いてみました。）

• AWS
  2017年：Amazon S3（米国リージョン）障害。S3依存サービスが連鎖的に影響。
  2020年：Amazon Kinesis（us-east-1）起点でCloudWatch等に波及、広範なサービス影響。
  2021年：ネットワーク／制御プレーン関連の不具合で複数サービスに影響。
• Microsoft Azure
  2018年：Azure ADの認証障害でAzure/Office 365を含む広範な影響。
  2020年：DNS/ネットワーク関連障害により多数サービスで断続的影響。
• Google Cloud (GCP)
  2019年：ネットワーク／ルーティング障害で複数プロダクトに広範な影響。
  2020年：認証基盤やストレージ関連の不具合が一部リージョンで大きく影響（報道・公開RCA参照）。
• Oracle Cloud Infrastructure (OCI)
  2023年：電力設備の障害(UK Southリージョン)。一部OCIサービス停止・性能劣化

これらの障害は主にHW/NW/電源装置などの一部の物理障害に起因したものと推測され、Multi AZであったことにより防げたものではないと考えられます。むしろこのレベルのHW障害であればFDの冗長化構成を組んでいればMulti AZと同等の可用性は十分担保できるのでは？と思っています。（AZごとダウンしたという話は聞いたことある？？？）

Fault Domainのよいところ

私がFDのとても良いと考えるポイントをいくつか上げさせてもらうと以下のような感じかなと思います。

• 同一AD内でより可用性の高い構成が組める。
  　→Oracle RACなどOracle DBの非常に重要なエンタープライズワークロードを支える技術を簡単に持ち込むことができます！
• 同一AD内ですべてのOCIリソースを配置できるのでネットワークレイテンシー低下の心配がない。
  　→同じDC内でのネットワーク通信となるため非常に高速、かつリージョン間通信が発生しないため余計な通信コストが係りません！
• FDを可用性モデルの基本とすることでDCを小さなフットプリントから構築できる。
  　→OCIはDedicated Region Cloud@Customerのようにお客様データセンター内へOCIサービスを持ち込むような小規模なものから大規模なMulti ADリージョンまで様々な規模でのDCのプロビジョニングが可能です。これによって需要に応じた最適化されたDC構築が可能となりOCIが低コストにCloudサービスを提供できることと加速度的にリージョ数が増えている一因になっています。（一部推測。。。）

まとめ

ここまで私の私見と思い込みでFDへの思いを熱く語ってきましたが、皆さんどうでしょう？本当にMulti AZが当たり前と何も疑問を持たずに使ってきたことに違和感を感じていただけましたでしょうか？

ただ私もMulti AZを完全否定するわけではなく、いろいろな要件のトレードオフとしてデプロイメントモデルの考え方を今一度見直してみてる機会の一助になれば幸いです。

パターン	対策	コスト	柔軟性	分離性	可用性	主な用途
マルチFD	機械障害対策	◎	〇	△	△	シングルAD内でのOracle MAA構成
マルチAZ	サイト障害対策	△	〇	△	〇	リージョン内での可用性構成
マルチリージョン	広域障害対策	×	△	◎	◎	高可用性エンタープライズワークロードのDR構成