Amazon AuroraのHA戦略を理解する：高可用性を実現する5つのアプローチ

この記事を読んでいるということは、Amazon Auroraという名前を一度は耳にしたことがあるのではないでしょうか。Amazon Auroraは、AWSがRDSサービス群の一部として提供するPaaSです。MySQLとPostgreSQLの2種類のデータベースエンジンに対応し、それぞれとワイヤレベルの互換性を保ちながら、フルマネージド型のリレーショナルデータベース管理システム（RDBMS）環境を提供します。では、この特徴は私たちの高可用性（HA）戦略や選択肢にどのような影響を与えるのでしょうか。

Auroraは通常のRDSと何が違うのか

「Amazon RDS上のMySQLやPostgreSQLもフルマネージドサービスではないのか」と疑問に思うかもしれません。その通りですが、両者には本質的な違いがあります。従来のRDSは、オープンソースの標準的な実装をEC2インスタンス群の上で動かし、AWSが運用管理しているものです。一方Auroraの最大の特長は、ストレージエンジンをデータベースエンジンから分離した点にあります。AWSは「関心の分離」という設計原則を、オープンソースデータベースに適用したのです。

関心の分離（Separation of Concerns）

通常、RDBMSは市販の一般的なハードウェア上で動作することを前提に設計されています。そのため、OSやハードウェアが課す制約の中で、DML・DDL処理、ACID準拠のトランザクション、レプリケーション、高可用性（HA）、耐障害性など、現代のデータベースに求められるすべての機能を実現しなければなりません。

しかし、汎用ハードウェアではなくデータベース専用に設計された環境でのみ動作すればよいのであれば、各責務を階層ごとに切り分けることができます。これにより、データベースエンジンとストレージエンジンのそれぞれが専門性の高い処理に集中できるようになり、結果として可用性とパフォーマンスが大幅に向上します。実際、Auroraは標準のMySQLと比べて最大5倍、PostgreSQLと比べて最大3倍のパフォーマンスを実現しています。

「確かに速いのはわかった。でも、専用化されたエンジンはHAにどう役立つのか？」――その疑問にお答えする前に、まずAuroraのストレージエンジンがどのように動作しているのかを簡単に見てみましょう。HAがこの分離からどのように生まれるのかが理解しやすくなります。

データがAuroraのストレージエンジンに書き込まれるとき、同エンジンは一貫性・正確性・耐久性を確保する責任を担います。データは3つのアベイラビリティゾーン（AZ）のそれぞれに2箇所ずつ、合計6箇所に書き込まれます。これらすべてを正しく実行するための複雑な処理は、ストレージエンジンが担ってくれるのです。やや単純化しすぎではありますが、本質的にはデータベースエンジンは「fire-and-forget（送りっぱなし）」でよくなり、データが書き込まれたかどうか、トランザクションログ、リカバリーの必要性などを気にかける必要がなくなります。

このようにストレージに関する関心事をデータベースエンジンから取り除くことで、さまざまなHA戦略が選択可能になります。

リードレプリカ

リードレプリカという概念自体はAuroraよりはるかに前から存在しますが、オープンソースの実装ではログシッピングやクエリのリプレイによって複製を行います。一方Auroraでは、リードレプリカはマスターと完全に同じストレージに対して読み取り専用アクセスを行います。つまり、データが書き込まれてからリードレプリカに反映されるまでの遅延は極めて小さくなります（このケースでは「レプリケーションラグ」と呼ぶこと自体が誤りと言えるほどです）。複数のリードレプリカが必要な場合も、すべてのレプリカが同じデータを見るため、標準のMySQLやPostgreSQLで問題となるマスター側の負荷や複雑さが排除されます。

これらの特徴が組み合わさることで、マスターに障害が発生した際、リードレプリカが即座に引き継ぐことが可能になります。さらに、AWSはプロビジョニングされたキャパシティを維持するために障害インスタンスを新しいインスタンスに置き換え、DNSを新しいマスターへ向けて更新します。

これは読み取りが書き込みを大きく上回るアプリケーションにとって理想的なソリューションです。ただし注意点もあります。プライマリインスタンスは書き込み負荷全体を処理できるサイズである必要があります。また、書き込みのHAを確保したいなら、少なくとも1台のリードレプリカをマスターと同じサイズでプロビジョニングし、フェイルオーバー時に昇格される優先インスタンスとして設定しておきましょう。こうしておけば、障害発生時にも読み取り・書き込み両方のキャパシティで高可用性を維持できます。

オートスケーリング

オートスケーリングとは、利用可能なサーバー群に対して水平方向にスケールアウト（インスタンス追加）やスケールイン（インスタンス削除）を自動的に行う機能です。EC2インスタンスのAuto Scalingはよく知られていますが、Auroraのリードレプリカにも弾力性を持たせられることをご存じでしたか？ 通常は、基本負荷を処理できる最小数のリードレプリカを設定し、需要の変化に応じてインスタンスを追加・削除するオートスケーリングポリシーを組み合わせます。このような弾力的な運用が可能なのも、ストレージエンジンがデータベースエンジンから分離されていることの恩恵の一つです。

