2015/12/18 Amazon RDS for Aurora セミナー in 関西の講演資料です

1. ⽇日本のお客様におけるAmazon Aurora
への移⾏行行・検証事例例と技術ポイント
Amazon Web Services Japan K.K.
Yutaka Hoshino

2. Amazon Aurora

4. 2015/7/28 GAリリース
Virginia / Oregon / Ireland

5. 2015/10/7 Tokyoリージョンリリース !

7. Amazon Auroraローンチイベント @東京

8. リレーショナルデータベースをもう⼀一度度考える
• 今、データベースを再度度実装するならどうする
か？
– 少なくとも1970年年代の⽅方法で実装はしない
– AWSサービスを活かすことができ、スケールアウトが簡単で、
セルフヒーリングが出来るようなデータベースを作りたいと考
えた

9. Amazon Auroraの特徴
クエリ性能の向上
コストパフォーマンスが良良い ⾼高可⽤用性・⾼高耐久性セキュリティにも配慮
MySQL5.6互換スケーラブル

10. Amazon Auroraの特徴
• MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行可能
• ストレージが10GBから64TBまでシームレスに拡張
• 3AZに2つずつ、計6つのデータのコピーを保持
– S3にストリーミングバックアップを実施
• VPC内に起動
– Security GroupやNACLを使⽤用してアクセスコントロール可能
• Amazon Auroraは99.99%の可⽤用性を実現するように設計されている
http://bit.ly/1LXB7Jq

11. クラウド時代に適したリレーショナルデータベース
• ハイエンドデータベースの様なスピード と 可⽤用性
• オープンソースデータベースのシンプルさとコスト効果の⾼高さ
• MySQLと互換性を保つ
• 利利⽤用した分だけお⽀支払いいただく課⾦金金モデル
• AWSサービスと簡単に連携
マネージド・サービスとしてご提供

12. Establishing our ecosystem
“Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB
connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise の
MariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性
の⼼心配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを
加速させるために⼀一緒に働くことを楽しみにしています。”
̶— Roger Levy, VP Products, MariaDB

13. キャッシュレイヤの分離離
• キャッシュをデータベースプロセス外に
移動させた
• データベースプロセスのリスタート
が発⽣生してもキャッシュが残った状
態を維持可能
• サービスにすぐデータベースを戻す
ことが出来る
• ⾼高速なクラッシュリカバリ +
survivable cache = DB障害から⾼高
速に復復帰可能
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
キャッシュプロセスをDBプロセス外におくことで
DBプロセスの再起動でもキャッシュが残る

14. Auroraのストレージの特徴
• リードレプリカもマスタと同じストレージを参照
• Log Structured Storage
• 継続的なS3へ増分バックアップ
– パフォーマンスへの影響なし
• 64TBまで⾃自動でストレージがシームレスにスケールアップ
– パフォーマンスや可⽤用性に影響無し・利利⽤用開始時のプロビジョニング不不要
• ⾃自動で再ストライピング、ミラー修復復、ホットスポット管理理、
暗号化

15. Auroraのストレージ
• SSDを利利⽤用したシームレスにスケールするスト
レージ
– 10GBから64TBまでシームレスに⾃自動でスケールアップ
– 実際に使った分だけ課⾦金金
– Peer-‐‑‒to-‐‑‒peer gossipレプリケーション
• 標準でHighly availableを実現
– 3AZに6つのデータのコピーを作成
– 2つのディスクが利利⽤用不不能でも読み書き可能
• 万が⼀一1つのAZが利利⽤用不不能になっても3本で読み書き可
能な状態で稼働
– 3つのディスクが利利⽤用不不能の場合読み込みのみ可能
• Log structured Storage
– redo logを複数の⼩小さなセグメントに分割
– Log pageによってData pageを作成
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3

16. ディスク障害検知と修復復
• 2つのコピーに障害が起こっても、読み書きに影響は無い
• 3つのコピーに障害が発⽣生しても読み込みは可能
• ⾃自動検知、修復復
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transactio
n
AZ 1 AZ 2 AZ 3
Caching
読み書き可能読み込み可能

17. レプリケーション
AZ 1 AZ 2
Primary
Instance
Standby
Instance
EBS
Amazon S3
EBS
mirror
EBS
EBS
mirror
MySQL レプリケーション
PITR
シーケンシャ
ル・ライト シーケンシャ
ル・ライト
AZ 1 AZ 3
Primary
Instance
Amazon S3
AZ 2
Replica
Instance
改善点
• Consistency – 異異常を修復復
• Latency – 同期 vs ⾮非同期レプリケーション
• network I/Oを効率率率的に⾏行行う
⾮非同期 4/6クオーラム 分散書き込み
Amazon Aurora
ログレコード
Binlog
データ
Double-‐‑‒write buffer
metadata
書き込みの種類

18. レプリケーション
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

