ちょっと待って！Auroraを使う時にMulti-AZが本当に必要ですか？

Guri / Hajime Oguri

2016.03.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。
Auroraへ移行するお話を頂くことが増えてきました。そこでAuroraへの移行時における冗長化のポイントを考えてみました。

RDSのSLA定義はMulti-AZが前提である旨を追記しました。

そもそもMulti-AZって？

ここではMySQLの場合のMulti-AZについて述べます。 Single-AZでは、以下の問題があります。

耐久性：
ストレージボリュームで障害が発生した時には、「最新の復元可能な時刻」以降のデータ更新が失われる。
可用性：
ハードウェア障害が発生した時に、インスタンスを再作成するため再接続までの時間が必要になる

Auroraを除くRDSではストレージボリュームにEBSと同等のものが使用されているようなので通常のディスクに比べて高い可用性と信頼性を備えています。補足すると、EBSについての具体的な数字としては「年間故障率（AFR）が 0.1%～0.2% になるように設計」されているという記載があります。RDSのサイトでは「一般的な市販のディスクドライブ（AFR は 4% 前後）」とありますが、バックアップサービスのBackblazeが書いているブログ「Hard Drive Reliability Review for 2015」によるとBackblazeでの2015年の年間故障率でも5.84%なので、一般的なHDDの20倍以上の信頼性と言うことになります。（上記AFRは磁気ディスクを前提とした内容であるため、現在主流であるSSDベースのgp2には当てはまらない恐れがあります。）

ではMulti-AZ 配置の場合にはどうなるでしょうか？

耐久性：
異なるAZのインスタンスへ同期物理レプリケーション（MySQLの場合）をしているため、障害発生時点までデータの復旧ができる。（多重障害を除く）
可用性：
MySQLの場合は通常1～2分でフェイルオーバーが完了し再接続できる。

一般的にデータストアで最も重要なことは「耐久性」です。その次に「可用性」が重要となります。それを満たすために、実運用ではRDSをMulti-AZ化するのが普通になっています。
日本のAWSユーザは諸外国に比べてRDSをMulti-AZで運用する割合が多いと聞いたことがあります。これは日本のユーザがデータの耐久性を求めているのではないかと思います。

Auroraの場合は？

ではAuroraの場合はどうなるのでしょうか？Auroraの耐久性、可用性についてまとめてみます。

耐久性：
プライマリインスタンスのみでもデータを3つのAZにかけて6個のレプリケーションを作成。データブロックおよびディスクは自動的にリペアされる。
可用性：
プライマリインスタンスのみの場合は10分未満でサービスが回復する。1つ以上のAuroraレプリカがある場合には、復旧時間は120秒未満であり多くの場合60秒未満で復元される。

つまり、データストアとして重要な「耐久性」はプライマリインスタンスのみでも十二分に高い水準になっています。
次に重要な「可用性」は10分未満で回復するのでMySQLでのMulti-AZと比較すると時間がかかりますが、オンプレミスと比較すると予備機を待機させているのと同じ状態と言えます。また、RDS for MySQLではテーブル数が膨大な数になっている時などでは、フェイルオーバーが長時間になる場合がありますが、Auroraの場合はストレージが切り離されているためデータの状況に依存せずに10分未満でサービスが回復します。

また、MySQLのフェイルオーバー先はスタンバイ機（使用できない）ですが、Auroraの場合はレプリカ（使用できる）なので、トータルの台数がAuroraの方が少ないのでコスト効率が良いです。

ではAuroraに移行するときには？

既存がRDSでMasterのみで運用している前提となりますが、必要となる可用性のサービスレベルによってはプライマリインスタンス1台のみで問題ないと考えます。

基本的に以下の考え方でSingle-AZかMulti-AZかを判断ができます。要は10分の停止が許容できてデータセンタ障害が発生した時にも事業継続が必要か？という事です。そこまでのサービスレベルを求めなければSingle-AZの構成で要件を満たせます。Single-AZではメンテナンスなどでのサービス停止も許容しなければなりませんが。

高速フェイルオーバー(＊)：Auroraのinnodb_read_onlyグローバル変数でMasterとSlaveを判断して接続先を変更する方法。[MariaDB Connector/Jの実装](https://dev.classmethod.jp/cloud/faster-failo ver-by-aurora-jdbc-driver/)があります。これを使う場合は、レプリカを用意する必要があります。

AWS Documentation » Amazon Relational Database Service (RDS) » User Guide » Amazon RDS での Aurora » Amazon Aurora を使用する際のベストプラクティス » 接続先の DB インスタンスの決定

なお、Amazon RDSサービスレベルアグリーメントによると「Multi-AZインスタンスを毎月の請求期間における月間稼働率（以下に定義する）が99.95％以上で使用できるようにするため、商業的に合理的な努力を尽くす」と規定されているので、Single-AZではSLAがありません。SLAの定義はMulti-AZが前提です。