Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Amazon Aurora - Auroraの止まらない進化とその中身

10,813 views

Published on

2017/09/06 db tech showcaseでの発表資料「Amazon Aurora - Auroraの止まらない進化とその中身」です - http://www.db-tech-showcase.com/dbts/tokyo

Published in: Internet
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Amazon Aurora - Auroraの止まらない進化とその中身

  1. 1. Amazon Aurora Auroraの止まらない進化とその中身 Yutaka Hoshino, Database Specialist Solutions Architect Amazon Web Services Japan K.K.
  2. 2. 内容についての注意点 • 本資料では2017年9月6日時点のサービス内容および価格についてご説明しています。最新の情報は AWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。 • 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違が あった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。 • 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費税 をご請求させていただきます。 • AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.
  3. 3. データベース管理を簡単に • データベースを数分で作成可能 • 自動でパッチの適用 • 数クリックするだけでスケールアウト可能 • S3への継続的なバックアップ • 障害の自動検知と自動フェールオーバ • DBAが本来行うべき作業に注力して頂けるように – スキーマ設計・チューニング – クエリ設計・チューニング などなど Amazon RDS
  4. 4. Amazon Auroraの特徴 ハイパフォーマンス フルマネージド 高可用性・高耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
  5. 5. • ライセンス料金は 不要 • ロックインもない • 使った分だけ課金 vCPU Mem Hourly Price db.t2.small 1 2 $0.063 db.t2.medium 2 4 $0.125 db.r3.large 2 15.25 $0.35 db.r3.xlarge 4 30.5 $0.70 db.r3.2xlarge 8 61 $1.40 db.r3.4xlarge 16 122 $2.80 db.r3.8xlarge 32 244 $5.60 • ストレージ: $0.120/GB/月 • IO課金: $0.240/100万リクエスト • 東京リージョンの価格 Amazon Auroraの価格 *NEW* *NEW*
  6. 6. アーキテクチャ
  7. 7. Auroraのストレージ • SSDを利用したシームレスに スケールするストレージ – 10GBから64TBまでシームレスに自 動でスケールアップ – 実際に使った分だけ課金 • 標準で高可用性を実現 – 3AZに6つのデータのコピーを作成 • Log Structured Storage SQL Transactions AZ 1 AZ 2 AZ 3 Caching Amazon S3
  8. 8. ストレージノードクラスタ • Protection Group毎に6つのストレージノードを使用 • 各ログレコードはLog Sequence Number(LSN)を持っており不 足・重複しているレコードを判別可能 • 不足している場合はストレージノード間でゴシッププロトコルを利用し補完を行う
  9. 9. IO traffic in Aurora (ストレージノード) LOG RECORDS Primary instance INCOMING QUEUE STORAGE NODE S3 BACKUP 1 2 3 4 5 6 7 8 UPDATE QUEUE ACK HOT LOG DATA BLOCKS POINT IN TIME SNAPSHOT GC SCRUB COALESCE SORT GROUP PEER-TO-PEER GOSSIPPeer storage nodes 全てのステップは非同期 ステップ1と 2だけがフォアグラウンドのレイテンシーに 影響 インプットキューはMySQLの1/46 (unamplified, per node) レイテンシーにセンシティブな操作に向く ディスク領域をバッファーに使ってスパイクに対処 OBSERVATIONS IO FLOW ① レコードを受信しインメモリのキューに追加 ② レコードを永続化してACK ③ レコードを整理してギャップを把握 ④ ピアと通信して穴埋め ⑤ ログレコードを新しいバージョンのデータブロックに 合体 ⑥ 定期的にログと新しいバージョンのブロックをS3に 転送 ⑦ 定期的に古いバージョンのガベージコレクションを実 施 ⑧ 定期的にブロックのCRCを検証
  10. 10. ディスク障害検知と修復 • 2つのコピーに障害が起こっても、読み書きに影響は無い • 3つのコピーに障害が発生しても読み込みは可能 • 自動検知、修復 SQL Transaction AZ 1 AZ 2 AZ 3 Caching SQL Transactio n AZ 1 AZ 2 AZ 3 Caching 読み書き可能読み込み可能
  11. 11. セキュリティ • データの暗号化 – AES-256 (ハードウエア支援) – ディスクとAmazon S3に置かれている全ブロックを暗号化 – AWS KMSを利用したキー管理 • SSLを利用したデータ通信の保護 • 標準でAmazon VPCを使ったネットワークの分離 • ノードへ直接アクセスは不可能 • 業界標準のセキュリティとデータ保護の認証をサ ポート Storage SQL Transactions Caching Amazon S3 Application
  12. 12. フェイルオーバとリカバリ
  13. 13. フェイルオーバ と リプレース • リードレプリカが存在する場合は1分程でフェイル オーバ可能 – RDS for MySQLよりも高速にフェイルオーバ可能 – リードレプリカが存在しない場合は10-15分程 • Multi-AZ配置として別AZで起動可能 – RDS for MySQLと違いリードアクセス可能
  14. 14. 高速でより予測可能なフェイルオーバー時間 App runningFailure detection DNS propagation Recovery Recovery DB failure MYSQL App running Failure detection DNS propagation Recovery DB failure AURORA WITH MARIADB DRIVER 1 5 - 2 0 s e c 3 - 2 0 s e c
  15. 15. 0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% 35.00% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 0 - 5s – 30% of fail-overs 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 5 - 10s – 40% of fail-overs 0% 10% 20% 30% 40% 50% 60% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 10 - 20s – 25% of fail-overs 0% 5% 10% 15% 20% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 20 - 30s – 5% of fail-overs フェイルオーバー時間
  16. 16. Streaming backupとPITR • Amazon Auroraでは各セグメント毎にAmazon S3 へ継続的に増分バックアップを取得している – Backup retention periodでバックアップを残す期間を指定可能 • Amazon Auroraが使用しているディスクの仕組み によりパフォーマンスへ影響を与えない • PITRで5分前からBackup Retention Periodまでの 任意の位置に秒単位で復元可能
  17. 17. Streaming backup Segment snapshot Log records Recovery point Segment 1 Segment 2 Segment 3 Time – 各セグメントの定期的なスナップショットは並列で行われ、redo logはストリー ムで継続バックアップのためにS3に送られる。パフォーマンスや可用性に対する 影響は無し – リストアでは、セグメントのスナップショットとログストリームをストレージ ノードに転送し、並列で非同期で適用
  18. 18. SQLによるフェイルオーバのテスト SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能 • データベースノードのクラッシュをシミュレート: ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}] • レプリケーション障害をシミュレート: ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE [ TO ALL | TO "replica name" ] FOR INTERVAL quantity [ YEAR | QUARTER | MONTH | WEEK| DAY | HOUR | MINUTE | SECOND ]; • 他にも – ディスク障害をシミュレート – ディスクコンジェスションをシミュレート
  19. 19. Aurora Driver • MariaDB Connector/J 1.2.0以降に含まれている – https://mariadb.com/kb/en/mariadb/mariadb-connector-j-120-release- notes/ – リリースノートには明確にAuroraの記述は無いがドキュメント中に記載 • https://mariadb.com/kb/en/mariadb/about-mariadb-connector-j/ • https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with- mariadb-connector-j/#specifics-for-amazon-aurora – 2015.09 Amazon Linuxよりrpmを提供 • 現在の提供機能 – Fast failover – Auto node discovery
  20. 20. パフォーマンスTips
  21. 21. チューニング指針 • まずはデフォルトのパラメータグループを使用 – Amazon Auroraはデフォルトの設定でパフォーマンスを発揮できる ようにチューニング済み – 適切なインスタンスタイプを選択することが大切 • Amazon AuroraはCPUやメモリなどのマシンリソー スを最大限使うように様々な改良が入っています – 監視項目などは実際のシステムで必要なレイテンシなどの要件に 従って設定を行う – ClowdWatchやperformance schemaを活用
  22. 22. WRITE PERFORMANCE READ PERFORMANCE インスタンスサイズによるスケール AuroraはRead/Writeパフォーマンス共にインスタンスサイズに比例してスケール Aurora MySQL 5.6 MySQL 5.7
  23. 23. チューニングTips • 1トランザクションで大量の更新や削除を行ったり、 大量データのシーケンシャルリードを行う場合 • Amazon Auroraのアーキテクチャに合わせてクエリを 実行することで性能を向上させることが可能
  24. 24. チューニングTips #1> SELECT * FROM Table; #1> SELECT * FROM Table WHERE id BETWEEN 1 AND 10000; #2> SELECT * FROM Table WHERE id BETWEEN 10001 AND 20000; #3> SELECT * FROM Table WHERE id BETWEEN 20001 AND 30000; #4> ......... • SELECT (Parallel Read Aheadで大幅性能改善) • DELETE / UPDATE #1> DELETE * FROM Table WHERE id >= 100000; #1> DELETE FROM Table WHERE id BETWEEN 10000 AND 20000; #2> DELETE FROM Table WHERE id BETWEEN 20001 AND 30000; #3> DELETE FROM Table WHERE id BETWEEN 300001AND 40000; #4> .........
  25. 25. メトリクススキーマ • INFORMATION_SCHEMA.REPLICA_HOST_STATUS • mysql.ro_replica_status mysql> SELECT SERVER_ID, REPLICA_LAG_IN_MILLISECONDS, SESSION_ID FROM INFORMATION_SCHEMA.REPLICA_HOST_STATUS; +-----------------+-----------------------------------------------------+-----------------------------------------+ | SERVER_ID | REPLICA_LAG_IN_MILLISECONDS | SESSION_ID | +-----------------+----------------------------------------------------+-------------------------------------------+ | demo-db01 | 18.458999633789062 | 62c35a1c-2f61-11e5-96de-06be620fb7bd | | demo-db02 | 0 | MASTER_SESSION_ID | | demo-db03 | 19.39299964904785 | 6194b000-2f61-11e5-9bf6-12715c13435b | +-----------------+---------------------------------------+--------------------------------------------------------+
  26. 26. 拡張モニタリング User System Wait IRQ Idle CPU Utilization Rx per declared ethn Tx per declared ethn Network Num processes Num interruptible Num non-interruptible Num zombie Processes Process ID Process name VSS Res Mem % consumed CPU % used CPU time Parent ID Process List MemTotal MemFree Buffers Cached SwapCached Active Inactive SwapTotal SwapFree Dirty Writeback Mapped Slab Memory TPS Blk_read Blk_wrtn read_kb read_IOs read_size write_kb write_IOs write_size avg_rw_size avg_queue_len Device IO Free capacity Used % Used File System これらのメトリクスを最短1秒間隔で取得可能
  27. 27. 拡張モニタリング • CloudWatch Logsにメト リクス送信可能 • CloudWatch logs- >Lambda- >Elasticsearch Service 連携も容易 – Kibanaを使ってアプリケー ション・DBサーバメトリク ス・クエリのパフォーマンス を一箇所で閲覧可能
  28. 28. Amazon Auroraへの移行
  29. 29. マイグレーション時の注意 • Amazon AuroraはInnoDB / ROW_FORMAT=Dynamicのみサポート – InnoDB以外のストレージエンジンやROW_FORMAT=COMPRESSは 非対応 • マイグレーション時に自動でからコンバートされる が、事前に手動で対応ストレージエンジンやROW FORMATへの変換を推薦 • ホワイトペーパー: http://bit.ly/2qjQzBc
  30. 30. RDS for MySQLからマイグレーション • マネージメントコンソールから数クリックでAmazon Aurora へ移行可能 – RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション 可能 – RDS for MySQLは5.6を使う必要がある
  31. 31. RDS MySQL DBインスタンスからAmazon Aurora Read Replica を作成 • RDS MySQLインスタンスからAmazon Auroraにダウ ンタイムを最小限に移行する場合、スナップショットか らAuroraクラスタを起動し、手動でレプリケーション を設定する必要があった • この機能を利用することによって、ワンクリックでRDS MySQLのスナップショットからAurora Read Replica を起動し、レプリケーションの設定まで自動で行われる
  32. 32. RDS MySQL DBインスタンスからAmazon Aurora Read Replica を作成 RDS MySQL5.6 (Master) Aurora (Writer) Aurora (Reader) Application Write Read Auroraクラスタへレプリケーション環境を自動で作成
  33. 33. MySQLスナップショットバックアップからの移行 • Percona Xtrabackupを利用して作成したバックアッ プデータを利用してオンプレミス環境やAmazon EC2 上のMySQLからAmazon Auroraクラスへ移行可能 – mysqldumpと比較したテストで約20倍高速に移行可能 • S3にアップロードしたバックアップデータを利用 – アップロードにはManagement ConsoleやCLI tools、データサイズが大 きい場合はAWS Import/Export Snowballを利用してS3へ転送する
  34. 34. 改善した機能
  35. 35. Reader Endpointの追加 • Amazon Aurora cluster内のReaderに単一のエンドポイントを提供 – ReaderがFailoverした場合は、再接続を行うことで新しいReaderに接続が可能 – Round Robinで接続 • メリット – Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間 でコネクションのロードバランシングが可能 – Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイン ト経由で接続することが可能 – 今までHAproxyなどで分散されていた方は置き換えることでシンプルに負荷分散 • 注意点 – DNSベースなのでアプリケーションやドライバ側でIPアドレスのキャッシュ周りの設定の確認や failoverのテストを推薦 – Readerが1インスタンスもいなくなった場合はWriterへfailbackを行う
  36. 36. Reader Endpoint • クラスタ内のReader にラウンドロビンで 接続 • 常にReaderに接続さ れるが、Readerが1イ ンスタンスもいなく なった場合はWriterに failback • Readerの追加・削除 は自動で行われる Availability Zone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Reader Aurora Reader リーダエンドポイント Read Aurora Writer
  37. 37. IAM Authentication Integration • Amazon Auroraへログインするための認証にIAMが利用可 能 • IAMのリソース制限を利用可能 • パスワードとしてSignature Version 4 を利用 (15分間有効の一時token) • SSL接続が必須 • データベースアクセスに必要な認証情報をEC2インスタンスなどに配置しなく ても良い • AWS SDKやAWS CLI Tools対応
  38. 38. IAM Authentication Integration SSL接続 CREATE USER iam-database-user IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS'; server
  39. 39. Load Data From S3 • S3バケットに保存されたデータを直接Auroraにインポート可 能 – テキスト形式(LOAD DATA FROM S3)・XML形式(LOAD XML FROM S3) – LOAD DATA INFILEとほぼ同様のオプションをサポート (圧縮形式のデータは現在 未サポート) – Manifestによる一括ロードにも対応 (Version 1.11以降) <row column1="value1" column2="value2" /> <row column1="value1" column2="value2" /> <row> <column1>value1</column1> <column2>value2</column2> </row> <row> <field name="column1">value1</field> <field name="column2">value2</field> </row>
  40. 40. Export Data into S3 • S3バケットにデータを直接Auroraエクスポート可能 – LOAD DATA FROM S3で利用できるManifestファイルを生成可能 – 1ファイルは最大6GBずつ分割される • 25GBを超えるようなデータをexportする場合は、複数のSQLに分割して exportする領域をずらして実行する事を推薦 SELECT * FROM employees INTO OUTFILE S3 's3://bucket_name/prefix’ FIELDS TERMINATED BY ',’ LINES TERMINATED BY '¥n’ MANIFEST ON OVERWRITE ON;
  41. 41. 空間インデックスサポート • Amazon Auroraは今までもGEOMETRY型や、 ST_Contains, ST_CrossesやST_Distanceといっ たspatial queryが利用可能 • 大きなデータセットに対してスケールするには不十分な点や制限が あった • Amazon Auroraではdimensionally ordered space- filling curveを利用しスケールし、高速かつ正確 に情報を取得できる改善を行った • MySQL5.7と比較して最大2倍のパフォーマンス
  42. 42. Advanced Auditing MariaDB server_audit plugin Aurora native audit support • 500K/sでイベントの 書き出しが可能 イベント情報の 書き出し DDL DML Query DCL Connect DDL DML Query DCL Connect ログ 書き 出し イベント情報の書 き出し イベント情報の書 き出し イベント情報の書 き出し イベント情報の書 き出し イベント情報の書 き出し Latch- free queue ログ書き出 し ログ書き出 し ログ書き出 し MySQL 5.7 Aurora Audit Off 95K 615K 6.47x Audit On 33K 525K 15.9x Sysbench Select-only Workload on 8xlarge Instance
  43. 43. Zero Downtime Patch (ZDP) • コネクションを切断すること無くオンラインでパッチを 適用 – 5秒程度スループットの低下が起こるが、アプリケーションとの接続を維持 したままパッチを適用可能 – ベストエフォート • 既に開かれているSSLコネクション、アクティブなロック、トランザクション の完了やテンポラリテーブルの削除を待機し、パッチ適用可能なウインドウが 出来た場合、ゼロダウンタイムパッチとして適用 • ゼロダウンタイムパッチで適用出来るウインドウがなかった場合、通常のパッ チ適用プロセスを実行 – 以下の条件では通常通りのパッチ適用プロセスを実施 • バイナリログを有効にしている • SSLを利用した接続を行っており、ZDPのリトライ回数内に接続が終了しない
  44. 44. Zero downtime patch (ZDP) Networking state Application state Storage Service App state Net state App state Net state BeforeZDP New DB Engine Old DB Engine New DB Engine Old DB Engine WithZDP セッションはパッチ 適用時に切断される パッチ適用中でも セッションは維持される Storage Service
  45. 45. Database Cloning • ストレージコストを増やすことなく データベースのコピーを作成 • データをコピーするわけではないため、 クローンの作成はほぼ即座に完了 • データのコピーはオリジナルボリュームと コピー先のボリュームのデータが異なる 場合の書き込み時のみ発生 ユースケース • プロダクションデータを使用したテスト • データベースの再構成 • プロダクションシステムに影響を及ばさずに 分析目的で特定の時点での スナップショットを保存 本番データベース Clone Clone Clone 開発/テスト アプリケーション ベンチマーク 本番 データベース 本番 データベース
  46. 46. 性能・安定面向上に対する新機能
  47. 47. Cached read performance • Catalog concurrency: デー タ・ディクショナリの同期と キャッシュ破棄の効率化 • NUMA aware scheduler: NUMA を考慮したスケジューラへ 変更すること、複数CPUが搭載さ れているインスタンスで性能向上 • Read views: read viewを作成 する際にラッチフリーなread viewを作成するアルゴリズムに変 更 0 100 200 300 400 500 600 700 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 1,000 read requests/sec * R3.8xlarge instance, <1GB dataset Sysbench25% Throughput gain
  48. 48. • Smart scheduler: IOヘビー・ CPUヘビーなワークロードそれぞ れに動的に処理スレッドを割り当 てるスケジューラに変更 • Smart selector: 最も良いパ フォーマンスのストレージノード にあるデータを選択することで リードレイテンシーを軽減 • Logical read ahead (LRA): btreeの順序に応じて事前にpage を読み込んで置くことで、IO waitを軽減 0 20 40 60 80 100 120 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 1,000 requests/sec * R3.8xlarge instance, 1TB dataset Sysbench 10% Throughput gain Non-cached read performance
  49. 49.  プライマリーキーでソートされている データのバッチインサートの速度を改善。 インデックス走査を行う際のカーソル位 置をキャッシュ  データパターンに応じて動的に機能を有 効・無効化  ツリーを下方向に走査する際のラッチ ロックの競合を軽減  双方向で全てのINSERTワークロードで 有効 – LOAD INFILE, INSERT INTO SELECT, INSERT INTO REPLACE, Multi-value inserts. Insert performance Index R4 R5R2 R3R0 R1 R6 R7 R8 Index Root Index R4 R5R2 R3R0 R1 R6 R7 R8 Index Root MySQL: 全てのINSERTがrootからB-treeをトラバースする Aurora: indexトラバースを抑制
  50. 50. Faster index build  MySQL 5.6 はLinuxの先読みを活用して いるため、btreeに連続したブロックア ドレスが必要。そのためエントリーを トップダウンで新しいbtreeに挿入する 際に、分割と多くオンロギングが発生  Auroraはtree内のポジションを元にブ ロックをスキャンしてプリフェッチし、 リーフブロックを作製してからブランチ を作製していく • 分割が発生しない • 各ページは1度のみ参照される • 1ページに1ログレコード 2-4X better 0 2 4 6 8 10 12 r3.large on 10GB dataset r3.8xlarge on 10GB dataset r3.8xlarge on 100GB dataset Hours RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016
  51. 51. Lab Mode • 今後提供予定の機能を試すことが可能 – DBパラメータグループ aurora_lab_mode 変数で設定可能 – 開発中の機能なので本番適用ではなく検証目的でお使い下さい • GAクオリティですが、全てのワークロードで性能が発揮出来るか検証 を行っている段階です – フィードバックをお待ちしています! • 現在ご提供中 – Lock compression • ロックマネージャーが利用するメモリを最大66%削減 • OOMを起こさず、更に多くの行ロックを同時に取得することが可能に – Fast DDL • nullableカラムをテーブルの最後に追加する場合にデータ件数によらず 高速に変更が行なえます
  52. 52. Fast DDL: Aurora vs. MySQL  フルテーブルコピー: 全てのインデックスを 再構築 - 数時間から数日かかることも  DMLクエリ実行のために一時領域が必要  DDLクエリがDMLクエリスループットに影響  DMLクエリ実行中にテーブル・ロックが発生 Index LeafLeafLeaf Leaf Index Root table name operation column-name time-stamp Table 1 Table 2 Table 3 add-col add-col add-col column-abc column-qpr column-xyz t1 t2 t3  メタデータテーブルにエントリーを追加し、 スキーマバージョニングを利用  変更を適用するために最新のスキーマへブロックを アップグレードする際はmodify-on-write  現在はテーブルの最後にNullableなカラムを 追加する場合に対応 MySQL Amazon Aurora
  53. 53. Fast DDLのパフォーマンス On r3.large On r3.8xlarge Aurora MySQL 5.6 MySQL 5.7 10GB table 0.27 sec 3,960 sec 1,600 sec 50GB table 0.25 sec 23,400 sec 5,040 sec 100GB table 0.26 sec 53,460 sec 9,720 sec Aurora MySQL 5.6 MySQL 5.7 10GB table 0.06 sec 900 sec 1,080 sec 50GB table 0.08 sec 4,680 sec 5,040 sec 100GB table 0.15 sec 14,400 sec 9,720 sec
  54. 54. さらなる改善に向けて
  55. 55. Database backtrack
  56. 56. – データベースの状態を容量によらず瞬時に特定の時点へ巻き戻す • オペミスなどをしてしまった場合に、作業実行前の状態にすぐに巻き戻すことでサー ビスへの影響を最小限に抑えることが可能 How does it work? t0 t1 t2 t0 t1 t2 t3 t4 t3 t4 Rewind to t1 Rewind to t3 Invisible Invisible
  57. 57. P o s t g r e S Q L F o r A u r o r a Aurora is now fully compatible with both PostgreSQL and MySQL
  58. 58. 1/10th The Cost Of Commercial Grade Databases Fully PostgreSQL Compatible Several times better performance than typical PostgreSQL database Scalable, Durable and Secure Migrate From RDS For PostgreSQL Amazon Aurora PostgreSQL-Compatible Edition
  59. 59. 一貫したスループットを発揮 測定中のパフォーマンスは、PostgreSQL に比べて 3倍以上一貫した結果に pgbench は TPC-B を想定したワークロードを実行。Aurora は 1280クライアントで実行時の結果。PostgreSQL は 523 クライアントで実行時の結果(クライアント数はそれぞれもっともよいスループットを出した際のものを採用) 開発中の結果のため正式リリース時と異なる可能性があります
  60. 60. Amazon Aurora with PostgreSQL Compatibility 性能測定のまとめ Measurement Result PgBench >= 2x faster SysBench 2x-3x faster Data Loading 3x faster Response Time >2x faster Throughput Jitter >3x more consistent Throughput at Scale 3x faster Recovery Speed Up to 85x faster 開発中の結果のため正式リリース時と異なる可能性があります
  61. 61. Performance Insights • DBの知識を持ったエンジニアがいな くとも、クエリパフォーマンスの評 価やDBの状態チェックを実施可能に する機能 • Amazon Aurora PostgreSQL- Compatible Editionには既に組み込 まれた状態でリリースされる • 他のデータベースエンジンにも順次 展開予定
  62. 62. まとめ
  63. 63. Amazon Aurora • クラウド時代にAmazonが再設計したRDBMS – MySQL5.6/PostgreSQL9.6と互換があり既存の資産を活かしやすい • 高いクエリ実行並列度・データサイズが大きい環境で 性能を発揮 – Amazon Auroraはコネクション数やテーブル数が多い環境で優位 • 高可用性・実環境での性能向上を実現するための多く のチャレンジを継続して行っている
  64. 64. 参考資料 • Amazon Aurora SIGMOD論文 – http://www.allthingsdistributed.com/files/p1041-verbitski.pdf • Amazon Auroraストレージエンジン – https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/ • Amazon Auroraストレージのquorumに関する実装について – https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-reads-and- mutating-state/ – https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-and- correlated-failure/ – https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-reducing-costs- using-quorum-sets/ – https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum- membership/ • AWS Database Blog (Amazon Aurora) – https://aws.amazon.com/blogs/database/category/aurora/

×