2016/10/22 JAWS Festa 東海道 2016でMySQLからAuroraに移行をした話をしました。DMSいいよ。

1. Road to Aurora
-JAWS Festa 東海道 2016-

2. ⾃⼰紹介
間瀬 哲也（ませ てつや）
愛知県出⾝（でも名古屋ではない）
Sansan株式会社でEightのインフラを担当
Twitter: @matetsu
Facebook: tetsuya.mase
Eight: https://8card.net/p/matetsu

3. 個⼈的な活動
• JAWS-UG 京王線いいだしっぺ
• Amazon Web Services 実践⼊⾨ 共著
• ４章(Route 53)と６章(S3/CloudFront)担当
• 初⼼者⽀部での発表資料
http://goo.gl/NE79sP

4. Sansan株式会社
ビジネスの出会いを資産に変え、
働き⽅を⾰新する
法⼈向け 個⼈向け
オペレーション（名刺のデータ化）
バックオフィス

5. 神⼭ラボ(サテライトオフィス)

6. Sansanエンジニア分布図
C#.NET
Ruby
R&D
InfraiOS Android
Data Scientist

7. エンジニア補助制度
書籍購⼊
年間 6万円/⼈
環境整備補助
年間3万円/⼈
ソフトウェア
購⼊補助
年間2万円/⼈
端末購⼊補助
年間5万円/⼈
※iOS/Androidエンジニア限定
勉強会参加補助
3,000円/回
※⽉に2回まで
有料カンファレンス
参加補助
半額会社負担
※要報告
(業務要請は全額会社負担)

8. [AD]名刺交換は で
「オンライン名刺交換」で紙いらず

9. 本⽇のハッシュタグ
#jawsfesta
#jawsfesta_5223
FinTechでもIoTでもありませんm(_ _)m

10. Aurora導⼊のために

11. アジェンダ
• Aurora導⼊の⽬的
• 導⼊前後の構成
• 全⽂検索のリプレイス
• MySQLからAuroraへ
• まとめ

12. Aurora導⼊の⽬的
パフォーマンスUP 運⽤コストDOWN
脱Spiderストレージエンジン
脱シャーディング
Log Structured
Storage
ストレージの拡張
Readerノード

13. Aurora導⼊前の構成
MySQL
(RDS)
MySQL
(RDS)
MySQL
(RDS)
MySQL+Mroonga
(EC2)
MySQL+Spider
app
・・・
appappapp

14. 最終⽬標
Aurora
(RDS)
Amazon
Elasticsearch Service
app
・・・
appappapp

15. なぜ脱Spiderなのか
MySQL
(RDS)
MySQL
(RDS)
MySQL
(RDS)
MySQL+Mroonga
(EC2)
Spider経由で論理的に1つ
のDBとして扱える
Spider→Dataノードで発
⾏されるクエリの差異・
コスト
SpiderのXAトランザク
ション管理テーブルの更
新コスト
ソフトウェアでのシャー
ディング不要
Spiderノードクラッシュ
時の復旧コスト

16. 全⽂検索のリプレイス
1st Mission

17. 全⽂検索＠
• Web版の検索機能
• MySQL＋Mroonga on EC2
• SpiderによるSharding
• Scale upで1ノード構成
• （苦⼿な検索もあるが）⾮常に⾼速で優秀
• (今だから⾔える)冗⻑化してなかった

18. 全ては「脱Spider」の名の下に
だが、こんなに優秀な彼を
どうリプレイスをするのか？
※決してSpiderが悪いわけではなく、我々の運⽤能⼒のなさが問題だっただけです。

19. ボツ案たち
全⽂検索といえば、
だが、即時検索したい
場合に不向き
なくはないけど、シンプ
ルではない&CloudSearch
部分の反映がネック
InnoDB FTSを使えば
シンプルな構成にはな
るが、⽇本語の扱いに
難あり

20. 採⽤
ではあるが、、、

21. どのように運⽤する？
AWSのマネージドサービス
将来的にはVPC Endpointを期待
バージョンが1.5と低い（当時）
ログが⾒られない
Elastic社のマネージドサービス
Elasticのサポート
バージョンは柔軟に
（サポート込みなので）少々お⾼い
EC2で⾃前クラスタ運⽤
⽬に⾒える⾦額は安い
クラスタ運⽤つらい
⾃由
Amazon
Elasticsearch Service

