© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Debanjan Saha, GM, Amazon AuroraJun Okubo, Business Development Manager

November 2015

Using Amazon Aurora

for Enterprise Workloads

Amazon Aurora

東京ローンチ記念セミナー

エンタープライズ顧客の要望リスト

….が出来るデータベース

コンポーネント障害が発生しても動き続ける….

エンタープライズ規模で安定した性能を発揮する…

専門家部隊がいなくても運用・管理できる…

大金をはたかずともよい; ライセンスを管理しなくてよい…

Amazon Aurora: クラウド向けのエンタープライズ級データベース

私たちはエンタープライズ向けの要件から入り、クラウド向けのリレーショナルデータベースとはどうあるべきか、を再考しました….

エンタープライズ級の可用性とパフォーマンス

完全なマネージドサービスとして提供

ライセンス不要; 商用データベースの1/10のコスト

MySQL互換のリレーショナルデータベース

商用データベース並みの

パフォーマンス と 可用性

オープンソースデータベース並みの

使いやすさ と コスト効果

マネージドサービスとして提供

Amazon Aurora とは?

Aurora at a glance

AZ 1 AZ 2 AZ 3

Amazon S3

MasterRead

Replica

Read

Replica

Read

ReplicaRead

Replica

Massively scale-out storage

distributed across 3 AZs

エンタープライズに最適

3箇所のデータセンターに6つの複製を保持

30秒以内でフェイルオーバー

ほぼ即時に行われるクラッシュリカバリー

最大50万回/秒の読込、10万回/秒の書込性能

15個までの低遅延(10 ms)リードレプリカ

64TBまで拡張できる、DBに最適化したストレージ

すぐに行えるプロビジョニングとデプロイ

自動化されたパッチとソフトウェアアップグレード

バックアップとポイント・イン・タイム・リカバリー

コンピュートとストレージのスケーラビリティー

パフォーマンスとスケール

エンタープライズ級の可用性

完全マネージドサービス

Amazon Auroraを活用中の顧客事例

AWSの歴史上

最も速く成長しているサービス

Aurora 採用顧客事例

Expedia: オンライン旅行販売

成長を続けるオンライン旅行販売データに対するリアルタイムなビジネス・インテリジェンスと分析

現行の SQL Server ベースのアーキテクチャは非常に高価であった。また、データボリュームの増加と共にパフォーマンスの低下が見られた。

Cassandra と Solr を組み合わせたインデックスは大きなメモリー空間を必要とし、コストを押し上げた

Auroraがもたらしたメリット：

Aurora はスケーラビリティーとパフォーマンス要件を満たし、コストもずっと低かった

平常時25,000インサート/秒 （ピーク時70,000）平均レスポンスタイムは書込30ミリ秒、読込17ミリ秒

世界をリードするオンライン旅行業者、

70カ国で150以上の旅行関連サイト

を運営

PG&E: 大手公益企業

電力関係のイベントが起きた際に突発的なトラフィックを処理することに常に課題を抱えていた

データベースが落ちた時の影響が甚大; 結果的に顧客に対するガスと電力の供給へ影響が出る

Auroraがもたらしたメリット：

遅延のほとんどない（ミリ秒級）リードレプリカを複数持つことが出来るため、電力関係のイベントが起きた際でも突発的なトラフィックを処理し、顧客に最新の情報をタイムリーに提供できるようになった

6ヶ所にデータを複製し、ストレージやインスタンス障害時に自動復旧するAmazon Auroraにより、ミッションクリティカルなアプリケーションが要求する可用性と信頼性がもたらされた

天然ガス＋電力の公益企業において米国最

大手の1社で、北部および中央カリフォルニア

で1,600万の顧客と70,000平方マイルのサー

ビスエリアを持つ

ISCS: 保険請求処理

Oracle と SQL Server を通常業務ならびにウェアハウスデータ用に使用

伝統的な商用データベースのコストが最も大きな支出となり、また維持管理に頭を悩ませていた

Auroraがもたらしたメリット： 「余裕を持たせた」Auroraのデプロイ構成のコストが、

ISCSのSQL Serverの構成よりも70%安価であることが分かった

Auroraの連続的なバックアップ機能により、バックアップ処理ウィンドウを廃止接続数が増えた際のリニアなスケールを実現Auroraのリードレプリカを利用したAmazon Redshiftへの連続的なアップロード

ポリシー管理、請求、ビリングソ

リューションを災害・損害保険企業向

けに提供

Alfresco: エンタープライズコンテンツ管理

Alfrescoのドキュメントリポジトリを数十億ドキュメント級までスケール

1秒未満のレスポンス時間を要求するユーザーアプリケーションへの対応

Auroraがもたらしたメリット：

10億ドキュメントに対し300万リクエスト/時までスケールし、現行環境の10倍の高速化を実現

巨大なデータセンターから、コスト効果に優れたAWSと Auroraへ移行

