こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。
前回の記事「AWSエンジニアから見たGCPサービス(DB/ストレージ編)」を読んでいただいた方々、ありがとうございます。
今回は、GCPのマネージドサービスであるCloud SQLへPostgreSQLのバージョンアップも兼ねて無事故で移行した時に思ったこと・気づいたことがたくさんあったので、それについてお話しいたします。
移行の経緯
約1年前、女子向けメディア「めるも」はオンプレ環境からGCPへほぼ既存構成のまま移行をし(lift)、その後現在までマネージドサービスへの移行を含むクラウド最適化を進めています(shift)。
また、オンプレ環境ではサーバスペックを余剰に確保していましたが、GCPへの移行時に最適なサーバスペックとなるよう全体的に大幅にサイズダウンしました。
しかし、以前の記事「PostgreSQLのメモリアーキテクチャを知る」でも触れていますが、GCP移行後にDBサーバの高負荷が頻発するようになり不安定な状態になってしまいました。
主な原因としてはPostgreSQLのメモリ関連のパラメータが移行後のスペックに対し最適化されていないことだったのでチューニングし対応しましたが、可用性と運用保守性を向上させるべくマネージドサービスであるCloud SQLへ移行させることとなりました。
当時のデータベースサーバの構成
当時のデータベースサーバの構成は以下になります。
- GCEインスタンス2台に対しPostgreSQLをインストールし運用
- PostgreSQLはバージョン9.4を使用
- 1台はMasterサーバ、もう1台はSlaveのMaster – Slave構成
- Masterサーバには書き込み処理の接続、Slaveサーバには読み取りのみの処理を接続させるようアプリで振り分けていた
- 最大接続数は1台あたり500
- Master – Slave間はWALファイルの同期によるレプリケーション接続を行なっていた
移行後の構成案
移行するにあたって、現在のMaster – Slaveとなっている構成をコストと高可用性を考慮し、以下のような構成に変更することにしました。
- 最大接続数500のCloud SQLインスタンス1台 + フェイルオーバーレプリカを待機
- PostgreSQL 13へバージョンアップ
Master – Slaveの2台構成にしていた背景としては、オンプレ環境時からの構成でMaster1台に対してのアクセス負荷を懸念してのことでした。
そして現状としては、DBへの接続元となっているWebサーバからのアクセス数も合計で500以下で最大接続数としては十分足りていたため、接続を受け付けるDBサーバは1台体制にし高可用性を考慮してフェイルオーバーレプリカをウォームスタンバイさせることにしました。
ちなみに、フェイルオーバーレプリカについては通常時はアクセスできませんが起動しているインスタンスからデータを常に同期しており、ゾーン障害時など起動しているインスタンスが停止した場合にダウンタイム3分未満で自動でフェイルオーバーしてくれます。これまでGCEインスタンスでDBサーバを運用していたため、フェイルオーバーにかかる時間も大幅に短縮させることができるようになりました。
また、PostgreSQLは9.4という低いバージョンを使っていたため、サポート終了期限も考えこれを機に最新バージョンの13にバージョンアップすることにしました。
データ移行の検証
PostgreSQLのバージョンアップも兼ねたCloud SQLへの移行のため、データ移行の検証は丁寧に行いました。
検証時に確認ポイントとしていたのは以下の点です。
- データベースのタイムゾーンがUTC+9になっているか
- データ移行前後で、各ロールの権限に差異がないか
- データ移行前後で、データベースオーナー/エンコーディング/アクセス権限/データベースサイズに差異がないか
- データ移行前後でスキーマ数/スキーマのオーナー/各スキーマへのアクセス権限に差異がないか
- データ移行前後でインデックス数/インデックスのオーナー/各インデックスへのアクセス権限に差異がないか
- データ移行前後でテーブル数/テーブルのオーナー/各テーブルへのアクセス権限に差異がないか
これ以外にも異なるPostgreSQLバージョン間でのパラメータの差分がいくつかあったため、差分吸収に関しての調査をしつつ丁寧に検証し作業手順を作成しました。
また、データ移行前後でのアプリの挙動差異などインフラの視点だけでは影響が把握できない箇所については、アプリチームにも動作確認を依頼しました。同様に、当日作業でもデータ移行作業後にアプリチームで動作確認を行っていただくため、作業手順のレビュー会を実施し何度か読み合わせを行いました。
並行して、負荷検証もアプリチームにて実施いただき、移行元のGCEと移行先のCloud SQLで性能比較を行なったところ、Cloud SQLへ移行したことで性能が上がることも確認できました。(一番重たいクエリも体感でですが速く返ってくることも確認)
本番環境でのデータ移行時
管理画面からの操作やバッチ処理など書き込み処理の停止は伴いますがサイトダウンは発生しないため、即座にリカバリすることも考慮し日中帯に作業を実施しました。
作業はdumpファイルの作成からアプリチームでの動作確認も含めて約2時間という長丁場でした。
作業実施中には検証を実施したステージング環境と本番環境の差分による想定外の問題も発生しましたが、この移行を通して学んだPostgreSQLデータベースの知識を活かしその場で解決することができました。
そしてそのまま無事故で移行作業を終えました。
その後
移行作業後、約2週間ほどエラーが発生しないか様子を見ましたが、特に問題はなかったため移行元のGCEインスタンスを削除しました。
無事故で移行できたことは自身の経験としても良い経験になりました。
どうして無事故で移行できたのか
丁寧に検証を行なったというのももちろんですが、一番の成功要因としては一人ではなくアプリチームやチームのマネージャーなどと連携しスムーズに作業ができるよう進めていたからです。
実際に検証時には、インフラ担当の私だけで行なった動作確認だけでは発見できなかったエラーをアプリチームで行なった動作確認で発見することができ、移行作業前の段階でエラーは潰し切ることができていました。
そして、私にはこのようなリスクの高いデータベース移行の経験が今までなかったのですが、経験豊富なチームのマネージャーにもフォローいただきつつ移行前に課題も潰し切ることができたからだと思っています。
アプリチームやチームのマネージャーも含め全員で「無事に移行を完了させる」というゴールに向かっていくために上手く連携できたことが今回の移行の一番の成功要因でした。
協力とフォローしていただいたアプリチームとチームのマネージャーの存在はとてもありがたかったですし感謝の気持ちしかないです。
おわりに
今回はCloud SQLへ無事故で移行した時の体験談を紹介しました。
この移行を通して、一人ではなくチーム間で協力し進めていくことの大切さを改めて実感しました。
私は弊社に転職し約1年半経ちましたが、転職時に経験したいと思っていた「チームで仕事をすること」をこの移行を通して経験できたので、個人的にも良い財産になりました。
これからも、他の業務でチーム間で連携し進めていくことも出てきますが、この移行で得た「自分たちはどこを目指して進めていくのか」を意識しみんなで協力して仕事を進めていければと思います。
※GMOアドマーケティングのクラウドエンジニアについて
GMOアドマーケティングではクラウドエンジニアを募集しております。
クラウドエンジニアの募集要項については こちら
GMOアドマーケティングのインフラエンジニア。(♀)
クラウドインフラのアーキテクチャ設計が得意です。
アプリ開発もできます。
白米と服とおいしいものとFPSと技術が好きです。
