AWS の障害分離境界について学べるホワイトペーパー AWS Fault Isolation Boundaries を読んでみた

コンバンハ、千葉（幸）です。

Jeff Barr 氏のツイートで、新たな AWS ホワイトペーパー AWS Fault Isolation Boundaries が紹介されていました。

New - #AWS Fault Isolation Boundaries - https://t.co/M9ulCD3KI9 (PDF or HTML)

"Don't let the boring title fool you" -- @QuinnyPig pic.twitter.com/FKxpZxXISh

— Jeff Barr ☁️ (@ ? ) ? (@jeffbarr) November 18, 2022

▲溢れ出るインパクト。「つまらないタイトルに騙されるな」！

ナナメ読みをしていくとわたしが大好きな AWS IAM のコントロール・データプレーンについても取り上げられていたので、これはじっくり読むしかない、となりました。

（画像はホワイトペーパーより引用）

内容をかいつまんでご紹介します。

AWS Fault Isolation Boundaries

AWS Fault Isolation Boundaries は 2022/11/16 に初版がリリースされたホワイトペーパーです。

大きく分けて以下の章からなります。

• AWS インフラストラクチャ
• AWS サービスタイプ

まずはリージョンやアベイラビリティゾーンといった AWS インフラの考え方が紹介され、それに応じたサービスの障害影響範囲が取り上げられます。

個人的に特に学びがあったなと感じるのは以下ポイントです。

• リージョンより上位のパーティションという考え方がある
• 統計的にデータプレーンよりコントロールプレーンの障害が起こる可能性が高い
• データプレーンはコントロールプレーンに依存関係を持たないよう構成されている
• 何をもってグローバルサービスと呼ぶかの定義

1. AWS インフラストラクチャ

この章で取り上げられるのは以下です。

• アベイラビリティゾーン
• リージョン
• AWS ローカルゾーン
• AWS Outposts
• PoP（Points of presence）
• パーティション
• コントロールプレーンとデータプレーン
• 静的安定性

太字にしている部分をピックアップします。

アベイラビリティゾーン

改めてアベイラビリティゾーン（AZ）とは何ぞや、というのが分かりやすくまとまっています。

（画像はホワイトペーパーより引用）

• アベイラビリティゾーンは AWS リージョン内で独立した 1 つ以上のデータセンターからなる
• アベイラビリティゾーンは最大約 100 km 離れており、各種災害の影響を同時に受けないよう設計されている
• 発電機、冷却装置などの一般的な障害点はアベイラビリティゾーンで共有されていない
• リージョン内のアベイラビリティゾーンは専用メトロファイバーを介して高帯域幅で低レイテンシーで相互接続されている
• AWS がピアする複数の Tier-1 インターネットプロバイダの 2 つのトランジットセンターを通じてインターネットに接続する

これらの機能からなるアベイラビリティゾーンの独立性は特に AZI （Availability Zone Independence）と呼ばれます。

パーティション

複数のリージョンをグルーピングする考え方としてパーティションがあります。パーティションには以下 3 種があり、各リージョンはどれか 1 つのパーティションにのみ属します。

• aws：商用リージョンが所属
• aws-cn：中国リージョンが所属
• aws-us-gov：GovCloud リージョンが所属

パーティションは ARN の一部に含まれます。

IAM リソースはパーティションごとに分離されているほか、各種クロスリージョン機能（S3 のクロスリージョンレプリケートなど）は同一パーティション内でのみ有効になっています。

パーティションを跨いで IAM の認証・認可を行なったり、クロスリージョン機能を使用したりはできません。

コントロールプレーンとデータプレーン

ほとんどの AWS サービスではコントロールプレーンとデータプレーンの概念を分けています。

• コントロールプレーン：
  • CRUDL に使用される管理 API を提供する基盤
    • リソースの作成、読み取り/表示、更新、削除、一覧表示
• データプレーン：
  • サービスの主要な機能を提供する基盤

例えば Amazon EC2 で考えると、「インスタンスの起動」「インスタンスタイプの変更」といった API リクエストに対応するのがコントロールプレーンで、EC2 インスタンスそのものを提供するのがデータプレーンです。

コントロールプレーンとデータプレーンは分離されており、データプレーンの方が単純化されています。そのため、統計的にデータプレーンの方が障害発生の可能性が低くなっています。

静的安定性

静的安定性（static stability）という重要な考え方があります。これは AWS が提供するものでもあり、カスタマー側で考慮すべきものでもあります。

システムが依存関係のある他の要素の障害に影響を受けず、同じ状態を維持し続けること・あるいはそうするためのデザインのことを指します。

例えば先ほどの Amazon EC2 のコントロールプレーンとデータプレーンの関係を考えます。コントロールプレーンへの「新規インスタンスの起動」というアクセスに基づきデータプレーンに EC2 インスタンスがプロビジョニングされますが、以降はコントロールプレーンに依存しません。「インスタンスタイプの変更」といった新たなコントロールプレーンからのデータアクセスが無い限り、データプレーンとしては独立しています。

