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

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

#AuroraMatsuri

⾃⼰紹介• 星野豊 (ほしのゆたか)

– @con_mame– facebook.com/conmame– データベースソリューションアーキテクト

• 経歴– 全てオンプレ環境のインフラエンジニア– 全てAWS環境のインフラエンジニア

• 担当– Webサービス / game / Video・Live Streamingなどのメディア系

のお客様

Amazon Aurora

Amazon Aurora

• re:Invent 2014で発表されたRDSの新しいエンジン

• Amazonがクラウド時代にリレーショナル・データベースを作るとどうなるかを1から考え構築– 新しい技術的チャレンジを盛り込んでいる

• エンタープライズグレードの可⽤性とOSSレベルのコストを両⽴

Amazon Auroraの特徴

ハイパフォーマンス

フルマネージド⾼可⽤性・⾼耐久性セキュリティにも配慮

MySQL5.6互換スケーラブル

Amazon Auroraの特徴• MySQL5.6と互換性があるため、既存のアプリケーションを簡単に

移⾏可能

• ストレージが10GBから64TBまでシームレスに拡張

• 3AZに2つずつ、計6つのデータのコピーを保持– S3にストリーミングバックアップを実施

• VPC内に起動– Security GroupやNACLを使⽤してアクセスコントロール可能

• Amazon Auroraは99.99%の可⽤性を実現するように設計されている

Po s t g r e S Q L Fo r A u r o raAurora is now fully compatible with

both PostgreSQL and MySQL

1/10th The Cost Of Commercial Grade Databases

Fully PostgreSQLCompatible

Several times better performance than typical PostgreSQL database

Scalable, Durable and Secure

Migrate FromRDS For PostgreSQL

Amazon Aurora PostgreSQL-Compatible Edition

新しいメトリクス画⾯• 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 |+-----------------+---------------------------------------+--------------------------------------------------------+

フェイルオーバとリカバリ

フェイルオーバとリプレース• リードレプリカが存在する場合は1分程でフェ

イルオーバ可能– RDS for MySQLよりも⾼速にフェイルオーバ可能– リードレプリカが存在しない場合は15分程

• Multi-AZ配置として別AZで起動する– RDS for MySQLと違いリードアクセス可能

クラスタエンドポイント• WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラ

スタエンドポイントが存在する• 各Auroraノードは個別にエンドポイントを持っている(⾍眼鏡タブ内のEndpointで確認可

能)

Reader

Writer

クラスタエンドポイント

Availability Zone A Availability Zone B

VPC subnet VPC subnet

VPC subnet VPC subnetAurora Writer Aurora Reader


• 各Auroraノードは個別にエンドポイントを持っている

• クラスタエンドポイントは、その時アクティブなAurora WriterノードのCNAME

• Readは各Readerを参照する

Write


• フェイルオーバが発⽣すると、Auroraノードの昇格が⾏われ、クラスタエンドポイントの指し先が変わる



VPC subnet VPC subnetAurora Writer Aurora Writer


Write

Writer / Readerノードの識別

• innodb_read_onlyを参照– SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ;– OFF: Writer– ON: Reader

• アプリケーションやドライバでAuroraノードに対する負荷分散やフェイルオーバーロジックの実装に利⽤可能– メトリクススキーマのSEESION_IDも利⽤可能

Amazon Aurora Driver

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

Aurora Driver

https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-mariadb-connector-j/

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


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


0%

5%

10%

15%

20%

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35


Database fail-over time

パフォーマンスTips

Auroraのパフォーマンスを引き出すために

• クエリ並列度が⾼い、データサイズが⼤きいケースで効果を発揮

• ロック機構やQuery Cache、スレッドプールなどに改善を⼊れて性能向上を⾏っている– Query Cacheはwrite heavyな環境ではoffを推奨– 全コアを効率的に利⽤する設計により、CPU利⽤率はMySQLと

⽐較して⾼くなるが、性能が落ちにくくなっている

よく⾒ると

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

スループットを出している

何をみるのか？

• よく聞かれる質問– CPU利⽤率⾼いんだけど?– メモリ利⽤量多いんだけど？– Disk IOが多めなんだけど？

• ⾒てほしいこと– Auroraはマシンリソースを最⼤限利⽤してスループットを

出す設計– システム全体でパフォーマンスが向上– 管理コスト、障害耐性、データ保全性

何をみるのか？

• AuroraはMySQL互換ですが、マシンリソースの使い⽅が根本的に違います

• Auroraが得意な場⾯・状況を理解してパフォーマンスを測定– マシンリソースを使い切りそうになっても、MySQLと⽐べ

るとスループットやレスポンスタイムの落ち⽅が緩やか

チューニング指針

• Amazon AuroraはMySQLと⽐較してインスタンスリソースを効率的に最⼤限利⽤する設計

