最近、PostgreSQL 15系から17系へのアップグレード対応を担当しました。
正直に言うと、最初は技術的な問題が一番大変だと思っていました。
PostgreSQL のメジャーバージョンアップなので、
- 非互換の変更はないか
- 利用しているライブラリに影響はないか
- Extension に問題はないか
- 本番環境でエラーが発生しないか
といった点を心配していました。
まずは技術調査
今回は社内で過去に PostgreSQL をアップグレードした事例だけではなく、海外の技術ブログやフォーラムも調査しました。
「PostgreSQL 17系にアップグレードした際にどのような問題が発生したのか」
をできるだけ事前に把握したかったからです。
調査の中では、Extension 関連の問題や設定変更による影響など、さまざまな事例が見つかりました。
しかし実際に確認してみると、私たちの環境では利用していないものも多く、心配していた技術的な問題はほとんどありませんでした。
ローカル環境の更新、ステージング環境での検証も順調に進み、アップグレード作業自体は想像していたよりもスムーズでした。
本当に難しかったこと
技術的には順調でした。
しかし、作業を進める中で別の難しさが見えてきました。
それは、
「どのチームがこの変更の影響を受けるのか」
を把握することでした。
今回の作業では、メンテナンス中に一部画面の利用を制限する必要がありました。
そのため、自分のチームだけではなく、他プロダクトの担当チームとも調整しながら進める必要がありました。
ここで私は一つ反省しました。
私は PostgreSQL 自体についてはかなり時間をかけて調査しました。
しかし、
「影響を受ける可能性がある他チーム」
についての確認は、もっと早い段階で行うべきでした。
マイクロサービスで感じたこと
マイクロサービス構成では、
「自分のサービスだけを見ればよい」
と思ってしまうことがあります。
私も少しそう考えていました。
しかし実際には、
- 別チームが管理している機能
- 共通で利用しているシステム
- 他プロダクトの画面
- 運用チームが利用している機能
など、コードだけを見ていては分からない依存関係がたくさんあります。
今回の対応を通じて気づいたのは、技術的な依存関係よりも、人やチームの依存関係の方が見えにくいということでした。
PostgreSQL のアップグレード自体は比較的スムーズに進みましたが、実際には多くのチームと調整しながら進める必要がありました。
今回の経験を通じて、
「何が壊れるか」
だけではなく、
「誰に影響するか」
を最初に考えることの重要性を学びました。
最後に
今回の PostgreSQL アップグレードでは、大きな技術的な問題は発生しませんでした。
しかし、プロジェクトを進める中で、技術以外の部分の重要さを強く実感しました。
次回、インフラや共通システムに関わる変更を担当するときは、
まずアーキテクチャ図を見る前に、
「この変更で影響を受ける人は誰か」
を整理するところから始めようと思います。
同じようなメンテナンスやインフラ変更を担当する方の参考になれば幸いです。