それにより、コントロールプレーンでの障害（例えば新規 API リクエストを受け付けられない）があったとしてもデータプレーンとしては問題なく稼働し続ける（EC2 インスタンスの稼働自体には影響が出ない）、ということができるようになっています。これが静的安定性の一例です。

この静的安定性をカスタマー側で担保する例としてはマルチ AZ 構成があります。例えば片方の AZ で稼働するインスタンスに障害があった場合、そこから別 AZ に新たなインスタンスをプロビジョニングする、というのは静的安定性に欠けています。

あらかじめ別 AZ にリソースをプロビジョニングしておき、片方の AZ で障害が発生してももう一方の AZ では変わらず稼働を続けられる、というのが静的安定性のある状態です。

2. AWS サービスタイプ

ここまでみてきた AWS インフラストラクチャの境界に基づき、AWS サービスは以下の 3 つにカテゴライズされます。

• ゾーナルサービス
• リージョナルサービス
• グローバルサービス

グローバルサービスはさらに細分化されます。

• パーティションごとに固有のグローバルサービス（パーティションサービス）
• エッジネットワークのグローバルサービス（グローバルエッジネットワークサービス）
• グローバルに依存する単一リージョンのオペレーション

ゾーナルサービス

Amazon EC2 や Amazon EBS といった、作成されるリソースがアベイラビリティゾーンに依存するサービスをゾーナルサービスと呼びます。

ゾーナルサービスにおいてはコントロールプレーンが階層化されています。ゾーンごとのデータプレーンに紐づくコントロールプレーンが存在し、その前段にリージョナルなコントロールプレーンが存在します。

（画像はホワイトペーパーより引用）

先ほど見たように、ゾーナルサービスにおいては特に静的安定性を意識する必要があります。あらかじめ各 AZ に十分なリソースをプロビジョニングしておけば静的安定性が高まりますが、コストとトレードオフになる部分もあります。Auto Scaling によって複数 AZ にまたがってスケールする構成をとっている場合、新たなリソースのプロビジョニングに時間がかかるほかコントロールプレーンに依存することにもなるので静的安定性に欠けることになります。最低限ワークロードの維持に必要となるリソース数を各 AZ に分散して配置しておく、というアプローチがベストプラクティスとされています。

AWS ローカルゾーン や AWS Outposts のデータプレーン

AWS ローカルゾーンや AWS Outposts は、いずれもよりエンドカスタマーに近いロケーションでデータプレーンを提供するサービスです。

ローカルゾーンでは AWS が、Outposts ではカスタマーがデータプレーンの管理に責任を持ちます。

いずれのサービスも、親となるリージョンのコントロールプレーンに依存関係を持ちます。それらで利用するサービスに応じて、ゾーナルコントロールプレーン、リージョナルコントロールプレーンに依存することになります。

リージョナルサービス

複数 AZ へのリソースの配置を AWS 側で管理するものをリージョナルサービスと呼びます。例えば Amazon S3 でバケットを作成する際、カスタマー側ではそのバケットをどの AZ に配置するかを意識する必要がありません。AWS 側で自動的に 3 つ以上の AZ にまたがるように配置するようになっています。 ^*1

マルチ AZ 構成と比較し、マルチリージョン構成をとるのは難易度が高いとされています。AWS で提供されているいくつかのサービスでのクロスリージョンレプリケーションは非同期であり、同期的なものではありません。よって、フェールオーバーを行う際にはデータの損失・不整合をどう吸収するかを考慮する必要があります。

また、アプリケーションの依存関係を減らし、個々のワークロードが独自にフェールオーバーの決定を下せるようにすることが重要、とされています。

グローバルサービス

コントロールプレーン、データプレーンが各リージョンに独立して存在しないサービスのことをグローバルサービスと呼びます。

多くのグローバルサービスでは、コントロールプレーンが単一のリージョンでホストされており、データプレーンがグローバルに分散されています。

グローバルサービスの中でもさらに細分化されます。

• パーティションごとに固有のグローバルサービス（パーティションサービス）
• エッジネットワークのグローバルサービス（グローバルエッジネットワークサービス）
• グローバルに依存する単一リージョンのオペレーション

パーティションサービス

AWS IAM などのグローバルサービスはパーティションごとに固有のコントロールプレーンを持ちます。多くの場合、単一のリージョンでコントロールプレーンがあり、各リージョンにデータプレーンが存在します。一部のグローバルサービスはコントロールプレーンのみが存在し、他のサービスのデータプレーンをコントロールします。

AWS IAM のawsパーティションにおける分散のイメージが以下です。

（画像はホワイトペーパーより引用）

コントロールプレーンで IAM リソースの CRUDL リクエストを受け付け、その内容を各リージョンのデータプレーンにプロパゲートします。データプレーンではその内容に応じて各 AWS サービスへのリクエストの認証・認可を行います。