22. 我々は将来性に賭けた
Amazon Elasticsearch Service
(Amazon ES)採⽤
(本当はElastic Cloud使いたかった）

23. データ移⾏の苦難 その1
(使い慣れた)Embulkが使えない！
Transport Clientに対
応していない
公式ドキュメントに
はLogstashの⽂字
専⽤のOutput
プラグインがある！
Logstash推しなんで
すね、分かりました

24. データ移⾏の苦難 その2
本番相当のデータ移⾏でESが固まる
1user-1index
という無謀
ドメインの削除も
ままならない
index設計の⾒直し
(Elasticの⽅の助⾔)
適切なサイズのindex
設計で解決

25. ⼀⽅、開発チームは
RDBのトランザクションが使えないから
データの不整合起きないか？
RDBのコミット後に
コールバックで処理
エラーになったら
バッチ処理にまわす
といった実装に明け暮れていた

26. データ移⾏
Mroonga
Importer
データエクスポート
データインポート
ユーザID
ごとの
CSV
ユーザID
ごとの
CSV
ユーザID
ごとの
CSV
ユーザID
ごとの
CSV
データの加⼯やら
整形やら
Importer Amazon ES
ある時点のsnapshot
差分
データ
追従
バッチ

27. Importer稼働体制
c4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlarge
c4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlarge
c4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlarge
c4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlarge
c4.8xlarge
↓
m4.10xlarge
c4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlargec4.8xlarge

28. リリース計画
部署内の⼀部の⼈のみリリース
負荷状況チェック
徐々に対象ユーザ追加
全ユーザリリース

29. の、はずでした

30. リリース計画
部署内の⼀部の⼈のみリリース
負荷状況チェック
徐々に対象ユーザ追加
全ユーザリリース

31. 切り戻し

32. 対策
Search APIのコスト⼤きい
「_id」に検索でも使えるIDの組み合わせを
⼊れていたので、それをGet APIで取得
それでも下がらない負荷には
札束で殴る
(意訳：スケールアウト)

33. 結果
たまにCPU使⽤率が100%に
張り付いてしまうこともありましたが
元気に稼働していました。
今では
2.3系にバージョンアップ
CPU使⽤率は、、、

34. 要望
1. ログの閲覧
※CategoryがAnalyticsなサービスだということは重々承知しております
2. Reserved Instance
3. VPC Endpoint

35. MySQLからAuroraへ
Final Mission

36. RDS@
• 全⽂検索、フィード、トークを除く
データ
• データ量の増加とともにノード数、
シャード数を拡⼤
• Spiderの発⾏するクエリによりRead
Replicaが使えないという苦⾏

37. MySQL時代のDB構成
基本データ
など
名刺データ
など
データ化情報
など
RDS for MySQL Multi-AZ 3台
データ量の多いテーブルは主にユーザのIDで⽔平分割

38. 分割されたDBを⼀つに
⼈類が⼿に⼊れたSpiderによるShardingと
RDSのPIOPSという⿇薬から今解き放たれよう
RDS補完計画
※特にこれといった意味はないです。ネタもこれだけです。

39. 移⾏案 その1
MySQL5.6 MySQL5.6 MySQL5.6
MySQL5.7
on EC2
Aurora
マルチソースレプリケーション

40. だめでした
AuroraはGTIDに対応していない
GTID系のパラメータはすべてOFF
⾊々パラメータを変更して試してみたが、
binlogが切り替わるタイミングでレプリケー
ションが⽌まるという。。。
※機能的には無効になっているがbinlogの中に
Previous-GTIDの⽂字列で出るのがNG

41. 困ったときのサポート
カクカクシカジカ
こういう状況です。
調査します
その要件だったら、DMS
(Database Migration
Service) なんてのもあり
ますよ
※実際はもっと丁寧な対応です

42. Database Migration Service!?
オンプレからの移⾏サポートツールかと思って、気にしていなかった。。。

43. まず、使ってみた
Subnet Group作成
Replication Instance (移⾏⽤中間ノード) 作成
Endpoint (移⾏元/移⾏先) 指定
Task (移⾏作業) 指定
実⾏

44. できた
速い 安い簡単
が、何かがおかしい、、、
charsetが全体的に「ucs2」！
PK以外のkeyやindexがない！

45. Task Settingsを無視してた
「Target table preparation mode」重要
(1)
(2)
(3)
(1) 既存テーブルがあっても何もしない
(2) 既存テーブルはDROPする(テーブル定義はDMSに従う) ※デフォルト
(3) 既存テーブルにデータあればTRUNCATEする
これ

46. もう⼀つ重要なこと
Table mappings
特定の1DBをそのまま移⾏するならそのまま
全DBを移⾏するなら「All schemas」

47. DB/テーブル統合の場合
カスタムマッピング
Selection
対象/対象外テーブルの
指定
Transfomation
DB/Table名の変換
カラム追加・削除など
Source Filter
WHERE句のように移⾏
対象の条件を指定

48. ⽅針
テーブル定義(CREATE TABLE)は
先にしておく
Table Mappingで
移⾏対象や移⾏先を指定
Filterで不要データは移⾏しない

49. 移⾏プラン
「初期移⾏＋レプリケーション」で
良きタイミングで短時間のサービス
停⽌で切り替え
のはずだったのですが、、、

50. DMS＋Aurora優秀すぎ
2時間もあれば完了してしまう
不要なログ系
テーブルの
データ
過去の
キャンペーン
データ
参照されない
古いデータ
(並列Load+Import)*複数タスク*AuroraのWrite
Exclude Exclude Filter

51. ということで
ガッツリサービス停⽌して
メンテナンスさせていただきました
(アクセスされていた⽅、申し訳ありません)

52. 実際に⾏ったこと
DMSの準備
テーブル定義投⼊
Auroraクラスタ作成
(r3.8xlarge)
メンテナンス開始
auto_increment値の
設定
DMS Task開始
レコードチェック
インスタンスタイプ
Down

53. 名前はダテじゃなかった
Database Migration Service

54. 無事、⽬標の構成に！
Aurora
(RDS)
Amazon
Elasticsearch Service
app
・・・
appappapp

55. 移⾏の翌⽇、
Failoverの洗礼を受けましたが、
それ以外は元気にやっています。

56. ⽬的を振り返っておきましょう
パフォーマンスUP 運⽤コストDOWN
脱Spiderストレージエンジン
脱Sharding
Log Structured
Storage
ストレージの拡張
Readerノード

57. まとめ
•Amazon ES
• クラスタ管理をしなくて良いので楽
• ログが⾒られないので有事に⾟い
•Aurora
• Read/Writeともに満⾜の⾏く性能
•DMSも素晴らしい

58. 最後に
We Are Hiring!
[募集職種]
Rubyエンジニア
.NETエンジニア
インフラエンジニア
UI/UXデザイナ