aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。1年以上古いエントリは疑ってかかってください)

訳: AWSで高可用性を実現するベストプラクティス

AWS Cloud Best Practice: Introduction to High Availability Deployment | Newvem

AWSのアーキテクチャセンターにも図があるが、解説が少ないので、このシナリオ・ステップは参考になるだろう。

しかし、インフラがRoute53でリージョン間冗長性を考えるグローバルスケールになりつつある中、1台のサーバのRASとか1ラック内のサーバ2台の可用性という小さなインフラしか考えられないガラパゴスな日本人は間違いなく置いて行かれるな。。

===

最初にAWSにアプリケーションをデプロイすることは難しい。たくさんの新しい用語と概念を理解する必要がある。AWSに最初のインスタンスを起動する前に、全てのAWSの選択肢を理解する必要がある。

本稿は、AWSのインフラで高可用性( High Availability , HA)を実現するアーキテクチャ設計を簡単に紹介する。まず、単純(かつ障害に弱い)アーキテクチャ設計から始めて、複数リージョンの複合構成までステップを進める。どこまでステップを進むかは、uptimeの要件(SLA)や予算に依存するので、あなた次第である。

(注:以降の図は、AWS上のアーキテクチャを設計・配備する支援ツールであるMadeiraCloudで書かれている)

Amazon Cloud World Data Centers

Amazonクラウドは世界にDCをいくつ所有しているのだろうか?一般的な答えは、上の図に示すように7つのリージョンであるが、正確ではない。顧客、特定の法律、その他の要件によって、近くにあるリージョンを選択するだろうが、リージョンはデータセンターを地理的にグループ化したものである。

アベイラビリティゾーン(AZ)は、リージョンよりはデータセンターに近い考え方である。各AZはリージョン内で独立した場所にあり、単一障害点(SPOF)を共有しないように実装されている。なので、Amazonクラウドは18のデータセンターを持っており、地理的に近いものがグループ化されてリージョンを形成し、同一リージョン内のAZ間は低遅延・安価なネットワークで接続されている、と考えると良いだろう。

興味深い点は、AmazonがAZに与えている名前が、全てのユーザで同一ではないことだ。例えば、もしあなたと私が US Eastリージョンでそれぞれインスタンスを立てたとすると、両方のインスタンスは Virginiaにあることはわかるので、その2台で通信するのは低遅延・低価格になる。しかしもし我々が US-East-1Aにそれぞれインスタンスを立てた場合、2台が必ずしも同じAZにあるとは限らない。あるユーザが、複数のインスタンスを同じAZに立てた場合はそのようなことは発生しないが、異なるユーザのインスタンスでは発生しうる。

高可用性を最大化させるために、どのようにアプリケーションを配備するか?を示す。

下図は、1台のウェブサーバ、1台のアプリケーションサーバ、そして1台のDBサーバで構成される単純なアプリケーションのアーキテクチャ設計図である。オレンジの箱は全てEC2とRDSインスタンスで同じAZ・同じリージョンにある。これがアプリケーションをセットアップする最も単純で安い方法になるが、もしどれか一つのノードがダウンすると、アプリケーション全体がダウンしてしまう!

Cloud Application deployment schema

そこで、アプリケーションの障害許容力( resilience)を改善するために、オートスケーリング(青い箱)を各層に追加し、トラフィックを分配するためにElastic Load Balancer(ELB)をWeb層に追加し、自動的にデータを同期しながらマスタDBに何か起きた場合にはフェイルオーバーするスレーブDBを加えてみよう。

Cloud application using auto-scale

これは良い方法だ。もしどこかの層の1つのノードがダウンしても、自動的に置き換わる。しかし、同一リージョンの同一AZ内にあるので、もしAZがダウンすると、アプリケーションもダウンしてしまう!

AWSアベイラビリティゾーン(AZ)はほとんどダウンしないが、それでもダウンする。あるAZが完全にダウンした場合に備えるためには、アーキテクチャを2つのAZに冗長的に持たせて完全なバックアップを他のAZに保持することだ。

AWS Elastic Load Balancer (ELB)を使うことで、2つのAZにトラフィックを振り分けることができる。マスターDBがある一つのAZに立てていても、複数のAZに立てたスレーブDBと同期をとっているのであれば、何が発生しても問題ない。

これは、1つのAZを使うよりさらに良い。というのも、各AZはSPOFを共有しないようAWSが実装しているので、両方のAZがダウンする確率は非常に低い。しかし両方のAZは同じリージョン・同じ地理的場所にあるので、地震のような悲劇的な出来事によって両方がダウンする可能性が潜在的に存在する。リージョンがダウンするような起こりそうもない出来事の中で、それでもあなたのアプリケーションは必要だろうか?

それでも、もし究極のHAデザインが必要なら、複数リージョンにアーキテクチャを複製し、さらに、各リージョンのELBにトラフィックを振り分けるために、AWSが提供しているDNSサービス Route53を使う必要がある。また、世界中34拠点にある全エッジロケーションからコンテンツを配信するCloudFrontも使える。そう、アーキテクチャの観点からみて、我々は防弾チョッキを手にしている。

まとめ

高可用性の肝は、単一障害点SPOFの数を減らすことであるが、各ステップでアーキテクチャの要件が2倍になり、よって(すべてを常に稼働させれば)コストも2倍になることに気づく。0.09%稼働時間伸ばして99.9%SLAにすることよりも1%稼働時間を伸ばして95%のSLAにすることは、 大幅に安く上がる。SaaSベンダーは、99.9xx%のSLAを実現するための追加リソースに注意を払う必要があるし、価格プランにも組み込むことになるだろう。

すべての課題の中で、クラウドデプロイは本来、最も議論されている。その中で最も重要な見地は、HAの要件に合った堅牢なデプロイによる障害を前提としたアーキテクチャ設計「Design for failure by architecting」である。Sholomo Swidlerの有名な「10個のクラウドデザインパターン」(勝手訳)は、AWSのMiles Wardも是非見るべきだと言っている。HAのエキスパートであるNetflixSmugMugも 2011年のAWSの障害を避けるための素晴らしいアドバイスをしている。

これは、クラウドによって作られた問題ではないが、新しいソリューションである。Amazonクラウドのリージョンは、複数のアベイラビリティゾーンとリージョンに

またがってアプリケーションを簡単にスケールできる。従来のホスティングでは実現困難だったHAアプリケーションに、新しい機会を与えている。少しの時間を使ってAWSでHAアプリケーションを作る方法を習得することでUptime顧客満足度を大幅に増加させることが出来る。