ダウンタイムなしで行うPostgreSQLアップグレード：Blue/Green、レプリケーション、そして本番ERPデータベースのロールバック計画

PostgreSQLのダウンタイムなしアップグレードは、第一印象ではクラウドのうたい文句のように聞こえます。実稼働のERPデータベースの現場では、それはむしろ一種の専門的な規律です。データ整合性、インターフェースの振る舞い、バッチ処理、レポーティング、権限、運用プロセスを相互に整合させ、実際のバージョン切替が制御されたスイッチングの瞬間に過ぎないようにする必要があります。「ダウンタイムなし」は多くの場合、絶対的に解釈されるものではありません。実務上の意味は次のとおりです：ユーザーにとって体感できる中断がないこと、予期しないロールバックが発生しないこと、何時間も続くロックが発生しないこと――そして何よりも、確実に機能するロールバック経路が用意されていることです。

本稿は、ERP環境におけるPostgreSQLの典型的なアップグレード経路を整理します――Blue/Green、レプリケーション（物理・論理）、そして紙の上だけでない復旧計画を含めてです。焦点はあえて運用と意思決定の観点に置いてあります：どのアーキテクチャが必要か、リスクはどこにあるか、どの下準備に時間を要するか。そして、ドライバやジョブチェーン、不明確なデータ所有権といった副次的な要因でアップグレードが頓挫しないようにするにはどうすべきか、という点です。

なぜERPデータベースのアップグレードは特に厄介なのか

ERPシステムはOLTP志向（Online Transaction Processing）、つまり多数の短いトランザクションに最適化されています：仕訳の書込み、在庫移動の計上、価格計算、支払計上など。これらのトランザクションは明確な期待に依存します：レイテンシは安定していること、ロックがエスカレートしないこと、そして負荷ピーク時に予測可能であることが求められます。

PostgreSQLのアップグレードは、アプリケーションが不変であってもまさにその安定性に手を触れることになります。主な原因は次のとおりです：

• クエリオプティマイザの変更（プランナー）：クエリが突然別の実行プランを選択する可能性があります。それ自体が「誤り」ではありませんが、負荷下では新たなホットスポットを生むことがあります。
• パラメータやデフォルトの変更：構成値やそのデフォルト挙動がメジャーバージョン間で変わることがあります。例としてはAutovacuum、WAL（Write-Ahead Log、トランザクションログ）、またはwork_memといった設定が挙げられます。
• ドライバおよびプロトコルの問題：ODBC/JDBC/Npgsqlのバージョン、SSL/TLSパラメータ、認証方式（例：SCRAM対MD5）、証明書チェーンはしばしば思わぬ阻害要因になります。
• インターフェースのエコシステム：ERPはめったに「単一のアプリケーション」だけを意味しません。レポーティング、EDI、Webサービス、ETL/BI、文書管理やバッチ統合がデータベースに直接または間接的にアクセスします。

その結果：アップグレードは単なるデータベース変更ではありません。アプリケーション、運用、周辺システムを跨ぐ調整されたリリース作業です。だからこそBlue/Greenやレプリケーションが有効なのです：技術的な切替を長時間のメンテナンスウィンドウというリスクから切り離すことができます。

目標を明確に定義する：「ダウンタイムなし」は「切替なし」を意味しない

アーキテクチャを選ぶ前に、運用指標に沿った明確な目標設定を行う価値があります：

• RTO（Recovery Time Objective）：障害発生後、ERPデータベースがどれだけ速やかに安定して利用可能でなければならないか？
• RPO（Recovery Point Objective）：最悪ケースでどの程度のデータ（時間の幅）が失われても許容できるか？真のゼロダウンタイム移行ではしばしばRPO≈0を目標とします。
• メンテナンスウィンドウ：切替のための「小さな」ウィンドウ（例：数分）を許容するのか、あるいは全くないのか？ERPでは切替は計画可能であれば通常実行可能です（シフト交替や月次締めなどのタイミングは避けるべきです）。

これらの目標は、レプリケーション＋カットオーバーで対応できるか、あるいは書き込み切り離し（例：インターフェースでのキューイング）のような追加の仕組みが必要かを決定する。ここを曖昧にすると、本番移行（Go-live）時に即席の対応を強いられることになる。

