thrakt's tech blog

コードとかやってる事の話。エモい話とかも含める。

データマイグレーションナイトに行ってきた

atnd.org

最近Excelの手入力からMySQLに移行するデータマイグレーションをやっており、インスピレーションと癒やしを求めて参加してきました。DMM.com Labo様主催。東京タワーとかすごい近い絶景のロケーションでした。

ChatWork株式会社 赤津 慶太氏

  • ChatWorkの移行プロジェクトで、メッセージングシステムをAuroraからHBaseに移行した話
    • メッセージングシステムと言うとMQみたいな物を想像したが、チャットのメッセージ全体を格納しているシステムの事で基幹
  • Auroraで17億のレコードを移行
  • 基本マイグレーション + 差分マイグレーションという構成
    • ダウンタイムを小さくする工夫。自分も昔やりました
  • 件数が多いため差分はbinlogを参照して出す。スナップショットから差分を取って移行を繰り返し、最後は本番から。本番とスナップショットのbinlogの出方の違いに注意。
  • DBMS側のメトリクスをしっかり見るのが大事。データを移行してもシステムを壊しては意味ない。
  • Sparkの高速化の話をかなり掘り下げて
    • 門外漢なのでまぁ

株式会社CyberZ 黒木 亮太氏

  • 自社プロダクトをオンプレからAWSに移行した話を全般的に
  • コストのモニターが大事みたいな話

なぜクラウド化したかについて、コスト面とアプリ開発に集中したいからと言われていて、インフラ専業エンジニアはやめてアプリ開発者にクラウド覚えてもらったみたいな話もされていた。DevOpsやんけ~ という感じ。

ただ、クラウドに移行したからといってインフラの知識がいらないとは思えず、むしろ高い専門性が必要になってくる印象がある。アプリ開発に集中というのは開発者の夢であり、PaaSを経て大Serverless時代の到来を待ち望んでいるのではありますが。個人的にクラウドのメリットって高可用性とかになるかなぁと思って聞いていた。

株式会社DMM.comラボ 飯田 涼太氏

  • 基幹システムのAPI更新に伴う新旧同期レプリケータの話
    • 字面がやばく、実際ヤバいアツさがあるプロダクトだった
  • 構成は、新旧ともにMySQLのスレーブとして振る舞うデータ取得機があり、そこから一旦RabbitMQに保存してキューイングし、vert.xで作ったマッパで変換して適用。それが新->旧と旧->新の双方向にある
    • アツい!!!
  • レプリケーションは一旦RabbitMQに書き出すことで、途中で落ちても大丈夫なようにする。永続性を確保。レプリケーションMySQLのバージョンが違ってても対応できるようにした
  • マッピングYamlで指定する形にした
    • なんかすごく汎用性が高いぞ
  • 反映順が担保されないが、結果整合性で解決
  • 更新時に、SQLのコメントやデータなどで更新者を明示し、循環更新されないようにした
  • 問題ないかは日々新旧APIを叩いて比較して検証。マッピングのミスなどで不整合が出ないかは、テスト系でしっかり検証して問題が出ないようにした
    • マジかよ……

とにかく絶対に止めたくないし安全完全ご安心にやるんだという強い意志が伝わってきて、そこまでやるかという感動がありました。これものすごいマンパワーでやってそうで、すごい事例だった印象。

株式会社サイバーエージェントクラウドファンディング(makuake) 吉田 慶章氏

developers.cyberagent.co.jp

の内容らしい。とにかく話が面白く、内容も絞られていて良かったです。

印象に残ったのは、あえて無停止移行を避けて安全側に倒した話。しくじった時のダメージも大きいし、ビジネス側の影響も考えて然るべき調整をして実施したと。そういうの大事だなあと。

Amazon Web Services Japan 千葉 悠貴氏

インバウンドは無料なのでじゃんじゃんデータを持ってきてください、という感じでした。

気になったサービス

www.publickey1.jp

えぇ……


とりあえずAuroraとか実のところRDSインスタンスとの違いがわかってなかったので、その辺調べてみようかと思います。あれ、AWSの勉強会に来たみたいな感想に

自分の経験だと、昔オンプレからクラウドに移行しようとなった時に、ついでにDBのスキーマを整理しようとなってマイグレーションをやったことがあります。基本+差分更新という形で、移行前日まで更新日付を見て移行しておいて、停止後に残りを処理して終わらせる形。移行プログラムはJaveで書いてて、JDBCを2系統用意してSQLで読んで変換しつつSQLで書く形。それなりにデータ量ありましたが、それくらいで済む環境ではありました。まぁなんとか無事には終わった。

最初に書いた人力DB移行の件は、移行データがそれ単体で完結しておらず、結局インポート後に人力で修正をしないといけないという状態で、どうしたものかと。今のところ中間データみたいな物を作って、プレ環境で修正して中間データに書き出し、本番移行という感じにできないかなと考え中ですが、はたして。