エンタープライズコンテンツ管理とビジネスプロ

セス管理の集約をリードする。金融サービス・ヘ

ルスケア・公共のリーダーを含む195カ国1,800

以上の組織がAlfrescoを利用。

Earth Networks: モノのインターネット

Earth Networksは25TB以上のリアルタイムでー

たを毎日処理しており、増え続ける分析のニーズとともに迅速に成長できるスケーラブルなデータベースを必要としていた

Auroraがもたらしたメリット： Auroraのパフォーマンスとスケーラビリティー（ス

ケールアップ／リードレプリカによるスケールアウト） が、日々増えるデータをうまく処理した

SQL ServerからAuroraへの移行は難しくなく、かつ大きなコスト節約につながった

独立した10,000以上の地域レベルのセンサーにより、 天候状況の正確なレ

ポート、地域の予測、いつ／どこでの災害警報を人々が最も必要とする時に提供

ThreatStack: 連続的なセキュリティ監視

脅威分析のために非常に大きく連続したデータストリームを扱う

およそ50万インサート(書込)/秒、1日の生データは約10TB

Auroraがもたらしたメリット：

Amazon Auroraを時系列データを扱うメインのデータベースとして採用し、ThreatStackが必要とするパフォーマンス要件を実現

AWS顧客に対し連続的なセキュリティ

監視を提供し、不正侵入やデータ損失、

内部の脅威から保護

.

高可用性のためのデザイン

ストレージノードの可用性

3つのAZにまたがり6つの複製を保持

データの読み書きにクオーラムを採用し、レイテンシーを

軽減

Peer-to-peer gossipレプリケーション

S3への継続的バックアップ (イレブンナインの可用性)

継続的なデータブロックの検査

継続的なノードやディスクの障害検知

クオーラムに参加するデータノードの変化の影響を受け

ない

AZ 1 AZ 2 AZ 3

Amazon S3

2つのストレージノード障害、あるいはAZ障害が起きても読み書きに影響がない

3つのストレージノード障害があっても読み込みは可能

自動的に障害を検出し、複製と修復を実行

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching

Read and write availability Read availability

障害に強く自己回復可能

トラディショナルなDB

最後のチェックポイントからのログを適用する必要がある

一般的にチェックポイントの間隔は5分

MySQLではシングルスレッドで行われる;

ディスクアクセスが多く発生する

Amazon Aurora

Disk readの一環として、オンデマンドでredo

logの適用を行う

並列、分散、非同期で行われる

起動時に実行する必要がない

Checkpointed data Redo log

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

T0 T0

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

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

高速なクラッシュリカバリ

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

AppRunningFailure Detection DNS Propagation

Recovery Recovery

DBFailure

MYSQL

App

Running

Failure Detection DNS Propagation

Recovery

DB

Failure

AURORA WITH MARIADB DRIVER

1 5 - 3 0 s e c

5 - 2 0 s e c

連続的なバックアップ

Segment snapshot Log records

Recovery point

Segment 1

Segment 2

Segment 3

Time

各セグメントのスナップショットを定期的かつ並列で取得し、REDOログをAmazon S3へ転送

バックアップは連続的に行われ、パフォーマンスや可用性への影響はない

リストア時は、該当するセグメントスナップショットとログストリームをストレージノードに復元

セグメントスナップショットへのログストリーム適用は並列・非同期に実行される

エンタープライズ級のパフォーマンス

• 4 client machines with 1,000 threads each

WRITE PERFORMANCE READ PERFORMANCE

• Single client with 1,000 threads

• MySQL SysBench

• R3.8XL with 32 cores and 244 GB RAM

SQLベンチマーク結果

テーブル数に応じたスケール

Tables

Amazon

Aurora

MySQL

I2.8XL

local SSD

MySQL

I2.8XL

RAM disk

RDS

MySQL

30K IOPS

(single AZ)

10 60,000 18,000 22,000 25,000

100 66,000 19,000 24,000 23,000

1,000 64,000 7,000 18,000 8,000

10,000 54,000 4,000 8,000 5,000

• Write-only workload

• 1,000 connections

• Query cache (default on for Amazon Aurora, off for MySQL)

11x

U P TO

FA S T E R

DBサイズに応じたスケール

67x

U P TO

FA S T E R

DB Size Amazon Aurora

RDS MySQL

30K IOPS (single AZ)

1GB 107,000 8,400

10GB 107,000 2,400

100GB 101,000 1,500

接続数に応じたスケール

• OLTP Workload

• Variable connection count

• 250 tables

• Query cache (default on for Amazon Aurora, off for MySQL)

Connections Amazon Aurora

RDS MySQL

30K IOPS (single AZ)

50 40,000 10,000

500 71,000 21,000

5,000 110,000 13,000

8x

U P TO

FA S T E R

I/Oを減らす

ネットワークパケットを最小限にする

結果をキャッシュしておく

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

