Amazon Aurora 最新アップデートと日本のお客様の移行事例
15 likes10,047 views
2016 年 2 月 16 日開催「事例とデモで知るAWSへのデータベース移行」での 「Amazon Aurora 最新アップデート」の資料です。
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などのメディア系 のお客様
- 4. 2015/7/28 GAリリース Virginia / Oregon / Ireland 2015/10/7 Tokyoリージョンリリース 2016/2/12 Sydneyリージョンリリース
- 6. リレーショナルデータベースをもう一度考える • 今、データベースを再度実装するならどうする か？ – 少なくとも1970年代の方法で実装はしない – AWSサービスを活かすことができ、スケールアウトが簡単で、 セルフヒーリングが出来るようなデータベースを作りたいと考 えた
- 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
- 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側のパッチの取り込み • 安定性の向上
- 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
- 24. 国外利用事例 • re:Invent 2015 Keynoteで発表
- 25. Amazon Auroraへの移行事例 • 既に日本でも多くのシステムがAmazon Aurora へ移行・検証が進んでいます – エンタープライズシステム・大規模webサービス・スタート アップ・ソーシャルゲーム
- 26. 毎日新聞社 様
- 27. • 12/6からAWSにフルマイ グレーション • コンテンツを格納してい るデータベースは全て Amazon Aurora • 当初RDS MySQLで検討し ていたが高速なフェイル オーバー、障害耐性面、 MySQLより低コストとい う理由でAmazon Aurora を採用 (本番移行2週間前 に決断・アプリケーショ ンの変更は一切なし)
- 29. 移行理由 • MySQLよりコスト減 – MySQLだと「インスタンス数×ストレージ料金(使わない分も先 買)」が、Auroraだと「1クラスタ1ストレージ料金(使っている 分だけ)」で良いので、大幅にコストが削減できた – その分、インスタンスの増強に利用） • 本番移行２週間前の変更だったが、開発したア プリケーションの変更は一切なし – ソースコード、設定ファイルなどの修正は全く行わなかった
- 30. Grani 様
- 32. Aurora 3x faster than MySQL (Total)
- 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も行っている – 様々なワークロードで安定して性能を発揮できる環境を重要視してい る