Amazon Relational Database Service (Amazon RDS)

Amazon Aurora

AWS Black Belt Online Seminar 2016

アマゾン ウェブ サービス ジャパン株式会社

ソリューションアーキテクト 星野 豊

AWS Black Belt Online Seminar とは

•

【水曜 18:00~19:00】

主にAWSサービスの紹介や アップデートの解説

(例：EC2、RDS、Lambda etc.)

【火曜 12:00~13:00】

主にAWSのソリューションや

業界カットでの使いどころなどを紹介

(例：ネットワーク、IoT、金融業界向け etc.)

※最新の情報は下記をご確認下さい。

オンラインセミナーのスケジュール&申し込みサイト

– http://aws.amazon.com/jp/about-aws/events/#webinar

本資料では2016年7月29日時点のサービス内容および価格についてご説明しています。

最新の情報は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.

価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、

別途消費税をご請求させていただきます。

今回お話する内容は2016/7/29現在の情報です

Amazon Aurora

データベース管理を簡単に

•

•

•

• S3

•

• DBA

– スキーマ設計・チューニング

– クエリ設計・チューニング などなど

Amazon RDS

Virginia / Oregon / Ireland / Sydney / Tokyo / Seoul / Mumbai

リージョン

Amazon Auroraの特徴

ハイパフォーマンス

フルマネージド 高可用性・高耐久性

セキュリティにも配慮

MySQL5.6互換 スケーラブル

リレーショナルデータベースをもう一度考える

• 今、データベースを再度実装するならどうする か？

–

–

セルフヒーリングが出来るようなデータベースを作りたいと考 えた

MySQLのエコシステムをそのまま活用可能

Business Intelligence Data Integration Query and Monitoring SI and Consulting

Source: Amazon

“Amazon Auroraに対してコンパチビリティを確認するテストスイートを実施し、全て完 璧に動作を行うことが確認出来ました。- Dan Jewett, Vice President of Product Management at Tableau

多くのサードパーティ監視ツールが利用可能

インスタンスタイプ

8GB 16GB 32GB 60GB 122GB 244GB

4core 8core 16core 32core

r3.8xl

2core 1core

r3.4xl r3.2xl

r3.xl r3.large

4GB 1GB

Memo ry

vCPU

アーキテクチャ

Service Oriented Architecture

•

•

•

99.999999999%の耐久性でス トリーミングバックアップ

Data Plane

Logging + Storage SQL

Transactions Caching

Amazon S3

Control Plane

Amazon DynamoDB

Amazon SWF

Amazon Route 53

キャッシュレイヤの分離

•

•

•

•

+

= DB

SQL Transactions

Caching

SQL Transactions

Caching

SQL Transactions

Caching

キャッシュプロセスをDBプロセス外におくことで

DBプロセスの再起動でもキャッシュが残る

セキュリティ

•

– AES-256 (ハードウエア支援)

– ディスクとAmazon S3に置かれている全ブロックを暗号化 – AWS KMSを利用したキー管理

•

•

•

Storage SQL Transactions

Caching

Amazon S3 Application

Aurora のストレージ

• SSD を利用したシームレス

にスケールするストレージ

• 標準で高可用性を実現

• Log structured Storage

SQL

Transactions

AZ 1 AZ 2 AZ 3

Caching

Amazon S3

Auroraのストレージの特徴

• リードレプリカもマスタと同じストレージを参照

• 継続的なS3へ増分バックアップ

–

• 64TBまで自動でストレージがシームレスにスケールアッ プ

–

• 自動で再ストライピング、ミラー修復、ホットスポット

管理、暗号化

ディスク障害検知と修復

• 2つのコピーに障害が起こっても、読み書きに影響は無い

• 3つのコピーに障害が発生しても読み込みは可能

• 自動検知、修復

SQL Transaction

AZ 1 AZ 2 AZ 3

Caching SQL

Transactio n

AZ 1 AZ 2 AZ 3

