アベイラビリティーゾーンを使用した静的安定性

Amazon で構築するサービスにおいては、非常に高い目標で可用性を達成する必要があります。これはつまり、システムが取る依存関係について、慎重に検討する必要があることを意味します。これらの依存関係が損なわれた場合でも復元力を維持するようにシステムを設計します。この記事では、このレベルの復元力を実現するために静的安定性と呼ばれるパターンを定義します。この概念を、AWS の重要なインフラストラクチャビルディングブロックであるアベイラビリティーゾーンに適用する方法を示します。したがって、すべてのサービスが構築される基盤になります。

静的に安定した設計では、依存関係が損なわれてもシステム全体が動作し続けます。おそらく、システムは、依存関係が提供するはずだった更新された情報（新しいもの、削除されたもの、変更されたものなど）を確認しません。しかし、依存関係が損なわれる前に行われていたすべての処理は、依存関係が損なわれているにもかかわらず機能し続けます。静的に安定するように Amazon Elastic Compute Cloud (EC2) を構築した方法について説明します。次に、アベイラビリティーゾーンの上に可用性の高いリージョナルシステムを構築するのに役立つ、静的で安定した 2 つのサンプルアーキテクチャを紹介します。

最後に、ソフトウェアレベルでアベイラビリティーゾーンの独立性を提供するためにどのように設計されているかなど、Amazon EC2 の背後にある設計理念の一部について詳しく説明します。さらに、このアーキテクチャを選択してサービスを構築する際のトレードオフについても説明します。

このセクションでは、静的安定性を活用して高可用性を実現するシステムを設計するために AWS で使用している高レベルな 2 つのパターンを紹介します。それぞれが独自の状況に適用できますが、どちらもアベイラビリティーゾーンの抽象的概念を活用しています。

アベイラビリティーゾーンに障害が発生した場合、前の図に示されているアーキテクチャはアクションを必要としません。障害のあるアベイラビリティーゾーンの EC2 インスタンスはヘルスチェックに失敗し始め、Application Load Balancer はそれらからトラフィックを移動します。実際、Elastic Load Balancing サービスはこの原則に従って設計されています。スケールアップを必要とせずにアベイラビリティーゾーンの障害に耐えるのに十分な負荷分散能力をプロビジョニングしています。

また、ロードバランサーまたは HTTPS サービスがない場合でも、このパターンを使用します。たとえば、Amazon Simple Queue Service (SQS) キューからのメッセージを処理する EC2 インスタンスのフリートもこのパターンに従うことができます。インスタンスは、複数のアベイラビリティーゾーンにわたって Auto Scaling グループにデプロイされ、適切にオーバープロビジョニングされます。アベイラビリティーゾーンに障害が発生した場合、サービスは何もしません。障害のあるインスタンスは作業を停止し、他のインスタンスはスラックを拾います。

ステートレス、アクティブ-アクティブの例の場合と同様に、プライマリノードのアベイラビリティーゾーンが機能しなくなった場合、ステートフルサービスはインフラストラクチャに対して何もしません。Amazon RDS を使用するサービスの場合、RDS はフェイルオーバーを管理し、作業中のアベイラビリティーゾーンの新しいプライマリに DNS 名を再ポイントし直します。このパターンは、リレーショナルデータベースを使用しない場合でも、他のアクティブ/スタンバイ設定にも適用されます。特に、リーダーノードを含むクラスターアーキテクチャを備えたシステムにこれを適用します。「ジャストインタイム」に交換するのではなく、これらのクラスターをアベイラビリティーゾーン全体にデプロイし、スタンバイ候補から新しいリーダーノードを選択します。

これら 2 つのパターンの共通点は、アベイラビリティーゾーンの機能障害の発生に備えて、予め必要な容量をプロビジョニングしていることです。どちらの場合も、サービスはアベイラビリティーゾーンの障害に応じて計画的なコントロールプレーンの依存関係を持ちません。

この記事の最後のセクションでは、障害耐性のあるアベイラビリティーゾーンのアーキテクチャをさらに一段階深く掘り下げ、Amazon EC2 のアベイラビリティーゾーンの独立性の原則に従う方法について説明します。これらの概念の一部を理解することは、高可用性のサービルを構築する場合だけではなく、他の高可用性のあるインフラストラクチャを提供する場合に役立ちます。Amazon EC2は、低レベル AWS インフラストラクチャのプロバイダーとして、アプリケーションが高可用性を実現するために使用できるインフラストラクチャです。他のシステムでその戦略を採用するべき場合もあります。

