Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ダウンタイム 30 秒で AlloyDB に移行した話
Search
Hiroaki KARASAWA
August 02, 2023
0
72
ダウンタイム 30 秒で AlloyDB に移行した話
https://cloudonair.withgoogle.com/events/alloy-db-casestudy-meetup?talk=session2
Hiroaki KARASAWA
August 02, 2023
Tweet
Share
More Decks by Hiroaki KARASAWA
See All by Hiroaki KARASAWA
Google Cloud のモニタリング製品を徹底活用してみた
karszawa
0
29
DMS で AlloyDB に簡単移行!
karszawa
0
26
【現場の本音】App Engine から Cloud Run に移行してみた
karszawa
0
120
cls-hooked による実行コンテキストの保存と利用
karszawa
0
720
Hasura の Relationship と権限管理
karszawa
0
770
React Native + Expo のバージョンアップと互換性の維持に関する運用と絶技
karszawa
0
720
ダイニーにおけるモニタリングと振り返りの仕組み
karszawa
1
230
ダイニーにおける本番 Hasura 運用
karszawa
1
2k
Hasura Con'21 Recap - GraphQL subscriptions
karszawa
0
450
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
506
140k
BBQ
matthewcrist
85
9.3k
Fireside Chat
paigeccino
34
3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
Teambox: Starting and Learning
jrom
133
8.8k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Unsuck your backbone
ammeep
668
57k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Transcript
ダウンタイム 30 秒で AlloyDB に移行した話 Database Migration Service で AlloyDB
に簡単移行! AlloyDB Case Study Meetup 2023/08/02 Hiroaki KARASAWA from dinii, inc
自己紹介 Google Cloud “Champion Innovator” (2023/07/10-) HASURAward “Champion of The
Year” (2023/07/07-) dinii, inc (2020~) 飲食店の POS と MO を作って CRM してます Full-stack Engineer フロント専門 ⇒ スタートアップ故の何でも屋 ひとこと 懇親会会場の調整はお任せください! 【実績】 • Google Cloud Innovators Meetup • Jagu'e'r Cloud Native Meetup
Cloud Run Node.js Hasura Hasura SRE React Native
Table of Contents dinii について 移行前の状況 移行の手順 移行当日のタイムライン 移行後 まとめ
01 02 03 04 05 06
dinii について 事業と DB 事情 01
10 Full-time SWEs
None
650万人
None
None
移行前の状況 + AlloyDB へ移行を決めた理由 02
dinii というミッションクリティカルなサービス dinii が動かなくなると… 1. 注文できない 2. 調理できない 3. 会計できない
システム構成(移行前) Hasura DB スキーマから GraphQL API を 提供してくれるスゴいミドルウェア
課題 Hasura の subscription の仕組みのせいで read がめちゃくちゃ重い • 1 query
/ 1 second for 1 user 🤯 • すでに Cloud SQL で設定可能な vCPU 数の上限 が近かった ※ Cloud SQL Enterprise Plus エディション (2023/07/12) で Cloud SQL 側も改善しています
AlloyDB のここが良さそう 1. Google の豊富なコンピューティング資源を活かす独自の実装 ⇒ なんかすごそう 2. Read Pool
により読み取り側の冗長性を高められる ⇒ 当座の危機を回避 3. columnar engine や index advisory などで OLAP でも雑に使える ⇒ 分析基盤の構築までは手が回っていなかったため
移行の手順 03
Database Migration Service (DMS) を使用 1. PostgreSQL, MySQL, Oracle から
Cloud SQL or AlloyDB に移行 2. 論理レプリケーションの仕組みを利用して リアルタイム にデータを同期 3. ボタンを押して 数秒〜数分 で移行先へのレプリケーションが停止される
セットアップは GUI でサクサク • 移行元でのレプリケーション設定 • VPC Peering or TCP
Proxy で通信設定 ※ AlloyDB はプロジェクト内の VPC に配置されるが Cloud SQL は Google 管理の VPC 内にあるため疎通設定が地味に面倒くさい サポートケースを大量に起票していたら DMS のプロダクトチーム がユーザーヒアリングを実施してくれた。感謝! 🥰
移行計画 移行の方針を経営層とすり合わせた上で、以下を 1ヶ月ぐらいで実施 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成
4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視
移行計画 移行の方針を経営層とすり合わせた上で、以下を1ヶ月ぐらいで実施 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 4.
社内周知・顧客案内 5. 移行実行 6. 移行後の監視
移行計画 移行の方針を経営層とすり合わせた上で、以下を1ヶ月ぐらいで実施 1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 4.
社内周知・顧客案内 5. 移行実行 6. 移行後の監視 このままだと X月Y日 までに 参照系が全部止まりますね 今期中に何か手を打たないと マズイですね me CTO DB 移行はビジネスインパクトの 大きい仕事 ⇒ “根回し” 大事!
1. パフォーマンス検証 ⇒ 主要な OLTP 操作の負荷テストを Cloud SQL と AlloyDB
で比較 ⇒ 同時実行数に比例した性能悪化が無いことを確認 ⇒ 本番 DB のスペックも決定 2. アプリケーション動作検証 3. DMS の構成 4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 性能悪化がないなら 本番の tps と CPU 使用量から簡単に類推可能
1. パフォーマンス検証 2. アプリケーション動作検証 ⇒ ステージング環境を AlloyDB に移行して通常の互換性確認試験を実施 ⇒ ステージングなので問題があればデータを捨てて
Cloud SQL に戻すだけ 3. DMS の構成 4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 4000 項目以上の豊富な試験項目と QA チームに感謝
1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 ⇒ ネットワーク構成周りが地味に大変だった …
4. 社内周知・顧客案内 5. 移行実行 6. 移行後の監視 とはいえドキュメントも豊富なので頑張っ てやるだけ
1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 4. 社内周知・顧客案内 ⇒
顧客に多大な影響を与えうる計画のため、社内全体にリスクを周知する 5. 移行実行 6. 移行後の監視
1. パフォーマンス検証 2. アプリケーション動作検証 3. DMS の構成 4. 社内周知・顧客案内 5.
移行実行 ⇒ ステージング・ベータで入念に練習した上で … ⇒ 当日のタイムラインと共に紹介します! 6. 移行後の監視
移行当日のタイムライン 04
本番移行のタイムライン 3:55 起床 4:00 DMSによるデータ同期 開始 6:44 DMSによるデータ同期 終了 6:45
レプリカへのクエリを AlloyDB で処理する 6:55 DMS CDC 移行 開始 6:56 DMS CDC 移行 終了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 DMS 職人の朝は早い! 前日も緊張で眠れない!
本番移行のタイムライン 3:55 起床 4:00 DMS によるデータ同期 開始 6:44 DMS によるデータ同期
終了 6:45 レプリカへのクエリを AlloyDB で処理する 6:55 DMS CDC 移行 開始 6:56 DMS CDC 移行 終了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 本来は前日にやる予定だったがトラブルがあ り実施できなかった データ量は WAL 抜きで 100GB ほど
本番移行のタイムライン 3:55 起床 4:00 DMS によるデータ同期 開始 6:44 DMS によるデータ同期
終了 6:45 レプリカへのクエリを AlloyDB で処理する 6:55 DMS CDC 移行 開始 6:56 DMS CDC 移行 終了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 移行先がレプリカとして機能して いるため先に変えておく Hasura & GraphQL で Read だけ上 手く分離できているからこそ可能
本番移行のタイムライン 3:55 起床 4:00 DMS によるデータ同期 開始 6:44 DMS によるデータ同期
終了 6:45 レプリカへのクエリを AlloyDB で処理する 6:55 DMS CDC 移行 開始 6:56 DMS CDC 移行 終了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 アプリケーションダウンタイムはここだ け!
本番移行のタイムライン 3:55 起床 4:00 DMS によるデータ同期 開始 6:44 DMS によるデータ同期
終了 6:45 レプリカへのクエリを AlloyDB で処理する 6:55 DMS CDC 移行 開始 6:56 DMS CDC 移行 終了 7:00 メトリクス監視 7:40 動作確認完了 7:45 完了報告 やり切る!
移行時の監視状況 エラーが発生している時間帯をダウ ンタイムと考えると 30s ほど 実際はバックグラウンドでのデータ取得な どユーザー影響が無い API が多数
移行後 05
移行後初の週末を無事に乗り切ることができた様子
AlloyDB への要望 これができたらすごい! 1. リードプールのオートスケーリング Cloud SQL では出来ているので期待 2. Maintenance
Window への対応 3. Datastream とのネイティブでの対応(現状では Compute Engine で Proxy を構成する必要あり) 4. Cloud Run との通信のためのネットワーク構成を楽にやりたい (こちらも現状では Serverless VPC Access connector を構成する必要あり)
まとめ AlloyDB の良さは 手軽さ と パフォーマンス を両立しているところ • DMS のおかげで簡単に移行できる
• PostgreSQL 完全互換なので挙動が分かりやすい • Google Cloud の DB のデフォルト選択肢として期待!