Caching

読み書き可能 読み込み可能

IO traffic in Aurora (ストレージノード)

LOG RECORDS Primary

instance

INCOMING QUEUE

STORAGE NODE

S3 BACKUP

1

2

3

4

5

6

7

8

UPDATE QUEUE ACK

HOT LOG

DATA BLOCKS

POINT IN TIME SNAPSHOT

GC

SCRUB COALESCE

SORT GROUP PEER-TO-PEER GOSSIP

Peer storage

nodes

全てのステップは非同期

ステップ1と2だけがフォアグラウンドのレイテンシーに影響 インプットキューはMySQLの1/46(unamplified, per node) レイテンシーにセンシティブな操作に向く

ディスク領域をバッファーに使ってスパイクに対処 OBSERVATIONS

IO FLOW

① レコードを受信しインメモリのキューに追加

② レコードをSSDに永続化してACK

③ レコードを整理してギャップを把握

④ ピアと通信して穴埋め

⑤ ログレコードを新しいバージョンのデータブロックに合体

⑥ 定期的にログと新しいバージョンのブロックをS3に転送

⑦ 定期的に古いバージョンのガベージコレクションを実施

⑧ 定期的にブロックのCRCを検証

レプリケーション

Aurora Master

30% Read 70% Write

Aurora Replica

100% New Reads

Shared Multi-AZ Storage MySQL Master

30% Read 70% Write

MySQL Replica

30% New Reads 70% Write シングルスレッド

でBinlog適用

Data Volume Data Volume

MySQL read scaling

• レプリケーションにはbinlog / relay logが必要

• レプリケーションはマスターへ負荷がかかる

• レプリケーション遅延が増加していくケースが ある

• フェイルオーバでデータロスの可能性がある

PAGE CACHE UPDATE

コスト比較: Aurora vs. RDS for MySQL

Primary r3.8XL

Standby r3.8XL

Replica r3.8XL

Replica R3.8XL

Storage 6 TB / 10 K PIOP

Storage 6 TB / 10 K PIOP

Storage 6 TB / 5 K PIOP

Storage 6 TB / 5 K PIOP

$1.33/hr

$1.33/hr

$1.33/hr $1.33/hr

$2,42/hr

$2,42/hr $2,42/hr

Instance cost: $5.32 / hr Storage cost: $8.30 / hr Total cost: $13.62 / hr

$2,42/hr

コスト比較 : Aurora vs. RDS for MySQL

Instance cost: $4.86 / hr Storage cost: $4.43 / hr Total cost: $9.29 / hr

Primary r3.8XL

Replica r3.8XL

Replica R3.8XL

Storage / 6 TB

$1.62 / hr $1.62 / hr $1.62 / hr

$4.43 / hr

31.8%

Savings

 スタンバイインスタンスのコストが不要

 １つの共有ストレージ

 No POIPs – pay for use I/O

新しいメトリクス画面

•

– Select – Commit – DML/DDL

•

– Select – Commit – DML/DDL

•

– Buffer Cache – Result Set

•

•

•

新しいメトリクス画面

• 課金に関わるディスク利用量やIOPS

–

–

–

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

フェイルオーバ と リプレース

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

–

–

• Multi-AZ配置として別AZで起動する

–

クラスタエンドポイント

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

• 各Auroraノードは個別にエンドポイントを持っている(虫眼鏡タブ内のEndpointで確認可 能)

Reader

Writer

クラスタエンドポイント

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

クラスタエンドポイント

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

Availability Zone A Availability Zone B

VPC subnet VPC subnet

VPC subnet VPC subnet

Aurora Writer Aurora Writer

クラスタエンドポイント

Write

フェイルオーバー時の注意点

• Auroraのフェイルオーバーの仕組みにより、RDS MySQLよりも高速にフェイルオーバーが行われる

• フェイルオーバー実行時に新WriterとReaderの

キャッシュの整合性をとるため各ReaderのAuroraプ ロセスもリスタートされる

