現代のWebサービスでほぼ当たり前になっている「静的安定性」
堀貴裕氏：私からは「高可用性を実現する静的安定性という考え方」について、発表したいと思います。静的安定性という考え方は、現代のWebサービスだと、だいたいのシステムで考えるべき考え方となっているので、本日このセッションを聞いたあとに（この）静的安定性という考え方を持ち帰ってもらって、みなさまのサービスで静的安定性が保たれているかを確認してもらいたいです。
（スライドを示して）まず自己紹介をします。私は堀貴裕と申します。所属はアマゾンウェブサービスジャパン合同会社のソリューションアーキテクトで、ふだんは技術相談やAWSのアーキテクチャの相談などを承っています。好きなAWSサービスは機械学習系サービスのAmazon SageMakerで、趣味は動く系ではバドミントン、ゲームではポケモンが趣味です。
本日話す内容の元となった記事を紹介します。（スライドを示して）これはAmazon Builders' Libraryの「アベイラビリティゾーンを使用した静的安定性」という記事です。こちらにリンクとQRコードを載せているので、発表を聞きながらこの記事を見たい方は、こちらからアクセスしてもらえるとうれしいです。
本セッションのアジェンダ
では始めに本日話すアジェンダについてお伝えしたいと思います。まず、本日伝えたいことを結論からお話しします。そしてそのあとに、静的安定性という考え方、概念を理解してもらおうと思います。
静的安定性を理解した上で、アベイラビリティゾーンを使用したアーキテクチャの例を取って、静的安定性という考え方について理解してもらおうと思います。最後にまとめを行います。
高いパフォーマンス、高機能、高可用性を実現する必要において必要なこと
（スライドを示して）では、本日伝えたいことをお話しします。AWSのような高いパフォーマンス、高機能、そして高可用性を実現する必要があるシステムにおいては、ソフトウェア開発やアーキテクチャ設計で静的安定性が必要になります。
これはみなさまのサービスでも同様です。そして静的安定性という言葉（の意味）は、障害によって依存関係が損なわれても、システムが動作し続ける設計のことです。
「静的安定性」とは何か、なぜ必要なのか
まず静的安定性という概念がどのようなものかを理解したいと思います。（再度）確認ですが、静的安定性の定義は、障害で依存関係が損なわれてもシステムが動作し続ける性質です。
（スライドを示して）例えば、このようなSystem1とSystem2が存在したとします。System1はSystem2に依存しています。そこで例えばSystem2に障害が発生してしまった、つまり依存関係が損なわれてしまった。そのような状態でも（System1は）動いてほしい、System1は安定稼働し続ける。これが静的安定性の定義です。
これをさらに詳しく理解するために、静的安定性がなぜ必要なのかの理由を説明します。通常、システムが高い可用性を持つためには、依存するシステムの可用性も高い必要があります。
（スライドを示して）例えばこれは、可用性が低いシステムに依存している場合の例です。System1は先ほどと同様にSystem2に依存していますが、System2の可用性が低いため、障害が起きてしまった際に、System1も同時に障害を起こしてしまいます。これは例えば、System2の設定ファイルをSystem1に読み込んでいるような依存関係が考えられます。
これを解決するために、Amazon S3のような非常に可用性の高いサービスを使うことが考えられます。これはシンプルで良い設計になっているのですが、AWSのような多数のお客さまが多数の設定変更を頻繁に行っているシステムだと、その設定内容を継続的に再計算してS3に書き込み、そして読み込みを行うのはパフォーマンス上、現実的ではありません。
なので、より高いパフォーマンスを達成するためには、可用性はあまり高くないのですが、高速に設定を読み書きするサーバーを使って設定変更を行う必要が出てきます。
そして、高パフォーマンスでさらに高機能なAWSのサービスを作る上で、すべての依存先の可用性を高く保つことは困難です。
（スライドを示して）例えばこのように動かしたいシステムがあって、それが多数のシステムに依存しているとします。そしてそのシステム1つがダウンしてしまうと、動かしたかったシステムも同時にダウンしてしまいます。これが静的安定性がない場合です。
静的安定性があるシステムを組むと、依存関係が損なわれても動作する性質があるので、依存先のシステムに障害が起きたとしても、上のシステム自体は安定稼働を続けられます。
静的安定性を実現するシステムの具体例
ではここで、静的安定性を実現するシステムは具体的にどのようなものかを説明します。（スライドを示して）先ほどと同様に、System1はSystem2に依存しています。しかし（今回は）、System2のキャッシュなどをSystem1に置いていく。
このように設計することによって、たとえSystem2が障害を起こして停止してしまったとしても、System1にSystem2のキャッシュは残っているので、System1は動作を継続できます。
（スライドを示して）さらにわかりやすく理解するために、ECサイトの例を説明します。ECサイトでは商品購入サービスと住所変更サービスがあります。商品購入サービスの1つの段階において、配送先を何か指定しなければいけません。その際に住所を使う必要があるのですが、この住所変更は住所変更サービスに依存していることになります。
しかし、住所をキャッシュで持っておけば、住所変更サービスに何か障害が起きた際も、商品購入サービス自体は動作を継続できます。
AWSサービス内部の静的安定性
ここまで静的安定性の概念的な説明をしてきたのですが、ここからはAWSサービス内部の静的安定性はどのようなものになっているかを説明します。
AWS内部では、コントロールプレーンとデータプレーンを分離することによって実現されています。（スライドを示して）こちらの図がAWSサービスを模擬的に示した図で、データプレーンとコントロールプレーンで分かれています。
データプレーンはAWSサービスの基本的な機能を司っていて、単純な依存関係しか持っていません、そのため高い可用性を実現（することが）求められる部分です。
（データプレーンと）比較してコントロールプレーンは、システムの変更機能などを司っています。例えばシステムの追加・変更・削除などです。これは複雑な依存関係、つまり高い機能を持っていますが、可用性はデータプレーンほど要求されない構成になっています。
これらが完全に分離されることによって、コントロールプレーンで何か障害が起きたとしても、データプレーンは動き続けるというような設計がされています。
（スライドを示して）これも詳しく理解するために、Amazon EC2という仮想サーバーのサービスを例に取って、コントロールプレーンとデータプレーンを説明します。
EC2のデータプレーンは、ネットワークやサーバー自体の計算能力、そしてストレージとの通信などの、絶対に止まってはならない部分がデータプレーンを構成しています。
逆にコントロールプレーンは、新しくインスタンスを作成したり、インスタンスの設定を変更するなどの機能を司っています。これらが完全に分離しているので、例えばインスタンス作成で何か障害が起きた際にも、ネットワークが止まってしまうような障害が発生することはありません。
静的安定性の概念、AWSの静的安定性のまとめ
最後にここまでのまとめを行います。AWSサービスのような高パフォーマンスで多機能なサービスを作る際には、静的安定性が必要です。静的安定性は障害で依存関係が損なわれてもシステムが動作し続ける性質ということを学びました。
そしてAWSではデータプレーンとコントロールプレーンを完全に分離することによって、静的安定性の高いサービスを実現して可用性を高く保っています。
（次回に続く）
