こんにちは。
株式会社いい生活のサーバープラットフォームチームで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にはまだまだあることを認識しました。
例えば、
あたりの機能や手法の話とか、
- Global Transaction ID support
- Aurora backup billing
- 起動バージョン・バージョンアップ対象の指定方法改善
- Serverless Endpoint Provisioning
- データベースクラスタのstop/startサポート
- Deletion Protection(削除保護フラグの設定)
- OOM Avoidance（OOM回避機能）
- Advanced Auditing
- Load Data From S3
- Export Data into S3
- 拡張モニタリング
-
Lab mode
- Hash Join
- Batched Scan
といった新機能の話も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継続して数々の新機能が追加されている
最新の技術を使ってお客様へ価値を届ける