読者です 読者をやめる 読者になる 読者になる

たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

マルレク講義ノート:Amazon Auroraについて

2015年3月24日に開催されたマルレクの講義ノートです。マルレク開催概要と講演資料は下記にて。
 
マルレク 第六回「Amazonクラウド・データベースAurora」
講演資料:https://drive.google.com/file/d/0B04ol8GVySUuX3Q3RzJqWGJMTWs/view?pli=1
 
また、丸山先生のHPは下記です。
 
 
本記事は、丸山先生の講義を受けて、私が理解したところを記すものです。
 
注意!
本記事に記した内容は、特に性能値について、全て、私が理解し認識している内容です丸山先生の見解やAmazon社のアナウンス内容とは異なっている場合があります
 
〜・〜
 

■ Amazon Auroraとは?

 
正式名は「Amazon RDS for Aurora」で、Amanonの提供する5つ目の「Amazon RDS」となります。
 
※「RDS」は「Relational Database Service」の略
 
Amazon RDS for Aurora 製品の詳細」:http://aws.amazon.com/jp/rds/aurora/details/
 
ただし既存の4つ(※「 for MySQL」、「for PostgreSQL」、「for Oracle」、「for SQL Server」)とは異なり、Amazonクラウドインフラを直接使い込んだ独特のアーキテクチャーで構築され、下記のような高性能さが特徴です。
 
WRITE性能
・(各種条件によるものの、)RDS for MySQLに対して、3〜10倍
・特にアクセスの並列度が高い時の“対RDS for MySQL”性能が際立つ
READ性能
・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プロセス内で動きます。
 

f:id:tanakakoichi9230:20150327124400p:image

*:背景グレーの囲みがプロセスを表します。
 
Auroraでは、これを、下図のような階層構造に再構成して、プロセスが分けられています。
 

f:id:tanakakoichi9230:20150327124353p:image

*:背景グレーの囲みがプロセスを表します。
 
丸山先生は「サービス指向アーキテクチャー」となっている、と表現していました。
 
この構成により、例えば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クラスター自体は(※このレイヤーでは同期機構など無いので)シンプルな構造となります。
 

f:id:tanakakoichi9230:20150327124345p:image

*:背景グレーの囲みがプロセスを表します。一番下の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社のアナウンス内容とは異なっている場合があります

◆以上
 

関連記事