More than 5 years have passed since last update.

AWS Summit Tokyo 2019 参加記（サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造）

Posted at 2019-06-21

こんにちは。
株式会社いい生活のサーバープラットフォームチームでDBAやってる @es_t_iida です。

今日は、2019/6/12(水)～14(金) の期間で開催された「AWS Summit 2019 Tokyo」の2日目、
「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」
の話を以下メモ書きで記載します。

概要

スピーカー：Amazon Web Services, Inc. Aurora, MySQL, and MariaDB Senior Product Manager Yoav Eilat

このセッションでは、クラウドの技術革新を活用するためにゼロから設計された、クラウドネイティブデータベースサービスであるAmazon Auroraについて詳しく説明します。 Auroraはその記憶域として分散型マルチテナントログ構造化ストレージサービスを使用するなど、モノリシックデータベーススタックをサービス指向アーキテクチャに移行しています。 Auroraは、低レイテンシーレプリカなど、数々の革新的な機能を備えています。このセッションでは、主なイノベーション、パフォーマンス結果とその達成方法の確認、そして実際のアプリケーションについてお話しします。

参加理由

自分は今年から社内でAurora MySQL触りはじめ、AWSのドキュメントやブログ、知見を持つ方々のTwitter、個人ブログ等で情報を収集していますが、Aurora特有の機能やパフォーマンスの部分が普通のMySQLとどう違うのかを正しく理解したいと思い参加することにしました。

所感

内容としては非常に面白かったのですが、時間が足りなくて資料がかなりスキップされていたので、そこだけもったいないセッションでした。
（それだけAuroraは話すことたくさんあるってことなんでしょうが）

当社のAWS担当の方と最初に会ったときに
「Aurora PostgreSQL、力入れてますよ！」
と言ってたんですけど、「 Cluster Cache Management Aurora PostgreSQL(以下CCM) 」あたりを見ると納得。
（これ、MySQL側にも入らないかな？）

とはいえ、MySQL側のAuroraでも Aurora Parallel Query あたりは面白そうで、速度改善大好きな自分としてはぜひ試して積極的に使っていきたいと思った機能。

運用面だと

Aurora Backtrack はリカバリ時にバイナリログを使ったロールフォワードの極力減らせるし、
Fast Database Cloning もこのセッションを聞く前に試してみたが非常に便利かつ高速で、

通常のMySQLを使う場合と比べてこれらはインフラ・非インフラの人たちの負荷を大きく下げると思う。

あと、このセッションでは説明はなかった（飛ばされた中にあったかもしれない）んですが、 Custom Endpoints 　も非常に使える機能だと思いました。

参考イメージ

オンライン用とバッチ用と分析用とか分けられることでクエリを読み込むインスタンスの負荷が競合しないのは非常に安心。

Aurora MySQLは2015年から2018年にかけてスループットがWriteは2倍、Readについては1.4倍に上がってることを謳っていたのでこれからのパフォーマンスにも期待が持てますね。

スケーラブルで
レプリ遅延が最小なため参照データが新しい
DBのパラメータがデフォルトで効率よく設定されている
パラレルクエリ等の機能で速度を更に改善できる
MySQL5.7系までの機能なら基本的には使える
ロック機構が最小のロックを取るようにしていて、待ち時間を小さくしている
バックアップが自動的に取られていて安心
インスタンスが二重化しているので、万が一落ちても切り替わる
切り替わるインスタンスの重み付けができる
パフォーマンスインサイトで監視がOSとDB両方見られる（自分で監視ツールを入れる必要が無い可能性がある）
リードレプリカの利用におけるすみ分けができる
DBのクローンも簡単に作れる

このセッションを聞いたことで小さいDBでも大きいDBでもAuroraは非常に使いやすいことを再認識できました。

とはいえ、表面的なことがわかっただけでツラミはまだまだこれからなので、今後触っていく上でそういう経験談はアップしていきたいと思います。

（あとはMySQL8.0の機能も追随してくれると個人的には言うこと無いんだけどなぁ）

ちなみに、後述のメモで文字だけではイメージしづらいところもありますので、去年のAmazon Aurora_Deep Diveやre:Invent 2018のスライド等を参考資料として挟ませてもらっています。

