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

1. Amazon Auroraを使いこなすための
ベストプラクティスと最新アップデート
Amazon Web Services Japan K.K.
#AuroraMatsuri

2. ⾃⼰紹介
• 星野 豊 (ほしの ゆたか)
– @con_mame
– facebook.com/conmame
– データベース ソリューションアーキテクト
• 経歴
– 全てオンプレ環境のインフラエンジニア
– 全てAWS環境のインフラエンジニア
• 担当
– Webサービス / game / Video・Live Streamingなどのメディア系
のお客様

3. Amazon Aurora

4. Amazon Aurora
• re:Invent 2014で発表されたRDSの新しいエンジン
• Amazonがクラウド時代にリレーショナル・データ
ベースを作るとどうなるかを1から考え構築
– 新しい技術的チャレンジを盛り込んでいる
• エンタープライズグレードの可⽤性とOSSレベルの
コストを両⽴

5. Amazon Auroraの特徴
ハイパフォーマンス
フルマネージド ⾼可⽤性・⾼耐久性セキュリティにも配慮
MySQL5.6互換スケーラブル

6. Amazon Auroraの特徴
• MySQL5.6と互換性があるため、既存のアプリケーションを簡単に
移⾏可能
• ストレージが10GBから64TBまでシームレスに拡張
• 3AZに2つずつ、計6つのデータのコピーを保持
– S3にストリーミングバックアップを実施
• VPC内に起動
– Security GroupやNACLを使⽤してアクセスコントロール可能
• Amazon Auroraは99.99%の可⽤性を実現するように設計されている

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. 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. 新しいメトリクス画⾯
• Throughput
– Select
– Commit
– DML/DDL
• Latency
– Select
– Commit
– DML/DDL
• Cache Hit Ratio
– Buffer Cache
– Result Set
• Deadlocks
• Login Failures
• Blocked Transactions

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. フェイルオーバとリカバリ

12. フェイルオーバ と リプレース
• リードレプリカが存在する場合は1分程でフェ
イルオーバ可能
– RDS for MySQLよりも⾼速にフェイルオーバ可能
– リードレプリカが存在しない場合は15分程
• Multi-AZ配置として別AZで起動する
– RDS for MySQLと違いリードアクセス可能

13. クラスタエンドポイント
• WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラ
スタエンドポイントが存在する
• 各Auroraノードは個別にエンドポイントを持っている(⾍眼鏡タブ内のEndpointで確認可
能)
Reader
Writer

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. クラスタエンドポイント
• フェイルオーバが発
⽣すると、Aurora
ノードの昇格が⾏わ
れ、クラスタエンド
ポイントの指し先が
変わる
Availability Zone A Availability Zone B
VPC subnet VPC subnet
VPC subnet VPC subnet
Aurora Writer Aurora Writer
クラスタエンドポイント
Write

16. Writer / Readerノードの識別
• innodb_read_onlyを参照
– SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ;
– OFF: Writer
– ON: Reader
• アプリケーションやドライバでAuroraノードに
対する負荷分散やフェイルオーバーロジックの
実装に利⽤可能
– メトリクススキーマのSEESION_IDも利⽤可能

17. Amazon Aurora Driver

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. Aurora Driver
https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/

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. パフォーマンスTips

22. Auroraのパフォーマンスを引き出すために
• クエリ並列度が⾼い、データサイズが⼤きい
ケースで効果を発揮
• ロック機構やQuery Cache、スレッドプールな
どに改善を⼊れて性能向上を⾏っている
– Query Cacheはwrite heavyな環境ではoffを推奨
– 全コアを効率的に利⽤する設計により、CPU利⽤率はMySQLと
⽐較して⾼くなるが、性能が落ちにくくなっている

23. よく⾒ると
• CPU / Memoryの利⽤率がMySQLより⾼いがス
ループットが出ている
– 分散ロック機構によりCPUリソースを使いきって
スループットを出している

