Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Recap: Migrating 80 BILLION RECORDS From MySQL ...

Recap: Migrating 80 BILLION RECORDS From MySQL to Bigtable

Go 1.21 リリースパーティ & GopherCon 2023 報告会( https://gocon.connpass.com/event/299108/ )登壇資料です。
サンディエゴにて開催された、GopherCon2023に参加してきたのでそちらの報告で登壇させていただきました!

▼ Recapしたネタ元
https://www.gophercon.com/agenda/session/1158499

▼ 実装検証したリポジトリ
https://github.com/TakumaKurosawa/Migrating-80-BILLION-RECORDS-From-MySQL-to-Bigtable

Takuma Kurosawa

October 31, 2023
Tweet

More Decks by Takuma Kurosawa

Other Decks in Programming

Transcript

  1. 黒澤 拓磨 CyberAgent ‘21年新卒入社 AI事業本部配属後、新規事業立ち上げに従事。 今年(2023年)からハノイ開発センターの立ち上げに携わるた め、ベトナムへ移住。 Goとの馴れ初め CA Tech

    DojoにてGoの基礎やバックエンド開発の基礎を学んだ のがきっかけ。CyberAgentで携わってきたプロダクトは全てGoで 開発。 TakumaKurosawa
  2. MySQL→Bigtable移行のモチベーション なぜMySQLではダメだったのか? 1. 運用面での問題 a. ソフトウェアおよびセキュリティアップデート b. DBホストプロビジョニング c. 100%利用可能な状態を維持しつつ実行すること

    2. バックアップとリストアにかかるメンテコストが莫大だった a. 最大まる2人日必要 3. マルチリージョンやグローバルな配信での課題 a. 手作業でのMySQLシャーディングには限界がある 󰢃
  3. MySQL→Bigtable移行のモチベーション Google Cloud Bigtableへの移行を決定した理由 • 99.999% SLA • 無制限のスケール •

    1桁msのレイテンシー • ビルトインのモニタリングシステム • マルチリージョンレベルのレプリケーション • リージョン間のシームレスなレプリケーションにより、地理的分散が可能 • コンピュートリソースとストレージのオンデマンドスケールに対応 • Bitlyにおいて他のGoogleCloudサービスを利用しており、親和性が高い • Bitlyの仕様上、NoSQLデータベースとの相性の良いデータセット形式であった
  4. MySQL→Bigtableマイグレーション計画 MySQL writes MySQL reads Bigtable writes Bigtable reads Start

    dual writes マイグレーション Bigtableに切り替え End dual writes
  5. 前提条件 Bitlyでのデータ管理(Before) hash_0 to hash_7 hashdb-1 hash_8 to hash_15 hashdb-2

    hash_16 to hash_23 hashdb-3 hash_24 to hash_31 hashdb-4 hash_32 to hash_39 hashdb-5 hash_40 to hash_47 hashdb-6 hash_0 to hash_23 hash-archive-1 hash_24 to hash_47 hash-archive-2
  6. 前提条件 シャーディングのメリット 4,000,000件 1,000,000件 1,000,000件 1,000,000件 1,000,000件 • 応答時間の改善 •

    単一障害点を無くせる • スケーリングしやすくなる https://aws.amazon.com/jp/what-is/database-sharding/
  7. 前提条件 Bitlyでのデータ管理(Before) hash_0 to hash_7 hashdb-1 hash_8 to hash_15 hashdb-2

    hash_16 to hash_23 hashdb-3 hash_24 to hash_31 hashdb-4 hash_32 to hash_39 hashdb-5 hash_40 to hash_47 hashdb-6 hash_0 to hash_23 hash-archive-1 hash_24 to hash_47 hash-archive-2
  8. データ移行プログラム 改善③ チャネルを使用してワーカーパターンに = max( 予測総時間 time(shard_a) , time(shard_b) ,

    … , time(shard_n) ) SELECT * FROM tableName … SELECT * FROM tableName … ・・ ・ Insert Insert Insert Insert Insert Insert MigrateRows() Worker 1 Worker 2 Worker 3
  9. 📩 メールの内容 Hashキーの特性とホットスポット回避 • MySQLに保存していたHashデータは時系列順に並ぶようなキーになっていた ◦ 言及されていないが、恐らくULID? • MySQLのデータをそのままBigtableに入れると、ホットスポットになる ◦

    Bigtableの仕様上、行キーはアルファベット順でソートされる • ホットスポットを回避するために、HashをReverseするようにした Bulk insertにしなかった理由 • Bigtableの仕様上、バルクインサートする対象のデータリストが互いに近い位置に配 置されるようなデータ構造でない場合は並列処理されずに順次実行されてしまう • どうせBigtableの仕様で順次実行になるのであれば、実装が楽な1件ずつinsertしよう と思った
  10. 用意した環境 Docker compose • MySQL • DynamoDB MySQL • hashdb-1

    ~ 6 テーブル • 10,000件 / table • データ構造は一緒 DynamoDB • Hash(String):PartitionKey • amazon/dynamodb-local イメージを使用