【レポート】サービス責任者が語る 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に2つずつ、計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
  • データベースをフェイルオーバーしてキャッシュをウォームアップするにはしばらく時間がかかる

Aurora Backtrack

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

Fast Database Cloning

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

コメントは受け付けていません。