PostgreSQL の Blue/Green：原理、利点、典型的な落とし穴

Blue/Green とは、二つの完全な環境が並存することを意味する。 「Blue」は本番、「Green」は新バージョンである。決定的な利点は単なる切り替え可能性だけでなく、実運用に近い条件でのテスト可能性にある：Green は、ユーザーが切り替える前に、本番に近いデータ、実際のインターフェース、実運用のモニタリングで検証できる。

ERP コンテキストの PostgreSQL における Blue/Green は通常次を含む：

• 新しいホスト/VM または別インスタンス上の分離された PostgreSQL-クラスタ（Green）
• ネットワークおよびセキュリティパラメータの同一化（Firewall、TLS、DNS 解決、Service-Accounts）
• 定義されたデータ移行（初期コピー + 差分）
• カットオーバー機構（DNS-/VIP 切替、接続文字列の切り替え、Proxy）

Blue/Green が運用面で実際にもたらすもの

実務では、差を生むのは次の三点である：

• ロールバックが迅速: 障害発生時は、アップグレードを「元に戻して修復する」よりも、速やかに切り戻すことができる。
• 事前検証によるリスク低減: Green はパフォーマンスおよび機能チェックを受けられ、典型的な ERP 負荷（バッチ実行、印刷、伝票処理のピーク）を含めて検証できる。
• データベースとアプリケーションリスクの明確な分離: Green が稼働していれば、ドライバー、認証、Extensions、パラメータなど多くの不確定要素は既に解消されている。

Blue/Green における典型的な失敗パターン

Blue/Green は概念そのものよりも、細部で失敗することが多い：

• 依存関係の不完全さ: レポーティングツールや統合先が旧ホストに対して（IP、エイリアス、証明書ピンニングなどで）固定的に参照している。カットオーバー時にそれらが動かなくなる。
• インターフェースの所有責任が不明確: すべてのコンシューマが切り替わる、または少なくともテストされるように誰が責任を持つかが明確でない。
• データ検証の欠如: 「データはレプリケートされている」ことは、業務的に全てが正しいことを意味しない（例：シーケンス/ID、タイムスタンプ、副帳ロジック）。

レプリケーションをアップグレード手段として使う：物理レプリケーション vs 論理レプリケーション

ダウンタイムなしでのPostgreSQLアップグレードでは、データを並行して保持するためにリプリケーションが通常主要な仕組みとなります。PostgreSQLはこれに対して異なるトレードオフを持つ複数のアプローチを提供します。重要：『リプリケーション』が自動的に『高可用性』を意味するわけではありません。アップグレードではリプリケーションを 移行ブリッジ として利用します。

Physische Replikation (Streaming Replication): schnell, nah an der Maschine

物理レプリケーションはWALレベルで動作します：スタンバイはトランザクションログを受け取り、それを適用します。これはパフォーマンスと安定性に優れますが、メジャーアップグレードに関しては中心的な制約があります：通常、Primary と Standby は同じメジャーバージョンである必要があります。例えば PostgreSQL 13 から 16 へのバージョンジャンプでは、物理レプリケーションはバージョン内の運用（HA、保守）には有効でも、直接のメジャーアップグレード経路としては適していません。

それでも、物理レプリケーションは Blue システムの安全網として利用することで、実務的なメリットを発揮します：Cutover 前に既存の本番が冗長化されていることを確認しつつ、並行して Green を構築できます。

Logische Replikation: Delta-Übernahme über Publikationen/Subscriptions

論理レプリケーションはテーブル単位の変更（INSERT/UPDATE/DELETE）を転送するため、Publisher と Subscriber が異なるメジャーバージョンであっても（各互換性に留意すれば）メジャーアップグレードに適しています。ERPデータベースでは、最小の切替窓を実現するための現実的な手段であることが多いです。

計画時に考慮すべき典型的な特性：

