こんにちは、yassanです。
今回は「AWS東京リージョン障害で学ぶ可用性」を紹介します。
昨日の深夜に東京リージョンにあるAZの一つで、障害が発生しました。
このニュースに対して、ベストプラクティスに従った可用性とはどのようなものかを改めて復習したいと思います。
僕はAWSに関しては、実務経験がない初学者ですが、
最近はSSA試験に向けて勉強を進めています。
可用性ってなんだっけ
障害発生と切っても切れない関係性にあるのが、可用性という観点です。
可用性とは、システムが正常に継続してサービスを提供し続けられる性能をさします。
例えば、なんらかの理由で年間あたり1時間程度、システムが利用できない場合、その稼働率は約99.9%となります。（0.1%は非稼働、つまりシステムを利用できないこと）
稼働率は、可用性を表現するもっとも代表的な数値です。
稼働率を高めることは、すなわち可用性を高めることに直結します。
稼働率（可用性）を高めるためには、冗長化が必要になります。
冗長化とは、ざっくりいうと、システムを一つのサーバーで稼働させるのではなく、複数のサーバーで稼働させることを指します。
つまり、サーバーが1台ポシャっても、予備があるから大丈夫！な状態を作っておくことですね。
ここまでは一般的な可用性の話なのですが、AWSでは可用性について、次のような考え方に基づいてAWSサービスを利用してシステム設計・構築をすることが推奨されています。
Design for Failure
Design for Failureとはつまり、障害発生を見越したシステム設計をしましょう。ということです。
天下のAWSでさえも、障害を100%防ぐということは無理なので、割り切って障害が発生しても大丈夫なようにしておきましょう。と僕は解釈しました。
事故のないように車の運転技術を身につけることも大事ですが、それを究極的に追い求めるのではなく、万が一事故してしまった時でも大丈夫なように保険に入っておきましょうみたいな感じですかね。
このDesign for Failureに基づいてやることといえば、やはり冗長化になります。
具体的には、
- 単一障害点の排除
- 地理的な冗長化（AZをまたがる、DRサイトの構築）
- 疎結合化
になります。
オンプレ環境での冗長化テクニックと同様のものもあるかと思いますが、あくまでAWS上で構築するサービスの可用性という観点で見ていきたいと思います。
単一障害点の排除
単一障害点の排除とは、その箇所が稼働できなくなった時に、システム全域に影響を与える点になります。
例えば、ECサイトのWebサーバーが利用できなくなったら、買い物ができないのでかなり困りますよね。
この場合は、Webサーバーが単一障害点となります。
AWSで構成している場合は、このWebサーバーがEC2と呼ばれる仮想的なコンピュータリソースになります。
EC2を冗長化することによって、単一障害点を排除できることになります。（他にもあるかもしれませんけど）
EC2を冗長化する具体的な手法としては、EC2を2台以上に増やし、それぞれにアクセスを割り振るようにELBで設定をしておく方法があります。
ちなみに、EC2はユーザー側で冗長化する必要がありますが、ELBやSNSなどのサービスはAWS内部で冗長化されているため、ユーザー側で冗長化構成を考える必要はありません。
また、EC2はAuto Scalingを利用することで、アクセスなどの情報を元にリソースを自在にスケーリングするよう設定することもできます。
地理的な冗長化
地理的な冗長化とは、文字通りコンピュータリソースを冗長化する際に、それぞれ地理的に距離がある場所に配置することです。
地震や長期間停電や火災など、物理的な原因での障害は、やはり建物単位ひいては地域単位で発生しやすいものになります。
そのような事態を踏まえて、地理的に離れた配置で冗長化するのが望ましいというわけです。
上述のEC2の冗長化でも、同一のAZに複数のEC2を配置するよりも、異なるAZに配置した方が、同じ冗長化でも効果が期待できます。
同じAZに冗長化しても、今回の障害のようにAZ単位での障害を発生した時に、システムの正常稼働ができなくなります。
複数のAZに冗長化しておくことで、一つのAZが障害で利用できなくなったとしても、（処理負荷やフェイルオーバーのリードタイムなど他の課題はあると思いますが）一旦はシステムを稼働し続けられます。
また、地理的な冗長化には、他にDisaster Recoveryの構築という選択肢もあります。
これは、AZだけでなくリージョンもまたぐ設計になります。（かなり高い可用性が期待できますね...!）
異なるリージョンのVPC間は、VPCピアリングを利用することで、プライベートIPアドレスで接続が可能になります。
疎結合化
疎結合化とは、コンポーネントからできるだけ依存関係を取り除き独立させる考え方です。
コンポーネントを疎結合化することで、一部分に障害が発生した場合に、その部分だけ切り離して、他で代替したり復旧することもできますし、影響範囲も小さくなり調査も簡単になります。
（これは、AWS・インフラに詳しくない方でも、オブジェクト指向について理解されていれば、こちらの理解も容易かと思います）
今回のようなAZ単位での障害対策
以上を踏まえて、今回の東京リージョンのAZ障害について振り返りたいと思います。
今回の障害は、東京リージョンにある1つのAZに障害が発生しました。
具体的には、EC2インスタンスとEBSの一部が利用できなくなってしまったとのことです。
では、どのように構成しておけば、可用性を高めることができたでしょうか。
この場合、マルチAZ構成にしていないと、その時点でアウトですね。
単一のアベイラビリティゾーンで構成していた場合は、このようなAZ単位の障害が発生した時に、運が悪いと信頼性を大きく欠如することになります。
（個人はともかく、企業レベルで運用しているものなら、単一構成はまずないとは思います。）
というわけで、マルチAZ構成にしておくことは必須ですね。
加えて、アクセス負荷に対応できるように、Auto Scalingの設定をしておくとなお良いですね。
AZの障害ということで、Route53やELBなどのネットワークに関する部分については問題なさそうです。
フェイルオーバーの設定をしっかりしてさえおけば、大丈夫かと思います。
ストレージ（EBS）に関しては少し考慮が必要かと思います。
EBSは、AZ単位で作成されます。
AZ内では自動的に複製されますので、ディスク障害に関しては対策する必要はありません。
しかし、今回のようなAZ単位での障害に備えるのであれば、EBSスナップショットをS3に保存する対策が必要ですね。
マルチクラウドの必要性について
AWSの可用性。という観点ではないのですが、可用性を極限まで高めようとすれば、マルチクラウドという選択肢があります。
パブリッククラウドを提供するのは、AWSだけでなくAzureやGCPがあります。
これらの別のパブリッククラウドと組み合わせてシステムを構成することも、可能みたいです。
そうすると、やはり管理が大変になるなどのデメリットもあるみたいですね。
というわけで、今回は「AWS東京リージョン障害で学ぶ可用性」でした。
AWS学習におすすめの書籍
AWSについて、しっかりと基礎から学びたい、実践的なスキルを身につけたいと考えている方向けに、おすすめの書籍を紹介します。
これらの書籍は、実際にAWSエンジニアとして働く僕が参考にしている書籍です。
AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ
AWSを使いこなすための前提となるITインフラの知識が足りない初学者にとって、どこからどのように学べばよいのかがわかりづらくなっています。そこで本書では、AWS学習サイト運営YouTuberである監修者自身が実サービスの導入で習得しながら体系化した「学習ロードマップ」に沿って、AWSのサービスとIT技術をやさしく解説していきます。
著者が作成した学習ロードマップに沿って、AWSやインフラストラクチャを体系的に学ぶことができます。
付属のロードマップの完成度が高く、学習に迷ったときや復習にも使えます。
これからAWSエンジニアを目指す方や、インフラストラクチャを基礎から学びたい方におすすめです。
Amazon Web Services 業務システム設計・移行ガイド
オンプレミス上に構築された業務システムをAWS上に移行するための「サービスの選定」「ネットワーク設計・構築」「サーバとデータの移し方」「運用・監視体制の構築」など。これまで多くの企業にAWSを導入し、コンサルティングフェーズから実際の設計・開発、運用フェーズまでの全行程に携わってきた著者陣のノウハウを凝縮して、一般的な企業にAWSを導入する際のベストプラクティスをお届けします。
実務を想定した様々なユースケースとそれに対するベストプラクティスを、設計構築から運用まで幅広くカバーして紹介しています。
タイトルからは移行に焦点を当てたように見えますが、僕としては移行に限らずエンタープライズとしてAWSを利用する上で知っておくべきことが記されていると思います。
より実践的な知識やノウハウを身に着けたい方、初学者から一皮むけたい方におすすめです。
