[レポート] DAT304: ディープ・ダイブ・オン MySQL互換Amazon Aurora #reinvent

大栗です。

re:InventでMySQL互換Auroraのディープダイブセッションに参加したのでレポートします。

レポート

Amazon Auroraはオープンソース料金のエンタープライズデータベースであり、マネージドサービスとして提供している

Auroraはたくさん顧客が導入しており、AWS史上最も早く成長している。

パフォーマンス

伝統的なデータベースアーキテクチャ

一つの箱にモノリシックなスタックでコンピュートとストレージが結合している

伝統的な分散データベーススタック

• シャーディング
• シェアード・ナッシング
• シェアード・ディスク

同じモノリシックなスタックで、分散合意アルゴリズムが貧弱である。

Aurora: スケールアウトな分散アーキテクチャ

アプリケーションからストレージへログをプッシュする

4/6書き込みクォーラムとローカルトラッキング

ログアプリケータの動作

マスタへ順々に書き込まれたデータがストレージのページに対して順々に書き込まれ、レプリカへ非同期でレプリケーションされる。オンデマンドでログが提供されて、レプリカもそのログを読み込んでいく。つまりログがデータベース！

MySQL vs Aurora I/Oプロファイル

MySQLとレプリカではマスタがストレージに書き込むデータと同じものをレプリカインスタンスに送る必要がある。

Amazon Auroraでは非同期な4/6クォーラムでストレージに書き込み、一分のデータのみレプリカに送る。

Sysbenchの計測でトランザクション数が35倍増え、トランザクションあたりのI/O回数が7.7倍減る。

読み書きスループット

Aurora MySQLはMySQLと比べて5倍高速

バルクデータロードのパフォーマンス

Aurora MySQLはMySQLと比べて2.5倍高速

読み込みスケールアウト

MySQLでは、論理的に変更したデータ全体を書き込み、マスタへの書き込みと同量の書き込みをレプリカにも行う必要がある。

Amazon Auroraでは、物理的に変更した差分を書き込み、レプリカに書き込まない

Aurora MySQLの論理と物理のレプリカラグ

Auroraの論理レプリカラグは増えていくが、Auroraの物理レプリカラグは20ms程度で安定する。

クォーラムとローカルトラッキングの動作

待っているトランザクションが4個あるとする。各々がストレージに書き込まれコミットするが、一部のトランザクションデータで書き込みが6個全部完了していない状態になったとする。書き込みが完了していないストレージノードは内部でレプリケーションされるので、重い分散コミットは不要。

負荷時の性能変化

レスポンスタイムが、Amazon Auroraは安定するがMySQLでは安定しない

スレッドモデルが、MySQLではクライアントの接続ごとに独立しているが、Auroraではepoll()で受けてラッチ無しのタスクキューに入れられる。

そのためMySQLのロックマネージャではスキャンを行うと各処理がロックされるが、Auroraではスキャンと並行して削除や挿入を行える。

時間経過での性能向上

2015年から2018年で、最大書き込みスループットや最大読み込みスループットが伸びている。

パフォーマンスパラメータは何か？

異なるハードウェア設定に対する事前チューニングか自動チューニング

リカバリ時間 vs 書き込み性能

MySQLではチェックポイントの大きさによって書き込み性能とともにリカバリ時間も伸びるがAuroraは書き込み性能が高くてもリカバリ時間が短い。もはやリカバリ時間と書き込み性能はトレードオフではない！

分散データベースの比較

既存のマルチマスタソリューション

分散ロックマネージャ

非常に重い同期処理で悲観的でネガティブなスケーリング

読み書きできるグローバルな順序付け

グローバルエンティティ：スケーリングがボトルネック

2層コミットのPaxosリーダー

非常に重い合意プロトコル：パーティション超えクエリによるホットパーティションと奪い合い

Auroraマルチマスタのアーキテクチャ

• 悲観的ロック無し
• グローバルな順序付け無し
• グローバルなコミット調整無し
• 楽観的コンフリクト解決
• 分離されたシステム
• マイクロサービスアーキテクチャ

Auroraマルチマスタの動作（幸運なパス）