24. 何をみるのか？
• よく聞かれる質問
– CPU利⽤率⾼いんだけど?
– メモリ利⽤量多いんだけど？
– Disk IOが多めなんだけど？
• ⾒てほしいこと
– Auroraはマシンリソースを最⼤限利⽤してスループットを
出す設計
– システム全体でパフォーマンスが向上
– 管理コスト、障害耐性、データ保全性

25. 何をみるのか？
• AuroraはMySQL互換ですが、マシンリソースの
使い⽅が根本的に違います
• Auroraが得意な場⾯・状況を理解してパフォー
マンスを測定
– マシンリソースを使い切りそうになっても、MySQLと⽐べ
るとスループットやレスポンスタイムの落ち⽅が緩やか

26. チューニング指針
• Amazon AuroraはMySQLと⽐較してインスタンスリ
ソースを効率的に最⼤限利⽤する設計
• CPUやメモリの利⽤率が⾼めだが、パフォーマンスに影響が出ない限
りは過度な⼼配は必要ない
• Amazon Auroraは実際のワークロードで性能が発揮でき
るように開発・チューニングが⾏われている
– ベンチマークテストでは無く実際のワークロードでテストを⾏う
– 監視項⽬もインスタンスリソースでは無く、実際のパフォーマンステス
トを元にクエリレイテンシやスループット・buffer poolのcache hitレー
トに注⽬

27. チューニング指針
• まずはデフォルトのパラメータグループを使⽤
– Amazon Auroraはデフォルトの設定でパフォーマンスを発揮できる
ようにチューニング済み
• 適切なインスタンスタイプを選択することが⼤切
– それでも性能が出ない場合にパラメータグループの変更を検討

28. チューニングTips
• 1トランザクションで⼤量の更新や削除を⾏っ
たり、⼤量データのシーケンシャルリードを⾏
う場合
• 1トランザクションで⼤量の更新・削除やシーケンシャル
リードを⾏う場合Amazon Auroraのアーキテクチャに合わ
せてクエリを実⾏することで性能を向上させることが可能
• Amazon Auroraは並列でトランザクションが実⾏される
ワークロード(実ワークロード)に向けてチューニングされて
いるため、クエリを分割して並列で実⾏

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. パフォーマンスの改善
• 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. Amazon Auroraの使いどころ

32. クエリ同時実⾏数やテーブルサイズが⼤きい
• Amazon Auroraに移⾏することで、クエリスル
ープットの向上などが⾒込まれる
– マルチコア環境でCPUを効率的に利⽤
– 分散ロック機構やQuery Cacheの改善による性能向上
• ディスク
– データ量の増加に応じてディスク容量を気にする必要が無い
– 性能に影響を及ばさずバックアップ

33. 複数のサーバにシャーディングしている
• 複数の⼩さいDBを1つにまとめる
– コスト効果増⼤と管理コストの軽減
– シャーディングをするデータベースを減らすことでアプリケー
ションの設計を簡略化出来る
– 障害時の影響を考慮する必要はある
– シャーディングガイド
• http://amzn.to/2m1ay4P

34. 改善を⾏って来た機能

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. 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. Endpoint活⽤tips
• Cluster / Reader endpointを利⽤することでバッ
クエンドのAuroraインスタンスの状態をアプリ
ケーションから意識する必要が軽減されてきた
• さらに恩恵を受けるためにアプリケーション / ドラ
イバで適切にリトライを⾏ったり、コネクション
プーリングの再接続を設定
– アプリケーションの可⽤性の更なる向上

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. クロスリージョンレプリケーション対応
• リージョン間でWriterとReaderを配置可能
• クロスリージョンレプリケーションのセットアップなどは全てマネージド
• コンソールやAPI経由で簡単に構築可能
• DRや他リージョンへDBを移設する場合などに利⽤
• 注意点
• 機能を有効にする前に必ず最新のパッチを適⽤して下さい
• バイナリログを利⽤したレプリケーションのため、設定前にDBパラメータ
グループでbinlog_formatを設定(MIXED推薦)
• バイナリログを利⽤したリージョン間レプリケーションのため、⼤きめの
レプリカラグが発⽣しやすい