デプロイのプラクティスでは、Amazon EC2 のアベイラビリティーゾーンの独立性の原則に従います。Amazon EC2では、EC2 インスタンス、エッジデバイス、DNS リゾルバー、EC2 インスタンス起動パス内のコントロールプレーンコンポーネント、および EC2 インスタンスが依存する他の多くのコンポーネントをホストしている物理サーバーにデプロイされます。これらのデプロイは、ゾーンデプロイカレンダーに従います。これは、同じリージョン内の 2 つのアベイラビリティーゾーンが、異なる日に特定のデプロイを受け取ることを意味します。AWS 全体で、デプロイの段階的なロールアウトを使用します。たとえば、最初にワンボックスをデプロイし、次に 1 / N のサーバーなどをデプロイするといった、 ベストプラクティスに従います。(これは、デプロイするサービスの種類に依存しません。)ただし、Amazon EC2のようなサービスの特定のケースでは、展開はさらに一歩進められ、アベイラビリティーゾーンの境界に意図的に合わせられています。このように、デプロイの問題は 1 つのアベイラビリティーゾーンに影響します。ロールバックされ、修正が行われます。これは通常どおり機能している他のアベイラビリティーゾーンには影響しません。

Amazon EC2 で構築するときのアベイラビリティーゾーンの独立性の原則に沿ったもう1つの方法は、すべてのパケットフローを境界を越えないようにアベイラビリティーゾーン内にとどめる設計をすることです。ネットワークトラフィックをアベイラビリティーゾーンのローカルにとどめることの 2 つめの理由について、詳しく見ていきたいと思います。これは、独立したアベイラビリティーゾーンのコンシューマーである、リージョン内の可用性の高いシステムを構築する場合の、弊社の考えを示す一例です。(つまり、高可用性サービスを構築するための基盤として、アベイラビリティーゾーンの独立性を確保します。) アベイラビリティーゾーンに依存しないインフラストラクチャを他のユーザーに提供して、高可用性を実現するといった方法と対照的な手法です。

次の図では、高可用性の外部サービスをオレンジ色で示しています。これは、緑で示されている別の内部サービスに依存しています。シンプルな設計では、これらのサービスの両方を、独立した EC2 アベイラビリティーゾーンのコンシューマーとして扱います。オレンジとグリーンの各サービスの前には Application Load Balancer があり、各サービスには、3 つのアベイラビリティーゾーンに分散した、適切にプロビジョニングされたバックエンドホストのフリートがあります。1 つの高可用性のリージョナルサービスが別の高可用性のリージョナルサービスを呼び出します。これはシンプルな設計で、弊社がこれまで構築した多くのサービスに適用してきました。良い設計です。

ただし、グリーンのサービスは基本的なサービスであるとします。つまり、可用性が高いだけでなく、それ自体がアベイラビリティーゾーンの独立性を提供するためのビルディングブロックとして機能することを目的としているからです。その場合、代わりにゾーンローカルサービスの 3 つのインスタンスとして設計し、アベイラビリティゾーンに対応したデプロイポリシーに従います。次の図は、高可用性リージョナルサービスが高可用性ゾーンサービスを呼び出す設計を示しています。

ブロック構築のサービスをアベイラビリティゾーンに依存しないように設計するには、単純な計算で求めることができます。アベイラビリティーゾーンに障害があるとしましょう。白黒の障害の場合、Application Load Balancer は影響を受けたノードから自動的に障害を取り除きます。ただし、すべての障害がすぐに判別でできるわけではありません。ソフトウェアのバグなど、判別しにくい障害が発生する可能性があります。ロードバランサーは、ヘルスチェックで障害を検出できず、正常に処理できません。

ある高可用性リージョナルサービスが別の高可用性リージョナルサービスを呼び出すという上述の例において、リクエストがシステムを介して送信され、障害のあるアベイラビリティーゾーンを回避する確率は、2/3 * 2 / 3 = 4/9 となります。つまり、このリクエストがイベントを回避できる確率は、五分五分の確率よりも低いということです。一方で、グリーンのサービスをゾーンのサービスとして構築した場合は、オレンジのサービスのホストは同じアベイラビリティゾーンにあるグリーンのエンドポイントを呼び出すことができます。この設計では、障害のあるアベイラビリティーゾーンを回避できる可能性は 2/3 になります。N 個のサービスがこのコールパスの一部である場合、N 個のリージョナルサービスでは (2/3) ^ N を、N 個のゾーンサービスでは 2/3 (一定) を、確率として一般化することができます。

