カスタマーサクセス部 佐竹です。
本日は、Amazon RDS と Amazon Aurora における Multi-AZ オプションを DB エンジンごとに整理する目的でブログを記載します。
はじめに
Amazon RDS 及び Amazon Aurora はデータベース管理者のインフラ保守コストを大幅に引き下げてくれるサービスで、今現在でも非常に人気のあるサービスです。
現在、RDS で選択が可能なデータベースエンジンは以下の通りです。
RDS の DB エンジン一覧
- Amazon RDS for MySQL
- Amazon RDS for PostgreSQL
- Amazon RDS for MariaDB
- Amazon RDS for Oracle
- Amazon RDS for SQL Server
そして、Amazon Aurora で選択が可能なデータベースエンジンは以下の通りです。
Aurora の DB エンジン一覧
- Amazon Aurora MySQL-Compatible Edition
- Amazon Aurora PostgreSQL-Compatible Edition
Aurora においてはエンジンによる機能差は少々あるものの、基本的には同一の機能が提供されておりますので、本記事内の Amazon Aurora はエンジンを加味せず記載させて頂きます。
ここまで前置きでした。
Multi-AZ DB cluster の機能追加
本題です。2022年3月に、新しい Multi-AZ オプションがリリースされました。
これにより、RDS におけるデプロイメントオプションの選択は複雑性を増しています。今回はそれを整理するのが目的です。
なお、本資料は2022年6月時点の資料となりますため、今後のアップデートによって状況が変わる可能性がございます。
Multi-AZ DB cluster 発表以前の Multi-AZ オプションのおさらい
Multi-AZ オプションは RDS におけるデプロイメントオプションの1つです。
Multi-AZ オプションを利用することで、複数のアベイラビリティゾーンにそれぞれ DB インスタンスを配置することができます。これにより可用性を向上させることが可能で、特に本番環境で有効なオプションです。ただし、スタンバイの DB インスタンスにはアクセスが不可能です。リードレプリカが必要な場合は、別途3台目の DB インスタンスを構築する必要があります。
この「スタンバイ DB インスタンスへとアクセスできない」という制約は「せっかくインスタンスがあるのに使えないのは勿体ない」という思いを同時に発生させていました。
この仕様を改善して実装されたと考えられるのが、Amazon Aurora です。Aurora における Multi-AZ は、スタンバイ DB インスタンスの役割を Aurora リードレプリカ（Reader node）が兼ねます。このため、Amazon Aurora ではリードレプリカの数を増やすことで、レプリケーションインスタンスの数も3以上にすることが可能です。これにより、Aurora では3つ（もしくはそれ以上）のアベイラビリティゾーンへ DB インスタンスを配置する冗長構成も可能となっています。これは、スタンバイインスタンスを1つしか持てない RDS の Multi-AZ では実装不可能な構成です。
図にすると以下の通りです。
ここまでの整理
| 項目 | Amazon RDS | Amazon Aurora |
|---|---|---|
| Multi-AZ の実装 | 可能 | 可能 |
| Multi-AZ スタンバイインスタンスへのリードアクセス | 不可能 | 可能 |
| Multi-AZ で2台以上のスタンバイインスタンスの構築 | 不可能（1台のみ） | 可能 |
ここまでが、Multi-AZ DB cluster 発表以前の Multi-AZ オプションのおさらいとなります。これまでの状況（経緯）を把握しておくことで、この後の話が理解しやすくなります。
Multi-AZ DB cluster 発表以後の Multi-AZ オプション
ここに追加で実装されたのが、RDS における「Multi-AZ DB cluster」です。これにより、既存の RDS における Multi-AZ のオプションは「Multi-AZ DB instance」という名称に変更されました。以下はマネジメントコンソールの画面キャプチャになります。
RDS に新機能として追加された「Multi-AZ DB cluster」は一体どのような機能でしょうか？
要点を2つにまとめてみます。
- 2つのアベイラビリティゾーンの冗長構成から、3つのアベイラビリティゾーンでの冗長構成に
- スタンバイインスタンスが Reader DB インスタンスとなり、読み取りアクセスが可能に
これまで不可能だった、これら2点がまとめて解決できる機能となっています。
既存の「Multi-AZ DB instance」と「Multi-AZ DB cluster」を比較し、構成図にまとめてみました。
Multi-AZ DB cluster に対応する DB エンジン
現時点で Multi-AZ DB cluster は、MySQL と PostgreSQL でのみ提供されています。その他の DB エンジンでは実装不可能となります。
加えて、これは費用面での注意ですが、ストレージが io1 (Provisioned IOPS) でしか実装できません。このため、インスタンスの数と費用が3倍になるだけでなく、ストレージの利用料含めて高額になります。
Multi-AZ DB cluster を含めた Multi-AZ オプションの整理
以下に、現時点でのまとめを記載します。テーブルで記載するには横幅が足りないため、画像で埋め込ませて頂きました。
リザーブド DB インスタンスが購入できない
以下の公式ドキュメントに記載がありますが、Multi-AZ DB cluster には様々な制約があります。
具体的には、対応していない機能として、Amazon RDS Proxy、AWS CloudFormation、Read replicas などが利用できませんが、リザーブド DB インスタンスにも対応しておりません。よって、コスト最適化のために RI の購入を検討されている場合は「RI が購入できない」という本仕様にご注意ください。
今後の機能拡張で対応する可能性はございますが、2022年8月時点では RI に対応しておりません状況です。
※ドキュメントがアップデートされており、現在は RI に対応済です（マルチ AZ DB クラスターのリザーブド DB インスタンス）
まとめ
本日は、Amazon RDS と Amazon Aurora における Multi-AZ オプションを整理する記事を記載しました。
RDS の Multi-AZ DB cluster が出たことで Multi-AZ オプションが複雑になったと感じますが、本ブログを読むことで少しでも整理の助けになればと存じます。
なお、途中でも少し触れましたが、Multi-AZ DB cluster はストレージが io1 (Provisioned IOPS) でしか実装できません。また、スタンバイインスタンスの数も2台となったことから、費用はシングルインスタンスと比較すると3倍です。
このため、どうしてもアベイラビリティゾーンを3つ使った高可用性が求められる場合や、自動フェイルオーバー期間が60秒では長く、35秒に短縮する必要がある場合には Multi-AZ DB cluster が有効ですが、費用面を加味せずに有効にするのは躊躇われる機能と感じます。費用対効果は十分に加味した上でご利用ください。
最後に補足ですが、その他の詳細な機能の差は以下の公式ドキュメントもご参考ください。
それでは、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