40. フェイルオーバー順の指定
• Amazon Auroraのフェイルオーバーの順位を任
意に設定可能
– フェイルオーバーで昇格させるReaderの順番を指定可能
• 優先的にフェイルオーバー先に指定するReaderを設定可能なため、
バッチや集計⽤となどで利⽤している、サービスに組み込みたくな
いReaderを作ることも可能
• 優先度: Tier 0 > Tier 1 > … > Tier 15
• 同じ優先度のReaderが存在する場合
– Writerよりも⼤きいインスタンス
– 優先度もインスタンスサイズも同じ場合は、同じ優先度のReaderから
任意に選択される

41. Cluster View
• Amazon Aurora Clusterの情報専⽤の画⾯
– Cluster毎に情報を参照出来る
– 例: Cluster Snapshotからリカバリを⾏ったり、Cluster内のDB
インスタンスを全て削除した場合、Cluster定義のみが残るので、
Instance Viewには表⽰されないが、Cluster Viewには表⽰され
る

42. 新機能

43. RDS MySQL DBインスタンスからAmazon
Aurora Read Replica が作成可能に
• RDS MySQLインスタンスからAmazon Auroraに
ダウンタイムを最⼩限に移⾏する場合、今までは
SnapshotからAuroraクラスタを起動し、⼿動でレ
プリケーションを設定する必要があった
• この機能を利⽤することによって、ワンクリックで
RDS MySQLのSnapshotからAurora Read Replica
を起動し、レプリケーションの設定まで⾃動で⾏わ
れる

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. Zero downtime patch (ZDP)
• コネクションを切断すること無くオンラインでパッチを適
⽤
– 5秒程度スループットの低下が起こりますが、アプリケーションとの接続を維
持したままパッチを適⽤可能になりました (1.10以降)
– ベストエフォート
• 既に開かれているopen SSLコネクション、アクティブなロック、トランザクショ
ンの完了やテンポラリテーブルの削除を待ちます。パッチ適⽤可能なウインドウが
出来た場合、ゼロダウンタイムパッチとして適⽤
• ゼロダウンタイムパッチで適⽤出来るウインドウがなかった場合、通常のパッチ適
⽤プロセスを実⾏
– 以下の条件では通常通りのパッチ適⽤プロセスを実施
• バイナリログを有効にしている
• Open SSLを利⽤した接続を⾏っており、ZDPのリトライ回数内に接続が終了しな
い

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. 性能に関する改善
• 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. db.t2.medium インスタンスクラスサポート
• 検証・テスト向けにdb.t2.mediumインスタンスを
サポート
– テストや開発向けに利⽤を推薦
– CPUCreditUsageとCPUCreditBalanceの監視を⾏う

49. Improved index build
• secondary indexの作成/変更を⾼速化
– db.r3.8xlargeを利⽤した場合、最⼤約75%⾼速化
– ボトムアップ⽅式でインデックスを構築し、不要なページ分割を
排除することで⾼速

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. 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. 性能・安定⾯の向上
• Smart read selector
– 全てのリードリクエストで、異なるストレージセグメント間で適
切なストレージセグメントを選択することでリードレイテンシを
改善
– SysBenchを⽤いたWriteワークロードのテストで27%性能向上

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. 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. 拡張モニタリング
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. 拡張モニタリング
Process list
Metrics list

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. 様々な性能改善
• Throughput improvement for workloads
with hot row contention
• Insert performanceの向上
• などなど

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. 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. • 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. まとめ

63. Amazon Aurora
• クラウド時代にAmazonが再設計したRDBMS
– MySQL5.6と互換があり既存の資産を活かしやすい
• ⾼いクエリ実⾏並列度・データサイズが⼤きい環境
で性能を発揮
– Amazon Auroraはコネクション数やテーブル数が多い環境で優位性
を発揮
• ⾼可⽤性・⾼速なフェイルオーバ・PITRを実現す
るための多くのチャレンジ