# AWS インフラストラクチャ
このセクションでは、AWS グローバルインフラストラクチャとその障害分離境界について概説します。さらに、AWS のサービスの設計方法における重要な違いであるコントロールプレーンとデータプレーンの概念についても概要を示します。この情報は、障害分離境界とサービスのコントロールプレーンおよびデータプレーンが、次のセクションで説明する AWS のサービスカテゴリにどのように適用されるかを理解するための基礎となります。
**Topics**
+ [アベイラビリティーゾーン](availability-zones.md)
+ [リージョン](regions.md)
+ [AWS Local Zones](aws-local-zones.md)
+ [AWS Outposts](aws-outposts.md)
+ [Point of Presence](points-of-presence.md)
+ [パーティション](partitions.md)
+ [コントロールプレーンとデータプレーン](control-planes-and-data-planes.md)
+ [静的安定性](static-stability.md)
+ [まとめ](summary.md)
# アベイラビリティーゾーン
AWS は世界中の複数のリージョンの 100 以上のアベイラビリティーゾーンを運用しています (最新の状況については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください)。アベイラビリティーゾーンは、AWS リージョン内で独立した冗長な電源設備、ネットワーク、接続を備えた 1 つ以上の個別のデータセンターです。リージョン内のアベイラビリティーゾーン間は、相関する障害を防ぐために意味のある距離として最大 60 マイル (約 100 km) 離れていますが、1 桁ミリ秒のレイテンシーで同期レプリケーションを利用するには十分近い距離にあります。停電、断水、ファイバー断線、地震、火災、竜巻、洪水などの広域災害のシナリオから同時に影響を受けないように設計されています。発電機や冷却装置などの一般的な障害点は、アベイラビリティーゾーン間で共有されず、独立した配電所から受電するように設計されています。AWS がサービスに更新プログラムをデプロイする場合、相関する障害を防ぐために、同じリージョン内の各アベイラビリティーゾーンへのデプロイは時間的に分離されます。
リージョン内のすべてのアベイラビリティーゾーン間は、完全冗長な専用メトロファイバーを介して、高帯域幅、低レイテンシーのネットワークで相互接続されています。リージョン内の各アベイラビリティーゾーンは、2 つのトランジットセンター (ここで AWS は複数の [Tier-1 インターネットプロバイダー](https://en.wikipedia.org/wiki/Tier_1_network)とピアリングします) を経由してインターネットに接続します。詳細については、「[Amazon Web Services の概要](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card)」を参照してください**。
これらの特性により、アベイラビリティーゾーンは互いから強く分離されます。これをアベイラビリティーゾーンの独立性 (AZI) と呼びます。アベイラビリティーゾーンの論理構造とインターネットへの接続を次の図に示します。
![\[この図は、アベイラビリティーゾーンが 1 つ以上の物理データセンターで構成され、これらが相互に、またインターネットに冗長接続されている様子を示しています。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/images/availability-zones.png)
# リージョン
各 AWS リージョンは、1 つの地理的エリア内における、複数の独立した、物理的にも分離されたアベイラビリティーゾーンで構成されています。現在、すべてのリージョンに 3 つ以上のアベイラビリティーゾーンがあります。リージョン自体が他のリージョンから分離され、独立しています。ただし、このドキュメントで後述するいくつかの例外を除きます (「[グローバルな単一リージョンのオペレーション](global-services.md#global-single-region-operations)」を参照してください）。このようなリージョン間の分離により、サービスの障害が発生しても影響は 1 つのリージョンに限定されます。この場合、他のリージョンの通常のオペレーションには影響しません。また、1 つのリージョンで作成したリソースやデータは、AWS のサービスが提供するレプリケーション機能やコピー機能を明示的に使用するか、手動でリソースをレプリケートした場合を除いて、他のどのリージョンにも複製されることはありません。
![\[この図は、2022 年 12 月時点の現在の AWS リージョンおよび計画中の AWS リージョンを示しています。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/images/current-and-planned-aws-regions.png)
# AWS Local Zones
[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) は、コンピューティング、ストレージ、データベース、その他の[一部の AWS のサービス](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/)を大都市や産業中心地の近くに配置するインフラストラクチャを活用するデプロイタイプです。Local Zone でコンピューティングやストレージなどの AWS のサービスを使用することで、低レイテンシーのアプリケーションをエッジで実行したり、ハイブリッドクラウド移行を簡素化したりできます。Local Zones は、レイテンシーを短縮するために自身のインターネット接続 (送新/受信) を備えていますが、Amazon の冗長で高帯域幅のプライベートネットワークを介して親リージョンにも接続されているため、AWS Local Zones で実行中のアプリケーションからあらゆるサービスに高速、安全、シームレスにアクセスできます。
# AWS Outposts
[AWS Outposts](https://aws.amazon.com/outposts/) は、AWS のインフラストラクチャとサービスを実質的にすべてのオンプレミスまたはエッジロケーションに提供し、真に一貫したハイブリッドエクスペリエンスを実現するフルマネージドソリューションのファミリーです。Outposts ソリューションを使用すると、AWS のネイティブサービスをオンプレミスで拡張および実行でき、1U および 2U Outposts サーバーから 42U Outposts ラックや複数のラックデプロイまで、さまざまなフォームファクタで利用できます。
AWS Outposts を使用すると、[AWS の限定されたサービス](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html#services)をローカルで実行し、親の AWS リージョンで利用できる幅広いサービスに接続できます。AWS Outposts は、AWS が設計したハードウェアで構築された、フルマネージドで設定可能なコンピューティングおよびストレージラックであり、お客様はクラウド内で AWS の幅広いサービスにシームレスに接続しながら、オンプレミスでコンピューティングとストレージを実行できます。
# Point of Presence
AWS リージョン およびアベイラビリティーゾーンに加えて、AWS は、グローバルに分散された Point of Presence (POP) ネットワークも運用しています。これらの PoP は、コンテンツ配信ネットワーク (CDN) である Amazon CloudFront、パブリックドメインネームシステム (DNS) 解決サービスである Amazon Route 53、およびエッジネットワーク最適化サービスである AWS Global Accelerator (AGA) をホストしています。グローバルエッジネットワークは現在、400 を超えるエッジロケーションを含む 410 を超える PoP と、48 か国の 90 を超える都市にある 13 のリージョンレベルの中間層キャッシュで構成されています (最新の状況については、「[Amazon CloudFront の主な特徴](https://aws.amazon.com/cloudfront/features/)」を参照してください)。
![\[この図は、Amazon CloudFront のグローバルエッジネットワークを示しています\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-fault-isolation-boundaries/images/amazon-cloudfront.png)
各 PoP は、他の PoP から分離されているため、1 つの PoP や大都市圏に影響する障害が発生しても、残りのグローバルネットワークには影響しません。AWS ネットワークは、世界中の何千もの Tier 1/2/3 の通信事業者とピアリングしており、すべての主要なアクセスネットワークとの良好な接続を通じて最適なパフォーマンスを実現し、数百テラビットの容量をデプロイしています。エッジロケーションは、AWS ネットワークバックボーンを介して AWS リージョン に接続されています。これは、地球を一周するほどの完全冗長の複数の 100 GbE 並列ファイバーであり、数万のネットワークとリンクして、オリジンの取得や動的コンテンツのアクセラレーションを向上させます。
# パーティション
AWS は、リージョンを[パーティション](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)にグループ化します。各リージョンは 1 つのパーティションに厳密に属し、各パーティションには 1 つ以上のリージョンがあります。パーティションには AWS Identity and Access Management (IAM) の独立したインスタンスがあり、異なるパーティション内のリージョン間に厳密な境界を提供します。AWS 商用リージョンは `aws` パーティション内にあり、中国のリージョンは `aws-cn` パーティション内にあり、AWS GovCloud リージョンは `aws-us-gov` パーティション内にあります。AWS の一部のサービスは、[Amazon S3 クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario)や [AWS Transit Gateway インターリージョンピアリング](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html)などのクロスリージョン機能を提供するように設計されています。この種の機能は、同じパーティション内のリージョン間でのみサポートされます。あるパーティションの IAM 認証情報を使用して別のパーティションのリソースとやり取りすることはできません。
# コントロールプレーンとデータプレーン
AWS では、概念として、ほとんどのサービスをコントロールプレーンとデータプレーンに分けています。これらの用語は、ネットワークの世界、特にルーターから来ています。ルーターの主な機能であるデータプレーンは、ルールに基づいてパケットを移動します。ただし、ルーティングポリシーを作成および配布する必要があり、その作成と配信を担うのがコントロールプレーンです。
コントロールプレーンは、リソースを作成、読み取り/表示、更新、削除、およびリスト (CRUDL) するための管理 API を提供します。例えば、新しい [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2) インスタンスの起動、[Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) バケットの作成、[Amazon Simple Queue Service](https://aws.amazon.com/sqs/) (Amazon SQS) キューの表示は、すべてコントロールプレーンのアクションです。EC2 インスタンスを起動する際、コントロールプレーンは、容量のある物理ホストの検索、ネットワークインターフェイスの割り当て、[Amazon Elastic Block Store](https://aws.amazon.com/ebs/) (Amazon EBS) ボリュームの準備、IAM 認証情報の生成、セキュリティグループルールの追加など、複数のタスクを実行する必要があります。コントロールプレーンは、複雑なオーケストレーションおよびアグリゲーションシステムになりがちです。
データプレーンは、サービスの主要な機能を提供するものです。例えば、実行中の EC2 インスタンス自体、EBS ボリュームへの読み取りと書き込み、S3 バケットのオブジェクトの取得と配置、Route 53 による DNS クエリへの応答とヘルスチェックの実行は、どれもが該当する各サービスのデータプレーンが提供する機能です。
データプレーンは、ワークフロー、ビジネスロジック、データベースの複雑なシステムを通常実装するコントロールプレーンと比較して、可動部分が少なく、意図的に複雑さが軽減されています。これにより、コントロールプレーンと比べて、データプレーンで障害イベントが発生する可能性は統計的に低くなります。データプレーンとコントロールプレーンは、どちらもサービス全体の運用と成功に貢献しますが、AWS ではこれらを別個のコンポーネントとみなします。この分離により、パフォーマンスと可用性の両方の利点が得られます。
# 静的安定性
AWS のサービスの最も重要なレジリエンス特性の 1 つは、AWS が静的安定性と呼ぶものです。この用語が意味するのは、依存先に障害が発生したり利用できなくなったりしても、追加の変更を加える必要がなく、システムは通常どおり動作し続ける、つまり静的な状態で動作するということです。これを実現する 1 つの方法は、サービス間の循環依存関係をなくして、サービスの正常なリカバリを阻害しないようにすることです。これを行うもう 1 つの方法は、既存の状態を維持することです。コントロールプレーンは統計的にデータプレーンよりも障害が発生する可能性が高いという事実を考慮します。データプレーンは通常、コントロールプレーンから着信するデータに依存しますが、データプレーンは既存の状態を維持し、コントロールプレーンに障害があっても動作し続けます。データプレーンによるリソースへのアクセスは、いったんプロビジョニングされると、コントロールプレーンに依存しないため、コントロールプレーンの障害の影響を受けません。つまり、リソースを作成、変更、または削除する機能が損なわれた場合でも、既存のリソースは引き続き使用できます。これにより、AWS データプレーンはコントロールプレーンの障害に対して静的に安定します。さまざまなパターンを実装して、さまざまなタイプの依存障害に対して静的に安定させることができます。
静的安定性の例は Amazon EC2 に見ることができます。EC2 インスタンスを起動すると、データセンター内の物理サーバーと同じように利用できるようになります。コントロールプレーン API に依存することなく、実行を継続したり、再起動後に実行を再開したりできます。同じ特性が、VPC、Amazon S3 バケットおよびオブジェクト、Amazon EBS ボリュームなどの他の AWS リソースにも当てはまります。
静的安定性は、AWS のサービスの設計方法に深く根付いた概念ですが、お客様が使用できるパターンでもあります。実際、AWS のさまざまな種類のサービスを回復力のある方法で使用するためのベストプラクティスに関するガイダンスの大部分は、本番環境に静的安定性を実装することです。最も信頼性の高い回復および緩和メカニズムは、最も少ない変更で回復を達成するメカニズムです。障害が発生したアベイラビリティーゾーンから復旧する際、EC2 コントロールプレーンに依存して新しい EC2 インスタンスを起動する代わりに、その余分な容量を事前にプロビジョニングしておくと、静的安定性を実現できます。したがって、リカバリパスでコントロールプレーン (リソースへの変更を実装する API) への依存関係をなくすことで、より回復力のあるワークロードを作成できます。静的安定性、コントロールプレーン、データプレーンの詳細については、Amazon Builders' Library の記事「[アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)」を参照してください。
# まとめ
AWS は、インフラストラクチャ内のさまざまな障害コンテナを利用して障害を分離します。インフラストラクチャのコアとなる障害コンテナは、パーティション、リージョン、アベイラビリティーゾーン、コントロールプレーン、およびデータプレーンです。次に、AWS のさまざまな種類のサービス、これらの障害コンテナをサービスの設計にどのように利用するか、これらのコンテナを使用して回復力を高めるワークロードをどのように設計するかについて検討します。