• CPUやメモリの利⽤率が⾼めだが、パフォーマンスに影響が出ない限りは過度な⼼配は必要ない

• Amazon Auroraは実際のワークロードで性能が発揮できるように開発・チューニングが⾏われている– ベンチマークテストでは無く実際のワークロードでテストを⾏う– 監視項⽬もインスタンスリソースでは無く、実際のパフォーマンステス

トを元にクエリレイテンシやスループット・buffer poolのcache hitレートに注⽬

チューニング指針

• まずはデフォルトのパラメータグループを使⽤– Amazon Auroraはデフォルトの設定でパフォーマンスを発揮できる

ようにチューニング済み

• 適切なインスタンスタイプを選択することが⼤切– それでも性能が出ない場合にパラメータグループの変更を検討

チューニングTips

• 1トランザクションで⼤量の更新や削除を⾏ったり、⼤量データのシーケンシャルリードを⾏う場合

• 1トランザクションで⼤量の更新・削除やシーケンシャルリードを⾏う場合Amazon Auroraのアーキテクチャに合わせてクエリを実⾏することで性能を向上させることが可能

• Amazon Auroraは並列でトランザクションが実⾏されるワークロード(実ワークロード)に向けてチューニングされているため、クエリを分割して並列で実⾏

チューニングTips

#1> SELECT * FROM Table;

#1> SELECT * FROM Table WHERE id BETWEEN 1 AND 10000;



#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> .........

パフォーマンスの改善

• 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にも適⽤を⾏う

Amazon Auroraの使いどころ

クエリ同時実⾏数やテーブルサイズが⼤きい

• Amazon Auroraに移⾏することで、クエリスループットの向上などが⾒込まれる– マルチコア環境でCPUを効率的に利⽤– 分散ロック機構やQuery Cacheの改善による性能向上

• ディスク– データ量の増加に応じてディスク容量を気にする必要が無い– 性能に影響を及ばさずバックアップ

複数のサーバにシャーディングしている

• 複数の⼩さいDBを1つにまとめる– コスト効果増⼤と管理コストの軽減– シャーディングをするデータベースを減らすことでアプリケー

ションの設計を簡略化出来る– 障害時の影響を考慮する必要はある– シャーディングガイド

• http://amzn.to/2m1ay4P

改善を⾏って来た機能

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をさす

Reader Endpoint

• クラスタないのReaderにラウンドロビンで接続

• 常にReaderに接続されるが、Readerが1インスタンスもいなくなった場合はWriterにfailback

• Readerの追加・削除は⾃動で⾏われる



VPC subnet VPC subnetAurora Reader Aurora Reader

リーダエンドポイント

Read

Aurora Writer

Endpoint活⽤tips

• Cluster / Reader endpointを利⽤することでバックエンドのAuroraインスタンスの状態をアプリケーションから意識する必要が軽減されてきた

• さらに恩恵を受けるためにアプリケーション / ドライバで適切にリトライを⾏ったり、コネクションプーリングの再接続を設定– アプリケーションの可⽤性の更なる向上

MySQLスナップショットバックアップからの移⾏

• Percona Xtrabackupを利⽤して作成したバックアップデータを利⽤してオンプレミス環境やAmazon EC2上のMySQLからAmazon Auroraクラスへ移⾏する

– mysqldumptと⽐較したテストで約20倍⾼速に移⾏可能

• バックアップデータをS3にアップロードし、そのデータを利⽤– アップロードにはManagement ConsoleやCLI tools、データサイズが⼤きい場合は

AWS Import/Export Snowballを利⽤してS3へ転送する

• MySQLからAmazon Auroraへレプリケーションを⾏う機能と合わせて利⽤することで、アプリケーションのダウンタイムを短縮可能

クロスリージョンレプリケーション対応• リージョン間でWriterとReaderを配置可能

• クロスリージョンレプリケーションのセットアップなどは全てマネージド• コンソールやAPI経由で簡単に構築可能

• DRや他リージョンへDBを移設する場合などに利⽤

• 注意点• 機能を有効にする前に必ず最新のパッチを適⽤して下さい• バイナリログを利⽤したレプリケーションのため、設定前にDBパラメータ

グループでbinlog_formatを設定(MIXED推薦)• バイナリログを利⽤したリージョン間レプリケーションのため、⼤きめの

レプリカラグが発⽣しやすい

フェイルオーバー順の指定• Amazon Auroraのフェイルオーバーの順位を任

意に設定可能– フェイルオーバーで昇格させるReaderの順番を指定可能

• 優先的にフェイルオーバー先に指定するReaderを設定可能なため、バッチや集計⽤となどで利⽤している、サービスに組み込みたくないReaderを作ることも可能