19. 高速なデータ修復
既存のデータベース
• 最後のチェックポイントからログを
適用していく
• MySQLではシングルスレッドなため
適用完了までの時間が増加
Amazon Aurora
• Disk readの⼀一環として、オンデ
マンドでredo logの適⽤用を⾏行行う
• 並列列、分散、⾮非同期で⾏行行われる
Checkpointed Data Redo Log
T0 でクラッシュが発⽣生すると
最後のチェックポイントからの
ログを適⽤用する必要がある
T0 T0
T0 でクラッシュが発⽣生するとredo
を並列列で分散して⾮非同期でログの適⽤用を⾏行行う

20. Streaming snapshotとPITR
• Amazon Auroraでは各セグメント毎にAmazon S3
へ継続的に増分バックアップを取得している
– Backup retention periodでバックアップを残す期間を指定可能
• Amazon Auroraが使⽤用しているディスクの仕組み
によりパフォーマンスへ影響を与えない
• PITRで5分前からBackup Retention Periodまでの
任意の位置に秒単位で復復元可能

21. クラスタエンドポイント
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

22. 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 ];
• 他にも
– ディスク障害をシミュレート
– ディスクコンジェスションをシミュレート

23. 過去数ヶ⽉月で改善したこと
書き込みバッチサイズのチューニング
read/write I/O要求送信の⾮非同期化
パージスレッドのパフォーマンス
バルクインサートのパフォーマンス
バッチ操作
フェイルオーバー時間の短縮
mallocの削減
システムコールの削減
Undoスロットのキャッシュパターン
協調したログ適⽤用
その他
binlogと分散トランザクション
ロックの圧縮
先読み(read-‐‑‒ahead)
顧客フィードバック
ホットな⾏行行競合
ディクショナリ統計
⼩小さなトランザクションのコードパス
クエリーキャッシュのread/write競合
ディクショナリシステムのmutex
ロック競合

24. Amazon Aurora利利⽤用事例例

25. 国外利利⽤用事例例
• re:Invent 2015 Keynoteで発表

26. Amazon Auroraへの移⾏行行事例例
• 既に⽇日本でも多くのシステムがAmazon Aurora
へ移⾏行行・検証が進んでいます
– エンタープライズシステム・⼤大規模webサービス・スタート
アップ・ソーシャルゲーム
• Grani様 / dwango様 / 毎⽇日新聞様の事例例を今
回お話します

28. Grani様 移⾏行行事例例
http://bit.ly/1Qaq6e9

29. Environment
Before
RDS for MySQL
MultiAZ + Read Replica
r3.4xlarge
After
Amazon Aurora
2 node (1 writer / 1 reader)
r3.4xlarge

30. Measure Response Time
New Relic
Application, Database, Redis, External の監視、通知
> データベース処理の所要時間が一目瞭然
BigQuery
アプリケーションが発行したクエリを全て計測
> 同一クエリのAurora による変化を調査可能

31. Before : RDS for MySQL
Total Database Response : 15 ～ 22 ms (時間帯によって前後)

32. After : Amazon Aurora
Total Database Response : 5.5 ms

33. Aurora 3x faster than MySQL (Total)

34. Query Average duration

35. Select : 1x about same

36. Update : 5x+ faster

37. Insert : 2x+ faster

38. Delete : 0.8x slower

39. Amazon Auroraの性能改善: MultiAZ
RDS for MySQL w/ MultiAZ 同期待ち遅延の解消
MultiAZ のスタンバイ側とAZ間の同期待ち時間がAuroraで改善

40. Amazon Auroraの性能改善: Commit
⾮非同期グループコミットの採⽤用
コミットキューを⾮非同期に書き込み
4 / 6 のストレージノードACK応答で成功判定

41. Amazon Auroraの性能改善: その他
スレッドプールの改善、ロックハンドリングの改善
多くの要素が改善されて、特にUPDATE / INSERT に⼤大きく寄与している

42. Amazon Auroraへの移⾏行行
• Amazon Aurora DB クラスターへのデータの
移⾏行行
– http://docs.aws.amazon.com/ja_̲jp/AmazonRDS/latest/U
serGuide/Aurora.Migrate.html
• Amazon Aurora とのレプリケーション
– http://docs.aws.amazon.com/ja_̲jp/AmazonRDS/latest/U
serGuide/Aurora.Replication.html

43. Amazon Auroraによるコスト削減効果
性能向上によるDB 統合でノード削減も期待できる
Grani様の場合、DB統合も⾏行行い 年年間 2,200万円超 のコスト削減効果
RDS (db.r3.4xlarge / gp2 /
OnDemand)
Hourly Daily Yearly
RDS for MySQL(MultiAZ + 1
ReadReplica)
$4.54 + $2.27 =
$6.81
$163.44 $59,655.60
Aurora (+ 1 Replica) $2.8 * 2 = $5.6 $134.40 $49,056.00
削減効果 ▲$1.21 ▲$29.04 ▲$10599.6

