AWSのMultiAZについて調べたので残しておく
AvailabilityZoneとは
各リージョン（TokyoやOregon、Frankfurt等）内で、物理的に離れた箇所にあるデータセンターの事を言う。
Tokyoリージョンには
- ap-northeast-1a
- ap-northeast-1b
- ap-northeast-1c
の3つのAvailabilityZoneが存在する。
また、必ずしもユーザーAのリージョンとユーザーBのリージョンが同じになるとは限らないようだ
ユーザーAの1aは物理センターのAだが、ユーザーBの1aは物理センターのBという場合もある
Multi-AZとは
一つのAZに対してアプリケーションを構築する（EC2やRDS等）Single-AZに対して、
複数のAZに対して構築することをMulti-AZと呼ぶことが多い。
Multi−AZという言葉自体は、RDSのオプションでしか存在しない（？
なぜMulti-AZ
障害耐性を上げるため、に尽きる。
ある程度の障害ならまぁなんとかなるだろ、とにかく安く済ませたい！ならSingle−AZでどうぞ
Multi-AZでどうなる
EC2
ELBにつけるEC2がMulti-AZになっている場合、AZ単位で障害が発生した場合にも別AZのEC2が応答するのでダウンタイムは存在しない。
これは単に障害だけの話ではなく、Amazonが何か緊急のセキュリティパッチを当てたい時などにAZ単位でインスタンスの強制再起動などが発生する場合にも同じことが言える。
EC2をMulti-AZにするためには、意識してインスタンスの起動AZを変更しておかなければならない。
また、起動しているインスタンスのAZを別のAZに移すといったことは出来ない。
RDS
RDSでのSingle-AZは、障害発生時の復旧は基本的に手動で行わなければならない。
Multi-AZの場合、障害発生時には自動フェイルオーバーが行われ、
1分から6分程度でスタンバイがメインとして動き始める。
これはインスタンスタイプの変更等で再起動を要する変更の場合にも適応される
自身で再起動を行う場合は、フェイルオーバーするかどうかは選択可能
フェイルオーバーによりAZが変更されるためIPは変更されるが、EndPointは同じままなので、再接続に問題はない。
当然だが、2インスタンス使うため料金は倍掛かる。
ELB
Multi-AZにするにあたり、AutoScalingで問題が発生する。
ELBがアクセスをAZに対して均等に振り分けた後、AZ内で均等に振り分けるため、AZ間でのインスタンス数が違うと負荷が偏る問題。
これについては、ELBのCrossZone-LoadBalancingを有効にすることで回避出来る。
Multi-AZの注意点
AZ間の通信には（同一リージョンであっても）1G/$0.01かかる点には注意しなければならない。