• Initialer Snapshot + laufende Änderungen：データは初期コピー（スナップショット）され、その後に発生した変更が追随されます。
• DDL ist nicht automatisch dabei：スキーマ変更（DDL、すなわちテーブル／列／インデックス）はデータ変更のようには複製されません。アップグレードではスキーマが概ね同じであることが多いため問題にならないことが多いですが、Extensions、ロール、権限は意図的に移行する必要があります。
• Sequence/Identity-Themen：シーケンス（例：伝票番号）はERPで重要です。セットアップに応じて、シーケンス値が一貫して引き継がれ、Cutover後に正しく継続されることを保証する必要があります。
• Konfliktfreiheit：レプリケーション期間中は一方の側のみで書き込みを行うべきです。そうしないとERP運用で回復が困難な競合が発生します。

Der Upgrade-Pfad in der Praxis: ein belastbares Vorgehensmodell

使用ツールに関わらず、ERP環境でのダウンタイムを最小化したアップグレードは通常明確な段階で進行します。実務的な構成は次の通りです：

1) Voranalyse: Was muss wirklich mit umziehen?

ここでの焦点は「PostgreSQL X をインストールする」ことではなく、依存関係です：

• Extensions（例：全文検索、ジョブ、特殊データ型）：どれが本番で稼働中で、どれが履歴的に存在しているだけか？
• 認証とロール: ローカルロール、LDAP/AD 統合、SCRAM、証明書認証。ロールおよび権限のエクスポートは別個の作業手順です。
• ジョブとバッチ実行: スケジューリングは外部（例：ジョブサーバー経由）で動くのか、それともデータベース内（例：拡張機能経由）で動くのか？どのジョブがカットオーバーにとってクリティカルか（夜間処理、請求処理、MRP）?
• コンシューマー構成: 誰が読み書きするのか？ ERPバックエンド、Webポータル、統合サービス、BI/ETL、パートナー接続、DMS、監視。

シンプルだが有効な成果物はアプリケーションマップです: 中央にデータベース、すべてのシステムへの矢印、そのオーナーと切替手段（DNS、設定、シークレット、プロキシ）を示します。これにより、突然タイムアウトする「忘れられた」リーダーが原因でカットオーバーが失敗するのを防げます。

2) Green aufbauen: nicht nur Datenbank, sondern Betriebsfähigkeit

Green は「運用上本番相当」である場合にのみ意味があります。これに含まれるもの：

• Monitoring (Metriken, Logs, Alarme): Blue と同等の可視性を確保すること。さもなければ本番稼働時に状況が把握できなくなります。
• Backup/RESTore: Green 上のバックアップは機能しなければなりません。リストアテスト（最低でも抜き取りで）を含むことで、障害時に二重に損失を被らないことを確認できます。
• Security-Parität: TLS 設定、暗号スイート、証明書チェーン、HBA ルール (Host-Based Authentication)、ファイアウォール。「後で強化する」は切替時に裏目に出ます。
• Performance-Basis: ストレージレイテンシ、IOPS、CPU、RAM。アップグレードは、不適切なストレージクラスや老朽化した VM プロファイルを修正する好機です。

3) Datenübernahme: initiale Kopie und Delta-Phase

大規模な ERP データベースでは、初期コピーが最も時間のかかる工程であることが多いです。きちんと切り離せばメンテナンスウィンドウ内に行う必要はありません。重要なのはデルタフェーズ（レプリケーション）が安定して稼働し、監視されていることです: 遅延、エラー、保留中の変更。

運用上の重要点: カットオーバーを実行する閾値を定義してください。Green が常に遅れている場合、切替は可能でも問題を本番システムに移してしまいます。

4) Validierung: fachlich und technisch, ohne Perfektionismus

検証は数か月に及ぶテストプロジェクトではありませんが、「SELECT COUNT(*)」以上の作業が必要です。ERP 環境では次のチェックが有効です：

• 重要テーブルの抜き取り検査: 未決項目、在庫残、伝票ヘッダ/行、価格決定テーブル、債権/債務。
• 集計比較: 定義した期間の合計（売上、数量）により大きな差分を素早く確認します。
• 技術的指標: インデックス・統計情報の状態、Autovacuum の活動状況、レプリケーション遅延、接続上限、クエリ遅延。

重要なのは、何が承認に本当に必要かを決めることです。アップグレードは業務リリースではありません。証明すべきは: 同一データ、同一の振る舞い、安定したパフォーマンス。それには信頼でき、再現可能な検証ポイントで十分です。

5) Cutover: der Umschaltmoment muss wie ein Runbook funktionieren

