この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
よく訓練されたアップル信者、都元です。今回はコードや操作手順などなく。
オンプレミス環境等と比較すると、AWS上で稼働させるシステムには、サーバアーキテクチャはもちろん、アプリケーションのアーキテクチャにも色々考えるべきポイントが多々あります。AWSで仕事をしていると当たり前過ぎてなかなか記事として言及する機会がないのですが、これらのアーキテクチャを組み上げる基礎知識となる、AWSにおける可用性の考え方をまとめてみました。
サーバは落ちるもの、データセンタは止まるもの
AWSにおいては、単体のEC2インスタンスは「突如として落ちるかもしれない」という前提があります。さらに、何らかの障害や災害等で「AZ(availability-zone)も丸ごと落ちるかもしれない」という前提があります。突然落ちるというのは大げさ（でもないのですが…）にしても、時にEC2インスタンスはAWSから強制的に「再起動を求められ」たりするわけです。従来のオンプレ環境では考えられないことでしょう。
AWS上にシステム構築する場合は、これらを考慮し、EC2インスタンスが唐突に落ちたり、AZ（≒データセンタ）1つが丸ごと消滅したとしてもシステムが稼働し続けられる（高可用性＝high-availability＝HA）ようなアーキテクチャを推奨しています。もう、サーバやDCは落ちるものなんだ。AWSとしてもその前提でHAを実現するための機能を積極的に提供するから、ウワモノとしてもHAを考えて構築してくれ、と。
この考え方を「design for failure」と呼びます。障害を見据えた設計をしよう、ということですね。
通常のシステムはサーバが落ちたらシステムが止まるため、我々はしばしば「絶対に落ちないサーバ」を求められたりします。が、そんなものはこの世に存在しないことには、誰もが気づいているはずです。ならば、1つくらいサーバが落ちたとしても、システムが稼働し続ければ良いじゃないか。AWSは、もう気持ちいいくらいの割り切りようです。そしてこれはだたの開き直りではなく、非常に現実的です。
非HAのアーキテクチャ
ここで実例を見て行きましょう。
以前「Amazon VPCを使ったミニマム構成のサーバ環境を構築する」というエントリで紹介した構成は、右図の通りです。エントリ内でも「障害耐性や冗長化、負荷分散、オートスケール等の機能は完全に割り切った」と断っています。
先に説明した通り、EC2のインスタンスやRDBのインスタンスは、唐突に落ちる可能性があるのです。この構成で例えばDBが落ちたら、システムは正常稼働を続けられません。アプリサーバが落ちても同様です。
つまりこれは、AWSの考え方的には、非常に不安定で脆弱なアーキテクチャと言わざるを得ません。
HAのアーキテクチャ
では、このシステムはどのようにHAを実現すれば良いのでしょうか。
まず、インスタンスは落ちる前提であるため、少なくとも2台のapp-serverが必要です。また、AZ丸ごと落ちてもシステムが止まらないよう、この2台のapp-serverは、それぞれ別のAZに配置します。
これらのインスタンスにはELBを使ってアクセスを振り分けます。ELB自身の可用性は、詳細なアーキテクチャは公開されていませんが、内部的に確保されています。つまり、LBを実現するための内部的なEC2インスタンス（内部的なので、EC2 Management Consoleからは見えません）を複数のAZに渡って配備しています。そのため、図中では、2つのAZにまたがった曖昧な場所にELBを描いています。EC2インスタンスやAZが落ちた場合、ELBの死活監視機能によって落ちたapp-serverにはリクエストが振り分けられなくなります。
DBに対する考え方も同様ですが、こちらはもっと簡単です。RDSの設定においてMultiAZの設定をONにするだけで、マスターDBがあるAZとは別のAZに、スタンバイDBを起動し、レプリケーションを行ってくれるようになります。この設定により、マスタDBやマスタのあるAZが落ちたとしても、自動でフェイルオーバーが起こり、システムは稼働し続けるのです。
これらの考え方を理解した時、AZがなぜAZという名前なのか、合点がいったものでした。
まとめ
複数のインスタンスやAZの同時障害については、この冗長化を横に展開して行けば対応できますね。ある程度の冗長化を行っておけば、どこかが落ちたことに気付き次第、人力で復旧作業をする余裕も確保できます。その間もサービスの稼働は維持できるのです。さらに、リージョン丸ごとダウン（例えば東京が消失！）を想定するならば、別リージョンへの冗長化とレプリケーションを…。まぁどこまでやるか、あとは要件と予算次第ですね。100%完璧なものなど、残念ながら存在しないのですから。
まぁ、非冗長構成と比べるとコストは2倍〜ですが、AWSは元々がありえないくらい安いわけでありまして。開発環境ならば非HAで構いませんが、運用環境は是非ともHA構成を組むとよろしいかと思います、ハイ。