コントロールプレーンでの障害はデータプレーンに影響を与えませんし ^*2、一部のリージョンのデータプレーンでの障害は他のリージョンのデータプレーンに影響を与えません。

awsパーティションにおけるパーティションサービス・およびそのコントロールプレーンが存在するリージョンの一覧は以下の通りです。

• AWS IAM (us-east-1)
• AWS Organizations (us-east-1)
• AWS Account Management (us-east-1)
• Route 53 Application Recovery Controller (ARC) (us-west-2)
• AWS Network Manager (us-west-2)
• Route 53 Private DNS (us-east-1)

グローバルエッジネットワークサービス

ここで取り上げられるのは以下に該当するサービスです。

• コントロールプレーンがawsパーティション内の単一のリージョンでホストされる
• データプレーンがグローバル PoP インフラでホストされる
  • 一部は AWS リージョンでホストされる場合もある

PoP でホストされたデータプレーンには、パブリックインターネット・別のパーティションも含めた任意の場所からアクセスできます。

awsパーティションにおけるグローバルエッジネットワークサービス・およびそのコントロールプレーンが存在するリージョンの一覧は以下の通りです。

• Route 53 Public DNS (us-east-1)
• Amazon CloudFront (us-east-1)
• AWS WAF Classic for CloudFront (us-east-1)
• AWS WAF for CloudFront (us-east-1)
• Amazon Certificate Manager (ACM) for CloudFront (us-east-1)
• AWS Global Accelerator (AGA) (us-west-2)
• AWS Shield Advanced (us-east-1)

Route 53 は機能によって分類が変わるのが面白いところですね。

グローバルに依存する単一リージョンのオペレーション

最後のカテゴリは「グローバルサービス」と呼ぶのは少し違うかもしれません。

ここで取り上げるのは、ゾーナルあるいはリージョナルサービスの特定のオペレーションが別のリージョンのコントロールプレーンと依存関係にあるケースです。

• Amazon Route 53 に関連するサービスのオペレーション
• Amazon S3 のオペレーション
• Amazon CloudFront に関連するサービスのオペレーション

例えば ELB や RDS のDB インスタンスを作成すると、専用の DNS 名が設定されます。それらは Route 53 で管理されるものであり、Route 53 のコントロールプレーンは us-east-1 リージョンでホストされます。つまり、us-east-1リージョンのコントロールプレーンで障害が発生した場合、 新規の ELB や DB インスタンスの作成が失敗する場合があります。

なお、EC2 インスタンス用の VPC DNS（ip-10-0-10.ec2.internalなどの DNS レコードを管理するもの）は各リージョンに独立して存在しており、Route 53 のコントロールプレーンの影響を受けないとのことです。

また、awsパーティションの Amazon S3 に関しては以下の依存関係があります。

• 一部のオペレーションは us-east-1 に依存関係がある
  • バケットの各種変更オペレーション
  • 作成・削除オペレーション（S3 バケット名のグローバルでの一意性の担保のため）
• Amazon S3 Multi-Region Access Points のコントロールプレーンは us-west-2 のみでホストされ、以下に依存関係を持つ
  • AWS Global Accelerator (AGA) (us-west-2)
  • Amazon Route 53 (us-east-1)
  • Amazon Certificate Manager (ACM) (us-west-2)

そして、us-east-1 の CloudFront のコントロールプレーンに依存するものとして Amazon API Gateway のエッジ最適化 API エンドポイントがあります。

おまけ：単一リージョンのみで展開されるサービス

ここまで見てきたサービスはパーティション内の各リージョンで展開されるものでしたが、中には単一のリージョンでのみ提供されるものもあります。

それらのサービス・あるいはサービス内の特定の機能の一覧は以下ページで取り上げられています。

• Appendix C - Single-Region services - AWS Fault Isolation Boundaries

終わりに

AWS の障害分離境界について学べるホワイトペーパー AWS Fault Isolation Boundaries を読んでみました。

AWS のインフラストラクチャの考え方の紹介から始まり、それらに依存するサービスカテゴリごとの障害分離性が述べられていました。

特にコントロールプレーンとデータプレーンの関係性は興味深かったです。

• データプレーンとコントロールプレーンは分離されている
• データプレーンに比べコントロールプレーンの障害の可能性が高い
• 一部のサービスのオペレーションは他のリージョンのコントロールプレーンに依存する

コントロールプレーンでの障害発生時の復旧作業を考える際、新規のリソースのプロビジョニングといったコントロールプレーンに依存するオペレーションは避けるべきである。あらかじめ必要なリソースを準備しておき、必要時に切り替えることで静的安定性を高めるべし、ということを学びました。

このホワイトペーパーで初めて公開された情報も多々あるように感じましたので、一読することをオススメします。

以上、 チバユキ (@batchicchi) がお送りしました。

脚注