2015年3月24日に開催されたマルレクの講義ノートです。マルレク開催概要と講演資料は下記にて。
マルレク 第六回「Amazonのクラウド・データベースAurora」講演資料：https://drive.google.com/file/d/0B04ol8GVySUuX3Q3RzJqWGJMTWs/view?pli=1
また、丸山先生のHPは下記です。
丸山事務所、「マルレク2014-1015」：http://www.digital-life365.com/%E3%83%9E%E3%83%AB%E3%83%AC%E3%82%AF2014-2015/
本記事は、丸山先生の講義を受けて、私が理解したところを記すものです。
◆注意！◆本記事に記した内容は、特に性能値について、全て、私が理解し認識している内容です。丸山先生の見解やAmazon社のアナウンス内容とは異なっている場合があります。
〜・〜
■ Amazon Auroraとは？
正式名は「Amazon RDS for Aurora」で、Amanonの提供する５つ目の「Amazon RDS」となります。
※「RDS」は「Relational Database Service」の略
「Amazon RDS for Aurora 製品の詳細」：http://aws.amazon.com/jp/rds/aurora/details/
ただし既存の４つ（※「 for MySQL」、「for PostgreSQL」、「for Oracle」、「for SQL Server」）とは異なり、Amazonのクラウドインフラを直接使い込んだ独特のアーキテクチャーで構築され、下記のような高性能さが特徴です。
WRITE性能
READ性能・（各種条件によるものの、）RDS for MySQLに対して、3〜10倍・特にアクセスの並列度が高い時の“対RDS for MySQL”性能が際立つ
・READはキャッシュに依存していて、RDS for MySQLに対して最大で20倍程度・Read Replicaへの反映ラグは、400分の1以下の10ミリ秒以下程度
他下記の特徴を備えます。
・最大64TBまで、10GB単位で自動容量増減がなされる。事前の容量決定は不要。自動増減時に、パフォーマンスやAvailabilityに影響を与えない。・MySQL 5.6 InnoDB互換のSQL I/Fをサポート。
■ Amazon Auroraの技術的特徴
プロセスが分離された階層アーキテクチャー
RDBMSの内部構造は、一般に下図のような階層構成を取るようです。そして、一般には、“Monolithic”に作られ、全て1プロセス内で動きます。
*:背景グレーの囲みがプロセスを表します。
Auroraでは、これを、下図のような階層構造に再構成して、プロセスが分けられています。
*:背景グレーの囲みがプロセスを表します。
丸山先生は「サービス指向アーキテクチャー」となっている、と表現していました。
この構成により、例えばSQL + Transactionのプロセスが落ちても、Cacheが温存されます。
READ性能は巨大Cacheに拠る
AuroraのCacheは巨大で、基本的に“全て”のデータがCache上（メモリー上）に存在します。Auroraは最大64TBの容量をサポートするというので、Cache（のメモリ）も64TB相当分用意されるはずです。WRITE時にCacheのメンテとStorageへの書き込みが行われます。CacheというよりIn-Memory DBが併設されていると捉える方がより妥当なのかもしれません。READ性能はもっぱらこの巨大Cacheによって発揮されています。
“論理的に一つ”のStorageを共有するRead Replica
「SQL + Transaction」のプロセス＝Read Replicaは多重化されます。「3つのAZ（Availability Zone）上の6つのRead Replica」が標準的な構成で、最大15個までRead Replicaを持てます。WRITEは唯一のMaster Instanceが担います。Master InstanceはRead Replicaを兼ねます。
Auroraの分散アーキテクチャーは、Shared-NothingではなくShared-Diskといえます。複数のRead Replicaは“論理的に一つ”のStorageを共有します。これによりRead Replicaクラスター自体は（※このレイヤーでは同期機構など無いので）シンプルな構造となります。
*:背景グレーの囲みがプロセスを表します。一番下のStorage層は、上位層からは、全体が論理的に一つに見えます。
“論理的に一つ”のStorageの内部は、複数のAZ（Availability Zone）上の複数の物理Storage（※おそらく各Read Replicaに対応）から構成され、その複数の物理Storage間でデーターコピーが為される、という構造を取ります。このデーターコピーが高速で、結果的なRead Replicaへの反映ラグが通常10ミリ秒以下ということです。
というよりも、最大15個の物理Storage群内におけるデータ伝播を10ミリ秒以内に完了できる方式の見通しがあったので、「論理的に一つのStorageに対するShared-Disk方式」を採ったのだ、といえるでしょう。
Log-Structured Storageが実現する高可用性
AuroraのStorageは、Log-Structuredというデータ構造を採っています。詳細は丸山先生の講演資料を参照いただくとして、イメージとしては下記のようなものです。（※あくまで概略を理解するためのイメージであり、詳細の説明としては不正確です。）
・単位ノードのリンクリスト様構造が基本構造となる。・ノードは原則追加のみ行われる。「更新」も新しい内容を含むノードの追加である。このとき、新旧ノードのリンクの繋ぎ換えがされる。・また、リンクリスト様の基本構造とは別に、「その時有効なノードのセット」を管理する「チェックポイント領域」が用意される。「更新」にてノードの繋ぎ換えが発生するとき、旧ノードセットを表すエントリーに加えて、新ノードセットを表すエントリーが「チェックポイント領域」に追加されることとなる。トランザクションのロールバックや、障害復帰時のロールフォワードは、この「チェックポイント領域」のエントリーを手掛かりに実施される。
・「更新」によって参照されなくなったノードは適宜“ガベージコレクト”される。
・「更新」も追加操作なので、ロック、排他制御は不要となっている。一方で「更新」の競合が発生する。競合は楽観ロック方式で解決する。「更新」の直前に当該ノードの現在バージョンを読み取り、バージョン値の変化の有無をチェックするのである。
一言でいえば、「WRITEが「変更差分の追記」のみで実現されている」のです。
この方式は以下のようなメリットをもたらします。
・データ自体が既に変更履歴を持っているので、別途トランザクション・ジャーナルを記録する必要がない。その分高速化できる。・物理Storage間のデーターコピーが変更差分（の追加）のみで済むので高速化できる。
このメリットが「Read Replica反映ラグが通常10ミリ秒」で「論理的なShared-Disk」が採用可能となった技術的根拠となっています。
ただこのようなLog-Structuredの方式が採用できるためには、次のような大前提があります。
・変更履歴を相当量記録することとなるので、それが可能な程度のStorage容量を用意できること。・“ガベージコレクション”をバックグラウンドで実施する必要があるので、それが可能な程度のCPUを用意できること。
いずれも、巨大クラウド・インフラにおいては容易に解決出来る前提です。一方物理リソースが限定されている環境では、Log-Structuredは選択し難い方式といえるでしょう。
■ まとめ
Amazon Auroraの特徴をまとめます。
・MySQL 5.6 InnoDB互換のSQL I/Fが提供され、MySQL前提の既存アプリがそのまま（※少なくともほぼそのまま）稼働可。・Log-Structured Storageにより、Storage層レベルでの高速データ複製を実現。最大15個のRead Replica反映ラグは通常10ミリ秒以下。また、それを前提として論理的なShared-Disk方式での分散クラスターを採用。・巨大CacheとLog-Structured Storageにより、RDS for MySQLに対して、READは最大で20倍程度、WRITEは平均5倍程度の速度を達成。
◆注意！◆本記事に記した内容は、特に性能値について、全て、私が理解し認識している内容です。丸山先生の見解やAmazon社のアナウンス内容とは異なっている場合があります。
◆以上
