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

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

 

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

Cacooを担当してます。

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

EKS最高！！

 

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

参照：テレワークで使える！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の拡張が必要
  • 増設するにしても拡張するにしても、サービス停止の影響が発生する。

どうやってDBを移設するかパターンを考えてみた

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

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

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

この中だとAWS Database Migration Service一択かな

DMSとは？

• AWS マネジメントコンソールで数回クリックするだけで、データベースの移行を始められる！
• データベースの AWS への移行を事実上ダウンタイムなしで行える
• バージョンアップしながらの移行も可能

詳しくは → Ref : AWS Database Migration Service（最小限のダウンタイムでデータベースを移行）| AWS

 

かいつまんで言うと、

• 移行元DBのデータを移行先DBへコピーしてくれる
• 移行元DBのデータの更新を移行先DBへレプリケーションしてくれる

DMSを正しく理解していなかったのでハマった点

• 移設元と先でフィールドの型が異なり、データが正しく移行できない
  • 例えば、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のサポートに問い合わせると丁寧に教えてくれます！

Ref : ソースとしてのPostgreSQLデータベースの使用AWS DMS – AWS Database Migration Service

 

2019年12月31日 大晦日 メンテ当日

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

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

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

 

当日の作業の流れ

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

これにより、統計情報が失われクエリのレスポンスに影響を与えていました

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL.Minor

• アップグレードを行った後は、ANALYZEを実行しましょう！

 

ということで、大晦日のメンテナンスは大失敗に終わりました。

 

2020年1月26日 リベンジメンテ

今回は前回の反省を踏まえ、

• 最初からPostgreSQLのバージョンを上げた移行先DBへDMSを利用して移行
  • この事により、統計情報は失われませんでした。
  • DMSで異なるバージョン感のデータ移行が行える機能が効いた感じ

これで大晦日のリベンジを果たせました。

 

結果

• 増加していく容量問題をマネージドサービスであるRDSにお任せ
  • 容量の問題
  • EBSの運用からの開放
• 更にコストの削減ができた
  • 移行前はEC2にEBSをアタッチしていたので、未使用容量を最適化できなかったが、RDSへの移行後は最適化できコストの削減ができた
  • コストも50%以上削減！！

 

最後に

• 大晦日にも関わらず、メンテナンスをサポートしてくれた平山さん、中原さん ありがとうございました！
• PostgreSQLのアップグレードを行った後は、ANALYZEを実行しましょう！！