AWSでマルチAZ構成にする？しない？

# TL;DR

* AWSで、よく「可用性を求めるならマルチAZだ」と言われるが、シングルAZと比べた時のトレードオフを知っておきたい
* AZ間の通信には料金がかかるし、そもそも構成も倍になるからお金がかかる
* AWSは多くのサービスのSLAが公開されているが、マルチAZが前提になっているものもある
    * シングルAZの場合の可用性って、算出が難しいのでは
* AZ間の通信レイテンシは、意外とかかるようなので問題になるか実測した方がよい


# マルチAZ or シングルAZ

一般にはマルチAZが推奨、とは思いますが、それでもシングルAZとする場合に以下のような観点がよく挙げられているかと思います。

* コスト重視
* 高い可用性が求められない
* 性能重視

これを、ちゃんと見ていっておこうかなと。


# リージョンとアベイラビリティゾーン（AZ）

そもそも、リージョンとアベイラビリティゾーン（AZ）という言葉について、あらためて。

[リージョンとアベイラビリティーゾーン](https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/)

リージョンについて。

> AWS にはリージョンという概念が存在します。これは、データセンターが集積されている世界中の物理的ロケーションのことです。
> 各 AWS リージョンは、1 つの地理的エリアにある、複数の、それぞれが隔離され物理的にも分離された AZ によって構成されています。

アベイラビリティゾーンについて。

> アベイラビリティゾーン (AZ) とは、1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている 1 つ以上のデータセンターのことです。AZ によって、単一のデータセンターでは実現できない高い可用性、耐障害性、および拡張性を備えた実稼働アプリケーションとデータベースの運用が実現されています。AWS リージョン内のすべての AZ は、AZ 間に高スループットかつ低レイテンシーのネットワーキングを提供する、完全に冗長性を持つ専用メトロファイバー上に構築された、高帯域幅、低レイテンシーのネットワーキングで相互接続されています。AZ 間のすべてのトラフィックは暗号化されます。ネットワークには、AZ 間の同期レプリケーションを実行するのに十分なパフォーマンスが備わっています。

アベイラビリティゾーンがひとつ以上のデータセンターで構成された単位のことで、それを地域でまとめたものがリージョン、というのがざっくりとした考え方ですね。

なので、マルチAZを使うということは、複数のデータセンターを利用するということとほぼ同義なので（ほぼ、なのは、AZがひとつ以上のデータセンターを指しているからこう書いています）、高い可用性が得られそうなことは想像に難くないでしょう。


# コスト

シングルAZからマルチAZにした時に、利用するインスタンスの数などが増えれば、そりゃあその分は増えますよね、という話がまずあるでしょう。シンプルに、倍。

たとえば、RDSを高可用性構成にして別AZにレプリカができたら、台数増えますしね。同じような構成を各AZに構築することによって、NATゲートウェイといった要素が増えていくのもコストに跳ねるでしょう。塵も積もればなんとやら。

あとは、やっぱり通信コストでしょうかね。AZを跨いだ場合はどうなるのでしょう。


## 異なるアベイラビリティ間の転送料金

VPCのFAQに書かれていました。

