オンプレからAuroraへの移行とその効果

Copyright © 2017 CyberZ, Inc. All Rights Reserved. Please do not change and reprint without permission.
1
オンプレからAuroraへの移行とその効果
〜第２回Aurora事例祭り〜
2017/07/05
CyberZ 片岡雅人

2
名前
片岡雅人（かたおかまさと）
所属
株式会社CyberZ コアテクノロジー局
インフラエンジニア
好きなAWSサービス
・Aurora
・VPC
・Amazon Certificate Manager
・Amazon Inspector
自己紹介

3
F.O.XのDBをオンプレからAuroraへ移行とその効果のお話
・会社概要・サービス紹介
・ビジネス上の課題は何だったか
・なぜAuroraを採⽤したか
・オンプレからAurora移行時の課題をどう乗り越えたか
・導⼊後の効果
本日のアジェンダ

4
会社概要とサービス概要

5
株式会社CyberZ
・CyberAgentの100%子会社
主な事業
・スマートフォン広告代理業
・ゲーム動画配信プラットホーム：OPENREC.tv
・スマホアプリマーケティングツール：Force Operation X (F.O.X)
会社紹介

6 今日のお話の範囲
株式会社CyberZ
・CyberAgentの100%子会社
主な事業
・スマートフォン広告代理業
・ゲーム動画配信プラットホーム：OPENREC.tv
・スマホアプリマーケティングツール：Force Operation X (F.O.X)

7
スマホアプリの広告効果を計測する3rdパーティトラッキングツール
Force Operation X

8 サードパーティトラッキングツールとは？

9 サードパーティトラッキングツールとは？
24時間365日
連続可用性なシステム

10 システム構成図
F.O.Xシステム構成図（本日の話に合わせて抜粋したもの）

11
ビジネス上の課題

12
①DBへの書き込みが激しい
・書込が非常に多いので、オンプレDBではFusion-IO利用
②Fusion-IOを容量ギリギリまで利用
・サービスの特性上、書込量が上振れしやすく予測も困難
③システムコストが把握しにくい
・特に減価償却費
ビジネス上の課題

13
なぜAuroraを採⽤したか

14
①ディスク容量を気にする必要がないこと
②マネージドサービスなので運用コストが減ること
・専任者ではなく開発者による運用が可能
③レプリ遅延が発生しないこと
・書込が激しい時はFusion-IOへのレプリでも遅延が発生…
④MySQLとの互換性が高いこと
・元々Percona MySQLを使っていたため運用ノウハウがある＆アプリの改修は最低限にできる
・移設はレプリなどの枯れた技術が利用可能
なぜAuroraを採⽤したか？

15
オンプレからAurora移行時に発生した問題

16
バックアップとリストアに大量の時間がかかる
レプリケーション遅延が解消しない(その1)

17
その問題をどうやって乗り越えたか？

18

19 バックアップとリストアに大量の時間がかかる
マスタDBのサーバ数 4台
1サーバあたりのスキーマ数（データベース数） 400〜600
1スキーマのファイルサイズ数KB〜300GB
総テーブル数 2000〜3000テーブル
データベース領域の全体サイズ約1.8TB/1サーバ
データベース領域が約1.8TBと巨大
＆
スキーマ数と総テーブル数も多い

20
mysqldumpを利用したバックアップで対応
・安全性と確実性を重視
・バックアップに約1～2日… （--single-transaction利用。バックアップ中はDDLを停止してもらうよう調整)
・バックアップファイルをスキーマ毎に分割するのに約1日…
・リストアに約4日…

21
リストアの方法
・1プロセスで普通にリストアするとbinlog保持期間中に終わらない
→レプリケーション不可となってしまう
・4〜10スキーマを並行実施
・終了時間を合わせるため、スキーマサイズが同じくらいのものを並行で！

22
検証に時間がかけられなかったため、以下の利用は断念…
・xtrabackup + S3によるAuroraクラスタ復元
・AWS Database Migration Service (DMS)

23

・1.8TBのDBを数時間で移行することは不可能
・そのため、Aurora側にデータ同期している状態を
作ってから移行することとなった
【前提】レプリケーションをする背景

25 レプリケーション遅延が解消しない(その1)
・解消しないどころか、約20件/分で遅延が拡大
・一晩待っても拡大する一方（！）
・書き込みが多すぎるために発生した問題か？？
→Aurora移行断念が頭をよぎった
ところが…

26
RDS for MySQLにレプリさせると、差分が縮小した！
上記のRDS for MySQLからAuroraリードレプリカ作成
↓
現象が再現！Aurora独自の問題だった！
原因は何だったかというと…

27
バグでした！！
(しかもAurora 1.12だけの話)

28
これはAWSのサポートチームが突き止めてくれたものです
・移行する時は、ビジネス以上のサポート契約にした方が
よいと思いました。
AWSサポートチームには大変お世話になりました。ありがとうございます。

29
https://forums.aws.amazon.com/ann.jspa?annID=4630
・Improvements:
…
- Fixed the performance issue, introduced in Aurora version 1.12, where the performance of
the Aurora writer was reduced when users have a large number of tables.
(訳)
Auroraバージョン1.12における、大量のテーブルがある時にwriterのパフォーマンスが
低下する問題を修正した。
“Announce: New Aurora Release 1.13 Now Available” にあるこの記載
■対応
・Aurora 1.13 にバージョンアップ
・問題解消【解決】

30
レプリケーション遅延が解消しない (その1)
レプリケーション遅延が解消しない (その2)

31 レプリケーション遅延が解消しない(その2)
・本番として利用するには多少時間があった(レプリさせるだけよい状態)
・費用節約のため、データ更新量の少ないDBは db.t2.medium を利用
（更新量が多いDBはdb.r3.largeを利用)
→データ更新量の少ないDBでレプリ遅延が解消しない

■調査して分かったこと
・別DBでは現象が起きていない
・DML Throughtput の値が頭打ちとなっている
・これらから、インスタンスサイズの問題の可能性が高そう
■対応
・インスタンスをdb.t2.medium→db.r3.largeに変更
・遅延が解消するようになった【解決】
32

33
変更前後のDML Throughtputの比較 (11:00頃にdb.r3.largeに変更)

34
導⼊後の効果

35
・ディスク容量を意識する必要がなくなった
・レプリ遅延がほとんどなくなった
・開発者自身による運用が可能となった
・コストを意識するようになった
苦労も少なくなかったが、それに見合う十分なメリットがあった
導⼊後の効果

36
Change the technology , Make the rule.

オンプレからAuroraへの移行とその効果

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie オンプレからAuroraへの移行とその効果

Ähnlich wie オンプレからAuroraへの移行とその効果 (20)

オンプレからAuroraへの移行とその効果