アベイラビリティゾーンを使用した静的安定性の例
堀貴裕氏：ここまででAWS内部と静的安定性の概念を説明してきたのですが、ここからはアベイラビリティゾーンを使用したアーキテクチャを例に取って、静的安定性をより深掘りしたいと思います。
では、この章で学ぶことについて説明します。ここまではAWSサービス内の静的安定性を説明していることが多かったのですが、ここからはAWSサービスを使った静的安定性の高いアーキテクチャ設計を学びます。
そしてこれを説明するために、複数のアベイラビリティゾーンを使用したアーキテクチャを例に取って、静的安定性の高いアーキテクチャを実現する方法を学びたいと思います。
AWSのアベイラビリティゾーンの考え方
（スライドを示して）始めに、AWSのアベイラビリティゾーンの考え方を復習したいと思います。このアベイラビリティゾーンは、1つ以上のデータセンターで構成されています。。
また、アベイラビリティゾーンは落雷・竜巻・地震などの大規模な災害の相関的な影響から保護するために、意味のある距離で物理的に分離されています。これはつまり、1つのアベイラビリティゾーンでこのような災害が起きた際も、違うアベイラビリティゾーンに波及しないということです。
そしてこれも重要なのですが、高速で暗号化されたプライベート光ファイバーネットワークで接続されています。（スライドを示して）下はアベイラビリティゾーンを図示していて、1つのアベイラビリティゾーンに1つ以上のデータセンターがあって、そのアベイラビリティゾーンが高速な光ファイバーネットワークで通信されていて、その複数のアベイラビリティゾーンでリージョンを形成しています。
例えば日本のリージョンでは、東京リージョン・大阪リージョンがあります。このようにアベイラビリティゾーンで冗長化、そして光ファイバーネットワークで高速に通信することによって、パフォーマンスを落とさずに高い可用性を実現できます。
高い可用性を持つアーキテクチャ
次に、そのようなアベイラビリティゾーンを複数使用した、高い可用性を持つアーキテクチャを説明したいと思います。これはかなり有名なアーキテクチャですが、複数のアベイラビリティゾーンにEC2仮想サーバーを配置します。Elastic Load Balancingはいわゆるロードバランサーの役割を持って、リクエストを均等に配分します。
そしてAuto scalingです。（スライドを示して）Auto scaling groupと書いてあるAuto scalingはEC2の1つの機能で、負荷に応じてEC2のインスタンスの数を増減させます。つまり、負荷が増えるとEC2を増やし、負荷が減るとEC2の数を減らします。
そしてこのような構成を取ることによってアベイラビリティゾーンで冗長化されているので、1つのアベイラビリティゾーンの障害の際にも、もう片方のアベイラビリティゾーンで動作を継続できます。
複数のアベイラビリティゾーンを使ったアーキテクチャの静的安定性
ここまでで複数のアベイラビリティゾーンを使ったアーキテクチャを説明してきたのですが、ここでそれを使った静的安定性を説明する前に、一般的なアーキテクチャ設計における静的安定性の考え方を説明したいと思います。
これは復習ですが、静的安定性の定義は障害で依存関係が損なわれてもシステムが動作し続ける性質（のこと）でした。
そしてAWSサービス自体の静的安定性は、コントロールプレーンが障害の際もデータプレーンが安定して動作し続ける設計でした。
そこでアーキテクチャ設計における静的安定性はどのようなものかをお話しすると、何らかの障害が発生した際に、先ほど説明したコントロールプレーンに依存しない。そのような設計を取ることが、AWSのアーキテクチャにおける静的安定性です。
では、先ほどの複数のアベイラビリティゾーンを使ったアーキテクチャで、静的安定性を考えていきましょう。ここで、EC2インスタンスのアイコン2つ分をリクエスト処理に必要なインスタンス数と仮定します。これは例えば負荷テストなどでインスタンス数を調査できます。
ここで、例えばアベイラビリティゾーン1つに何か障害が起きてしまったと仮定します。その際に考えられる動作としては、EC2の能力が1つしか残っていないので、Auto scaling groupの機能を使って、追加でEC2インスタンスを作成します。（スライドを示して）このように2つに増えていますね。
（スライドを示して）（図に書かれている）リクエスト処理に必要なインスタンス数の左側の片方。インスタンス作成という機能は、何かを作成したり設定を変更する、コントロールプレーンの機能であることを思い出してもらいたいです。つまりはアベイラビリティゾーンの障害の際に、可用性の低いコントロールプレーンに依存してしまっています。
これは先ほどのアーキテクチャ設計における「静的安定性の障害時にコントロールプレーンに依存しない」という原則に反しています。
（スライドを示して）なので、静的安定性が高いアーキテクチャを組む方法としては、マーク2つ分になっています。つまり、EC2インスタンスを200パーセント余分に用意する必要があります。
これはつまり、Auto scalingの設定は負荷テスト時の50パーセントにしておくということです。1つのアベイラビリティゾーンに何か障害が起きてしまった際に、1つのアベイラビリティゾーンに2つ分の負荷テストに耐え得るインスタンスが作成されているので、インスタンス作成の必要がありません。
そして、インスタンス作成に依存しないので、コントロールプレーンに依存せず静的安定性が高い設計になっています。デメリットとしては、やはり200パーセントもEC2インスタンスを余分に用意するので、コストは増加しています。
そのような問題を回避するために、3つのアベイラビリティゾーンを使用してコストを抑えることを考えます。（スライドを示して）このようにアベイラビリティゾーンを3つ使って、1つずつアイコンの分のEC2インスタンスを用意することです。EC2インスタンスを150パーセント余分に用意することです。これはつまり、Auto scaling groupの設定を負荷テスト値の66.6パーセントにしておくということです。
こちらの構成でも1つのアベイラビリティゾーンで何か障害が起きた際に、アイコン2つ分あるのでEC2インスタンスの作成の必要がありません。
そして、2つのアベイラビリティゾーンと比べて200パーセントから150パーセントになっているので、コストを削減できます。ですが、やはり150パーセント余分に用意するので、コストは増えてしまいます。なので、お客さまのコスト要件と可用性の要件を天秤にかけてもらって、（その上で）こちらを選択してほしいです。
データベースを使ったアーキテクチャの静的安定性
お客さまによっては、サーバー以外にもデータベースを使ったアーキテクチャを設計したいということが考えられます。なので最後に、データベースを使ったアーキテクチャの静的安定性を考えたいと思います。
（スライドを示して）これはRDS（Relational Database Service）データベースのサービスですが、静的安定性を高く保つためには、プライマリのインスタンスとしてスタンバイのインスタンスを用意することをおすすめしています。
このプライマリからスタンバイに同期的にレプリケーションがされています。そこでもしプライマリのアベイラビリティゾーンで何か障害が起きてしまった際は、スタンバイにフェイルオーバーすることによって、コントロールプレーンに依存せず静的安定性が高い構成を取ることができます。
アーキテクチャ設計において静的安定性を高める考え方のまとめ
ここまでのまとめを行います。アーキテクチャ設計において静的安定性を高めるためには、障害時にコントロールプレーンに依存しない設計にする必要がありました。こちらをまず大原則として覚えてもらいたいです。
そしてEC2の例では、コントロールプレーンに依存しないために余分にインスタンスを用意する必要がありました。
そしてデータベース、RDSのサービスでは、スタンバイを他のアベイラビリティゾーンに用意して、フェイルオーバーすることで静的安定性を高めることができます。
本セッションのまとめ
最後に全体のまとめを行いたいと思います。AWSサービスやお客さまのサービスのような高いパフォーマンス、高い機能、高い可用性を実現するサービスにおいては、静的安定性について考える必要があります。そして静的安定性の定義については、障害で依存関係が損なわれてもシステムが動作し続ける性質であることを学びました。
AWSサービス自体で静的安定性をどのように実現するかというと、コントロールプレーンが何か障害が起きた際にもデータプレーンが安定して動作し続けることで実現してきました。
そして最後に、アーキテクチャ設計における静的安定性を実現するためには、何らかの障害が起きた際にコントロールプレーンに依存して復旧しない設計を取ることが必要であることを学びました。
私からの発表は以上です。ご清聴ありがとうございました。