[Amazon RDS for PostgreSQL の料金 Amazon VPC のよくある質問](https://aws.amazon.com/jp/vpc/faqs/)

> Q:異なるサブネット内のインスタンス間のネットワーク帯域幅に対しては請求が発生しますか?

> インスタンスが異なるアベイラビリティーゾーン内のサブネットにある場合は、お客様にはデータ転送料として 1 GB あたり 0.01 USD が請求されます。

レプリケーションに関しては、AZを跨いでも無料らしいです。

[データ転送](https://aws.amazon.com/jp/rds/postgresql/pricing/?pg=pr&loc=3#Data_Transfer)


# 可用性

マルチAZを使って可用性を高めよう、という話は、まず以下の記事を読むとよいのかなと思います。

[アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/jp/builders-library/static-stability-using-availability-zones/)

AWSのサービスにはSLAがあり、以下にリストがあります。

[AWS Service Level Agreements (SLAs) / English](https://aws.amazon.com/jp/legal/service-level-agreements/?nc1=h_ls)

EC2とかは日本語のままだとリンクを失うので、言語をEnglishにして見た方がよさそうです。

[Amazon Compute Service Level Agreement / English](https://aws.amazon.com/compute/sla/?nc1=h_ls)

EC2のSLAには、EC2だけではなく、ECSやFargateも含まれています。

* EC2
* EBS
* ECS
* Fargate

[Amazon Compute サービスレベルアグリーメントを Amazon ECS および AWS Fargate に拡張](https://aws.amazon.com/jp/about-aws/whats-new/2017/12/amazon-compute-service-level-agreement-extended-to-amazon-ecs-and-aws-fargate/)

たとえばFargateのSLAを知りたい、と思った場合に、[AWS Service Level Agreements (SLAs)](https://aws.amazon.com/jp/legal/service-level-agreements/?nc1=h_ls)からたどるのは困難なので、FAQや周辺情報から探し回ったりするのだと思います。

[Amazon Elastic Container Service のよくある質問](https://aws.amazon.com/jp/ecs/faqs/)

[AWS Fargate のよくある質問](https://aws.amazon.com/jp/fargate/faqs/)

ところで、EC2のFAQでのSLAに関する記述を見てみます。

[Amazon EC2 よくある質問](https://aws.amazon.com/jp/ec2/faqs/)

> SLA では、リージョン内の Amazon EC2 および Amazon EBS の月間稼動率が 99.99% 以上になるよう保証されます。

SLA自体にも書かれているのですが、単位が「リージョン」です。マルチAZ前提っぽいですね。

一方で、EC2単一のインスタンスのSLAは90％だったりします。

[Amazon Compute Service Level Agreement / English](https://aws.amazon.com/compute/sla/?nc1=h_ls)

> AWS will use commercially reasonable efforts to ensure that each individual Amazon EC2 instance (“Single EC2 Instance”) has an Hourly Uptime Percentage of at least 90% of the time in which that Single EC2 Instance is deployed during each clock hour (the “Hourly Commitment”). In the event any Single EC2 Instance does not meet the Hourly Commitment, you will not be charged for that instance hour of Single EC2 Instance usage.

マルチAZにした場合に、これが99.99％まで上がるのはどういうロジックなんだろう？という気もしますが、AWSのEC2サービスとしてのSLAとしてはこうですと。

というか、「シングルAZの場合の可用性」はSLAから単純に導出できない気がしますね。

RDSの方も見てみましょう。こちらは、SLAのみの記載でした。

[Amazon RDS Service Level Agreement / English](https://aws.amazon.com/rds/sla/?nc1=h_ls)

> AWS will use commercially reasonable efforts to make Multi-AZ instances available with a Monthly Uptime Percentage of at least 99.95% during any monthly billing cycle (the "Service Commitment").

マルチAZの場合に99.95％と言っています。

こういう情報、特にEC2まわりを見ていくと、シングルAZの時の可用性ってけっこう低い気がしますね。

S3とかだとどうなんでしょう。FAQを見ると、こういう記述でした。

[Amazon S3 のよくある質問](https://aws.amazon.com/jp/s3/faqs/)

> S3 標準ストレージクラスは 99.99% のアベイラビリティー、S3 標準 – IA ストレージクラスは 99.9% のアベイラビリティー、S3 1 ゾーン – IA ストレージクラスは 99.5% のアベイラビリティー、S3 Glacier Deep Archive クラスは 99.99% のアベイラビリティーおよび 99.9% の SLA に設計されています。

SLAの方を見ると、99.9％のように見えます。

[Amazon S3 Service Level Agreement](https://aws.amazon.com/jp/s3/sla/?nc1=h_ls)

SLAを見る時は、各サービスのSLA、FAQ両方を見ていった方が良さそうですね。


# 性能

ここは、ネットワークに関するところがポイントでしょう。AZ間の通信レイテンシは、2msec以下らしいです。

[AWSのデータセンターの中身を、設計総責任者が話した (2/2)](https://www.atmarkit.co.jp/ait/articles/1411/20/news106_2.html)

> 複数AZ間の遅延は1、2ミリ秒であるため、（アプリケーションは）2つのAZに対して同時にコミットができる。

とは言うものの、RDSで高可用性構成を取った時にこういう記述があったり

[Amazon RDS での高可用性 (マルチ AZ)](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)

> マルチ AZ 配置を使用する DB インスタンスでは、同期データレプリケーションが発生するため、シングル AZ 配置より書き込みとコミットのレイテンシーが増加する場合があります。

以下のような記事を見てみると、実際にはそれ以上の遅延は発生するみたいです。

[AWSでアベイラビリティゾーンをまたいでのアクセスが想像以上に遅かった話](https://qiita.com/rintaro-ishikawa/items/98e26637fbd9ce20a87e)

[AZ間のレイテンシについて](http://xoxo-infra.hatenablog.com/entry/2013/05/02/032918)

[AWS EC2とRDSのリージョンまたぎのレイテンシ遅延を測ってみた](https://www.tcmobile.jp/dev_blog/infrastructure/aws-ec2%E3%81%A8rds%E3%81%AE%E3%83%AA%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%BE%E3%81%9F%E3%81%8E%E3%81%AE%E3%83%AC%E3%82%A4%E3%83%86%E3%83%B3%E3%82%B7/)

[AWSの失敗談 - しらなくてミスした話](https://qiita.com/begaborn/items/94d926fb7f741c0fd931)

これに関しては、実際の遅延がどのくらいかということと、それが許容できるかは実測あるのみというところでしょうねぇ。