• 優先度: Tier 0 > Tier 1 > … > Tier 15• 同じ優先度のReaderが存在する場合

– Writerよりも⼤きいインスタンス– 優先度もインスタンスサイズも同じ場合は、同じ優先度のReaderから

任意に選択される

Cluster View• Amazon Aurora Clusterの情報専⽤の画⾯

– Cluster毎に情報を参照出来る– 例: Cluster Snapshotからリカバリを⾏ったり、Cluster内のDB

インスタンスを全て削除した場合、Cluster定義のみが残るので、Instance Viewには表⽰されないが、Cluster Viewには表⽰される

新機能

RDS MySQL DBインスタンスからAmazon Aurora Read Replica が作成可能に

• RDS MySQLインスタンスからAmazon Auroraにダウンタイムを最⼩限に移⾏する場合、今まではSnapshotからAuroraクラスタを起動し、⼿動でレプリケーションを設定する必要があった

• この機能を利⽤することによって、ワンクリックでRDS MySQLのSnapshotからAurora Read Replicaを起動し、レプリケーションの設定まで⾃動で⾏われる

Advanced AuditingMariaDB 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

Zero downtime patch (ZDP)• コネクションを切断すること無くオンラインでパッチを適

⽤– 5秒程度スループットの低下が起こりますが、アプリケーションとの接続を維

持したままパッチを適⽤可能になりました (1.10以降)– ベストエフォート

• 既に開かれているopen SSLコネクション、アクティブなロック、トランザクションの完了やテンポラリテーブルの削除を待ちます。パッチ適⽤可能なウインドウが出来た場合、ゼロダウンタイムパッチとして適⽤

• ゼロダウンタイムパッチで適⽤出来るウインドウがなかった場合、通常のパッチ適⽤プロセスを実⾏

– 以下の条件では通常通りのパッチ適⽤プロセスを実施• バイナリログを有効にしている• Open SSLを利⽤した接続を⾏っており、ZDPのリトライ回数内に接続が終了しな

い

ゼロダウンタイムパッチ

Net

wor

kin

gst

ate

Appl

icat

ion

stat

e

Storage ServiceApp stat

e

Net stat

e

App state

Net stat

e

Befo

re Z

DP

New DB

Engine

Old DB Engine

New DB

Engine

Old DB Engine

With

ZDP

セッションはパッチ適⽤時に切断される

パッチ適⽤中でもセッションは維持される

Storage Service

性能に関する改善• 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倍のスループットとなりました

db.t2.medium インスタンスクラスサポート

• 検証・テスト向けにdb.t2.mediumインスタンスをサポート– テストや開発向けに利⽤を推薦– CPUCreditUsageとCPUCreditBalanceの監視を⾏う

Improved index build

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

排除することで⾼速

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

Hou

rsRDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016

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

性能・安定⾯の向上

• Smart read selector– 全てのリードリクエストで、異なるストレージセグメント間で適

切なストレージセグメントを選択することでリードレイテンシを改善

– SysBenchを⽤いたWriteワークロードのテストで27%性能向上

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とほぼ同様のオプションをサポート (圧縮形式のデータ

は現在未サポート)

<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>

拡張モニタリング

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

拡張モニタリング

Process list

Metrics list

spatial index

• 空間インデックスサポート– Amazon Auroraは今までも地点やエリアを表すためにGEOMETRY

型を利⽤可能で、この型を使ってカラムを作成し、ST_Contains, ST_CrossesやST_Distanceといった機能をspatial queryを実⾏するために利⽤可能

• ⼤きなデータセットに対してスケールするには不⼗分な点や制限があった

– Amazon Auroraではdimensionally ordered space-filling curveを利⽤しスケールし、⾼速かつ正確に情報を取得できる改善を⾏った

• MySQL5.7と⽐較して最⼤2倍のパフォーマンス

様々な性能改善

• Throughput improvement for workloads with hot row contention

• Insert performanceの向上

• などなど

§ プライマリーキーでソートされているデータのバッチインサートの速度を改善。インデックス⾛査を⾏う際のカーソル位置をキャッシュ

§ データパターンに応じて動的に機能を有効・無効化

§ ツリーを下⽅向に⾛査する際のラッチロックの競合を軽減

§ 双⽅向で全ての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トラバースを抑制

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

• 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

まとめ

Amazon Aurora

• クラウド時代にAmazonが再設計したRDBMS– MySQL5.6と互換があり既存の資産を活かしやすい

• ⾼いクエリ実⾏並列度・データサイズが⼤きい環境で性能を発揮– Amazon Auroraはコネクション数やテーブル数が多い環境で優位性

を発揮

• ⾼可⽤性・⾼速なフェイルオーバ・PITRを実現するための多くのチャレンジ

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

Data & Analytics