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を実行しましょう!!

オンライン コラボレーション作図ツール

250万ものユーザーがなぜ Cacoo を選んでいるのかご自身の目でお確かめください

無料トライアル