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

こんにちは。
[株式会社いい生活のサーバープラットフォームチーム](https://jobs.qiita.com/employers/e-seikatsu/development_teams/24)で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は、低レイテンシーレプリカなど、数々の革新的な機能を備えています。このセッションでは、主なイノベーション、パフォーマンス結果とその達成方法の確認、そして実際のアプリケーションについてお話しします。

https://aws.summitregist.jp/public/session/view/75

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

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

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

とはいえ、MySQL側のAuroraでも[ **Aurora Parallel Query** ](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html)あたりは面白そうで、速度改善大好きな自分としてはぜひ試して積極的に使っていきたいと思った機能。

運用面だと 

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

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

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

#### 参考イメージ
![Screenshot from 2019-06-21 10-29-10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/07f4b700-d0d5-d703-f23d-6963915bbbe4.png)

https://www.slideshare.net/AmazonWebServicesJapan/20190424-aws-black-belt-online-seminar-amazon-aurora-mysql#32

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

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の書き込みトランザクション
過半数に書き込み完了しなかったらロールバック

#### 参考イメージ
![7ca49a96-8cd3-c3df-d2f4-6803d5d15f90.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/497629cd-b544-dfc3-0bd4-b71d155294ca.png)

参照

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

全てのステップが非同期

#### 参考イメージ
![887823e7-fa33-c20a-02a0-a2ee646a40b7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/5f2ececa-b080-33cc-7838-18a9dd7784a0.png)

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倍

#### 参考イメージ
![Screenshot from 2019-06-21 16-25-07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/2b2e844f-aa74-a735-2e45-2c8eec6c769e.png)

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

## Continuous HW upgrades to boost performance
2015年から2018年にかけて書き込み速度が最大2倍のスループットに

#### 参考イメージ
![Screenshot from 2019-06-21 16-28-31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/2c493f60-0600-ea7c-8aab-e4696b4922e5.png)

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より早いのはストレージが共有されているのが大きい

#### 参考イメージ
![Screenshot from 2019-06-21 15-54-22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/a4efa7bd-21f1-36d6-fe8f-04c756fc47d3.png)

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

![dc0accf9-d542-da0c-d88a-fe3d8eb522e6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/099e5d61-1974-bd1e-492b-5a51b49bdb90.png)

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に減らせた

#### 参考イメージ
![Screenshot from 2019-06-21 16-04-41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/03bcfa09-23cb-55cd-f8f9-1ccd3e32c8dd.png)


#### >データベースでONにして試してみては？

## ロック管理
### MySQLのロックチェーン
MySQLでは大きなロックが他を待たせてデッドロック発生

### Aurora lock manager
- 個々のロックチェーン内の複数のスキャナ
- ロックフリーデッドロック検出
- 多くの同時セッションをサポートする、高い更新スループット

#### 参考イメージ
![57e431d0-2673-9a50-278e-bd60fdbaf138.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/57c9550a-2990-cbcc-7f91-0210b434ebf2.png)

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


## Instant crash recovery
### 今までのDB
- チェックポイントが生成されて5分毎とかに作られる
- MySQLではシングルスレッド。大量のディスクアクセスが必要

### Aurora
- チェックポイントはない
- ストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで再適用
- 並列、分散、非同期
- 起動時に再適用無し

#### 参考イメージ
![bfb902a3-601c-6358-cc2f-df5a999ded42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/fa3a16ec-3f77-b0b5-5199-e5d4ae60c9d5.png)

https://www.slideshare.net/AmazonWebServices/amazon-auroradeep-dive#21

## Cluster Cache Management Aurora PostgreSQL（CCM）
新機能
https://aws.amazon.com/jp/about-aws/whats-new/2019/06/amazon-aurora-with-postgresql-compatibility-supports-cluster-cache-management/
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.cluster-cache-mgmt.html
参照

通常、DBをバックアップしてキャッシュをウォームアップするにはしばらく時間がかかります。
この（スライド）フェールオーバーの例ではCCMがないと、DBの起動に32秒、パフォーマンスの90％を回復するには340秒でした。

### How Cluster Cache Management works
CCMが有効になっていると、FOから32秒後にパフォーマンスの90％復帰

#### 参考イメージ
![Screenshot from 2019-06-21 16-21-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/e7a82b2b-4c76-9def-d5d1-a4df7c175ea4.png)

https://www.slideshare.net/AmazonWebServices/deep-dive-on-amazon-aurora-with-postgresql-compatibility-dat305r1-aws-reinvent-2018#36
参照

## Aurora Backtrack
バックアップからの復元を必要とせずにDBを特定の時点に戻すことが可能

#### 参考イメージ
![1565504f-30ae-459a-9bdd-16831ad2988b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/65324cb9-b454-79d4-47c3-ee4a554d6fd7.png)

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

## Fast Database Cloning
- 重複したストレージコスト無くデータを重複して持てる
- クローンストレージはポインターのみ持つ

#### 参考イメージ
![9697764a-7e2c-cd45-3eff-c6e1c7c36b03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/136073/f0a0f446-44d4-aa44-a655-298e9eb26f0e.png)

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

## 参考資料
https://www.slideshare.net/AmazonWebServices/amazon-auroradeep-dive
https://aws.amazon.com/jp/about-aws/whats-new/2019/06/amazon-aurora-with-postgresql-compatibility-supports-cluster-cache-management/
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html
https://www.slideshare.net/AmazonWebServicesJapan/20190424-aws-black-belt-online-seminar-amazon-aurora-mysql
https://www.slideshare.net/AmazonWebServices/deep-dive-on-amazon-aurora-with-postgresql-compatibility-dat305r1-aws-reinvent-2018
https://www.slideshare.net/AmazonWebServices/repeat-1-deep-dive-on-amazon-aurora-with-mysql-compatibility-dat304r1-aws-reinvent-2018

# 最後に
AWSを使い始めてまだ１年。まだまだ手探り状態でやっている部分も多いので、
[株式会社いい生活では一緒に働く仲間を募集しています。](https://jobs.qiita.com/postings/197)