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.

[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス

18,811 views

Published on

2017/03/07開催のイベント「Amazon Aurora事例祭り」での表題セッション資料です。

Published in: Data & Analytics
  • Hi there! Essay Help For Students | Discount 10% for your first order! - Check our website! https://vk.cc/80SakO
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス

  1. 1. Amazon Auroraを使いこなすための ベストプラクティスと最新アップデート Amazon Web Services Japan K.K. #AuroraMatsuri
  2. 2. ⾃⼰紹介 • 星野 豊 (ほしの ゆたか) – @con_mame – facebook.com/conmame – データベース ソリューションアーキテクト • 経歴 – 全てオンプレ環境のインフラエンジニア – 全てAWS環境のインフラエンジニア • 担当 – Webサービス / game / Video・Live Streamingなどのメディア系 のお客様
  3. 3. Amazon Aurora
  4. 4. Amazon Aurora • re:Invent 2014で発表されたRDSの新しいエンジン • Amazonがクラウド時代にリレーショナル・データ ベースを作るとどうなるかを1から考え構築 – 新しい技術的チャレンジを盛り込んでいる • エンタープライズグレードの可⽤性とOSSレベルの コストを両⽴
  5. 5. Amazon Auroraの特徴 ハイパフォーマンス フルマネージド ⾼可⽤性・⾼耐久性セキュリティにも配慮 MySQL5.6互換スケーラブル
  6. 6. Amazon Auroraの特徴 • MySQL5.6と互換性があるため、既存のアプリケーションを簡単に 移⾏可能 • ストレージが10GBから64TBまでシームレスに拡張 • 3AZに2つずつ、計6つのデータのコピーを保持 – S3にストリーミングバックアップを実施 • VPC内に起動 – Security GroupやNACLを使⽤してアクセスコントロール可能 • Amazon Auroraは99.99%の可⽤性を実現するように設計されている
  7. 7. 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
  8. 8. 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
  9. 9. 新しいメトリクス画⾯ • Throughput – Select – Commit – DML/DDL • Latency – Select – Commit – DML/DDL • Cache Hit Ratio – Buffer Cache – Result Set • Deadlocks • Login Failures • Blocked Transactions
  10. 10. メトリクススキーマ • 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 | +-----------------+---------------------------------------+--------------------------------------------------------+
  11. 11. フェイルオーバとリカバリ
  12. 12. フェイルオーバ と リプレース • リードレプリカが存在する場合は1分程でフェ イルオーバ可能 – RDS for MySQLよりも⾼速にフェイルオーバ可能 – リードレプリカが存在しない場合は15分程 • Multi-AZ配置として別AZで起動する – RDS for MySQLと違いリードアクセス可能
  13. 13. クラスタエンドポイント • WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラ スタエンドポイントが存在する • 各Auroraノードは個別にエンドポイントを持っている(⾍眼鏡タブ内のEndpointで確認可 能) Reader Writer
  14. 14. クラスタエンドポイント Availability Zone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Reader クラスタエンドポイント • 各Auroraノードは個 別にエンドポイントを 持っている • クラスタエンドポイン トは、その時アクティ ブなAurora Writer ノードのCNAME • Readは各Readerを参 照する Write
  15. 15. クラスタエンドポイント • フェイルオーバが発 ⽣すると、Aurora ノードの昇格が⾏わ れ、クラスタエンド ポイントの指し先が 変わる Availability Zone A Availability Zone B VPC subnet VPC subnet VPC subnet VPC subnet Aurora Writer Aurora Writer クラスタエンドポイント Write
  16. 16. Writer / Readerノードの識別 • innodb_read_onlyを参照 – SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ; – OFF: Writer – ON: Reader • アプリケーションやドライバでAuroraノードに 対する負荷分散やフェイルオーバーロジックの 実装に利⽤可能 – メトリクススキーマのSEESION_IDも利⽤可能
  17. 17. Amazon Aurora Driver
  18. 18. 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
  19. 19. Aurora Driver https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/
  20. 20. 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 Database fail-over time
  21. 21. パフォーマンスTips
  22. 22. Auroraのパフォーマンスを引き出すために • クエリ並列度が⾼い、データサイズが⼤きい ケースで効果を発揮 • ロック機構やQuery Cache、スレッドプールな どに改善を⼊れて性能向上を⾏っている – Query Cacheはwrite heavyな環境ではoffを推奨 – 全コアを効率的に利⽤する設計により、CPU利⽤率はMySQLと ⽐較して⾼くなるが、性能が落ちにくくなっている
  23. 23. よく⾒ると • CPU / Memoryの利⽤率がMySQLより⾼いがス ループットが出ている – 分散ロック機構によりCPUリソースを使いきって スループットを出している
  24. 24. 何をみるのか? • よく聞かれる質問 – CPU利⽤率⾼いんだけど? – メモリ利⽤量多いんだけど? – Disk IOが多めなんだけど? • ⾒てほしいこと – Auroraはマシンリソースを最⼤限利⽤してスループットを 出す設計 – システム全体でパフォーマンスが向上 – 管理コスト、障害耐性、データ保全性
  25. 25. 何をみるのか? • AuroraはMySQL互換ですが、マシンリソースの 使い⽅が根本的に違います • Auroraが得意な場⾯・状況を理解してパフォー マンスを測定 – マシンリソースを使い切りそうになっても、MySQLと⽐べ るとスループットやレスポンスタイムの落ち⽅が緩やか
  26. 26. チューニング指針 • Amazon AuroraはMySQLと⽐較してインスタンスリ ソースを効率的に最⼤限利⽤する設計 • CPUやメモリの利⽤率が⾼めだが、パフォーマンスに影響が出ない限 りは過度な⼼配は必要ない • Amazon Auroraは実際のワークロードで性能が発揮でき るように開発・チューニングが⾏われている – ベンチマークテストでは無く実際のワークロードでテストを⾏う – 監視項⽬もインスタンスリソースでは無く、実際のパフォーマンステス トを元にクエリレイテンシやスループット・buffer poolのcache hitレー トに注⽬
  27. 27. チューニング指針 • まずはデフォルトのパラメータグループを使⽤ – Amazon Auroraはデフォルトの設定でパフォーマンスを発揮できる ようにチューニング済み • 適切なインスタンスタイプを選択することが⼤切 – それでも性能が出ない場合にパラメータグループの変更を検討
  28. 28. チューニングTips • 1トランザクションで⼤量の更新や削除を⾏っ たり、⼤量データのシーケンシャルリードを⾏ う場合 • 1トランザクションで⼤量の更新・削除やシーケンシャル リードを⾏う場合Amazon Auroraのアーキテクチャに合わ せてクエリを実⾏することで性能を向上させることが可能 • Amazon Auroraは並列でトランザクションが実⾏される ワークロード(実ワークロード)に向けてチューニングされて いるため、クエリを分割して並列で実⾏
  29. 29. チューニング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> .........
  30. 30. パフォーマンスの改善 • Large dataset read performance – スケジューラの改善により、IO/CPUヘビーなワークロードでAuroraが動的に処理スレッド 数を調整することでIO数/CPU利⽤率のバランスがとれ、性能を向上させる • Fast Insert – Primary keyで並んでいるデータを LOAD DATA や INSERT INTO ... SELECT で並列に実⾏ した場合の速度を改善 (将来的には他のワークロードにも適⽤予定) – モニタリング⽤にGlobal変数を追加 • aurora_fast_insert_cache_hits: キャッシュのcursorにヒットした • aurora_fast_insert_cache_misses: ヒットせずindexを⾛査した • Parallel Read Ahead – B-Treeスキャン性能を向上させる。Disk pageの読み込みパターンを⾃動的に判断し、事前 にフェッチしバッファキャッシュに載せることで速度改善を⾏う。 – 現在は、Writerで有効になっており、今後の改善でReaderにも適⽤を⾏う
  31. 31. Amazon Auroraの使いどころ
  32. 32. クエリ同時実⾏数やテーブルサイズが⼤きい • Amazon Auroraに移⾏することで、クエリスル ープットの向上などが⾒込まれる – マルチコア環境でCPUを効率的に利⽤ – 分散ロック機構やQuery Cacheの改善による性能向上 • ディスク – データ量の増加に応じてディスク容量を気にする必要が無い – 性能に影響を及ばさずバックアップ
  33. 33. 複数のサーバにシャーディングしている • 複数の⼩さいDBを1つにまとめる – コスト効果増⼤と管理コストの軽減 – シャーディングをするデータベースを減らすことでアプリケー ションの設計を簡略化出来る – 障害時の影響を考慮する必要はある – シャーディングガイド • http://amzn.to/2m1ay4P
  34. 34. 改善を⾏って来た機能
  35. 35. Reader Endpointの追加 • Amazon Aurora cluster内のReaderに単⼀のエンドポイントを提供 – ReaderがFailoverした場合は、再接続を⾏うことで新しいReaderに接続が可能 – Round Robinで接続 • メリット – Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間 でコネクションのロードバランシングが可能。リードワークロードを分散することで利⽤可能な Reader間でリソースを効率的に活⽤することができます – Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイン ト経由で接続することが可能。Availability Zoneの可⽤性の問題が万が⼀発⽣した場合、リード エンドポイントを利⽤することで最⼩限のダウンタイムでリードトラフィックを他のレプリカに 実⾏可能 – 今までHAproxyなどで分散されていた⽅は置き換えることでシンプルに負荷分散 • 注意点 – DNSベースなのでアプリケーションやドライバ側でIPアドレスのキャッシュ周りの設定の確認や failoverのテストを推薦 – Readerが1インスタンスもいなくなった場合はWriterへfailbackを⾏うため、Reader Endpointが Writerをさす
  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. Endpoint活⽤tips • Cluster / Reader endpointを利⽤することでバッ クエンドのAuroraインスタンスの状態をアプリ ケーションから意識する必要が軽減されてきた • さらに恩恵を受けるためにアプリケーション / ドラ イバで適切にリトライを⾏ったり、コネクション プーリングの再接続を設定 – アプリケーションの可⽤性の更なる向上
  38. 38. MySQLスナップショットバックアップからの移⾏ • Percona Xtrabackupを利⽤して作成したバックアップデータを 利⽤してオンプレミス環境やAmazon EC2上のMySQLから Amazon Auroraクラスへ移⾏する – mysqldumptと⽐較したテストで約20倍⾼速に移⾏可能 • バックアップデータをS3にアップロードし、そのデータを利⽤ – アップロードにはManagement ConsoleやCLI tools、データサイズが⼤きい場合は AWS Import/Export Snowballを利⽤してS3へ転送する • MySQLからAmazon Auroraへレプリケーションを⾏う機能と合 わせて利⽤することで、アプリケーションのダウンタイムを短 縮可能
  39. 39. クロスリージョンレプリケーション対応 • リージョン間でWriterとReaderを配置可能 • クロスリージョンレプリケーションのセットアップなどは全てマネージド • コンソールやAPI経由で簡単に構築可能 • DRや他リージョンへDBを移設する場合などに利⽤ • 注意点 • 機能を有効にする前に必ず最新のパッチを適⽤して下さい • バイナリログを利⽤したレプリケーションのため、設定前にDBパラメータ グループでbinlog_formatを設定(MIXED推薦) • バイナリログを利⽤したリージョン間レプリケーションのため、⼤きめの レプリカラグが発⽣しやすい
  40. 40. フェイルオーバー順の指定 • Amazon Auroraのフェイルオーバーの順位を任 意に設定可能 – フェイルオーバーで昇格させるReaderの順番を指定可能 • 優先的にフェイルオーバー先に指定するReaderを設定可能なため、 バッチや集計⽤となどで利⽤している、サービスに組み込みたくな いReaderを作ることも可能 • 優先度: Tier 0 > Tier 1 > … > Tier 15 • 同じ優先度のReaderが存在する場合 – Writerよりも⼤きいインスタンス – 優先度もインスタンスサイズも同じ場合は、同じ優先度のReaderから 任意に選択される
  41. 41. Cluster View • Amazon Aurora Clusterの情報専⽤の画⾯ – Cluster毎に情報を参照出来る – 例: Cluster Snapshotからリカバリを⾏ったり、Cluster内のDB インスタンスを全て削除した場合、Cluster定義のみが残るので、 Instance Viewには表⽰されないが、Cluster Viewには表⽰され る
  42. 42. 新機能
  43. 43. RDS MySQL DBインスタンスからAmazon Aurora Read Replica が作成可能に • RDS MySQLインスタンスからAmazon Auroraに ダウンタイムを最⼩限に移⾏する場合、今までは SnapshotからAuroraクラスタを起動し、⼿動でレ プリケーションを設定する必要があった • この機能を利⽤することによって、ワンクリックで RDS MySQLのSnapshotからAurora Read Replica を起動し、レプリケーションの設定まで⾃動で⾏わ れる
  44. 44. Advanced Auditing MariaDB server_audit plugin Aurora native audit support • We can sustain over 500K events/sec Create event string DDL DML Query DCL Connect DDL DML Query DCL Connect Write to File Create event string Create event string Create event string Create event string Create event string Latch-free queue Write to File Write to File Write to File MySQL 5.7 Aurora Audit Off 95K 615K 6.47x Audit On 33K 525K 15.9x Sysbench Select-only Workload on 8xlarge Instance
  45. 45. Zero downtime patch (ZDP) • コネクションを切断すること無くオンラインでパッチを適 ⽤ – 5秒程度スループットの低下が起こりますが、アプリケーションとの接続を維 持したままパッチを適⽤可能になりました (1.10以降) – ベストエフォート • 既に開かれているopen SSLコネクション、アクティブなロック、トランザクショ ンの完了やテンポラリテーブルの削除を待ちます。パッチ適⽤可能なウインドウが 出来た場合、ゼロダウンタイムパッチとして適⽤ • ゼロダウンタイムパッチで適⽤出来るウインドウがなかった場合、通常のパッチ適 ⽤プロセスを実⾏ – 以下の条件では通常通りのパッチ適⽤プロセスを実施 • バイナリログを有効にしている • Open SSLを利⽤した接続を⾏っており、ZDPのリトライ回数内に接続が終了しな い
  46. 46. ゼロダウンタイムパッチ Networkin g state Applicatio n state Storage Service App stat e Net stat e App state Net stat e BeforeZDP New DB Engine Old DB Engine New DB Engine Old DB Engine WithZDP セッションはパッチ 適⽤時に切断される パッチ適⽤中でも セッションは維持される Storage Service
  47. 47. 性能に関する改善 • Replication improvements – Readerのbuffer cacheを更新するためのログストリームを改善することで、heavy writeやreadワークロードで、リードパフォーマンスの向上と安定 • Throughput improvements for workload with cached reads – Buffer cacheから取得する様なワークロードで、Amazon Auroraはラッチフリーア ルゴリズムをread viewに適⽤することでスループットを向上させました – SysbenchのSelect onlyのベンチマークでは、Amazon Auroraは625K reads/sec、 MySQL5.7は164K reads/secの結果がみられました • Throughput improvements for workload with hot row contention – Amazon Auroraは新しいロックリリースアルゴリズムを利⽤することで、多くのト ランザクションが特定のrowやpageにアクセスするようなワークロードで性能向上 を⾏ないました – TPC-Cベンチマークの結果では、MySQL5.7と⽐較して最⼤16倍のスループットと なりました
  48. 48. db.t2.medium インスタンスクラスサポート • 検証・テスト向けにdb.t2.mediumインスタンスを サポート – テストや開発向けに利⽤を推薦 – CPUCreditUsageとCPUCreditBalanceの監視を⾏う
  49. 49. Improved index build • secondary indexの作成/変更を⾼速化 – db.r3.8xlargeを利⽤した場合、最⼤約75%⾼速化 – ボトムアップ⽅式でインデックスを構築し、不要なページ分割を 排除することで⾼速
  50. 50. Faster index build § MySQL 5.6 はLinuxの先読みを活用しています が、これにはbtreeに連続したブロックアドレスが 必要です。そのためエントリーをトップダウンで新 しいbtreeに挿入する際に、分割とたくさんのロギ ングを引き起こします。 § Auroraはtree内のポジション(ブロックアドレスで はなく)を元にブロックをスキャンしてプリフェッチ § Auroraはリーフブロックを作製してからブランチを 作製していく • 分割が発生しない • 各ページは1度のみ参照される • 1ページに1ログレコード 2-4X better than MySQL 5.6 or MySQL 5.7 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. Performance schema • Performance schemaを有効にした場合の性能劣 化を最⼩限に – Amazon Auroraチームのベンチマークでは、Sysbenchを⽤いた場 合MySQLでは60%性能低下があったが、Amazon Auroraでは MySQLと⽐較して1/4の劣化だった – db.r3.8xlargeを⽤いた場合、 Performance schemaを有効にした状 態のSysbenchで100K write/sec, 550K reads/sec
  52. 52. 性能・安定⾯の向上 • Smart read selector – 全てのリードリクエストで、異なるストレージセグメント間で適 切なストレージセグメントを選択することでリードレイテンシを 改善 – SysBenchを⽤いたWriteワークロードのテストで27%性能向上
  53. 53. 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 ;
  54. 54. Load Data From S3 • S3バケットに保存されたデータを直接Auroraにインポー ト可能 – テキスト形式(LOAD DATA FROM S3)・XML形式(LOAD XML FROM S3) – LOAD DATA INFILEとほぼ同様のオプションをサポート (圧縮形式のデータ は現在未サポート) <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>
  55. 55. 拡張モニタリング 50+ system/OS metrics | sorted process list view | 1–60 sec granularity alarms on specific metrics | egress to Amazon CloudWatch Logs | integration with third-party tools
  56. 56. 拡張モニタリング Process list Metrics list
  57. 57. spatial index • 空間インデックスサポート – Amazon Auroraは今までも地点やエリアを表すためにGEOMETRY 型を利⽤可能で、この型を使ってカラムを作成し、ST_Contains, ST_CrossesやST_Distanceといった機能をspatial queryを実⾏す るために利⽤可能 • ⼤きなデータセットに対してスケールするには不⼗分な点や制限が あった – Amazon Auroraではdimensionally ordered space-filling curveを利 ⽤しスケールし、⾼速かつ正確に情報を取得できる改善を⾏った • MySQL5.7と⽐較して最⼤2倍のパフォーマンス
  58. 58. 様々な性能改善 • Throughput improvement for workloads with hot row contention • Insert performanceの向上 • などなど
  59. 59. § プライマリーキーでソートされている データのバッチインサートの速度を改善。 インデックス⾛査を⾏う際のカーソル位 置をキャッシュ § データパターンに応じて動的に機能を有 効・無効化 § ツリーを下⽅向に⾛査する際のラッチ ロックの競合を軽減 § 双⽅向で全ての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トラバースを抑制
  60. 60. 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 using Sysbench 25% Throughput gain
  61. 61. • 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 using Sysbench 10% Throughput gain Non-cached read performance
  62. 62. まとめ
  63. 63. Amazon Aurora • クラウド時代にAmazonが再設計したRDBMS – MySQL5.6と互換があり既存の資産を活かしやすい • ⾼いクエリ実⾏並列度・データサイズが⼤きい環境 で性能を発揮 – Amazon Auroraはコネクション数やテーブル数が多い環境で優位性 を発揮 • ⾼可⽤性・⾼速なフェイルオーバ・PITRを実現す るための多くのチャレンジ

×