以下メモ

Auroraとは

コマーシャルデータベースの性能と可用性
OSSDBのシンプルさとコスト効果
MySQL,PostgreSQLと互換性がある
利用した分だけ支払い

パフォーマンスとスケーラビリティ

スケールアウト・分散ストレージシステム
- Shared storage volume
  - ページ書き込み
  - 3つのAZに2つずつ、6つのデータコピー作成
  - データは10GBずつprotection groupsに保存され６４TBまで自動的にスケールアップ

それぞれのAZに２つずつ計6つのデータのコピーを保存することでAZ＋１の障害に対応

Six-way replicated storage

６つのレプリケーションされたストレージ
データは6ノードに非同期、並列で書き込む
書き込むクォーラムは4／6
ノードの修復には Peer to peer "gossip protocol”を利用

T1～T4の書き込みトランザクション
過半数に書き込み完了しなかったらロールバック

参考イメージ

参照

I/O flow in Aurora storage node

ログレコードを受信してインメモリキューに追加
ホットログとACKでレコードを保持(終了時点で結果がインスタンスに返される)
レコードを整理し、ログのギャップを特定
ギャップを埋めるためにゴシッププロトコルを利用
ログレコードを新しいページバージョンに結合
定期的にログと新しいページのバージョンをS３に保存
定期的に古いバージョンをガベージコレクション
ブロックのCRCコードを定期的に検証

全てのステップが非同期

参考イメージ

https://www.slideshare.net/AmazonWebServices/amazon-auroradeep-dive#14
参照

Aurora MySQL is 5x faster than MySQL

読み取りの速度がMySQLの5倍

Bulk data load performance

MySQLの2.5倍
PostgreSQLでも2倍

参考イメージ

Continuous HW upgrades to boost performance

2015年から2018年にかけて書き込み速度が最大2倍のスループットに

参考イメージ

https://www.slideshare.net/AmazonWebServices/repeat-1-deep-dive-on-amazon-aurora-with-mysql-compatibility-dat304r1-aws-reinvent-2018#21
参照

Aurora Read Replicas

マスター(書き込み可能なやつ)は一つ
15個リードレプリカ(読み取り専用)が作れる
REDOログベースのレプリケーションより遅延が遅い10ms未満
フェールオーバーの順序を設定可能なカスタムリーダーエンドポイント

MySQL vs Aurora I/O profile

MySQLより早いのはストレージが共有されているのが大きい

参考イメージ

https://www.slideshare.net/AmazonWebServices/amazon-auroradeep-dive#13
参照

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html
参照

過半数のインスタンスがACKを返してくるのを待つが、それのみ。

Aurora read replicas are dedicated to reads

Auroraの場合は共有ストレージなのでスレーブがWriteをしないのでReadに専念できて早い
(MySQLはレプリケーションでSQLをスレーブに流しているので、SQLが重ければその分反映が遅くなる)

Aurora read Scaling options

クラスタ毎に昇格可能な15台のレプリカ
自動的に追加・削除を行うAuto-scalingレプリカ
リージョンをまたいだリードレプリカ
MySQLのbinlogを使ってレプリカ

Aurora Grobal Database

リージョンをまたいでリードレプリカできる
例えば、

コロンブスでRWが１台
ポートランドにROのレプリカ1台、
ワシントン、ダブリンにROのレプリカ1台ずつ

上記のような構成でも、

ハイスループット　200K　Write/sec
低いレプリカラグ1秒未満　国またぎでも
早いリカバリ　1分未満　リージョン

Global Replication performance

遅延が非常に短い
秒間クエリ数は多い

Aurora Parallel Query

Auroraストレージには数千のCPUが存在する
- Aurora Parallel Queryを使うことでクエリが並列化される
- データと処理が近い(NWまたがない)状態にしてNWトラフィック削減
NetFlixの事例では
- 22本中8本のクエリは10倍の速度改善(下の図で290秒くらいかかっているQuery-10をベースに見る)
- 120倍早くなったクエリも
- かつインスタンスタイプをr3.8xlargeからr3.2xlargeに減らせた