カットオーバー自体は複雑でないことが多いですが、時間制約が厳しいです。良い Runbook は手順だけでなく、チェックポイントと中止基準も記述します。典型的な構成要素：

• 書き込み停止のコントロール: アプリケーションのメンテナンスモード、あるいは技術的なロック（例: 書き込みロールの接続を切る）で実施します。目的: 最終段階で Blue に対する新しい書き込みが発生しないこと。
• レプリケーションを「ゼロ」にする: Green がすべての変更を取り込むまで待つこと（RPO≈0）。
• アプリケーションの切り替え: Connection-Strings、DNS、VIP、プロキシ規則。重要なのは：ERPバックエンドだけでなく、全コンポーネントで一貫していること。
• Smokeテスト: ログイン、マスタデータの表示、伝票の登録、典型的なレポート、インターフェースのPing。短時間で要点を確認できること。

ロールバック計画（Rollback）に幻想は不要：実際に元に戻せる範囲

リカバリ計画は「使いたくない」と思う部分だ。だからこそ具体的でなければならない。Blue/Green構成では、本質的にリカバリはBlueへの切り戻しである。しかし、カットオーバー後にGreenで実際の書き込みが発生すると、その間にBlueが同じ書き込みを受けていなければ「元に戻す」ことが運用上の問題になる。

ロールバックの種類とその影響

• 本番書き込み前の即時ロールバック: 理想的なケース。ユーザー公開前に根本的な問題を検出した場合、データ競合を起こさずに切り戻せる。
• 少数書き込み後のロールバック: 可能ではあるが明確な戦略が必要：手作業で後から帳尻を合わせる（業務的対応）か、一時的な逆レプリケーション／差分取り込み（技術的対応）を行う。ただしERPプロセスではこれが平穏に進むことは稀である。
• ロールバックではなく「Fix forward」: Greenが既に本番書き込みを行い、そこのデータが新たな「Single Source of Truth」になっている場合、切り戻すことは往々にして前方に向けた安定化より危険である。これを事前に選択肢として受け入れておく必要がある。

したがって、信頼できるリカバリ計画は明確に以下を定義する：

• いつまでロールバックが「安全」か（時間ウィンドウまたはRunbook内のフェーズ）
• どのような中止基準が適用されるか（例：Smokeテストの失敗、インターフェース障害、整合しない集計値）
• コミュニケーションと承認の流れ（誰が決定し、誰に通知するか）

ロールバックより重要なのは、インターフェースの「緊急運用」体制である

ERPの環境では、カットオーバー後に慌てる原因としてインターフェースがより頻繁である。パートナー接続や内部の統合サービスが突如応答しなくなった場合に備え、緊急運用が必要だ：中間バッファ（Queues）、再起動ルール、明確なリトライ戦略。リトライは冪等である必要がある（重複登録なしに繰り返せる）。これはデータベースの機能ではなくアプリケーション／統合設計の問題であり、稼働停止なしにアップグレードを達成できるかを左右する。

アップグレード後の性能と安定性：最初の48時間が重要な理由

多くのチームはカットオーバーが終わるとアップグレードを「完了」と見なす。しかし実際には、負荷プロファイル、キャッシュの挙動、Autovacuumが安定するまでのフェーズがこれから始まる。実務で有効だった典型的な対策は次の通りである：

• 最初の48時間における綿密なモニタリング: クエリレイテンシ、ロック、I/O待機時間、WAL量、Autovacuumの実行。
• プラン回帰を検出する：以前は「問題なかった」個別のクエリが、アップグレード後に支配的になることがあります。ここではトップクエリ一覧と、誰がチューニングできるか（DBA vs. アプリケーションチーム）を明確にしたエスカレーションが有効です。
• Reporting/ETLを分離して監視する：読み取り寄りのツールは、長時間実行されるクエリや新しいプランといった問題を最初に引き起こすことが多いです。リードレプリカは助けになりますが、全体設計に適合している必要があります。

IT管理層にとって重要なのは：この安定化をChangesの一部として計画することです。ダウンタイムなしでのアップグレードは「手間がかからない」わけではなく、適切なタイミングと管理されたリスクで行うための工数が必要です。

ERPを中心とした典型的なアーキテクチャ判断：DNS、接続文字列、プロキシ

