【レポート】サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造 #AWSSummit

こんにちは、崔です。
AWS Summit Tokyo 2019 2日目のD2-05のセッションである「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」のレポートをお届けします。

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

スピーカー

Amazon Web Services, Inc.
Aurora, MySQL, and MariaDB
Senior Product Manager

Amazon Aurora

• マネージドサービス
• 商用DBの性能と可用性
• オープンソースDBのシンプルさとコスト効果
• MySQL/PostgreSQLと互換性がある
• 利用した分だけのお支払い

Auroraの性能と拡張性

Auroraのscale-out, ditributed architecture

• log-structured 分散ストレージシステム
• それぞれのAZに２つずつ、計6つのデータのコピーを保存
• データは10GBずつ保存され、64TBまで自動的にスケールアップ
  • 事前に増やしておく必要はない

Six-way replicated storage

• データは6ノードに非同期・並列で書き込む
• 書き込みクォーラムは4ノード, 読み込みクォーラムは3ノード正常であればOK。

Write quorum in action

• 4つのディスクに書き込まれた時点でコミットされる

I/O flow in Aurora storage node

• 1.ログレコードを受信してインメモリキューに追加
• 2.ホットログをACKでレコードを保持
• 3.レコードを整理し、ログのギャップを特定
• 4.ギャップを埋めるためにゴシッププロトコルを利用
• 5.ログレコードを新しいページバージョンに結合
• 6.定期的にログと新しいページのバージョンをS3に保存
• 7.定期的に古いバージョンをガベージコレクション
• 8.ブロックのCRCコードを定期的に検証

全てのステップは非同期

Write and read throughput

• Aurora MySQL is 5x faster than MySQL

Bulk data load performance

• Aurora MySQL loads data 2.5x faster than MySQL
• Aurora PostgreSQL loads data 2x faster than PostgreSQL

Continuous HW upgrades to boost performance

• Aurora MySQL - 2015 to 2018
  • Max write throughput - up 100%

Aurora Read Replicas

• 複数のAZに最大15の昇格可能なリードレプリカ
• REDOログベースの（物理）レプリケーションにより、レプリカの遅延が低い（通常10ms未満）
• フェイルオーバーの順序を設定可能なカスタムリーダーエンドポイント

MySQL vs Aurora　I/O profile

• MySQL I/O profile for 30 min Sysbench run（MySQL with Replica）
  • 0.78MM transactions
  • 7.4 I/Os per transaction
• Aurora I/O profile for 30 min Sysbench run
  • 27MM transactions 35倍以上
  • 0.95 I/Os per transaction　　7.7倍弱
• MySQLのレプリカ構成に比べ、Auroraのリードレプリカ構成の方が、I/O量が少なく済み、トランザクション量が35倍以上可能となる

Aurora read replicas are dedicated to reads

• MySQL READ Replica
  • 論理的な完全な変更
  • マスターと同じ書き込みワークロード
  • 独立したストレージ
• Aurora Read Replica
  • 物理的な差分の変更
  • 書き込みが発生しないレプリカ
  • シェアードストレージ

Aurora read scaling options

• クラスタごとに昇格可能な15台のリードレプリカ
• 自動的に追加・削除を行うAuto-Scalingレプリカ
• リージョンを跨いだリードレプリカ
• MySQLからbinlogを利用したレプリケーション

Aurora Grobal Database

• Faster disaster recovery and enhanced data locality
• リージョンを跨いだリードレプリカ
• High throughput : Up to 200K writes/sec
  • ディスクレイヤーでのリージョン間コピー
• Low replica lag : < 1 sec cross-country lag
  • レプリケーションの遅延が非常に小さい
• Fast recovery : < 1 min region unavailability

Aurora Parallel Query

• Auroraストレージには数千のCPUが存在する
  • クエリ処理をプッシュダウンして並列化
  • 処理をデータ近くに移動することでネットワークトラフィックと待ち時間を削減
• 実現のためには多くのチャレンジ
  • データは範囲分割されていない。フルスキャンが必要
  • データは実行中の可能性がある リードビューでは最新のデータを表示できない場合がある
  • すべての機能をプッシュダウンできるわけではない

Parallel Query performance results

• NETFLIX事例
• Parallel Queryを使うことで、インスタンスタイプをr3.8xlargeからr3.2xlargeに減らすことができた
• パラメータをONにすれば良いだけ

Aurora lock management

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

Aurora availability & management

Instant crash recovery

• Traditional database
  • 最後のチェックポイント以降からログを適用する必要
  • チェックポイント間は通常5分
  • MySQLではシングルスレッド。大量のディスクアクセスが必要
• Amazon Aurora
  • ストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで再適用
  • 並列、分散、非同期
  • 起動時に再適用なし

Cluster Cache Management - Aurora PostgreSQL（最新リリース機能！）

• Avoiding a cold cache after failover
• データベースをフェイルオーバーしてキャッシュをウォームアップするにはしばらく時間がかかる
  • DBの起動に32秒、パフォーマンスの回復には340秒かかっていた
  • それが、パフォーマンスの回復が、ほぼ起動と同タイミングにまで可能となった！！！
  • PostgreSQL 準拠の Amazon Aurora がクラスタキャッシュ管理をサポート

Aurora Backtrack

• Backtrackにより、バックアップからの復元を必要とせずにデータベースを特定の時点に戻すことが可能
  • 意図しないDMLまたはDDL操作から回復

Fast Database Cloning

• 重複したストレージコストなしでデータを重複してもてる
• クローンストレージはポインターのみを持つ