Photo by Birk Enwald on Unsplash
インフラチームの笠井（@takayukikasai）です。
ウォンテッドリーでは複数の Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL を運用しています。使用していた PostgreSQL のバージョンが EOL を迎えるためアップグレード作業が必要になりました。これまでは深夜にメンテナンスウィンドウを設けてアップグレードしていましたがダウンタイムのタイミングも読みづらく準備工数も大きいという課題がありました。今回 AWS の Blue/Green Deployment 機能を使ってアップグレードを実施したところタイミングをコントロールしやすくダウンタイムも短縮できています。本記事では事前調査から検証、本番実施まで一連の作業で得られた知見を紹介します。
背景・課題
なぜ Blue/Green Deployment を採用したのか
やったこと・わかったこと
前提
調査・検証
手順作成
実施
やっておいて良かったこと
学んだこと
Blue/Green Deployment の特性
アップグレード手法の選択
パフォーマンス最適化
まとめ
ウォンテッドリーではメインデータベースとして Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL を複数運用しています。PostgreSQL は各バージョンごとにサポート期間が決まっており適切にアップグレードしないと意図しないタイミングで自動アップグレードが実施され予期しないダウンタイムやサービス影響が発生するリスクがあります。標準サポート期間終了後も有料で延長サポートを受けられますがコストを抑えるためにも定期的なアップグレードが望ましいと考えています。過去にも同様のアップグレード作業を実施しておりその際の事例は以下の記事で紹介しています。
アップグレード作業には多くの考慮事項があり特にダウンタイムへのアプローチについて社内で検討を重ねてきました。最近は問題発生時のロールバックのしやすさとオペレーションの単純化を重視して深夜にメンテナンス時間を設けユーザーからのアクセスを完全に遮断した上でアップグレードするという比較的オーソドックスな手法を採用していました。
ただこの方法には次のような課題がありました。
これらの課題を解決するには「操作から適用までの時間が短く予測可能であること」と「ダウンタイムが短いこと」が重要でした。
調査したところ AWS の Blue/Green Deployment を使えばこれらの要件を満たせそうだとわかりました。Blue/Green Deployment は本番環境（Blue）と同じ構成の新環境（Green）を作成しデータベースの変更を Green で適用してからトラフィックを切り替える仕組みです。レプリケーションで両環境のデータを同期するためスイッチオーバー時のダウンタイムを最小限に抑えることができます。詳細については AWS の公式ドキュメントを参照してください。
他の選択肢として Zero Downtime Patching (ZDP) も検討しました。ZDP は Aurora でのみ使える機能でパッチ適用中も可用性を維持することを謳っていますが実際に検証してみると ZDP でもダウンタイムが発生しました。
具体的には次のような特性が確認できました。
こうした理由からスイッチオーバーのタイミングをコントロールしやすくかつ RDS と Aurora の両方に対応できる Blue/Green Deployment を採用することにしました。
ウォンテッドリーでは Sandbox、QA、本番（production）の3つの環境を運用しています。新機能の実装や運用変更を行う際はまず Sandbox で動作確認し次に QA で本番に近い条件で検証してから最後に本番へ適用するフローになっています。今回のデータベースアップグレードも同じアプローチで進め各環境で実際に作業しながら手順を改善していきました。なお RDS/Aurora では MySQL などのデータベースも選択できますが本記事で扱うのはすべて PostgreSQL のケースです。
まず AWS のドキュメントを精査しました。Blue/Green Deployment の公式ドキュメントでベストプラクティスや制約事項を確認できます。特に重要だったのは以下の点です。
本番作業の前には Sandbox 環境と QA 環境で検証を実施しました。具体的には以下を確認しています。
検証結果を踏まえて Sandbox、QA、本番の順に手順を作成し各環境で実施しながら改善を重ねました。最終的には以下のような手順になっています。
0. 開始アナウンス
1. 準備（作業当日からメンテナンス前まで）
2. 実行（メンテナンス時間中）
3. 後片付け
4. 終了アナウンス
Blue/Green Deployment の作成は大半のデータベースで比較的短時間で完了しましたが大規模なデータベースでは想定以上に時間がかかっています。スイッチオーバー自体は短時間で完了しオペレーションを並列化すればさらに短縮できる可能性があります。ただしスイッチオーバー後に大量のトランザクション失敗エラーが発生するという予期しない問題が起きました。Pod を再起動したところ解消されたため Pod 内の DNS キャッシュにより古いデータベースに接続していたと考えられます。結果として対象となるすべての RDS/Aurora インスタンスのアップグレードを完了し PostgreSQL の最新バージョンへ更新できました。
Blue/Green Deployment の作成を作業時間前に早めに開始したことが重要でした。Blue/Green Deployment の作成に予想以上に時間がかかるデータベースがあったためメンテナンスウィンドウの前に余裕を持って開始しておく必要があります。Sandbox と QA で複数回実際に作業を実施しそのたびに改善点を修正していったことも本番作業の成功につながりました。
今回の作業を通じて Blue/Green Deployment を用いたデータベースアップグレードに関する多くの知見を得られました。
Blue/Green Deployment の作成時間にはばらつきがあり大半のデータベースは比較的短時間で完了しますがデータ量が多くストレージクラスが gp2 など古いものは想定以上に時間がかかることがあります。
スイッチオーバー後も Pod に DNS キャッシュが残り古いデータベースに接続しようとしてエラーが発生する場合があるためアップグレード対象のデータベースへ接続している Deployment をすべて再起動する手順を追加する必要があります。
レプリカラグについては Blue/Green Deployment が自動で追いつくまでスイッチオーバーしないガードレールがありますが Blue/Green Deployment 作成とスイッチオーバーのタイミングが大きく離れている場合追いつくのに時間がかかる可能性があるため両者の間はできるだけ短くするのが安全です。重要な点としてスイッチオーバー後はロールバックできないためフォールバックプランは用意しておくべきで実際に上手くいかなかったときのためにフォールバック手順を用意して臨んでいます。
Zero Downtime Patching (ZDP) でもダウンタイムが発生することが検証で明らかになりました。Aurora でのみ利用可能な ZDP ですが実際にはダウンタイムが発生しダウンタイム開始までの時間も比較的かかるためウォンテッドリーでは Blue/Green Deployment の方がタイミング制御がしやすいと判断し今後も継続して使用する方針です。
アップグレードの種類によって物理レプリケーションと論理レプリケーションが使い分けられ論理レプリケーションにはプライマリキーがないテーブルをサポートしないなど複数の制約があるため論理レプリケーションを使用するアップグレード時にはこの点を含めた制限事項の考慮が必要です。
スイッチオーバー後の ANALYZE は必ず実施しましょう。Green は直近のスナップショットから復元されたばかりであり統計情報を更新しないと十分なパフォーマンスを出すことができません。
今回 AWS の Blue/Green Deployment を使って PostgreSQL のアップグレードを実施しダウンタイムを短時間に抑えることに成功しました。従来の手法と比べてタイミングをコントロールしやすくダウンタイムも短縮できメンテナンス準備の工数も削減できることを確認できています。事前の調査と検証、特に AWS のドキュメントの精読と検証環境でのリハーサルが成功の鍵となり Blue/Green Deployment 作成の早期開始やスイッチオーバー後の Pod 再起動など実践的な知見も得られています。
次回以降 Blue/Green Deployment を活用することで事前準備の工数を削減しより短期間でデータベースのアップグレードを実施できる目処が立ちました。作業手順の標準化とメンテナンスウィンドウの短縮によりメンテナンスコストの削減が実現だけでなくユーザーへの影響も最小限に抑えられる結果につながりました。
本記事が同様のデータベースアップグレードを検討されている方の参考になれば幸いです。
