Contenu connexe Similaire à [Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス (20) Plus de Amazon Web Services Japan (20) [Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス2. ⾃⼰紹介
• 星野 豊 (ほしの ゆたか)
– @con_mame
– facebook.com/conmame
– データベース ソリューションアーキテクト
• 経歴
– 全てオンプレ環境のインフラエンジニア
– 全てAWS環境のインフラエンジニア
• 担当
– Webサービス / game / Video・Live Streamingなどのメディア系
のお客様
4. Amazon Aurora
• re:Invent 2014で発表されたRDSの新しいエンジン
• Amazonがクラウド時代にリレーショナル・データ
ベースを作るとどうなるかを1から考え構築
– 新しい技術的チャレンジを盛り込んでいる
• エンタープライズグレードの可⽤性とOSSレベルの
コストを両⽴
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 |
+-----------------+---------------------------------------+--------------------------------------------------------+
12. フェイルオーバ と リプレース
• リードレプリカが存在する場合は1分程でフェ
イルオーバ可能
– RDS for MySQLよりも⾼速にフェイルオーバ可能
– リードレプリカが存在しない場合は15分程
• Multi-AZ配置として別AZで起動する
– RDS for MySQLと違いリードアクセス可能
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
16. Writer / Readerノードの識別
• innodb_read_onlyを参照
– SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ;
– OFF: Writer
– ON: Reader
• アプリケーションやドライバでAuroraノードに
対する負荷分散やフェイルオーバーロジックの
実装に利⽤可能
– メトリクススキーマのSEESION_IDも利⽤可能
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
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
23. よく⾒ると
• CPU / Memoryの利⽤率がMySQLより⾼いがス
ループットが出ている
– 分散ロック機構によりCPUリソースを使いきって
スループットを出している
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にも適⽤を⾏う
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インスタンスの状態をアプリ
ケーションから意識する必要が軽減されてきた
• さらに恩恵を受けるためにアプリケーション / ドラ
イバで適切にリトライを⾏ったり、コネクション
プーリングの再接続を設定
– アプリケーションの可⽤性の更なる向上
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には表⽰され
る
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のリトライ回数内に接続が終了しな
い
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倍のスループットと
なりました
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
57. spatial index
• 空間インデックスサポート
– Amazon Auroraは今までも地点やエリアを表すためにGEOMETRY
型を利⽤可能で、この型を使ってカラムを作成し、ST_Contains,
ST_CrossesやST_Distanceといった機能をspatial queryを実⾏す
るために利⽤可能
• ⼤きなデータセットに対してスケールするには不⼗分な点や制限が
あった
– Amazon Auroraではdimensionally ordered space-filling curveを利
⽤しスケールし、⾼速かつ正確に情報を取得できる改善を⾏った
• MySQL5.7と⽐較して最⼤2倍のパフォーマンス
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