今日は Data Migration Night に参加してきた & LT 枠で登壇してきた!
ChatWork がデータマイグレーションに使った技術の話
- CQRS + Event Sourcing System
- Aurora にある17億メッセージを HBase にマイグレーションする
- 基本マイグレーションと差分マイグレーションに分類した
- Aurora の binlog を直接取得して差分マイグレーションに使った
- メトリクスを取得して,マイグレーションの成功をちゃんと確認するようにした
- Aurora から Spark で HBase に書き込むときのパーティションを試行錯誤した
17億メッセージを管理する Aurora って,どんなインスタンスタイプを使ってるんだろう?質疑応答では Room ID でパーティショニングをしていると言っていた.あと資料に “巨大部屋” という表現があって笑った.Spark も HBase も使ったことがなくて,詳細はわからなかったけど,分散システムの特性を理解した上でマイグレーションを考えたという話は参考になった.
(資料公開待ち)
オンプレから AWS 移行で変えた3つの意識
- コスト意識
- RI をインスタンスの在庫確保として使う
- AWS オペレーション意識
- インフラ専任エンジニアの撤廃
- IAM で細かく制御して,オペミスが起きないようにした
- システムダウン意識
- フルマネージドを使うようにした
- サーバダウンを許容し,復旧できることを重要視した
インフラ専任を撤廃していくのは施策としては非常に興味深かった.もっと事例を聞いてみたかった.また RDS で適用必須なメンテナンスが入るとサービスダウンに繋がるので,前段で書き込みを止めて対応しているとのこと.メンテナンスを選択できれば良いんだろうけど,無停止前提だと厳しいよなぁ.
www.slideshare.net
2000万アカウントの無停止データ移行の裏側
- 新旧同期 Replicator
- 双方向レプリケーション
- Replicator は MySQL の Slave として見える
- GitHub - whitesock/open-replicator: Open Replicator is a high performance MySQL binlog parser written in Java. It unfolds the possibilities that you can parse, filter and broadcast the binlog events in a real time manner. を使っている
- binlog を取得して RabbitMQ に置いてからデータを同期する
- Statement と Row フォーマットの違いも考慮した
- 新旧のデータ構造を yml でマッピングできるようにした
- 循環更新を防ぐ
- Vert.x 3 を使った
大きな問題無く移行できたのは凄いと思う.個人的にはレプリケーション遅延も気になるし,循環更新も気になる.懇親会で話を聞いたら「今はもう役目を終えた」と言っていて,完全に移行専用のアーキテクチャとのこと.強い!あと open-replicator は全く知らなかったので,調べる.
LT : どのように MySQL on EC2 から Aurora に移行したのか
僕は CyberAgent Developers Blog に投稿した記事の一部 + α を紹介した.Aurora に特化した内容はあまり話さず,データ移行の Tips を中心に話したけど,比較的反応もあって良かった!
資料も up した!
LT : AWS のデータ移行ソリューション
- AWS Direct Connect
- AWS Snowball
- AWS Snowmobile
- などなど
(資料公開待ち)
関連記事
登壇写真
撮影してもらった!素晴らしい会場だったし雰囲気ある ( ゚д゚)ノシ