カットオーバーは、切り替えポイントが明確であればあるほどきれいに行えます。よくあるパターン：

• DNSエイリアス（例：db-erp.prod）：シンプルですが、TTL（Time To Live）とクライアント側キャッシュにより切り替え時間が延びる可能性があります。ドライバーによってはDNSキャッシュが意外にしつこいです。
• 仮想IP／ロードバランサ：技術的には高速に切り替えられますが、明確なヘルスチェック設計がないと不安定な状態へルーティングしてしまいます。
• 接続文字列を設定／シークレットで配る：集中管理された構成配布があれば制御しやすいです。リスクは、全コンポーネントが同時に新しい設定を取得するとは限らない点です。
• DBプロキシ：切り替えを集中化するのに役立ちますが、追加の複雑さと新たなクリティカルサービスをチェーンに導入します。

成長してきたエンタープライズソフトウェアでは、現実的にはミックスになることが多いです：中央サービスは構成で切り替え、「古いコンポーネント」はDNSで対応。重要なのはランブックに記載してテストすることです — 古いアプリサーバ上で「忘れられた」ジョブも含めて。

セキュリティとコンプライアンス：アップグレードは好機だが別問題にしない

PostgreSQLアップグレードは、古い認証方式や過度に緩いロール、あいまいなネットワーク開放などの脆弱性を解消する良い機会です。同時に、セキュリティを無制御にスコープ拡大させてはいけません。

実務的な方針：

• カットオーバー時のセキュリティパリティ：Greenは少なくともBlueと同等の安全性を確保し、可能なら小さく明確な改善を施します（例：TLSのデフォルト設定、MD5の代わりにSCRAM、より厳格なHBAルール）。
• 大規模な改修は後追いにする：ロールのリファクタリング、厳格なネットワーク分割、包括的なシークレットローテーションは有益ですが、安定化後の別個のChangeパッケージとして扱う方が良いです。

工数を現実的に見積もる：プロジェクトが現場で時間を失う場所

計画とコミュニケーションには正直な工数構造が役に立ちます。経験上、時間を消費するのは「PostgreSQLをインストールすること」ではなく、次の点です：

• Consumerのインベントリ：すべての読み手／書き手を特定し、オーナーを明確にし、切り替えルートを定義すること。
• テストデータとテスト環境：本番に近いデータ（データ保護に留意）と現実的な負荷が決定的です。そうでなければ、問題を外したテストをしてしまいます。
• ランブックと承認：メンテナンス窓で誰が何を許可するのか？ ロールバックの判断は誰が行うのか？ 誰が連絡を取るのか？ 明確さがなければ、重要な瞬間に遅延が発生します。
• ドライバー／TLS関連の問題：小さな非互換が大きな症状を生むことがあります（断続的な切断、認証エラー、タイムアウトなど）。

これらの項目を初めから個別の作業パッケージとして扱えば、「アップグレード」は管理可能なプロジェクトになり、緊張した週末作業にはなりません。

結論：PostgreSQLのダウンタイムなしのアップグレードは主に運用設計である

PostgreSQLのアップグレードをダウンタイムなしで達成するには単独のトリックではなく、切替とロールバックを制御可能にするアーキテクチャが必要です。Blue/Greenは必要な分離を提供し、レプリケーションはデータの橋渡しを行い、現実的なロールバック計画によりチームが障害時にデータ損失と数時間に及ぶ停止のどちらかを選ばされる事態を防ぎます。

利用側の環境を正確に棚卸し、Greenを運用可能な環境として構築（モニタリング、バックアップ、セキュリティ）、データ移行を監視し、Cutoverを中止基準付きのRunbookとして演習すれば、バージョン移行は制御された変更になります — 多数のインターフェースを持つ本番ERPデータベースであっても同様です。

ERPデータベースのアップグレードを体系的に準備し、アーキテクチャ、インターフェース、ロールバック計画を併せて検討したい場合は、弊社にご相談ください：

このテーマではBlue/Green DeploymentとCutover-Planも重要です。本稿はこれらの側面を分かりやすく整理し、日常運用で重視すべき点を示します。

プロジェクトまたはモダナイゼーション案件をNet-Baseとご相談ください.