異なるマスタが異なるテーブルに対してコンフリクトがない書き込みを行う。この場合は同期不要。

Auroraマルチマスタの動作（物理的なコンフリクト）

異なるマスタが同じテーブルに対して物理的なコンフリクトがある書き込みを行う。この場合は楽観的コンフリクト解決を行う。

Auroraマルチマスタの動作（論理的なコンフリクト）

異なるマスタが同じテーブルに対して論理的なコンフリクトがある書き込みを行う。この場合は分散ロックが不要。

Auroraマルチマスタのグローバルリードとは？

（筆者注：マスチマスタの動作について理解が不足しているので、セッション動画を見ることをお勧めします）

Auroraマルチマスタ間は非同期でデータをやり取りしている。各々はSingleというステータスになっている。あるマスタノードに対して更新すると対象マスタがEngagedのステータスとなる。別のマスタに対してローカルリードする場合は、個別のノードのデータを読み込み、グローバルリードを行う時には別の元データにアクセスしてステータスがEngagedになります。

Auroraマルチマスタのグローバルリードはどう動いてるか？

（筆者注：マスチマスタの動作について理解が不足しているので、セッション動画を見ることをお勧めします）

N1はT2とT3がキャッチアップするまでレプリケーションを待つ。

グローバルな整合性結果をクライアントを返す。

• 書き込みパスの待機がない
• グローバルな整合性のある読み取りの場合のみレイテンシが増加する
• セッションごとに構成可能

Auroraマルチマスタ - サマリ

• リニアなスケーリング → 楽観的コンフリクト解決
• 継続的な可用性 → マイクロサービスアーキテクチャ
• 高い耐久性 → 6個のコピー、AZ当たり2個のコピー
• SQL互換性 → インデックス、成約、トリガー、プロシージャ、ファンクションなどのサポート、

クエリレイテンシの短縮

• バッチスキャン
• ハッシュジョイン
• Asynchronous Key Prefetch

パラレルクエリの性能向上

TPC-Hのクエリのレスポンス時間の低下

• ピークで最大18倍
• 22クエリ中10クエリは2倍以上スピードアップ

クエリレイテンシの短縮 - パラレルクエリ

• 並列、分散処理
• 近いデータを処理して押し下げる
• バッファプールの汚染を低減する

パラレルクエリのアーキテクチャ

パラレルクエリの性能向上

• ストレージノードからのネットワークトラフィックが240倍低減
• OLTP性能のスループットに対するインパクトは50%以上から4%以下に低減

可用性

Auroraのアーキテクチャ - 高可用性

分散（10GBストライプ、6重化）

• AZ+1の障害でも生き残る

ログ構造

• 継続的バックアップ
• Backtrack
• 即時にクラッシュredoリカバリ
• 高速フェイルオーバー
• マルチマスタによる継続的な可用性

グローバルレプリケーション

迅速なDR復旧とデータの地域化の強化

管理性

Performance Insughts

• データベースの負荷をダッシュボードで表示する
• ボトルネックの原因を見分ける
• タイムフレームが調整可能

簡素化された管理

• 64TBまで自動でストレージ拡張
• 負荷分散できるリーダーエンドポイント
• 自動的な再ストライプ、ミラー修復、ホットスポットの管理、暗号化
• リーダーエンドポイントのオートスケーリング

Aurora Serverless

Aurora Serverlessの特徴は

• アプリケーション負荷応じて自動応答する
• 10秒以内にキャパシティを上下できる
• 新しいインスタンスに温まったバッファプール
• マルチテナントプロキシが高可用性

WebサービスデータAPIの紹介

• Lambdaアプリケーションからデータベースにアクセスできる
• HTTPリクエストにパッケージされたSQL文
• プロキシの後ろでコネクションプールが管理される

さいごに

Auroraのアーキテクチャはある程度理解しているつもりでしたが、マルチマスタ周辺の動作についていまいち理解できていないことがよく分かりました。またAurora Global Databaseの発表前のセッションでしたが、ヒントになるような内容も含んでおり面白いセションでした。

Auroraのアーキテクチャについては、別に論文が出ており2017年に出た物は読んだのですが2018年にも次の論文が出ているので読んでいきたいと思います。