•

高速でより予測可能なフェイルオーバー時間

App running Failure detection DNS propagation

Recovery Recovery

DB failure

MySQL

App running Failure detection DNS propagation

Recovery DB

failure

AURORA WITH MARIADB DRIVER

1 5 - 2 0 s e c

3 - 2 0 s e c

Streaming snapshotとPITR

• Amazon Auroraでは各セグメント毎にAmazon S3 へ継続的に増分バックアップを取得している

–

• Amazon Auroraが使用しているディスクの仕組み によりパフォーマンスへ影響を与えない

• PITRで5分前からBackup Retention Periodまでの

任意の位置に秒単位で復元可能

高速なデータ修復

既存のデータベース

•

•

Amazon Aurora

•

•

Checkpointed Data Redo Log

T0 でクラッシュが発生すると 最後のチェックポイントからの ログを適用する必要がある

T₀ T₀

T0 でクラッシュが発生するとredo

を並列で分散して非同期でログの適用を行う

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

•

–

–

チューニングとパフォーマンス

WRITE PERFORMANCE READ PERFORMANCE

MySQL SysBench results

R3.8XL: 32 cores / 244 GB RAM

5X faster than RDS MySQL 5.6 & 5.7

SysBenchを用いたベンチマークにおいて MySQLと比較して、5倍高いスループットを計測

0 25,000 50,000 75,000 100,000 125,000 150,000

0 100,000 200,000 300,000 400,000 500,000 600,000 700,000

Aurora MySQL 5.6 MySQL 5.7

WRITE PERFORMANCE READ PERFORMANCE

インスタンスサイズによるスケール

AuroraはRead/Writeパフォーマンス共にインスタンスサイズに比例してスケール

Aurora MySQL 5.6 MySQL 5.7

Beyond benchmarks

• もしも 実環境のアプリケーションがベンチマークと 同様のパフォーマンスを出すのであれば、新しい

データベースを作る必要は無かった

• POSSIBLE DISTORTIONS

–

–

–

–

チューニング指針

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

• CPU

りは過度な心配は必要ない

• Amazon Aurora は実際のワークロードで性能が発揮でき るように開発・チューニングが行われている

–

–

buffer pool

cache hit

チューニング指針

• まずはデフォルトのパラメータグループを使用

– Amazon Aurora

• 適切なインスタンスタイプを選択することが大切

–

I/Oを減らす

ネットワークパケットを最小限にする 結果をキャッシュしておく

データベースエンジンをオフロードする

DO LESS WORK

非同期で処理する

レイテンシーの通り道を減らす ロックフリーなデータ構造を使う バッチ操作を同時に行う

BE MORE EFFICIENT

データベースは I/O が全て

ネットワーク接続したストレージは PACKETS/SECOND が全て 高スループットの処理に コンテキストスイッチ は許されない

性能向上のために行っていること

IO traffic in RDS MySQL

BINLOG DATA DOUBLE-WRITE

LOG FRM

FILES T Y P E O F W R I T E

MYSQL WITH STANDBY

EBSに書き込み– EBSがミラーへ複製し、両方終了後ack

スタンバイインスタンス側のEBSに書き込み IO FLOW

ステップ1, 3, 5はシーケンシャルかつ同期

それによりレイテンシーもパフォーマンスのゆらぎも増加 各ユーザー操作には様々な書き込みタイプがある

書き込み破損を避けるためにデータブロックを2回書く必要性 OBSERVATIONS

780K トランザクション

100万トランザクション当たり7,388K I/Os (ミラー, スタンバイを除く) 平均1トランザクション当たり7.4 I/Os

PERFORMANCE

30 minute SysBench write-only workload, 100 GB data set, RDS SingleAZ, 30K PIOPS

EBS mirror

EBS mirror

AZ 1 AZ 2

Amazon S3

Amazon Elastic EBS Block Store (EBS) Primary instance

Standby instance

1

2

3

4

