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 様

31. Aurora 3x faster than MySQL (Total)

32. Query Average duration

33. Delete : 0.8x slower

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

35. dwango 様

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

37. LDR構成

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

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

40. まとめ

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