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

2019/6/12(水)～14(金) の期間で開催された「AWS Summit 2019 Tokyo」の3日目、
「Going Deep on Amazon Aurora with MySQL Compatibility」の話を
以下メモ書きで記載します。

概要

スピーカー：アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト桑野章弘

Amazon Auroraは、クラウド時代にAmazonが再設計したRDBMSです。また、システムを構築する上でデータベースを切り離すことはできません。 Amazon Auroraの最新情報や、リリースされてから行ってきた機能追加や安定性向上に対する取り組みと、その内部アーキテクチャをご紹介し、実環境で運用する際に注意する点などの Tips もご紹介します。

参加理由

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

前回記事：https://qiita.com/es_t_iida/items/1f8bca982423be700a60

所感

このセッションもAuroraの話であるため、https://qiita.com/es_t_iida/items/1f8bca982423be700a60
と重複している部分はありますが、MySQL側の部分に特化していることからより詳細な話となっていました。

更に、この記事を書いている際に20190424 AWS Black Belt Online Seminar Amazon Aurora MySQLの資料を見つけ、セッションでは時間の関係上省略された機能等がAuroraにはまだまだあることを認識しました。

例えば、

あたりの機能や手法の話とか、

といった新機能の話もBlack Beltには書かれていて、このセッションでは聞けなかったものがまだまだあることを知ることができました。
当セッション参加したことで参加記事を書くこととなり、それにより更に多くの機能があることを知れたことは大きな収穫でした。

セッションに参加しなかった方は後述のメモでは省略されている部分もありますので、
今すぐBlack Beltの記事の方を読むことをお勧めします。

そして

Aurora面白い、Aurora触った開発やってみたいと思った方は是非当社にいらしてください。
僕らはAWSを使い始めてまだ１年なので、まだまだ手探り状態でやっている部分も多いです。
AWS触ったことあるなら若い人もベテランもWelcomeです！
(一緒に勉強していく気持ちがある人なら未経験でも大歓迎です)

株式会社いい生活では一緒に働く仲間を募集しています

以下メモ

Amazon Auroraの説明

Amazon Aurora

クラウド上で動作することに特化して構築され、MySQL・PostogreSQL互換のRDB
OSSのいいところを使用可。1/10のコスト。商用DB。

特色

Leveraging:AWS Servicesと連携
Lambda:イベントをSPやトリガーで実行
CloudWatch:ログやメトリクスをアップ
Identity and Access Management：IDMロールを利用してDBユーザー認証
S3をつかったバックアップ・リストア

パフォーマンス改善

2015年から2018年にかけてスループットがWriteは2倍、Readについては1.4倍
多くのパフォーマンス最適化に加えて、HWプラットフォームもアップグレード

「AuroraはAWSの歴史の中で一番早く成長しているサービス」

インスタンスのタイプが増えたこと
安定性向上等の改善
利用ユーザー

Aurora Internal

内部アーキテクチャ

Aurora Storage

SSDを利用したシームレスにスケールするストレージ
10GB〜64TBまでシームレスに拡張可能（無停止）
peer-to-peerゴシップレプリケーション
標準で高可用性：3つのAZに6つのデータコピー
S3 に継続的なバックアップ
Log Structured Storage
- Redo Logを複数の小さなセグメントに分割
- Log PageによってData Pageを作成

Aurora I/O Profile

ログコピーについては通常のMySQLのレプリカ(冗長構成)と比べて35倍のトランザクションをさばきつつ、7.7分の１のストレージサイズ

ストレージノードクラスタ

Protection Groupごとに６つのストーレージノードを使用
各ログレコードはLSN(Log Sequence Number)を持っており、
- 不足・重複しているレコードを判別可能
- 不足している場合はストレージノード間でGossip Protocolを利用し補完を行う（自己修復）

ディスク障害検知と修復

２つのコピーに障害が起こっても、読み書きに影響はない
３つのコピーに障害が発生しても読み込みは可能
自動検知・修復
クォーラムという機構
- Writeでは4/6で修復
- Readでは半分で修復

クォーラムモデル

レプリ管理のためのクォーラム

なぜ6個のクォーラムなのか？
- AWSは大規模環境
- AZ障害は影響範囲が広域
- AZ＋１の障害を許容し、修復する必要がある
- 3つのAZの場合、6つのコピーが必要
- 増やせばいいけど、コストがかかる

>>>コストと堅牢性のバランスで６としている

メンバーシップチェンジ