5

IO traffic in Aurora (データベース)

AZ 1 AZ 3

Primary instance

Amazon S3 AZ 2

Replica instance AMAZON AURORA

ASYNC 4/6 QUORUM

DISTRIBUTED WRITES

BINLOG DATA DOUBLE-WRITE

LOG FRM

FILES T Y P E O F W R I T E

30 minute SysBench write-only workload, 100 GB data set IO FLOW

REDOログレコードのみ書き込む; 全てのステップは非同期 データブロックは書かない(チェックポイント, キャッシュ置換時) 6倍のログ書き込みだが, 1/9のネットワークトラフィック

ネットワークとストレージのレイテンシー異常時の耐性 OBSERVATIONS

27,378K トランザクション 35X MORE

100万トランザクション当たり950K I/Os 7.7X LESS (6X amplification)

PERFORMANCE

REDOログレコードをまとめる–完全にLSN順に並ぶ

適切なセグメントに分割する–部分ごとに並ぶ ストレージノードへまとめて書き込む

スレッドプール

• Amazon Auroraはスレッドプールが実装されてい る

–

–

Client Thread Thread Thread Thread Client

MySQL

Client Thread Thread Thread Thread Client

Aurora

Thread Pool

• アクティブなスレッドに複数のコネクションを収容

• スレッドプールの数は動的に調整される

• r3.8xlインスタンスのAmazon Auroraで5,000同時コネクションを扱 える

• Standard MySQL –コネクション毎に1

• コネクション数に応じてスケールしない

• MySQL EE –スレッドプール毎にコネクションをアサイン

• しきい値を慎重に設定する必要がある

CLIENT CONNECTION CLIENT CONNECTION

LATCH FREE TASK QUEUE

epoll()

MYSQL THREAD MODEL AURORA THREAD MODEL

Adaptive Thread Pool

非同期グループコミット

Read

Write

Commit Read

Read

T1

C o m m i t ( T 1 ) C o m m i t ( T 2 ) C o m m i t ( T 3 )

L S N 1 0 L S N 1 2 L SN 2 2 L S N 5 0

L SN 3 0 L SN 3 4 L SN 4 1 L SN 4 7

LSN 20

LSN 49

C o m m i t ( T 4 ) C o m m i t ( T 5 ) C o m m i t ( T 6 ) C o m m i t ( T 7 ) C o m m i t ( T 8 )

LSN GROWTH

Durable LSN at head-node

COMMIT QUEUE

Pending commits in LSN order

TIME

GROUP COMMIT TRANSACTIONS

Read

Write

Commit Read

Read

T1

Read

Write

Commit Read

Read

Tn

TRADITIONAL APPROACH

AMAZON AURORA ディスクへ書き込むためののログバッファを管理

バッファが一杯になるか書き込み待ち時間を超過すると書 き込みを実行

書き込み頻度が少ない場合は最初の書き込みが遅くなる

最初の書き込みと同時にI/Oリクエストを実行。書き込み が実行されるまでバッファを埋める

6つの内4つのストレージノードからACKが返ってきた時 点で堅牢性のある書き込みが完了

過去数ヶ月で改善したこと

書き込みバッチサイズのチューニング read/write I/O要求送信の非同期化 パージスレッドのパフォーマンス バルクインサートのパフォーマンス

バッチ操作

フェイルオーバー時間の短縮 mallocの削減

システムコールの削減

Undoスロットのキャッシュパターン 協調したログ適用

その他

binlogと分散トランザクション ロックの圧縮

先読み(read-ahead)

顧客フィードバック

ホットな行競合 ディクショナリ統計

小さなトランザクションのコードパス クエリーキャッシュのread/write競合 ディクショナリシステムのmutex

ロック競合

Amazon Auroraの使いどころ

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

• Amazon Aurora に移行することで、クエリスル ープットの向上などが見込まれる

–

CPU

–

Query Cache

• ディスク

–

–

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