有効なシナリオの一例として、B2B向けECサイトを挙げてみましょう。平日の日中はトラフィックが集中しますが、夜間や週末はほとんどアクセスがありません。商品画像や説明文へのアクセスは読み取り比率が非常に高いため、リードレプリカとオートスケーリングの双方のメリットを享受できます。リードレプリカをオートスケーリングすれば、ピーク時の需要に応えながら、オフタイムのコストを最小限に抑えられます。

クロスリージョンレプリケーション

可用性をさらに一段引き上げたいなら、別のリージョンへ複製しましょう。データベースエンジンがデータを別リージョンにレプリケートすることで、現地での読み取りや、プライマリリージョン障害時の切り替え先として活用できます。セカンダリリージョンのインスタンスはリードレプリカとして扱われます（マルチマスター構成ではありません）。さらに、セカンダリリージョン自身もリードレプリカを持つことができ、プライマリリージョンに障害が発生した場合はマスターに昇格することも可能です。

クロスリージョンレプリケーションが必要になる理由は多々あります。事業継続性、法規制、財務上の理由などにより、データを単一の地理的リージョンだけに保管することが許されないケースもあるでしょう。また、ユーザーとデータベースバックエンド間のレイテンシを低減するのも大きな目的の一つです。再びECサイトを例にとると、画像や説明文の変更は単一リージョンのマスターに対して行い、その内容をグローバルに配信して各地でローカルに読み取れるようにする、といった使い方ができます。

外部レプリケーション

では、Auroraクラスタの外でデータが必要になる場合はどうでしょうか。企業方針や規制環境の要件で外部へのデータ配置が求められるケースや、Auroraの外でデータ加工やレポート生成を行いたいケースなどがあるかもしれません。こうしたニーズには外部レプリケーションで対応できます。

Auroraから、EC2上で稼働するMySQLインスタンス、さらには社内データセンターのMySQLインスタンスへデータをレプリケートすることも簡単に行えます。この一方向レプリケーションを利用すれば、データは常にAuroraクラスタと同期され、Auroraの外でも利用可能になります。

サーバーレス

最後に紹介するのは、決して軽視できないサーバーレスです。可用性とスケーラビリティに関して最も重要な進展の一つが、サーバーレスの登場と言えるでしょう。「サーバーレス」といってもサーバーが存在しないわけではありません。意味するところは、サーバーのプロビジョニング、設定、スケーリング、メンテナンスから解放されるということです。

Aurora Serverlessを構成するには、アプリケーションに必要なキャパシティを指定するだけで、あとはAWSが、クライアントが必要なときにそのキャパシティがオンデマンドで確保される仕組みの詳細を処理してくれます。サーバーレスでは、既存のデータベースエンジン層とストレージエンジン層の2層に加えて、「プロキシ層」という新たな層が追加されます。

AWSは受信リクエストを待ち受けるプロキシサーバーのフリートを運用しています。また、リクエストに応答できるよう、ウォームプールと呼ばれるDBキャパシティが常時待機しています。最初のクエリが到着すると、プロキシフリートがそれを受け付け、ウォームプールからインスタンスを要求し、割り当て完了後にそのインスタンスへリクエストを転送します。さらに嬉しいことに、使用のために割り当てられるインスタンス数は弾力的であり、需要とAurora Serverless構成で指定した上限値に基づいてスケールイン・スケールアウトします。これも前述の戦略と同様、データベースとストレージの分離によって初めて実現できる仕組みです。設定に応じて、データベースインスタンスは一定時間あなたに割り当てられたまま即座に使える状態を維持し、タイムアウト期間が経過するとウォームプールへ返却されます。

課金は実際に使用しているリソースに対してのみ行われます。インスタンスが割り当てられている間は、その分と消費したストレージ分が課金対象となり、割り当てされていない間は消費したストレージ分のみが課金されます。

開発・検証環境のような急激な変動（スパイク）のあるワークロードや、まだ利用履歴が不足していて利用パターンを予測できない新しいアプリケーションには、サーバーレスが最適です。使っていないリソースに支払う必要がなくなり、開発チームが週末前に電源を切ったかどうか心配する必要も、ユーザーのタイムゾーンと自分の睡眠時間が重なるせいで深夜にキャパシティ調整のために叩き起こされることもなくなります。

まとめ

Amazon Auroraは、可用性・耐久性・拡張性を念頭に置いて設計されています。標準的なオープンソース実装と同じように使えば、堅牢で信頼性が高く高性能なデータベースとして機能します。しかし、Auroraの能力とそれを活かすパターンをもう少し深く掘り下げれば、ローカルでの読み取りオフロードからグローバルに分散された可用性まで、ニーズに合ったソリューションを実装できるのです。

ご意見やご質問がある場合は、フィードバックタブをご利用ください。