ゾーンサービスとして Amazon EC2 NAT ゲートウェイを構築した理由がこれです。NAT ゲートウェイは、プライベートサブネットからのアウトバウンドインターネットトラフィックを許可する Amazon EC2 機能であり、リージョン内の VPC ワイドゲートウェイとしてではなく、ゾーンリソースとして表示され、次の図に示すようにアベイラビリティゾーンごとに個別にインスタンス化します。NAT ゲートウェイは、 VPC のインターネット接続経路にあるため、その VPC 内の EC2 インスタンスのデータプレーンの一部です。1つのアベイラビリティーゾーンに接続障害が起こる場合、他のゾーンに拡大するのを避けるために、その障害をそのアベイラビリティーゾーンにとどめたいと考えます。最後に、この記事で前述したものと同様のアーキテクチャ (つまり、 2 つ十分なストレージ容量を備え、3 つのアベイラビリティーゾーンにフリートをプロビジョニングして、フルロードを保持することが可能なアーキテクチャー) を構築したお客様は、あるアベイラビリティーゾーンで障害が起こっても他のアベイラビリティゾーンへの影響は完全に回避できます。これを行う唯一の方法は、NAT ゲートウェイなどのすべての基本コンポーネントをアベイラビリティーゾーン内に確実に配置することです。

これを選択するとより複雑になりコストがかかります。Amazon EC2 におけるより複雑な構成では、リージョン内のサービス環境ではなく、ゾーンの管理環境という形でもたらされます。NAT ゲートウェイのお客様の場合、VPC のさまざまなアベイラビリティーゾーンで使用できる、複数の NAT ゲートウェイやルートテーブルを使用するという構成で複雑さが増します。NAT ゲートウェイ自体が基本的なサービスであり、ゾーンの可用性を確保する Amazon EC2 データプレーンの一部であるため、より複雑な構成は適切なのです。

アベイラビリティーゾーンに依存しないサービスを構築する際に考慮すべき点がもう 1 つあります。それはデータの耐久性です。前述の各ゾーンアーキテクチャは、単一のアベイラビリティゾーンに含まれるスタック全体を示していますが、災害復旧のために、複数のアベイラビリティゾーンにわたってハードウェアの状態をレプリケートします。たとえば、通常、定期的にデータベースのバックアップを Amazon S3 に保存し、アベイラビリティーゾーン間でデータストアのリードレプリカを維持します。これらのデータの複製は、プライマリアベイラビリティーゾーンで機能するために必要なものではありません。代わりに、顧客またはビジネスに不可欠なデータを複数の場所に確実に保存します。

AWSで実行されるサービス指向アーキテクチャを設計する際、これら 2 つのパターンのどちらか、または両方の組み合わせにするかを学びました。

•比較的に単純なパターン：regional-calls-regional。多くの場合、これは外部向けサービスに最適な選択肢ですが、ほとんどの内部サービスにも適しています。たとえば、Amazon API Gateway や AWS サーバーレステクノロジーなど、AWS で高レベルのアプリケーションサービスを構築する場合、このパターンを使用して、アベイラビリティゾーンの障害が発生しても高可用性を確保します。
•比較的に複雑なパターン：regional-calls-zonalまたはzonal-calls-zonal。Amazon EC2 の内部、場合によっては外部のデータプレーンコンポーネント (たとえば、重要なデータパスに直接配置されるネットワークアプライアンスまたはその他のインフラストラクチャ) を設計する場合、アベイラビリティーゾーンの独立性のパターンに従い、可用性でサイロ化されたインスタンスを使用します。これにより、ネットワークトラフィックが同じアベイラビリティゾーンにとどまります。このパターンは、アベイラビリティゾーンに隔離した障害を保持するのに役立つだけでなく、AWSでのネットワークトラフィックのコストにも優れています。

この記事では、AWSでアベイラビリティーゾーンへの依存に関する簡単な戦略をいくつか説明しました。静的安定性の鍵は障害が発生する前に障害を予測することであることを学びました。システムがアクティブ/アクティブ構成の水平スケール可能なフリートで実行されているかどうか、またはステートフルなアクティブ/スタンバイパターンであるかどうかにかかわらず、アベイラビリティーゾーンを使用して高レベルの可用性をターゲットとします。障害が発生した場合に必要となる十分な容量が完全にプロビジョニングされ、すぐに使用できるようにシステムをデプロイします。最後に、Amazon EC2 自体が静的安定性の概念を使い、アベイラビリティーゾーン間を独立させる方法について詳しく見てきました。