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

DMS で AlloyDB に簡単移行!

Hiroaki KARASAWA
June 26, 2023
21

DMS で AlloyDB に簡単移行!

Digital Native Leader’s Meetup #3 at Google

https://note.com/karszawa/n/n2f4122ddbcdd

Hiroaki KARASAWA

June 26, 2023
Tweet

More Decks by Hiroaki KARASAWA

Transcript

  1. 本日のアジェンダ 1. dinii について & dinii の DB ワークロード 2.

    移行前の状況 3. どうして AlloyDB への移行を決めたか 4. 移行方法 5. 移行当日のスケジュール 6. 移行後 7. まとめ
  2. 課題 Hasura の subscription の仕組みのせいで read がめちゃくちゃ重い • 1 query

    / 1 second for 1 user 🤯 • すでに Cloud SQL で設定可能な vCPU 数の上限 が近かった
  3. AlloyDB のここが良さそう 1. Google の豊富なコンピューティング資源を活かす独自の実装 ⇒ なんかすごそう 2. Read Pool

    により読み取り側の冗長性を高められる ⇒ 当座の危機を回避 3. columnar engine や index advisory などで OLAP でも雑に使える ⇒ 分析基盤の構築までは手が回っていなかったため
  4. Database Migration Service を使用 1. PostgreSQL, MySQL, Oracle から Cloud

    SQL or AlloyDB に移行 2. 論理レプリケーションの仕組みを利用して リアルタイム にデータを同期 3. ボタンを押して 数秒〜数分 で移行先へのレプリケーションが停止される
  5. セットアップは GUI でサクサク • 移行元でのレプリケーション設定 • VPC Peering or TCP

    Proxy で通信設定 ※ AlloyDB はプロジェクト内の VPC に配置されるが Cloud SQL は Google 管理の VPC 内にあるため疎通設定が地味に面倒くさい ⇒ サポートケースを大量に起票していたら DMS のプロダクトチームがユーザーヒア リングを実施してくれた。感謝! 🥰 各種リソースの設定画面 Datastream と似ている
  6. 移行計画 移行の方針を経営層と擦り合わせた上で 、以下を1ヶ月ぐらいで実施 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成

    4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 このままだと XX までに 参照系が全部止まりますね 今期中に何か手を打たないと マズイですね me CTO DB 移行はビジネスインパクトの 大きい仕事 ⇒ 頭出し大事!
  7. 1. パフォーマンス検証 ⇒ 主要な OLTP 操作の負荷テストを Cloud SQL と AlloyDB

    で比較 ⇒ 同時実行数に比例した性能悪化が無いことを確認 ⇒ 本番 DB のスペックも決定 2. アプリケーション動作検証 3. DMS の構成 4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 性能悪化がないなら 本番の tps と CPU 使用量から簡単に類推可能
  8. 1. パフォーマンス検証 2. アプリケーション動作検証 ⇒ ステージング環境を AlloyDB に移行して通常の互換性確認試験を実施 ⇒ ステージングなので問題があればデータを捨てて

    Cloud SQL に戻すだけ 3. DMS の構成 4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 4000 項目以上の豊富な試験項目と QA チームに感謝
  9. 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 ⇒ ネットワーク構成周りが地味に大変だった …

    4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 とはいえドキュメントも豊富なので頑張っ てやるだけ
  10. 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 ⇒ ネットワーク構成周りが地味に大変だった …

    4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 とはいえドキュメントも豊富なので頑張っ てやるだけ
  11. 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 4. 社内周知・顧客案内 ⇒

    顧客に多大な影響を与えうる計画のため、社内全体にリスクを周知する 5. 移行実行 6. 移行後の監視
  12. 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 4. 社内周知・顧客案内 5.

    移行実行 ⇒ ステージング・ベータで入念に練習した上で … ⇒ 当日のタイムラインと共に紹介します! 6. 移行後の監視
  13. 本番移行のタイムライン 3:55 起床 4:00 同期開始 6:44 同期完了 6:45 レプリカへのクエリを AlloyDB

    で処理する 6:55 DMS 移行開始 6:56 DMS 移行完了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 シンプルに辛い! 前日も緊張で眠れない!
  14. 本番移行のタイムライン 3:55 起床 4:00 同期開始 6:44 同期完了 6:45 レプリカへのクエリを AlloyDB

    で処理する 6:55 DMS 移行開始 6:56 DMS 移行完了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 本来は前日にやる予定だったがトラブルがあ り実施できなかった データ量は WAL 抜きで 100GB ほど
  15. 本番移行のタイムライン 3:55 起床 4:00 同期開始 6:44 同期完了 6:45 レプリカへのクエリを AlloyDB

    で処理する 6:55 DMS 移行開始 6:56 DMS 移行完了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 移行先がレプリカとして機能して いるため先に変えておく Hasura & GraphQL で Read だけ上 手く分離できているからこそ可能
  16. 本番移行のタイムライン 3:55 起床 4:00 同期開始 6:44 同期完了 6:45 レプリカへのクエリを AlloyDB

    で処理する 6:55 DMS 移行開始 6:56 DMS 移行完了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 ダウンタイムはここだけ!
  17. 本番移行のタイムライン 3:55 起床 4:00 同期開始 6:44 同期完了 6:45 レプリカへのクエリを AlloyDB

    で処理する 6:55 DMS 移行開始 6:56 DMS 移行完了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 やり切る!
  18. AlloyDB への要望 これができたらすごい! 1. リードプールのオートスケーリング Cloud SQL では出来ているので期待 2. Maintenance

    Window への対応 3. Datastream とのネイティブでの対応 4. Cloud Run との通信のためのネットワーク構成を楽にやりたい
  19. まとめ AlloyDB の良さは 手軽さ と パフォーマンス を両立しているところ • DMS のおかげで簡単に移行できる

    • PostgreSQL 完全互換なので挙動が分かりやすい • Google Cloud の DB のデフォルト選択肢として期待!