プロテクショングループは数千以上
ほとんどのシステムは、メンバーシップの変更にコンセンサスを使用するが、ジッタとストールを引き起こす
Auroraはクォーラムセットとエポックを使用
停止無しのAZ＋１のフォールトトレランス、積極的に障害を検知
- epoch 1:全てのノードがhealthy。最初は６ノードの場合。
- epoch 2: 一つインスタンスが死んでるっぽい→新しいノード追加(別ノードからコピー)。一時的に７ノード
- epoch 3:死んでるっぽいインスタンスはunhealthyに変更。６ノードに戻る

クォーラムの効率化

ほとんどのクォーラムベースのシステムでは読み込みにコストがかかる
Auroraはどのノードが最新でレイテンシーが少ないかの情報を持っている
- 6ノードのうち4ノードからACKが帰ってきたらWrite：OK
- その4ノードいずれかから読み取れば最新とする
リードクォーラムは修理やクラッシュリカバリに必要

コストを抑えるための工夫

6つのコピーはすべて同一ではない
- 3つのフルセグメント：データページとログレコード
- 3つのテールセグメント：ログレコードのみ(差分)
6つのコピーが必要だが、物理ストレージとしては必要な容量は6倍ではなく、3倍より少し多い程度

レプリケーション

MySQL

binlog/relay log
めちゃくちゃ重いクエリが流れてる
書き込みが多い

→つらい

Aurora

レプリケーションがbinlogによるものではない(同じディスク見るから)
マスターへの負荷を最小限に15台までリードレプリカを作成可能
10-20ms程度のレプリケーション遅延
フェールオーバーでデータロスが無い

ロックマネジメント

ロック範囲を最小限にしている
個々のロックチェイン内の複数のスキャナ

新機能

Custom Endpoints

オンラインクエリ用とか分析クエリ用のものを作れる
対象のレプリカインスタンスを指定できる

Global Database

リージョン間の話
通常1秒未満の低レイテンシなレプリと、通常1分以内の高速なFOが可能
ソースDBクラスタにパフォーマンス影響を与えない
Binlogを利用しない
クラスタ間でレプリケーション
- 但し、レプリケーション先に書き込みはできない

Aurora Serverless

負荷の少ないアプリ
可変負荷のアプリのピーク
夜間又は週末に必要とされない開発DBまたはテストDB
マルチテナントSaaSアプリケーションの統合基盤

スケールアップ・ダウン

データベース(CPU、メモリ、接続)のアプリケーション負荷を監視
スケーリングの閾値に達すると、インスタンスが自動的にスケールアップまたはスケールダウン
スケーリング操作はアプリケーションに透過的
接続とセッションの状態は新しいインスタンスに転送
スケーリングの最小及び最大値を設定

その他新機能として

Aurora Serverless Queries Directly from the AWS Management Console

マネージメントコントローラから直接クエリを投げさせる
IAMで制御可能

Aurora Serverless Database with the New Data API

HTTPSエンドポイントやSDKからのクエリアクセス
JDBCとかいらない
永続接続は不可能
サーバレスアプリケーション、軽量アプリケーション(IoTなど)

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

パラレルクエリ

OLTPワークロードの分析クエリ・リアルタイムデータの分析
クエリをストレージノードの数千のCPUにプッシュダウン
- ストレージフリートを使用して問い合わせ堀をプッシュ
- 各ノード上でクエリを実行
- データに近い位置で実行、ネットワークのトラフィックとレイテンシを軽減

>>>ETL等が高速になる可能性

パフォーマンスインサイト

もっとデータベースにドリルダウンしてみてみたい場合
例えば、重いクエリがどのロックで待っていたのか
ニアリアルタイムで確認可能

Backtrack

オペミスでデータベースの状態を特定の時点に戻す
数分で戻す

Database cloning

ストレージコストを増やすことなくデータベースのコピーを作成
データのコピーをするわけではない
プロダクションデータを使用したテスト
DB再構築
プロダクションシステムに影響を及ぼさずにスナップショットを保存

Aurora Audit ログをCloudWatchLogsで管理

特定ログでアラート発報などもできるように
直接転送可能
Filter Patternを設定することも
IAM Roleの設定が必要

まとめ

クラウド時代にAmazonが再設計したRDBMS
ストレージは性能とか要請を両立する多くの仕組みを持つ
Auroraniha継続して数々の新機能が追加されている

最新の技術を使ってお客様へ価値を届ける

参考資料

20190424 AWS Black Belt Online Seminar Amazon Aurora MySQL