2016 年 2 月 16 日開催「事例とデモで知るAWSへのデータベース移行」での 「Amazon Aurora 最新アップデート」の資料です。

1. Amazon Aurora 最新アップデートと
日本のお客様の移行事例
Amazon Web Services Japan K.K.
Yutaka Hoshino

2. 自己紹介
• 星野 豊 (ほしの ゆたか)
– @con_mame
– facebook.com/conmame
– ソリューションアーキテクト
• 経歴
– ニコニコ動画インフラエンジニア
– Cookpadインフラエンジニア
• 担当
– Webサービス / game / Video・Live Streamingなどのメディア系
のお客様

3. Amazon Aurora

4. 2015/7/28 GAリリース
Virginia / Oregon / Ireland
2015/10/7 Tokyoリージョンリリース
2016/2/12 Sydneyリージョンリリース

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

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

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

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

9. Amazon Aurora
• ログとストレージレイヤを
シームレスにスケールするス
トレージサービスに移動
• EC2, Amazon DynamoDB,
Amazon SWFなどのAWS
サービスを管理コンポーネン
トに採用
• Amazon S3を利用して
99.999999999%の耐久性で
ストリーミングバックアップ
Logging + Storage
SQL
Transactions
Caching
Amazon S3
Amazon
DynamoDB
Amazon SWF
Amazon Route
53

10. 新機能

11. Enhanced monitoring
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

12. Enhanced monitoring
Process list
Metrics list

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

14. Enhanced monitoring
• CloudWatch logsにメトリクスを送信出来る
• CloudWatch logs->Lambda->Amazon
Elasticsearch Service連携も容易
– Kibanaを使って可視化も可能 (KibanaはAmazon
Elasticsearch Serviceにインストール済)
– アプリケーションやクエリの種類に応じたメトリクスも取得す
れば、アプリケーション・DBサーバメトリクス・クエリのパ
フォーマンスを一箇所で閲覧可能

15. Enhanced monitoring
• CloudWatch logsからElasticsearch Service

16. Encryption at rest
• Key Management Service(KMS)を利用し、透過的な
暗号化と復号を行う
– 暗号化指定はAuroraクラスタ起動時のみ
– ストレージ内やスナップショットが暗号化される
– 暗号化されたスナップショットを暗号化が無効なAuroraクラスタに復元は
出来ない
• ディスクに書き込まれるタイミングで自動的に実施
• テーブルの中身を暗号化するものでは無い点注意
– 実施する場合はアプリケーションなどで実施 (KMSを活用可能)

17. Performance improvement
• 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を走査した

18. Lab mode
• 今後提供予定の機能を試すことが出来る
– 現在はLogical Read Ahead機能を提供中
– DBパラメータグループ aurora_lab_mode 変数で設定可能
– 開発中の機能なので本番適用ではなく検証目的でお使い下さい
– フィードバックをお待ちしています！
• Logical Read Ahead
– Facebook MySQLにも同名の物が有りますがAmazon Aurora
用に独自実装されたものです

19. メンテナンス方針と最近の改善

20. Amazon Auroraが取り組んでいること
• パフォーマンスの向上
– 様々な環境下でAuroraの性能を発揮出来るように性能改善を各レ
イヤーで実施
– マイグレーション速度向上
• 可用性・堅牢性の向上
– 耐障害性の向上
– Bugの修正やMySQL側のパッチの取り込み
• 安定性の向上

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

22. Backport MySQL Bug fix
• Port Bug#16446108 SEGV IN FTSPARSE().
• Port Bug#19465984 INNODB DATA DICTIONARY IS NOT UPDATED WHILE RENAMING THE COLUMN.
• Port Bug#16834860 FTS CRASH AFTER RENAMING TABLE TO DIFFERENT DATABASE.
• Port Bug#18596756 - FAILED PREPARING OF TRIGGER ON TRUNCATED TABLES CAUSE ERROR 1054.
• Port Bug#18684393 - METADATA CHANGES MIGHT CAUSE PROBLEMS WITH TRIGGER EXECUTION.
• Port Bug#17566396: MATERIALIZATION IS NOT CHOSEN FOR LONG UTF8 VARCHAR FIELD.
• Port Bug#16697792: POOR EXECUTION PLAN WHEN ORDER BY WITH LIMIT X
• Port Bug#17083851 BACK
• Port Bug#11765744 TO 5.1, 5.5 AND 5.6
• Port Bug#20788853 MUTEX ISSUE IN SQL/SQL_SHOW.CC RESULTING IN SIG6. SOURCE LIKELY
FILL_VARIABLES
• Port Bug#18903155: BACK
• Port Bug-18008907 TO 5.5+ VERSIONS.
• Port Bug #17607956 Addressed incomplete fix in MySQL full text search affecting tables where the
database name begins with digit.
• Adapt fix for a stack overflow error in MySQL 5.7 for Bug#19678930
https://forums.aws.amazon.com/ann.jspa?annID=3455
https://forums.aws.amazon.com/ann.jspa?annID=3396

23. Amazon Aurora利用事例

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

25. Amazon Auroraへの移行事例
• 既に日本でも多くのシステムがAmazon Aurora
へ移行・検証が進んでいます
– エンタープライズシステム・大規模webサービス・スタート
アップ・ソーシャルゲーム

26. 毎日新聞社 様

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

28. アーキテクチャ
記事データなど全てAmazon Auroraに格納

29. 移行理由
• MySQLよりコスト減
– MySQLだと「インスタンス数×ストレージ料金(使わない分も先
買)」が、Auroraだと「1クラスタ1ストレージ料金(使っている
分だけ)」で良いので、大幅にコストが削減できた
– その分、インスタンスの増強に利用）
• 本番移行２週間前の変更だったが、開発したア
プリケーションの変更は一切なし
– ソースコード、設定ファイルなどの修正は全く行わなかった

30. Grani 様

32. Aurora 3x faster than MySQL (Total)

33. Query Average duration

34. Delete : 0.8x slower

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

36. dwango 様

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

39. LDR構成

40. パフォーマンス
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

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

42. まとめ

43. Amazon Aurora
• 業界問わずAmazon Auroraへの移行事例が増えて
きている
– AWSのサービスの中で最も高速に成長をしている
• 積極的に新機能の追加・性能の改善を行っている
• 安定性向上のためのBug fixも行っている
– 様々なワークロードで安定して性能を発揮できる環境を重要視してい
る