RDBを再構築
グラバニ氏はAuroraについて「リレーショナルデータベースを再イメージした」と話す。2014年11月に開催されたAWSイベント「re:Invent」で初めて発表され、現在はまだ限定公開。開発に3年をかけたという。結果として出てきたAuroraはMySQL互換で高い性能を実現するRDBだ。AWSがAWSのために開発したRDBと言えるだろう。正式公開となればAmazon RDSからAuroraが選べるようになる。
データベースサービス担当副社長
ラジュ・グラバニ 氏
AuroraはMySQL 5.6との互換性を持つため、当初は「MySQLの新しいストレージエンジンを開発して、それに合わせてMySQLを改良したのかな？」とも思えた。しかしAuroraはそういうレベルのものではない。ほぼスクラッチからRDBを設計したイメージだ。クラウド環境、特にストレージ部分の開発にはかなり力が入っている。
AWSが目を付けたのは実存するRDBアーキテクチャが「モノリシック」であるところ。つまりRDBでいうところのデータベースとは「SQL」「トランザクション」「キャッシング」、「ロギング」までがひとつの塊となっているということ。もしスケールアウトしようとするときにはサーバーごとにこの塊をごっそり複製する必要がある。とはいえ、オンプレミス環境ならさほど違和感はないかもしれない。
しかしクラウド環境ではどうか。AWSのように多様なサービスを多く抱えている環境ではどうか。AWSは「（クラウド環境を前提として）いまRDBを設計したら、1970年代に発明されたときとは異なる形になるのでは」と考えた。RDBのモノリシックな塊を分解し、AWSが持つ多様なサービスと連携するようにRDBを新たに組み直したのがAuroraと考えていいだろう。
Auroraのデータプレーンでは先に挙げたモノリシックな塊からロギングを切り離し、ストレージのレイヤーと合体させたようなイメージとなる。ここはSSDで高速化する。さらにロギングとストレージ（加えてキャッシング）にあるデータのバックアップにはAWSの安定したストレージサービスS3を利用する。コントロールプレーンにはDynamoDB、Amazon SWF、Amazon Route 53のサービスを利用。これまで培ってきたサービスを有効活用できるのもAWSならではだ。
ロギングとストレージを担う部分はマルチテナントなSSDストレージなので、必要に応じて最大64TBまで拡張できる。書き込み時はredoログを持つ小さなセグメントで書き込み、ログページを使用してデータページを生成するという仕組みとなっている。
この仕組みはクラッシュリカバリで違いが生じる。従来のRDB（MySQL）であればクラッシュリカバリを行うときには、最後のチェックポイント以降のログを再生する（この処理には多くのディスクアクセスを必要とする）。一方、Auroraではデータとログがセットで細切れ存在しているようなものなので、ディスク読み込みと同時にredoレコードを再生することができる。redoログの処理が分散かつ並列で行えるのも有利なところ。
またAuroraではデータベースの塊からキャッシュも切り離されており、データベースをリスタートするときまでキャッシュは存続している。そのためクラッシュリカバリはとても早いと期待できる（とはいえクラッシュはできれば起きてほしくないが）。
なおAuroraではロギングとストレージのデータをSSDストレージに書き込むときには、1つのAZに2つずつ、それを3つのAZに行うため、合計で6つのレプリカが存在することになる。このデータをS3にバックアップするのだから、データが消失するリスクはほぼないと考えていいのではないだろうか。データ保護に関してはかなり徹底している。
