2015/11/10に開催したAurora東京ローンチ記念セミナーの資料です。

1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Debanjan Saha, GM, Amazon Aurora
Jun Okubo, Business Development Manager
November 2015
Using Amazon Aurora
for Enterprise Workloads
Amazon Aurora
東京ローンチ記念セミナー

2. エンタープライズ顧客の要望リスト
…. が出来るデータベース
コンポーネント障害が発生しても動き続ける ….
エンタープライズ規模で安定した性能を発揮する …
専門家部隊がいなくても運用・管理できる …
大金をはたかずともよい; ライセンスを管理しなくてよい …

3. Amazon Aurora: クラウド向けのエンタープライズ級データベース
私たちはエンタープライズ向けの要件から入り、クラウド向けの
リレーショナルデータベースとはどうあるべきか、を再考しました
….
 エンタープライズ級の可用性とパフォーマンス
 完全なマネージドサービスとして提供
 ライセンス不要; 商用データベースの1/10のコスト

4. MySQL互換のリレーショナルデータベース
商用データベース並みの
パフォーマンス と 可用性
オープンソースデータベース並みの
使いやすさ と コスト効果
マネージドサービスとして提供
Amazon Aurora とは?

5. Aurora at a glance
AZ 1 AZ 2 AZ 3
Amazon S3
Master
Read
Replica
Read
Replica
Read
Replica
Read
Replica
Massively scale-out storage
distributed across 3 AZs

6. エンタープライズに最適
 3箇所のデータセンターに6つの複製を保持
 30秒以内でフェイルオーバー
 ほぼ即時に行われるクラッシュリカバリー
 最大50万回/秒の読込、10万回/秒の書込性能
 15個までの低遅延(10 ms)リードレプリカ
 64TBまで拡張できる、DBに最適化したストレージ
 すぐに行えるプロビジョニングとデプロイ
 自動化されたパッチとソフトウェアアップグレード
 バックアップとポイント・イン・タイム・リカバリー
 コンピュートとストレージのスケーラビリティー
パフォーマンスとスケール
エンタープライズ級の可用性
完全マネージドサービス

7. Amazon Auroraを活用中の顧客事例

8. AWSの歴史上
最も速く成長しているサービス
Aurora 採用顧客事例

9. Expedia: オンライン旅行販売
 成長を続けるオンライン旅行販売データに対するリア
ルタイムなビジネス・インテリジェンスと分析
 現行の SQL Server ベースのアーキテクチャは非常
に高価であった。また、データボリュームの増加と共
にパフォーマンスの低下が見られた。
 Cassandra と Solr を組み合わせたインデックスは
大きなメモリー空間を必要とし、コストを押し上げた
Auroraがもたらしたメリット：
 Aurora はスケーラビリティーとパフォーマンス要件
を満たし、コストもずっと低かった
 平常時25,000インサート/秒 （ピーク時70,000）
平均レスポンスタイムは書込30ミリ秒、読込17ミリ秒
世界をリードするオンライン旅行業者、
70カ国で150以上の旅行関連サイト
を運営

10. PG&E: 大手公益企業
 電力関係のイベントが起きた際に突発的なトラフィック
を処理することに常に課題を抱えていた
 データベースが落ちた時の影響が甚大; 結果的に顧
客に対するガスと電力の供給へ影響が出る
Auroraがもたらしたメリット：
 遅延のほとんどない（ミリ秒級）リードレプリカを複数持
つことが出来るため、電力関係のイベントが起きた際
でも突発的なトラフィックを処理し、顧客に最新の情報
をタイムリーに提供できるようになった
 6ヶ所にデータを複製し、ストレージやインスタンス障害
時に自動復旧するAmazon Auroraにより、ミッション
クリティカルなアプリケーションが要求する可用性と信
頼性がもたらされた
天然ガス＋電力の公益企業において米国最
大手の1社で、北部および中央カリフォルニア
で1,600万の顧客と70,000平方マイルのサー
ビスエリアを持つ

11. ISCS: 保険請求処理
 Oracle と SQL Server を通常業務ならびにウェアハウ
スデータ用に使用
 伝統的な商用データベースのコストが最も大きな支出
となり、また維持管理に頭を悩ませていた
Auroraがもたらしたメリット：
 「余裕を持たせた」Auroraのデプロイ構成のコストが、
ISCSのSQL Serverの構成よりも70%安価であること
が分かった
 Auroraの連続的なバックアップ機能により、バックアッ
プ処理ウィンドウを廃止
接続数が増えた際のリニアなスケールを実現
Auroraのリードレプリカを利用したAmazon Redshiftへ
の連続的なアップロード
ポリシー管理、請求、ビリングソ
リューションを災害・損害保険企業向
けに提供

12. Alfresco: エンタープライズコンテンツ管理
 Alfrescoのドキュメントリポジトリを数十億ドキュメン
ト級までスケール
 1秒未満のレスポンス時間を要求するユーザーアプ
リケーションへの対応
Auroraがもたらしたメリット：
 10億ドキュメントに対し300万リクエスト/時までス
ケールし、現行環境の10倍の高速化を実現
 巨大なデータセンターから、コスト効果に優れた
AWSと Auroraへ移行
エンタープライズコンテンツ管理とビジネスプロ
セス管理の集約をリードする。金融サービス・ヘ
ルスケア・公共のリーダーを含む195カ国1,800
以上の組織がAlfrescoを利用。

