この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Summit Tokyo 2019 Day2 （本日6/13）のセッション、「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」をレポートします。面白かったです！
ライブストリーミングでのセッション参加のレポートです。
セッション概要
このセッションでは、クラウドの技術革新を活用するためにゼロから設計された、クラウドネイティブデータベースサービスであるAmazon Auroraについて詳しく説明します。 Auroraはその記憶域として分散型マルチテナントログ構造化ストレージサービスを使用するなど、モノリシックデータベーススタックをサービス指向アーキテクチャに移行しています。 Auroraは、低レイテンシーレプリカなど、数々の革新的な機能を備えています。このセッションでは、主なイノベーション、パフォーマンス結果とその達成方法の確認、そして実際のアプリケーションについてお話しします。
スピーカー
Amazon Web Services, Inc. Aurora, MySQL, and MariaDB Senior Product Manager Yoav Eilat
セッションレポート
Auroraの紹介
- コマーシャルデータベースの性能と可用性
- オープンソースデータベースのシンプルさとコスト効果
- MySQL,PostgreSQLとも互換性がある
- 従量課金
Aurora performance & scalability
Aurora Scale-out、distributed architecture
- Shared storage volumeが存在、重要な役割を司っている
- ページへの書き込みなど
- 3つのAZに2つずつ6つのデータコピーを作成
- 10GBずつデータが書き込まれる 64TBまで自動スケール
Six-way replicated storage
- 6の非同期並列書き込みのうち4つのストレージにデータが書き込まれたらコミットされたとみなす
- 読み込みは3つ
- ノードの修復は Peer to peer "gossip protocol”を利用
- 例 4つのトランザクションからPage1書き込む例で説明
- クラッシュがあった場合、4つに到達する前にクラッシュした場合はトランザクションされてないと通知される
I/O flow in Aurora storage node
- ログレコードを受信してインメモリキューに追加
- ホットログとACKでレコードを保持
- レコードを整理し、ログのギャップを特定
- ギャップを埋めるためにゴシッププロトコルを利用
- ログレコードを新しいページバージョンに結合
- 定期的にログと新しいページのバージョンをS3に保存
- 定期的に古いバージョンをガベージコレクション
- ブロックのCRCコードを定期的に検証
- 注目点
- 2終了時点で結果がインスタンスに返される
- 4で前述のゴシッププロトコルが使われている
- 6 s3にログと新しいページのバージョンを定期的に保存
Write and read throughput
通常のMySQLの5倍ほど早い
Bulk data load performance
MySQLの2.5倍ほど早い PostgreSQLより2倍ほど早い
Continuous HW upgrades
- 2015年のリリース以降、常にパフォーマンスが改善されている
- 間も無くR5インスタンスリリース
Aurora Read Replicas
- 一つのMaster
- 最大15個のRead Replica
- レプリカの遅延がかなり低い 10ms未満
- フェールオーバーの順序を設定可能 （どのリードレプリカを最初にMasterに昇格させるのか）
MySQL vs Aurora I/O profile
Auroraはストレージが共有されているからレプリカアップデートが早い
- 通常のMySQLは(レプリカアップデートまでに)5つのステップが必要
- プライマリのストレージに書き込み
- プライマリのバックアップストレージに書き込み
- リードレプリカにデータを送る
- レプリカのストレージに書き込み
- レプリカのバックアップストレージに書き込み
- Aurora - プライマリでの書き込みで最低4つのストレージノードへの書き込み完了まで待つ必要がある - レプリカは何も書き込む必要がない ストレージが共有されているから - トランザクション35倍増化 - IOの数は約1/8
Aurora read replicas are dedicated to reads
- Auroraが良いところはレプリカは100％Readに特化すれば良いところ (Writeはすでにプライマリが行なっていてそのストレージを共有しているから)
- だから早い！
Aurora read Scaling options
- クラスタ毎に昇格可能な15台のレプリカ
- 自動増加・削除を行うAuto-Scalingレプリカ
- リージョンをまたいだリードレプリカ(Aurora Global Database)
- binlogを利用したレプリケーション
- オンプレにレプリケーションもできる
Aurora Global Database(リージョンをまたいだリードレプリカ)
インスタンスではなくストレージがレプリケーションを行なう
- High throughput :Up to 200K writes/sec
- Low replica lag: < 1 sec cross-country lag
- Fast recovery: < 1 min region unavailability
Global replication performance
- 遅延が非常に短い
- 秒間クエリ数は多い
Aurora Parallel Query
- Aurora ストレージには数千のCPUが存在
- 一部をインスタンスではなくストレージノードで処理することで
- データに近いところで処理可能
- ネットワークトラフィックと待ち時間を削減
Parallel Query performance results
- Netflixの事例
- 120倍早くなったクエリがある
- 22クエリのうち8クエリが10倍以上早くなった
Aurora lock management
- MySQL 大きなロックが他を待たせてしまう デッドロック発生
- Aurora 複数のスキャナが存在 ロックがそれぞれに管理されている
可用性
Instant crash recovery
- 従来のDB
- チェックポイント間は通常5分
- 最新のチェックポイントのログからリカバリ
- Aurora
- チェックポイントという概念がない
- ストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで最適用
- 起動時に最適用無し
Cluster Cache Management - Aurora PostgreSQL
Avoiding a cold cache after failover
- ピチピチの新機能!
- https://aws.amazon.com/jp/about-aws/whats-new/2019/06/amazon-aurora-with-postgresql-compatibility-supports-cluster-cache-management/
- Cluster Cache Management無しでデータベースをフェールオーバーすると
- 32秒でデータベース起動
- パフォーマンスの90％を回復するのに340秒かかる(キャッシュウォームアップに時間がかかるから)
- Cluster Cache Management(CCM)があると
- DBはウォームアップされたキャッシュにフェールオーバー。フェイルオーバーから32秒後にパフォーマンス回復
Aurora Backtrack
- 特定時点にDBを戻す
- 数秒でその時点に戻れる
Fast Database Cloning
- 短時間でデータベースコピー
- 既存のストレージにポインターを作成する
- ポインターしかないので非常に高速にClone Strageが作られる
時間切れ
もっと紹介したいことがあるのに…と悔しそうでした(途中も何枚かスライドをスキップされていました)
おまけ
- Amazon社内でもDB移行している
- フルフィルメントセンター にてオラクルからAuroraに3月に全て移行した！
- Amazonの規模でもAuroraは対応できる！
感想
濃密なセッションでした。次から次へとAuroraの凄さとその内部構造についての説明があって非常に興味深かったです。
18