DO LESS WORK

非同期で処理する

レイテンシーの通り道を減らす

ロックフリーなデータ構造を使う

バッチ操作を同時に行う

BE MORE EFFICIENT

これらの結果をどう達成したか？

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

ネットワーク接続したストレージは PACKETS/SECOND が全て

高スループットの処理に コンテキストスイッチ は許されない

RDS MySQLのI/Oトラフィック

BINLOG DATA DOUBLE-WRITELOG FRM FILES

T Y P E O F W R I T E

MYSQL WITH STANDBY

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

DRBD経由でスタンバイインスタンスへ書き込みを伝播

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

IO FLOW

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

それによりレイテンシーもパフォーマンスのゆらぎも増加

各ユーザー操作には様々な書き込みタイプがある

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

OBSERVATIONS

780K トランザクション

7,388K I/Os (ミラー, スタンバイを除く)

1トランザクション当たり平均9.5 I/Os

PERFORMANCE

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

PIOPS

EBS mirrorEBS mirror

AZ 1 AZ 2

Amazon S3

EBSAmazon Elastic

Block Store (EBS)

Primary

instance

Standby

instance

1

2

3

4

5

AuroraのI/Oトラフィック(データベース)

AZ 1 AZ 3

Primary

instance

Amazon S3

AZ 2

Replica

instance

AMAZON AURORA

ASYNC

4/6 QUORUM

DISTRIBUTED

WRITES

BINLOG DATA DOUBLE-WRITELOG 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

950K I/Os (includes 6X amplification) 7.7X LESS

1トランザクション当たり平均0.035 I/Os 270X LESS

PERFORMANCE

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

適切なセグメントに分割する –部分ごとに並ぶ

ストレージノードへまとめて書き込む

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

Kernel空間の epoll() がラッチフリーキューにコネクションをアサイン

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

r3.8xlインスタンスのAmazon Auroraで5,000コンカレントコネクション

を扱える

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

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

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

閾値を慎重に設定する必要がある

CLIE

NT

CO

NN

EC

TIO

N

CLIE

NT

CO

NN

EC

TIO

N

LATCH FREE

TASK QUEUE

ep

oll(

)

MYSQL THREAD MODEL AURORA THREAD MODEL

適応型スレッドプール

非同期グループコミット

Read

Write

Commit

Read

Read

T1

Commit (T1)

Commit (T2)

Commit (T3)

LSN 10

LSN 12

LSN 22

LSN 50

LSN 30

LSN 34

LSN 41

LSN 47

LSN 20

LSN 49

Commit (T4)

Commit (T5)

Commit (T6)

Commit (T7)

Commit (T8)

LSN GROWTHDurable LSN at head-node

COMMIT QUEUEPending 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が返ってきた時点で堅牢性のある書き込みが完了

先行するDB durableポイントは最新のペンディングACKのポイントまで

アドバンスト・モニタリング（近日登場）

Advanced monitoring

50+ system/OS metrics | sorted process list view | 1-60 sec granularity

alarms on specific metrics | egress to CloudWatch Logs | integration with 3rd-party tools

coming soon

ALARM

Important systems and OS metrics

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

AuroraとRDS MySQLのTCO比較

Cost of ownership: Aurora vs. MySQLMySQL configuration hourly cost

Primary

r3.8XL

Standby

r3.8XL

Replica

r3.8XLReplica

r3.8XL

Storage6 TB / 10 K PIOP

Storage6 TB / 10 K PIOP

Storage6 TB / 5 K PIOP

Storage6 TB / 5 K PIOP

$4.54/hr

$4.54/hr

$4.54/hr $4.54/hr

$2.91/hr

$2.08/hr $2.08/hr

Instance cost: $18.16 / hr

Storage cost: $ 9.98 / hr

Total cost: $28.14 / hr

$2.91/hr

Cost of ownership: Aurora vs. MySQLAurora configuration hourly cost

Instance cost: $16.80 / hr

Storage cost: $ 5.32 / hr

Total cost: $22.12 / hr

Primary

r3.8XL

Replica

r3.8XL

Replica

R3.8XL

Storage / 6 TB

$5.60 / hr $5.60 / hr $5.60 / hr

$5.32 / hr

21.4%

Savings

No idle standby instance

Single shared storage volume

No POIPs – pay for use I/O

Reduction in overall IOP

Cost of ownership: Aurora vs. MySQLFurther opportunity for saving

Instance cost: $8.40 / hr

Storage cost: $5.32 / hr

Total cost: $13.72/ hr

51.3%

Savings

Primary

r3.8XL

Replica

r3.8XLReplica

r3.8XL

Storage / 6TB

$2.80 / hr $2.80 / hr $2.80 / hr

$5.32 / hr

r3.4XL r3.4XL r3.4XL

Use smaller instance size

Pay-as-you-go storage

Thank you!

https://aws.amazon.com/rds/aurora