Amazon Aurora ~ クラウドネイティブデータベースアーキテクチャの解剖メモ ~
はじめに
この技術メモは、Amazon Auroraのアーキテクチャを自分の学習のために整理したものだ。Auroraは従来のリレーショナルデータベースの概念を覆し、クラウド環境に最適化されたアーキテクチャを採用している。その設計思想と実装方法を掘り下げてみる。
参考にした資料は以下の通り。
- Amazon Aurora: Design considerations for high throughput cloud-native relational databases
- Amazon Aurora: On avoiding distributed consensus for I/Os, commits, and membership changes
全体像の把握
Amazon Aurora の基本概念
Auroraは、AWSが提供するOLTP（オンライントランザクション処理）向けのリレーショナルデータベースサービスだ。一般的なリレーショナルデータベースとの根本的な違いは、コンピュートとストレージの分離にある。
従来のデータベースがモノリシックなアーキテクチャを採用していたのに対し、Auroraはデータベースエンジンの下位1/4（ログ処理、永続ストレージ、クラッシュリカバリ、バックアップ/リストア）を分離し、専用の分散ストレージサービスとして実装している。
このアーキテクチャ刷新の背景には、クラウド環境におけるボトルネックの変化がある。
| 比較項目 | 従来のデータベース | Aurora |
|---|---|---|
| ボトルネック | 個々のディスクI/Oが制限要因となる | ネットワークが主な制限要因となる |
| アーキテクチャ | モノリシックなアーキテクチャ | コンピュートとストレージを分離した分散アーキテクチャ |
| 書き込み方式 | データページとredoログの両方を書き込み、増幅が発生 | redoログのみの書き込みで効率化 |
| ページ管理 | ダーティページの同期書き込みが必要 | バックグラウンドでのページ具現化による非同期処理 |
| リカバリ方法 | チェックポイントからのログリプレイが必要 | 連続的な分散バックグラウンドでのredo適用により高速復旧 |
Auroraの設計で解決しようとした主要な課題は、以下のような点だ。クラウド環境では従来のデータベース設計の前提が崩れているため、新たなアプローチが必要だった。
- ディスクではなくネットワークがボトルネックとなる環境への適応
- 書き込み処理の増幅を抑制し、ネットワークトラフィックを削減
- 素早いクラッシュリカバリと高可用性の実現
- 分散環境における一貫性の維持とジッターの低減
アーキテクチャの概要
Auroraのアーキテクチャを一言で表すなら、「ログがデータベース」という考え方だ。従来のデータベースでは、データページとログの両方を永続化していたが、Auroraではデータベースエンジンからストレージへの書き込みはredoログレコードのみとなる。
このアーキテクチャは以下の3つの大きな利点をもたらす。
| 利点 | 実現方式 |
|---|---|
| 一時的または永続的な障害に対して柔軟に対応できる | ・耐障害性があり自己修復するストレージ ・ネットワーク障害やストレージ層の障害から保護 ・マルチAZにまたがる設計 |
| 従来のアーキテクチャと比較して桁違いのトラフィック削減 | ・ネットワークIOPSの大幅な削減 ・ログレコードのみの書き込み ・データページ書き込みの排除 |
| チェックポイント不要の高速リカバリと非干渉バックアップ | ・重要機能のバックグラウンド処理化 ・バックアップとredoリカバリの継続的実行 ・分散フリートでの処理分散 |
Auroraをオンプレミスのデータベースと比較すると、運用面でも大きな違いがある。例えば、バックアップのためのメンテナンスウィンドウが不要になり、クラッシュリカバリが劇的に高速化され、可用性が大幅に向上する。
耐障害性設計の概念
クラウド規模の環境では、ノード、ディスク、ネットワークパスの障害が継続的に低レベルで発生している。これらの障害は期間も影響範囲も様々だ。一時的なネットワーク到達不能から、永続的なディスク障害、ラック全体、さらにはデータセンター全体の障害まで。
Auroraはこうした環境で高い耐障害性を実現するために、クォーラムベースの投票プロトコルを採用している。
データベースボリュームを小さな固定サイズのセグメントに分割し、これを「保護グループ」として6つの複製に分散させ、3つのAZにわたって配置する。書き込みクォーラムとして6つのうち4つ（Vw=4）、読み取りクォーラムとして3つ（Vr=3）を要求することで、次のような耐障害特性を実現している。
| 障害シナリオ | Aurora の保証 | 理由 |
|---|---|---|
| 1つのAZ全体の障害 + さらに1ノードの障害 |
データ損失なし | 読み取りクォーラム(3/6)が維持されるため |
| 1つのAZ全体の障害 | 書き込み可用性維持 | 書き込みクォーラム(4/6)が維持されるため |
| 任意の2ノードの障害 | 書き込み可用性維持 | 書き込みクォーラム(4/6)が維持されるため |
クォーラムベースのシステムを日常に例えると、Auroraのデータ保管方法は「大切な資料を6人の友人に預ける」ようなものだ。この6人は3つの異なる地域に住んでいて（各地域に2人ずつ）、あなたはどの地域でも資料を読んだり更新したりできる。
資料を更新する場合、少なくとも4人の友人に新しい内容を伝える必要がある（書き込みクォーラム）。資料を読みたい場合は、少なくとも3人の友人に確認する（読み取りクォーラム）。
この仕組みのよい点は、例えば1つの地域が大雪で孤立しても（1つのAZの障害）、残りの4人（2つの地域で各2人ずつ）に連絡が取れるため、資料の更新を続けられることだ。さらに、大雪の地域の2人と別の理由でもう1人に連絡が取れなくなっても（計3人に連絡不能）、残り3人から資料を読み出すことができる。
詳細理解
ストレージシステムの設計
Auroraのストレージは、10GB（参考資料執筆時点）のセグメントに分割されており、各セグメントは6つの複製として分散される。こうした設計により、障害発生時の修復時間を短縮している。
セグメント化されたストレージの具体的なメリットを見てみよう。
| 観点 | セグメント化の効果 | 具体的な利点 |
|---|---|---|
| 技術 | 修復単位の細分化 | 10GBのセグメントは10秒で修復可能 |
| 〃 | 並列修復の実現 | 複数のセグメント障害を同時に修復可能 |
| 〃 | ホットスポットの分散 | 高負荷領域を低負荷ノードに動的に移動可能 |
| 運用 | 運用作業の粒度向上 | メンテナンスをセグメント単位で実施可能 |
| 〃 | ソフトウェア更新の安全性 | AZ単位での順次アップデートが可能 |
| 〃 | インフラ更新の柔軟性 | 古いハードウェアから新ハードウェアへの段階的移行 |
従来のデータベースでは、書き込み増幅の問題が大きな課題だった。例えば、MySQLでの同期ミラーリング設定では、アプリケーションの1回の書き込みに対して、実際には複数の書き込みが発生する。
- redoログの書き込み
- バイナリログの書き込み
- データページの書き込み
- 二重書き込みバッファへの書き込み（ページ破損防止）
- メタデータファイルの書き込み
これらがAZ間で同期的に複製される場合、ネットワークトラフィックは膨大になる。Auroraではこの問題を「ログはデータベース」という考え方で解決している。
ログ中心設計の詳細
Auroraでは、データベースエンジンからストレージへの書き込みはredoログレコードのみとなる。データページは決して書き込まれない。その代わり、ログアプリケーターがストレージ層に移動され、バックグラウンドまたは要求に応じてデータページを生成する。
これによりネットワークIOが劇的に削減される。実験によると、レプリカを持つAuroraはミラーリングされたMySQLと比較して以下のような大幅な改善が見られる。
| 指標 | MySQL（ミラー） | Aurora（レプリカあり） | 改善倍率 |
|---|---|---|---|
| 30分間のトランザクション数 | 78万 | 2,737.8万 | 35倍 |
| トランザクションあたりのIO | 7.4 | 0.95 | 7.7倍低減 |
ログ中心のアーキテクチャは書き込みパフォーマンスだけでなく、可用性も向上させる。
ストレージノードでの処理は、フォアグラウンド（優先度高）とバックグラウンド（優先度低）に分かれている。フォアグラウンドではログレコードの受信と永続化、バックグラウンドではレコードの整理、ギャップの特定と修復、ページの具現化、バックアップ、ガベージコレクション、データ検証などが行われる。
分散コンセンサスの回避方法
分散システムでの一般的な課題の一つが、分散コンセンサスのオーバーヘッドだ。2フェーズコミット（2PC）やPaxosなどのプロトコルは、分散環境では高いレイテンシとネットワーク使用量を引き起こす。
Auroraは独自のアプローチでこの問題を解決している。ログシーケンス番号（LSN）という単調増加する値をベースに、非同期の一貫性ポイント（データベースの一貫した状態を表すLSNの特定地点）管理を行っている。
| 一貫性ポイントの種類 | 役割 |
|---|---|
| CPL (Consistency Point LSN) | ミニトランザクション(MTR)の最終ログレコードを示す特別なマーク。データベースの構造的に一貫した状態を表す |
| SCL (Segment Complete LSN) | 特定のセグメントが受信したギャップのない連続的なログレコードの上限 |
| PGCL (Protection Group Complete LSN) | 保護グループの4/6のメンバーが確認したログレコードの上限。書き込みクォーラムの成立を表す |
| VCL (Volume Complete LSN) | ボリューム全体で完全に耐久性が保証されたポイント（保存「は」できてる）。すべての保護グループのPGCL進行を妨げる保留書き込みがない |
| VDL (Volume Durable LSN) | VCL以下で最も高いCPL。構造的一貫性も保証された耐久性ポイント |
クライアントからのトランザクション開始からコミット確認までの流れと、各種LSNポイントの更新がどのように行われるかを下図に整理する（あってるかちょっと不安）。
これらのLSNポイントによって得られる主な利点は次の通りだ。
- ワーカースレッドをブロックしない（コミット処理の非同期化）
- 分散コンセンサスの回避（書き込みの順序と永続性をLSNベースで追跡）
- クラッシュリカバリの高速化（再起動時にVCL/VDLを再計算するだけで済む）
読み取り効率化とレプリカの仕組み
Auroraは読み取り効率も従来のデータベースと大きく異なる。分散クォーラムシステムでは、読み取りにも複数のノードからの応答が必要になるため、パフォーマンスが低下しがちだ。
しかし、Auroraは巧妙な方法でこの問題を解決している。
-
クォーラム読み取りの回避
データベースインスタンスは書き込み処理の追跡により、どのセグメントに最新データがあるかを把握し、直接そのセグメントからデータを読み取れる -
レプリカによる読み取りスケーリング
レプリカはライターと同じストレージボリュームをマウントし、ライターからredoログを受け取るだけでよい
従来のデータベースレプリケーションと比較したAuroraのレプリカの特徴は以下の通り。
| 比較項目 | 従来のレプリケーション | Aurora のレプリカ |
|---|---|---|
| ストレージ構成 | 専用のストレージが必要 | ストレージは共有 |
| セットアップ時間 | 時間がかかる | 素早いセットアップと削除が可能 |
| レプリカラグ | 大きい（秒〜分単位） | 最小限（ミリ秒単位） |
| フェイルオーバー | データ損失の可能性あり | データ損失なし |
実際の顧客データからも、Auroraのレプリカラグの小ささが確認されている。10,000書き込み/秒のワークロードでも、MySQLの300秒以上のラグに対し、Auroraは5.38ミリ秒という圧倒的な差がある。
スナップショット分離と構造的一貫性を維持するために、Auroraは以下のような工夫をしている。
- レプリカの読み取りビューは、ライターインスタンスの耐久性ポイントより遅れさせる（レプリカが不安定な中間状態のデータを見ることを防ぐ）
- B-Tree分割などの構造変更は、レプリカでアトミックに適用（図書館で本棚の整理をしている最中に利用者に見せると混乱するので、整理が完全に終わってから見せるようなもの）
- レプリカの読み取りビューは、ライターインスタンスの同等の時点にアンカー可能（時間的整合性の保証）
障害復旧の仕組み
Auroraの障害復旧機能は、従来のデータベースと比較して革新的だ。ARIESのような従来の復旧プロトコルでは、最後のチェックポイント以降のredoログを順次適用する必要があった。これは時間がかかるプロセスだ。
Auroraでは、以下の特徴により高速な復旧を実現している。
| 復旧プロセスの側面 | 従来のデータベース | Aurora |
|---|---|---|
| 開始点 | チェックポイントから再開 | 常に継続的に行われるredo適用 |
| 処理内容 | ログの順次適用が必要 | 起動時の特別な処理不要 |
| データベースの状態 | 完了まで全体がオフライン | すぐにオンラインに移行可能 |
| 復旧時間 | ログサイズに比例して増加 | ボリュームリカバリのみで高速 |
クラッシュ後の復旧では、データベースインスタンスは各保護グループの読み取りクォーラムを確立し、SCLからPGCLとVCLを再計算する。これにより、クラッシュ時に完了していなかった書き込みの「ぎざぎざのエッジ」を特定し、それらを切り捨てて一貫した状態を作り出す。
例えるなら、従来のデータベースは「スタート地点まで戻り、そこからすべての過程を時間をかけて再実行する」のに対し、Auroraは「すでに処理された状態をすぐに利用可能にし、未確定だった処理のみを整理する」方式といえる。これにより、100,000以上の書き込みステートメントを処理中に障害が発生しても、通常10秒以内に復旧できる。
まとめ
Auroraは、計算と永続性の分離、ログベースのアーキテクチャ、非同期処理の徹底活用により、クラウド環境に最適化されたデータベースとしての地位を確立している。単なる既存データベースのクラウド移植ではなく、クラウド環境の特性を踏まえた根本的な再設計の好例と言えるだろう。
Discussion