Amazon Aurora (MySQL-compatible edition) Deep Dive Amazon Web Services Japan K.K. Yutaka Hoshino, Database Specialist SA 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
内容についての注意点 本資料では 2017 年 6 1 時点のサービス内容および価格についてご説明しています 最新の情報は 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.
Amazon Aurora の特徴 ハイパフォーマンス スケーラブル MySQL5.6 互換 セキュリティにも配慮 フルマネージド 可 性 耐久性
Amazon Aurora の価格 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 *NEW* *NEW* ライセンス料 は不要ロックインもない使った分だけ課 db.r3.8xlarge 32 244 $5.60 ストレージ : $0.120/GB/ 月 IO 課金 : $0.240/100 万リクエスト 東京リージョンの価格
アーキテクチャ
Aurora のストレージ SSDを利 したシームレスにスケールするストレージ 10GBから64TBまでシームレスに 動でスケールアップ AZ 1 AZ 2 AZ 3 SQL Transactions Caching 実際に使った分だけ課 標準で 可 性を実現 3AZ に 6 つのデータのコピーを作成 Log structured Storage Amazon S3
ストレージノードクラスタ Protection Group 毎に 6 つのストレージノードを使 各ログレコードは Log Sequence Number(LSN) を持っており不 重複しているレコードを判別可能 不 している場合はストレージノード間で gossip protocol を利 し補完を う
ディスク障害検知と修復 2 つのコピーに障害が起こっても 読み書きに影響は無い 3 つのコピーに障害が発 しても読み込みは可能 動検知 修復 AZ 1 AZ 2 AZ 3 SQL Transactio n Caching AZ 1 AZ 2 AZ 3 SQL Transaction Caching 読み込み可能 読み書き可能
IO traffic in Aurora ( ストレージノード ) IO FLOW Primary instance Peer storage nodes LOG RECORDS 4 ACK INCOMING QUEUE 2 PEER-TO-PEER GOSSIP SORT GROUP STORAGE NODE UPDATE QUEUE HOT LOG 3 1 COALESCE 5 POINT IN TIME SNAPSHOT GC DATA BLOCKS 7 SCRUB 8 1 レコードを受信しインメモリのキューに追加 2 レコードを永続化して ACK 3 レコードを整理してギャップを把握 4 ピアと通信して 埋め 5 ログレコードを新しいバージョンのデータブロックに合体 6 定期的にログと新しいバージョンのブロックを S3 に転送 7 定期的に古いバージョンのガベージコレクションを実施 8 定期的にブロックの CRC を検証 6 OBSERVATIONS S3 BACKUP 全てのステップは 同期ステップ 1 と 2 だけがフォアグラウンドのレイテンシーに影響インプットキューは MySQL の 1/46 (unamplified, per node) レイテンシーにセンシティブな操作に向く ディスク領域をバッファーに使ってスパイクに対処
セキュリティ データの暗号化 AES-256 ( ハードウエア 援 ) ディスクと Amazon S3 に置かれている全ブロックを暗号化 AWS KMS を利 したキー管理 SSL を利 したデータ通信の保護 標準で Amazon VPC を使ったネットワークの分離 ノードへ直接アクセスは不可能 Application SQL Transactions Caching Storage 業界標準のセキュリティとデータ保護の認証をサポート Amazon S3
フェイルオーバとリカバリ
フェイルオーバとリプレース リードレプリカが存在する場合は 1 分程でフェイルオーバ可能 RDS for MySQL よりも 速にフェイルオーバ可能 リードレプリカが存在しない場合は 10-15 分程 Multi-AZ 配置として別 AZ で起動可能 RDS for MySQL と違いリードアクセス可能
速でより予測可能なフェイルオーバー時間 MYSQL DB failure Failure detection DNS propagation App running Recovery Recovery AURORA WITH MARIADB DRIVER DB failure Failure detection DNS propagation 15-20 sec Recovery 3-20 sec App running
Database fail-over time 0-5s 30% of fail-overs 5-10s 40% of fail-overs 35.00% 50.00% 30.00% 25.00% 40.00% 20.00% 15.00% 10.00% 30.00% 20.00% 5.00% 0.00% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 10.00% 0.00% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 10-20s 25% of fail-overs 20-30s 5% of fail-overs 60% 50% 20% 40% 15% 30% 10% 20% 10% 0% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 5% 0% 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
Streaming backup と PITR Amazon Aurora では各セグメント毎に Amazon S3 へ継続的に増分バックアップを取得している Backup retention period でバックアップを残す期間を指定可能 Amazon Aurora が使 しているディスクの仕組みによりパフォーマンスへ影響を与えない PITR で 5 分前から Backup Retention Period までの任意の位置に秒単位で復元可能
Streaming backup Segment snapshot Log records Segment 1 Segment 2 Segment 3 Recovery point Time 各セグメントの定期的な Snapshot は並列で われ redo log はストリームで継続バックアップのために S3 に送られる パフォーマンスや可 性に対する影響は無し リストアでは 適切なセグメントの Snapshot とログストリームをストレージノードに転送し 並列で 同期で適 していく
Writer / Reader ノードの識別 innodb_read_only を参照 SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ; OFF: Writer ON: Reader アプリケーションやドライバで Aurora ノードに対する負荷分散やフェイルオーバーロジックの実装に利 可能
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 ]; 他にも ディスク障害をシミュレート ディスクコンジェスションをシミュレート
Amazon Aurora Driver
Aurora Driver MariaDB Connector/J 1.2.0 以降に含まれている https://mariadb.com/kb/en/mariadb/mariadb-connector-j-120-releasenotes/ リリースノートには明確に Aurora の記述は無いがドキュメント中に記載 https://mariadb.com/kb/en/mariadb/about-mariadb-connector-j/ https://mariadb.com/kb/en/mariadb/failover-and-high-availability-withmariadb-connector-j/#specifics-for-amazon-aurora 2015.09 Amazon Linux より rpm を提供 現在の提供機能 Fast failover Auto node discovery
Aurora Driver https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/
パフォーマンス Tips
インスタンスサイズによるスケール WRITE PERFORMANCE READ PERFORMANCE Aurora MySQL 5.6 MySQL 5.7 AuroraはRead/Writeパフォーマンス共にインスタンスサイズに 例してスケール
チューニング指針 Amazon Aurora は MySQL と 較してインスタンスリソースを効率的に最 限利 する設計 CPU やメモリの利 率が めだが パフォーマンスに影響が出ない限りは過度な 配は必要ない Amazon Aurora は実際のワークロードで性能が発揮できるように開発 チューニングが われている 監視項 はインスタンスリソースでは無く 実際のパフォーマンステストを元にクエリレイテンシやスループット buffer pool の cache hit レートに注
チューニング指針 まずはデフォルトのパラメータグループを使 Amazon Aurora はデフォルトの設定でパフォーマンスを発揮できるようにチューニング済み 適切なインスタンスタイプを選択することが 切 それでも性能が出ない場合にパラメータグループの変更を検討
チューニング Tips 1 トランザクションで 量の更新や削除を ったり 量データのシーケンシャルリードを う場合 1 トランザクションで 量の更新 削除やシーケンシャルリードを う場合 Amazon Aurora のアーキテクチャに合わせてクエリを実 することで性能を向上させることが可能
チューニング Tips SELECT (Parallel Read Ahead で大幅性能改善 ) #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>... 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>...
新しいメトリクス画 Throughput Select Commit DML/DDL Latency Select Commit DML/DDL Cache Hit Ratio Buffer Cache Result Set Deadlocks Login Failures Blocked Transactions
メトリクススキーマ
メトリクススキーマ 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 +-----------------+---------------------------------------+--------------------------------------------------------+
拡張モニタリング CPU Utilization User System Wait IRQ Idle Network これらのメトリクスを最短 1 秒間隔で取得可能 Rx per declared ethn Tx per declared ethn Processes Num processes Num interruptible Num non-interruptible Num zombie Process List Process ID Process name VSS Res Mem % consumed CPU % used CPU time Parent ID Memory MemTotal MemFree Buffers Cached SwapCached Active Inactive SwapTotal SwapFree Dirty Writeback Mapped Slab Device IO TPS Blk_read Blk_wrtn read_kb read_ios read_size write_kb write_ios write_size avg_rw_size avg_queue_len File System Free capacity Used % Used
拡張モニタリング CloudWatch Logs にメトリクス送信可能 CloudWatch logs->lambda- >Elasticsearch Service 連携も容易 Kibana を使ってアプリケーション DB サーバメトリクス クエリのパフォーマンスを 箇所で閲覧可能
Amazon Aurora への移
マイグレーション時の注意 Amazon Aurora は InnoDB / ROW_FORMAT=Dynamic のみサポート InnoDB 以外のストレージエンジンや ROW_FORMAT=COMPRESS は 対応 マイグレーション時に 動でからコンバートされるが 事前に 動で対応ストレージエンジンや ROW FORMAT への変換を推薦 White paper: http://bit.ly/2qjqzbc
RDS for MySQL からマイグレーション マネージメントコンソールから数クリックで Amazon Aurora へ移 可能 RDS for MySQL のスナップショットから Amazon Aurora へマイグレーション可能 RDS for MySQL は 5.6 を使う必要がある
RDS MySQL DB インスタンスから Amazon Aurora Read Replica を作成 RDS MySQL インスタンスから Amazon Aurora にダウンタイムを最 限に移 する場合 Snapshot から Aurora クラスタを起動し 動でレプリケーションを設定する必要があった この機能を利 することによって ワンクリックで RDS MySQL の Snapshot から Aurora Read Replica を起動し レプリケーションの設定まで 動で われる
RDS MySQL DB インスタンスから Amazon Aurora Read Replica を作成 Write Application Read RDS MySQL5.6 (Master) Aurora (Writer) RDS MySQL の RR を作る感覚で Aurora クラスタへレプリケーション環境を自動で作成 Aurora (Reader)
MySQL スナップショットバックアップからの移 Percona Xtrabackup を利 して作成したバックアップデータを利 してオンプレミス環境や Amazon EC2 上の MySQL から Amazon Aurora クラスへ移 可能 mysqldump と 較したテストで約 20 倍 速に移 可能 S3 にアップロードしたバックアップデータを利 アップロードには Management Console や CLI tools データサイズが きい場合は AWS Import/Export Snowball を利 して S3 へ転送する
改善を って来た機能
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 を う
Reader Endpoint クラスタ内の Reader にラウンドロビンで接続 VPC subnet Aurora Writer Read リーダエンドポイント VPC subnet 常に Reader に接続されるが Reader が 1 インスタンスもいなくなった場合は Writer に failback Aurora Reader VPC subnet Availability Zone A Aurora Reader VPC subnet Availability Zone B Reader の追加 削除は 動で われる
IAM Authentication Integration Amazon Aurora へログインするための認証に IAM が利 可能に (1.10 以降 ) IAM のリソース制限を利 可能 パスワードとして Signature Version 4 を利 (15 分間有効の 時 token) SSL 接続が必須 データベースアクセスに必要な認証情報を EC2 インスタンスなどに配置しなくても良い AWS SDK や AWS CLI Tools 対応
IAM Authentication Integration CREATE USER iam-database-user IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS'; server SSL 接続
Lambda Function Integration Amazon Aurora 内から AWS Lambda を呼び出せる ストアードプロシジャーとして実 (mysql.lambda_async) 同期で Lambda を実 する IAM Role で事前に Aurora へ権限を付与しておく DELIMITER ;; CREATE PROCEDURE SNS_Publish_Message (IN subject VARCHAR(255), IN message TEXT) LANGUAGE SQL BEGIN CALL mysql.lambda_async( Lambda ARN', CONCAT('{ "subject" : "', subject, '", "message" : "', message, '" }') ); END ;; DELIMITER ;
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</column1> <column2>value2</column2> </row> <row> <field name="column1">value1</field> <field name="column2">value2</field> </row> <row column1="value1" column2="value2" /> <row column1="value1" column2="value2" />
spatial index 空間インデックスサポート Amazon Aurora は今までも GEOMETRY 型や ST_Contains, ST_Crosses や ST_Distance といった spatial query が利 可能 きなデータセットに対してスケールするには不 分な点や制限があった Amazon Aurora では dimensionally ordered space-filling curve を利 しスケールし 速かつ正確に情報を取得できる改善を った MySQL5.7 と 較して最 2 倍のパフォーマンス
Spatial Index Benchmarks Sysbench points and polygons R-Tree MySQL 5.7 140000 120000 100000 80000 60000 40000 20000 Aurora MySQL 5.7 Z-index / Aurora (dimensionally ordered space filling curve) 0 Select-only (reads/sec) Write-only (writes/sec) r3.8xlarge using Sysbench on <1GB dataset Write Only: 4000 clients, Select Only: 2000 clients, ST_EQUALS
Advanced Auditing MariaDB server_audit plugin Aurora native audit support Query Query Create event string DDL DDL Create event string Write to File DML DCL Create event string DML DCL Create event string Create event string Latch-free queue Write to File Connect Connect Create event string Write to File Write to File MySQL 5.7 Aurora We can sustain over 500K events/sec Audit Off 95K 615K 6.47x Audit On 33K 525K 15.9x Sysbench Select-only Workload on 8xlarge Instance
Zero downtime patch (ZDP) コネクションを切断すること無くオンラインでパッチを適 5 秒程度スループットの低下が起こるが アプリケーションとの接続を維持したままパッチを適 可能に (1.10 以降 ) ベストエフォート 既に開かれている SSL コネクション アクティブなロック トランザクションの完了やテンポラリテーブルの削除を待機し パッチ適 可能なウインドウが出来た場合 ゼロダウンタイムパッチとして適 ゼロダウンタイムパッチで適 出来るウインドウがなかった場合 通常のパッチ適 プロセスを実 以下の条件では通常通りのパッチ適 プロセスを実施 バイナリログを有効にしている SSL を利 した接続を っており ZDP のリトライ回数内に接続が終了しない
Zero downtime patch (ZDP) Before ZDP セッションはパッチ適 時に切断される Net stat e Net state App state App state Old DB Engine New DB Engine Storage Service With ZDP パッチ適 中でもセッションは維持される Networking state Application state Old DB Engine New DB Engine Storage Service
性能 安定 向上に対する新機能
Cached read performance Catalog concurrency: データ ディクショナリの同期とキャッシュ破棄の効率化 700 600 NUMA aware scheduler: NUMA を考慮したスケジューラへ変更すること 複数 CPU が搭載されているインスタンスで性能向上 Read views: read view を作成する際にラッチフリーな read view を作成するアルゴリズムに変更 25% Throughput gain 500 400 300 200 100 0 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 1,000 read requests/sec * R3.8xlarge instance, <1GB dataset Sysbench
Non-cached read performance Smart scheduler: IO ヘビー CPU ヘビーなワークロードそれぞれに動的に処理スレッドを割り当てるスケジューラに変更 Smart selector: 最も良いパフォーマンスのストレージノードにあるデータを選択することでリードレイテンシーを軽減 Logical read ahead (LRA): btree の順序に応じて事前に page を読み込んで置くことで IO wait を軽減 10% Throughput gain 120 100 80 60 40 20 0 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 1,000 requests/sec * R3.8xlarge instance, 1TB dataset Sysbench
Insert performance Root プライマリーキーでソートされているデータのバッチインサートの速度を改善 インデックス 査を う際のカーソル位置をキャッシュ R0 R1 Index R2 R3 R4 R5 Index R6 R7 R8 データパターンに応じて動的に機能を有効 無効化 ツリーを下 向に 査する際のラッチロックの競合を軽減 MySQL: 全てのINSERTがrootからB-treeをトラバースする Root Index Index 双 向で全ての INSERT ワークロードで有効 LOAD INFILE, INSERT INTO SELECT, INSERT INTO REPLACE, Multi-value inserts. R0 R1 R2 R3 R4 R5 Aurora: indexトラバースを抑制 R6 R7 R8
Faster index build MySQL 5.6 は Linux の先読みを活 しているため btree に連続したブロックアドレスが必要 そのためエントリーをトップダウンで新しい btree に挿 する際に 分割と多くオンロギングが発 Aurora は tree 内のポジションを元にブロックをスキャンしてプリフェッチし リーフブロックを作製してからブランチを作製していく 分割が発 しない 各ページは 1 度のみ参照される 1 ページに 1 ログレコード 2-4X better than MySQL 5.6 or MySQL 5.7 Hours 12 10 8 6 4 2 0 r3.large on 10GB dataset r3.8xlarge on 10GB dataset r3.8xlarge on 100GB dataset RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016
Lab mode 今後提供予定の機能を試すことが可能 DB パラメータグループ aurora_lab_mode 変数で設定可能 開発中の機能なので本番適 ではなく検証 的でお使い下さい GA クオリティですが 全てのワークロードで性能が発揮出来るか検証を っている段階です フィードバックをお待ちしています! 現在ご提供中 Lock compression ロックマネージャーが利 するメモリを最 66% 削減 OOM を起こさず 更に多くの ロックを同時に取得することが可能に Fast DDL nullable カラムをテーブルの最後に追加する場合にデータ件数によらず 速に変更が なえます
Fast DDL: Aurora vs. MySQL MySQL Amazon Aurora Root table name operation column-name time-stamp Index Index Table 1 Table 2 Table 3 add-col add-col add-col column-abc column-qpr column-xyz t1 t2 t3 Leaf Leaf Leaf Leaf フルテーブルコピー : 全てのインデックスを再構築 - 数時間から数 かかることも DML クエリ実 のために 時領域が必要 DDL クエリが DML クエリスループットに影響 DML クエリ実 中にテーブル ロックが発 メタデータテーブルにエントリーを追加し スキーマバージョニングを利 変更を適 するために最新のスキーマへブロックをアップグレードする際は modify-on-write 現在はテーブルの最後に Nullable なカラムを追加する場合に対応
Fast DDL performance Aurora MySQL 5.6 MySQL 5.7 On r3.large 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 On r3.8xlarge 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
さらなる改善に向けて
Database backtrack
How does it work? t 0 t 1 Invisible t 2 t 4 Invisible t 3 Rewind to t 3 Rewind to t 1 t 0 t 1 t 2 t 3 t 4 DB の 貫した状態を提供するためにログストリーム中のログを LSN ツリー内のブランチを元に可視 不可視にする 最初の t2 から t1 への rewind は 紫 のログを不可視にする 次の t4 から t3 へ DB を rewind する場合 と紫のログを不可視にする
Database backtrack vs Offline Point in Time Restore (PiTR) Database backtrack Database backtrack は現在のデータベースの状態を変更 数テラバイトのテータベースでも数秒で利 可能になる 追加のストレージの料 は発 しない 複数回の PITR のイテレーションの実施も現実的 購 した rewind ストレージを元にした rewind period 内の範囲で実 可能 Cross-region online PiTR は未サポート Offline PiTR PITR は現在の DB のバックアップから所望の時点の新しい DB を作成 数テラバイトのデータベースをリストアするのに数時間かかる リストアされた それぞれの DB 毎にストレージ料 がかかる 複数回のオフライン PITR は時間を消費する オフライン PITR はスナップショットか設定したバックアップウインドウ内で実 可能 Aurora は Cross-region PITR をサポート
Database cloning
Database cloning ストレージコストを増やすことなくデータベースのコピーを作成 データをコピーするわけではないため クローンの作成はほぼ即座に完了 データのコピーはオリジナルボリュームとコピー先のボリュームのデータが異なる場合の書き込み時のみ発 Dev/test applications Clone Benchmarks Clone Clone ユースケース プロダクションデータを使 したテスト データベースの再構成 プロダクションシステムに影響を及ばさずに分析 的で特定の時点でのスナップショットを保存 Production applications Production applications Production database
まとめ
Amazon Aurora クラウド時代に Amazon が再設計した RDBMS MySQL5.6 と互換があり既存の資産を活かしやすい いクエリ実 並列度 データサイズが きい環境で性能を発揮 Amazon Aurora はコネクション数やテーブル数が多い環境で優位 可 性 実環境での性能向上を実現するための多くのチャレンジを継続して っている
Thank you!