• 複数の小さい DB を 1 つにまとめる

–

–

–

新機能

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

• Percona Xtrabackup を利用して作成したバックアップデータを 利用してオンプレミス環境や Amazon EC2 上の MySQL から

Amazon Aurora クラスへ移行する

– mysqldump

20

• バックアップデータを S3 にアップロードし、そのデータを利用

–

Management Console

CLI tools

AWS Import/Export Snowball

S3

• MySQL から Amazon Aurora へレプリケーションを行う機能と合

わせて利用することで、アプリケーションのダウンタイムを短

縮可能

クロスリージョンレプリケーション対応

• リージョン間で Writer と Reader を配置可能

•

•

API

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

• 注意点

•

•

DB

binlog_format

(MIXED

)

•

大きめのレプリカラグが発生しやすい

Auroraでアカウント間でスナップショットを共有可能 に

• Auroraスナップショットを共有可能に

–

–

• 用途

–

–

Auroraで暗号化されていないSnapshotから暗号化ク ラスタを作成可能に

• 暗号化されていないAuroraクラスタを、KMSで 暗号化されたAuroraクラスタへ簡単に移行可能

• Snapshotからrestoreを行う

• 既存のSnapshotからrestoreする際にEnable

EncryptionをYesに設定し使用するKeyを選択

ローカルタイムゾーン対応

• time_zone パラメータにより任意のタイムゾー

ンに設定可能

– RDS MySQL, RDS MariaDB

フェイルオーバー順の指定

• 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

拡張モニタリング

Process list

Metrics list

重要なシステム／OSメトリクスに対応

User System Wait IRQ Idle

CPU Utilization

Rx per declared ethn Tx per declared ethn Network

Num processes Num interruptible Num non-interruptible Num zombie

Processes

Process ID Process name VSS

Res Mem % consumed CPU % used CPU time Parent ID Process List

MemTotal MemFree Buffers Cached SwapCached Active

Inactive SwapTotal SwapFree Dirty Writeback Mapped Slab Memory

TPS Blk_read Blk_wrtn read_kb read_IOs read_size write_kb write_IOs write_size avg_rw_size avg_queue_len Device IO

Free capacity Used

% Used File System

拡張モニタリング

• CloudWatch LogsからElasticsearch Service

Encryption at Rest （格納時暗号化）

• Key Management Service(KMS) を利用し、透過的な暗 号化と復号を行う

–

Aurora

–

Snapshot

–

Snapshot

Aurora

• Disk に書き込まれるタイミングで自動的に実施

• テーブルの中身を暗号化するものでは無い点注意

–

(KMS

)

パフォーマンスの改善

• 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

–

Lab mode

• 今後提供予定の機能を試すことが可能

– DB

aurora_lab_mode

–

• Production

に向けて多くのワークロードで安定して性能を出せるように最後の 調整が行われているステータスです

•

OFF

–

まとめ

Amazon Aurora

• クラウド時代に Amazon が再設計した RDBMS

– MySQL5.6

• 高いクエリ実行並列度・データサイズが大きい環境で 性能を発揮

– Amazon Aurora

• 高可用性・高速なフェイルオーバー・実環境での性能

向上を実現するための多くのチャレンジ

Webinar資料の配置場所

• AWS クラウドサービス活用資料集

–

– http://aws.amazon.com/jp/aws-jp-introduction/

• AWS Solutions Architect ブログ

–

– http://aws.typepad.com/sajp/

Q&A

[導入に関しての問い合わせ]

http://aws.amazon.com/jp/contact-us/aws-sales/

[課金・請求内容、またはアカウントに関するお問い合わせ]

https://aws.amazon.com/jp/contact-us/

Webinar資料の配置場所

• AWS クラウドサービス活用資料集

– http://aws.amazon.com/jp/aws-jp-introduction/

公式Twitter/Facebook

AWSの最新情報をお届けします

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを 日々更新しています！

もしくは

http://on.fb.me/1vR8yWm