45. 適⽤用プロジェクト
• LDR
– 国産RSSリーダー(Livedoor開発→Lineへ移⾏行行→Dwangoに譲受)
– 3社に渡り約9年年間続いたサービス
• その時々での負荷軽減策が実装されている
• アプリケーションレイヤーで⽔水平分割を実装など
• コードベースは古く、特定DC内で動くことを前提としたコードなど
» プロセスに対応するソースコードが既に削除されていたり
» アクセス先IPのサーバーが既に存在しなかったり
• ⻑⾧長い歴史があるだけに、⼤大量量の記事情報がMySQL
上に存在

46. LDR構成

47. 適⽤用プロジェクト
• LDR
– 国産RSSリーダー(Livedoor開発→Lineへ移⾏行行→Dwangoに譲受)
– 3社に渡り約9年年間続いたサービス
• その時々での負荷軽減策が実装されている
• アプリケーションレイヤーで⽔水平分割を実装など
• コードベースは古く、特定DC内で動くことを前提としたコードなど
» プロセスに対応するソースコードが既に削除されていたり
» アクセス先IPのサーバーが既に存在しなかったり
• ⻑⾧長い歴史があるだけに、⼤大量量の記事情報がMySQL上に存在
その数 15台 約10TB

48. Aurora導⼊入検討での観点
• MySQLとの互換性
• ディスク使⽤用特性
• パフォーマンス

49. MySQLとの互換性
• 古いコードベースということもあり、移⾏行行する際に安⼼心感が
あるということは強いメリット
– 実環境のデータとコードで検証し正常動作が確認できた
• 運⽤用上必要な設定値がそのまま流流⽤用できる
– RDSコンソール上のParameter Groupに設定という形
– max_̲connections、wait_̲timeoutなど
• 馴染んだ⼿手順でのデータ移⾏行行
– mysqldumpとreplicationでデータ同期できる
– ダウンタイムを最⼩小限にする移⾏行行⽅方法が確⽴立立されている
– https://docs.aws.amazon.com/ja_̲jp/AmazonRDS/latest/UserGuide/Aur
ora.Replication.html

50. ディスク使⽤用特性
• ディスク使⽤用効率率率や運⽤用⾯面で現時点ではマイナスポ
イントもある
– レコード削除しても⼀一旦増えた使⽤用領領域はシュリンクされない
– Compressed row formatをサポートしていない
• ⼀一⽅方で空き領領域の再利利⽤用は効率率率よく⾏行行われている
• 各スキーマの“DATA_̲FREE / (DATA_̲LENGTH + INDEX_̲LENGTH)”
の平均値をとったものを⽐比較

51. パフォーマンス
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
DB on
Instance
• 5系統の記事DBをアプリケー
ションレイヤーで⽔水平分割
• Auroraは「最⼤大 5 倍のス
ループットを提供」とのこと
• １系統のAuroraに集約して
もいけるはず！
Aurora

52. パフォーマンス
• 最⼤大並列列数時でも実環境でのピーク時クエリを⼗十分捌くこと
ができるパフォーマンスが確認できた
• また数TBのデータセットにてクローリングした情報を追加し
ながらの数週間の検証でも⽬目⽴立立ったパフォーマンス劣劣化⾒見見ら
れない
– RDS MySQLでは6TBがEBSの限界、EC2ではLVM等がTBオーダーのディスク
構築に必要
– 最⼤大64TBまでシームレスにサポートされる点の安⼼心感
• 空き容量量確保バッチ実⾏行行時 CloudWatch上でCPU利利⽤用率率率が
100%に張り付く現象がみられた
– サービス側クエリ応答時間では⼤大きな影響は⾒見見られない

53. 最新の移⾏行行事例例
毎⽇日新聞社 様

54. • 12/6からAWSにフルマイ
グレーション
• コンテンツを格納してい
るデータベースは全て
Amazon Aurora
• 当初RDS MySQLで検討し
ていたが⾼高速なフェイル
オーバー、障害耐性⾯面、
MySQLより低コストとい
う理理由でAmazon Aurora
を採⽤用 (本番移⾏行行2週間前
に決断・アプリケーショ
ンの変更更は⼀一切切なし)

55. まとめ

56. Amazon Aurora
• クラウド時代にAmazonが再設計したRDBMS
– MySQL5.6と互換があり既存の資産を活かしやすい
• 高いクエリ実行並列度・データサイズが大きい環境で性能を
発揮
– Amazon Auroraはコネクション数やテーブル数が多い環境で優位性を発揮
• 高可用性・高速なフェイルオーバ・PITRを実現するための多
くのチャレンジ
– Log StructuredStorage
– SOA

57. Amazon Aurora
• MySQL5.6と互換により過去資産を活かせる
– データの移行が容易
– レプリケーションによりサービス停止時間を最小限に移行可能
• データベースサーバを集約することで管理コストを軽減
– アプリケーションやミドルウェアの設定を簡易化
– アプリケーションコードに注力できる
• データの堅牢性や高速なリカバリにより障害時の復帰
時間を高速化出来、データロストの可能性も軽減可能