13. Earth Networks: モノのインターネット
 Earth Networksは25TB以上のリアルタイムでー
たを毎日処理しており、増え続ける分析のニーズ
とともに迅速に成長できるスケーラブルなデータ
ベースを必要としていた
Auroraがもたらしたメリット：
 Auroraのパフォーマンスとスケーラビリティー（ス
ケールアップ／リードレプリカによるスケールアウ
ト） が、日々増えるデータをうまく処理した
 SQL ServerからAuroraへの移行は難しくなく、か
つ大きなコスト節約につながった
独立した10,000以上の地域レベルのセ
ンサーにより、 天候状況の正確なレ
ポート、地域の予測、いつ／どこでの災
害警報を人々が最も必要とする時に提
供

14. ThreatStack: 連続的なセキュリティ監視
 脅威分析のために非常に大きく連続したデー
タストリームを扱う
 およそ50万インサート(書込)/秒、1日の生デー
タは約10TB
Auroraがもたらしたメリット：
 Amazon Auroraを時系列データを扱うメインの
データベースとして採用し、ThreatStackが必
要とするパフォーマンス要件を実現
AWS顧客に対し連続的なセキュリティ
監視を提供し、不正侵入やデータ損失、
内部の脅威から保護
.

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

16. ストレージノードの可用性
3つのAZにまたがり6つの複製を保持
データの読み書きにクオーラムを採用し、レイテンシーを
軽減
Peer-to-peer gossipレプリケーション
S3への継続的バックアップ (イレブンナインの可用性)
継続的なデータブロックの検査
継続的なノードやディスクの障害検知
クオーラムに参加するデータノードの変化の影響を受け
ない
AZ 1 AZ 2 AZ 3
Amazon S3

17. 2つのストレージノード障害、あるいはAZ障害が起きても読み書きに影響がない
3つのストレージノード障害があっても読み込みは可能
自動的に障害を検出し、複製と修復を実行
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Read and write availabilityRead availability
障害に強く自己回復可能

18. トラディショナルなDB
最後のチェックポイントからのログを適用する
必要がある
一般的にチェックポイントの間隔は5分
MySQLではシングルスレッドで行われる;
ディスクアクセスが多く発生する
Amazon Aurora
Disk readの一環として、オンデマンドでredo
logの適用を行う
並列、分散、非同期で行われる
起動時に実行する必要がない
Checkpointed data Redo log
T0 でクラッシュが発生する
と最後のチェックポイントか
らのログを適用する必要が
ある
T0 T0
T0 でクラッシュが発生するとredo
を並列で分散して非同期でログの適用を行う
高速なクラッシュリカバリ

19. 高速で予測可能なフェイルオーバー時間
App
RunningFailure Detection DNS Propagation
Recovery Recovery
DB
Failure
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

20. 連続的なバックアップ
Segment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
各セグメントのスナップショットを定期的かつ並列で取得し、REDOログをAmazon S3へ転送
バックアップは連続的に行われ、パフォーマンスや可用性への影響はない
リストア時は、該当するセグメントスナップショットとログストリームをストレージノードに復元
セグメントスナップショットへのログストリーム適用は並列・非同期に実行される

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

22. • 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ベンチマーク結果

23. テーブル数に応じたスケール
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 STER

24. DBサイズに応じたスケール
67x
U P TO
FA STER
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

25. 接続数に応じたスケール
• 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 STER

26. I/Oを減らす
ネットワークパケットを最小限にする
結果をキャッシュしておく
データベースエンジンをオフロードする
DO LESS WORK
非同期で処理する
レイテンシーの通り道を減らす
ロックフリーなデータ構造を使う
バッチ操作を同時に行う
BE MORE EFFICIENT
これらの結果をどう達成したか？
データベースは I/O が全て
ネットワーク接続したストレージは PACKETS/SECOND が全て
高スループットの処理に コンテキストスイッチ は許されない

27. RDS MySQLのI/Oトラフィック
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W R IT 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
EBS
Amazon Elastic
Block Store (EBS)
Primary
instance
Standby
instance
1
2
3
4
5

28. 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 IT 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順に並ぶ
適切なセグメントに分割する – 部分ごとに並ぶ
ストレージノードへまとめて書き込む

29. アクティブなスレッドに複数のコネクションを収容
Kernel空間の epoll() がラッチフリーキューにコネクションをアサイン
スレッドプールの数は動的に調整される
r3.8xlインスタンスのAmazon Auroraで5,000コンカレントコネクション
を扱える
Standard MySQL – コネクション毎に1
コネクション数に応じてスケールしない
MySQL EE – スレッドプール毎にコネクションをアサイン
閾値を慎重に設定する必要がある
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL
適応型スレッドプール

30. 非同期グループコミット
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 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が返ってきた時点で堅牢性のある書き込み
が完了
先行するDB durableポイントは最新のペンディングACKのポイントまで

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

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

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

34. AuroraとRDS MySQLのTCO比較

35. Cost of ownership: Aurora vs. MySQL
MySQL configuration hourly cost
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
$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

36. Cost of ownership: Aurora vs. MySQL
Aurora 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

37. Cost of ownership: Aurora vs. MySQL
Further 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.8XL
Replica
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

38. Thank you!
https://aws.amazon.com/rds/aurora