CacooのRDS移行物語～3TB強を誇る巨大データベースに挑む、大晦日の熱き戦い

by Nulab

2020年12月16日

※このブログはヌーラバー Advent Calendar 2020の16日目の記事です。明日はKeisuke Okafujiさんの記事です。

SRE課の渡邉潔（@kyswtnb）です。

Cacooを担当してます。

最近は自前で運用しているkubernetesをEKSに移行している者です。

EKS最高！！

先日、Cacooは図の編集画面上でビデオ会議ができる「ビデオ通話」機能をリリースしました！

ぜひご利用ください。

今回の本題ですが、

2019年末から2020年初に、EC2 で実行されている3TB超えのPostgreSQLを、

AWS Database Migration Service を利用しAWS RDSに移行しました。

Cacooはお客様の大切なデータをAmazon RDS for PostgreSQLを利用して運用しております。

本記事では、CacooのデータベースをAWS RDSへ移行した2019年末から2020年初のあれこれを書いていきたいと思います。

PostgreSQLをDMSを利用して移行する際のヒントに慣れば幸いです。

なぜCacooのDBの移設が必要だったか？

以下のような状況からRDSに移設を行うことは差し迫った課題でした。

EC2 で実行されているPostgreSQLだったので、OSのKernel Updateなどで、サービス停止が発生していた。
Diskが足りなくなるとEBSをアタッチしてTABLESPACEを分けて運用してきた。
- すでに6本のDISK（EBS）がアタッチされており、運用負荷が大きかった。
更に近々Disk増設か、EBSの拡張が必要
- 増設するにしても拡張するにしても、サービス停止の影響が発生する。

以下のような手段しか浮かばなかった

EC2 で実行されているPostgreSQLとRDSのPostgreSQLでレプリケーションを組んで移設
- 論理レプリケーションは利用できなかった
  - PostgreSQL9系を利用していて、PostgreSQL10以降でないと使えない

EC2 で実行されているPostgreSQLからDumpファイルをRDSのPostgreSQLにインポートする
- Dumpエクスポートだけで10時間を超えた
- インポートを考えるとサービス停止時間が24時間超える
- お客様が利用できない時間が長過ぎて許容できない
AWS Database Migration Service を利用して移設する
- Cacooでは以前利用したことがあった

かいつまんで言うと、

移設元と先でフィールドの型が異なり、データが正しく移行できない
- 例えば、timestampがtimestamp(6)になったり、DEFAULT “now”()が消えたりする
- 対応
  - 事前に移設先DBにtableを作成しておく
  - データベース移行タスクのターゲットテーブル作成モードの設定で[何もしない]を選択する

外部キー制約でCASCADEによるデータ削除をレプリケーションしてくれない
- 対応
  - 外部キー制約を持つtableはDMSでの移行を行わず、手動で移設する
PostgreSQLを移行元とする場合、JSON 型のデータサイズが大きい場合に全データが移行出来ない制限がある
- 1レコードに、最大で60MBのJSONデータがある
- 対応
  - 短時間でdumpの投入ができるtableは、DMSを利用せずメンテ当日の手動移設とした
  - 短時間でdumpの投入ができないtableは、JSONからtextに変更し、アプリケーションも変更してもらった。JSONがなくなったのでDMSで移設できた。Cacoo開発陣に感謝！！
移行してくれないものがある
- ユーザー情報、Grant、シーケンス
- 対応
  - 手動で移設しました

その他にもありましたが、AWSのサポートに問い合わせると丁寧に教えてくれます！

移設元DBと移設先DBの同期を行ってくれるDMSが正常に働き、手動で移行する手順も完成し、メンテ当日を迎えます。

サポートしてくれたのはCacooの同僚でした。

大晦日にも関わらずのサポートに感謝！！！

当日の作業の流れ

メンテ開始
データの差分を出さないためにサービスを停止。
- お客様がCacooを利用できなくなります（ここからド緊張の始まり）
移設元DBの更新がなくなりDMSのデータ移行が追いつくまで待つ
- 初めての本番環境での確認！
- DMSが差分がない状態で同期できるのか！？
  - ・・・
- 緊張の数分後、正常にDMSの同期が完了した！
手動移行分のデータを移行するスクリプトを実行
- これも問題なく完了！
PostgreSQLのバージョンを上げる予定もあったため、移行先DBのバージョンを上げ再起動。
- AWSコンソールでポチポチと行い問題なく完了！
ステージング環境でテスト
- ここまで順調だったのにいきなり問題。
- ここでクエリのレスポンスが遅く、エラーとなっていることにきづく
- メンテ時間を延長して原因を追うが不明
- 真冬にも関わらず大汗
テストがうまく行かず、切り戻しを行うことになった。
- 切り戻し手順はつくっていたので助かった。けど、手は震えた。
切り戻し後に同僚が、移設先DBに統計情報が無いことを指摘してくれた！
- 原因は、メンテ中にバージョンアップを行ったこと