AWSのリージョンとアベイラビリティーゾーン
次は各「リージョン」とその中身のお話です。
まず出てくる重要な概念が「アベイラビリティーゾーン」です。
AWSにおけるリージョンは2つ以上の「アベイラビリティーゾーン」から成り立っており、「アベイラビリティーゾーン」は1つ以上の独立したデータセンターで構成されています。
具体的には、AWSの東京リージョン（"ap-northeast-1"）では、2つのアベイラビリティーゾーンを利用いただくことができ、各アベイラビリティーゾーンには"ap-northeast-1a"や"ap-northeast-1c"といったIDがつけられています（以前よりお使いいただいているお客さまの中には3つのアベイラビリティーゾーンをお使いいただける方もいらっしゃいます）。
リージョンとアベイラビリティーゾーンの関係については「リージョンとアベイラビリティーゾーンに関する概念」にある次の図を見ていただくのが一番分かりやすいと思います。
2016年11月現在、38のアベイラビリティーゾーンが運用されており、多くのリージョンは2〜3のアベイラビリティーゾーンで構成されていますが、バージニア北部リージョンでは古いアベイラビリティーゾーンも含めると5つ（！）もあったりします。
またアベイラビリティーゾーンと並んで重要な概念が、下図で「Transit」と描かれている「Transit Center」です（AZが「アベイラビリティーゾーン」です）。
AWSを使うにあたり意識していただく必要はない概念ですが、各アベイラビリティーゾーンはこのTransit Centerを介して、他リージョンやインターネットサービスプロバイダ、コンテンツサービスプロバイダなどと接続されています。つまり、各リージョンにおけるインターネットへの接続はこのTransit Centerを経由しておこなわれているとも言えます。
Transit Centerもアベイラビリティーゾーンと同じようにそれぞれ独立しており（次の項で詳しくお話しします）、一方の障害が他方へ影響することがありません。つまり、一つのTransit Centerに問題が発生しても各アベイラビリティーゾーンのインターネットへの接続性に影響はなく、高い可用性を実現することができます。これが各アベイラビリティーゾーンを直接インターネットと接続せず、Transit Centerを経由する設計となっている背景です。
ちなみに、PeeringDBというサイトでは、AWSを初めとする各種サービスプロバイダがどんなデータセンターやInternet eXchange（IX）とつながっているかを調べることができますが、AWSではこの「Transit Center」からIXなどにつながっています。
アベイラビリティーゾーン
アベイラビリティーゾーンについてさらに詳細に見ていきましょう。
アベイラビリティーゾーンの大きな特徴の一つとして、アベイラビリティーゾーン間の遅延が2ms以下（多くの場合1ms以下）となるように設計されているという点があります。
さてここで、1ms〜2msの遅延（往復）が発生する距離というのはどれくらいでしょうか？
光が通信路を通ると、おおよそ30％〜40％くらい遅くなるので、間とって35％で計算してみます。
- 光の速度：30万km/秒 × 65% ÷ 1000 ÷ 2 = 97.5km/ミリ秒
つまり、おおよそ100km〜200kmの範囲内にアベイラビリティーゾーンは用意されていると考えられます（実際には通信路は全然直線にはならないので、もっと近くにないと期待した遅延値にならないと思いますが、ここではさておきます）。
次の図では東京を中心に100km圏内（小さい円）と200km圏内（大きい円）を示しています。
こう考えると、アベイラビリティーゾーンが物理的（地理的）にどんな広がりをもっているか、おおよそのイメージをもっていただけるかと思います。
ところで、そもそもなぜ「アベイラビリティーゾーン」という考え方が導入されたのでしょう。
アベイラビリティーゾーンのような考え方が出てくるまで、アプリケーションの安定性を高めるためには、アプリケーションが動いているサーバだけでなくサーバが設置されるデータセンターの信頼性を上げることが必須でした。それは、サーバをどんなに冗長化しても、電力供給が止まればただの箱になってしまうためです。
そのため、電源設備・空調設備の2重化、3重化、蓄電池や発電機の用意、外部からデータセンターへのファイバパスやデータセンター内のファイバパスの異経路化などなど、信頼性の向上のために様々な対策がとられてきました。
しかし、データセンターも落ちます。ここでリンクしたThe Registerの記事は、Telecityというデータセンター事業者（現Equinix）の運営するロンドンのデータセンターで、2015年11月に大規模な障害があった時のものです。このように、有名なデータセンター事業者の運営するデータセンターでも、しかも2015年になっても、大規模障害は発生するのです。
このように、大規模なデータセンターを長期間運用した場合、結局は99.999％くらいの信頼性となってしまうため、1年間で5分くらいは障害が発生するものと想定する必要があります。
- 60分 × 24時間 × 365日 × 0.00001 = 5.256分
そのため従来は、非常に重要なアプリケーションを動かしており、より高い稼働率を求める場合は、遠く離れた複数のデータセンター間でアプリケーションを冗長運用していました。
（ただし、そもそも99.999％というのは非常に高品質であり、日本データセンター協会制定のデータセンターファシリティースタンダードでは、ティア4でエンドユーザの稼働信頼性を99.99%以上と想定しています。）
たとえば日本国内だと冗長運用のために東京と大阪のデータセンターを使う例が多く見られますが、東京〜大阪間の直線距離は400kmくらいで、往復遅延はおおよそ10msくらいになります。10msという値自体は大きくないですが、たとえばSSD（Solid State Drive）への読み書き遅延と比べるとかなり大きい値と言えます。
米国内ではさらに遅延は大きくなり東海岸〜西海岸の間だと一般的に約70msほどの遅延があり、アプリケーションにとってもかなり大きな遅延となります。
そこで「アベイラビリティーゾーン」の登場です！
耐障害性能を確保し、データのリアルタイムな同期を行う場合、低遅延と呼べる範囲内に独立した複数のデータセンターが必要です。アベイラビリティーゾーンによって、高い信頼性と運用の容易性を実現することができるのです。
その恩恵を受けているのが、AWSのサービスでいうと例えばAmazon Relational Database Service（Amazon RDS）におけるマルチAZ配置です（AZはアベイラビリティーゾーンの略）。従来、データベースの冗長構成は色々考えなければならないポイントが多く、設計も運用も煩雑なものでした。しかし、RDSでは管理者が数クリックで簡単にフェイルオーバーを実施でき、アプリケーションに対する影響も限定的なものとなります（戻すのも、もちろん数クリックです）。
マルチAZ配置は、アベイラビリティーゾーンという新たな考え方を導入することでアプリケーション側からインフラ側に期待する前提が変化し、それによってアプリケーション側の設計をも変えることができるようになったために実現可能となった、といえる好例かと思います。
アベイラビリティーゾーンという考え方が無く、遅延が保証されない場合、冗長構成を取る際は必ず非同期状態を想定する必要がありますが、低遅延が保証されている場合は（実施的には）その必要がなくなり、同期状態の管理等を大幅に簡素化できます。また、切り替えも瞬時にできるため、切り替え中のダウンも想定する必要がありません。
つまり、アベイラビリティーゾーンの登場により、複雑さを増すこと無く高信頼なインフラを構成することが可能となり、アプリケーションを設計する際の信頼性に関する考え方を大きく変えることができるようになったのです。
