AWS Tech

AWS東京リージョン障害で学ぶ可用性

投稿日:2021年2月21日 更新日:

こんにちは、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 Cloud Tech にて体系的なハンズオン学習も進めています。
フリーコースもありますので、興味がある方は覗いてみてください。

ここまで読んでいただき、ありがとうございました。

-AWS, Tech
-, , , , , ,

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

【Python】loggingの正しい使い方

開発効率やメンテナンス性の観点から、ログを残すことは非常に重要です。 Pythonにはログ出力用に「logging」モジュールが用意されています。loggingを使うことで、簡単にログ管理をすることが …

AWSマネジメントコンソールにサインインできなかった話【解決済み】

こんにちは、yassanです。今回は「AWSマネジメントコンソールにサインインできなかった話【解決済み】」を紹介します。 先日、AWSのマネジメントコンソールにサインインできない状況になったので、色々 …

【合格実績あり】実務経験なしでAWS SAA-C02に合格する方法

こんにちは、yassanです。今回は「【合格実績あり】実務経験なしでAWS SAA-C02に合格する方法」を紹介します。 世界中のコンピュータリソースがクラウドに移行しつつあることは、皆さんもご存知か …

ElasticIPアドレスとは?学んだことをまとめてみた【初心者エンジニアのAWS備忘録⑤】

こんにちは、yassanです。今回は「ElasticIPアドレスとは?学んだことをまとめてみた【初心者エンジニアのAWS備忘録⑤】」を紹介します。 AWSでは、Elastic IP と言う概念が登場し …

【MySQL】Error Code: 1175. You are using…の対処方法

Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE tha …

yassanさんのプロフィール写真

yassan
R&Dエンジニア。
新卒で大手の社内SEになったもののスキルアップのためにITベンダーに転職。
技術調査からプログラミングまで幅広くやってます。
趣味はバイクとガジェットと遊戯王カードです。