2026 年 4 月、SaaS プラットフォーム PocketOS は前例のない「技術的ブラックスワン」に見舞われました。社内で用いていた AI コーディングエージェントがエラー自動修復を試みた際、意図せずグローバル最高権限の API を呼び出し、わずか 9 秒で本番環境のデータベース全体を消去してしまいました。さらに致命的だったのは、バックアップデータがプライマリデータベース（本番 DB）と同一ボリューム上に置かれていたため、直近のバックアップもろとも失われたことです。

この出来事は、すべての技術チームにとっての警鐘となります。高度に自動化されたいま、破壊はミリ秒単位で発生しうる一方で、そのタイミングは完全には予測できません。本番環境で稼働するゲートウェイシステムにとって、データセキュリティは後回しにされがちですが、最も軽視してはならない要素の一つです。OpenResty Edge は、トラフィックルーティングルール、セキュリティポリシー、アプリケーション設定をデータベースに一元的に保存します。これらはチームが長年にわたり蓄積した運用資産であり、業務システム側から逆算して完全には再構築できません。データベースが不可逆な損傷を受けた場合、ゲートウェイのルールをゼロから組み立て直すことになります。

OpenResty Edge はこのリスクに対し、最も基礎的な定期バックアップからフル自動フェイルオーバーまで、三層のデータ保護機能を提供します。三層は相互に補完し合い、ビジネス上の可用性要件に応じて、自社に適した保護の組み合わせを選べます。

OpenResty Edge の試用を申請する

第一の防衛線：定期バックアップと異機間同期

すべてのデプロイメントで設定すべき基礎的な保護策です。OpenResty Edge では、Edge Admin DB（すべてのアプリケーション設定情報を保持するコアデータベース）と Edge Log Server DB（ログおよび統計指標データを保持するデータベース）という二つのコア DB 向けに、専用バックアップスクリプトを提供しています。スクリプトは手動実行できるほか、crontab により定時ジョブとして登録し、無人での定期バックアップにも対応できます。

ストレージ戦略として、バックアップファイルはローカルの指定ディレクトリへ書き出せるほか、rsync によるリモートマシンへの自動同期にも対応しています。実務上、特に次の二点に注目したいところです。

  • 第一に、ローカルのバックアップ先はデータベースと別物理ディスクに置くこと。そうでなければディスク障害でオンラインデータベースとバックアップファイルを同時に失います。
  • 第二に、リモート同期の有効化を強く推奨します。ローカルファイルのみでは消失リスクが残り、別ホストへ退避して初めて真の分離が実現します。

スクリプトにはバックアップ世代のローテーション機構が組み込まれており、保持する世代数をパラメータで制御でき、上限を超えた古いファイルは自動的に削除され、ディスク占有の無制限な肥大化を防ぎます。

復旧が必要な場合の流れは、バックアップを展開し、psql で SQL をインポートしてフルリストアを行うことです。具体的な手順は公式技術ドキュメントを参照してください。

率直に申し上げると、定期バックアップには固有の時間的ギャップがあります。二回のバックアップのあいだに発生したデータ変更はこの方式では取り戻せず、リストアの際には通常ダウンタイムを要します。この方式の限界が、次の防衛層を導入する理由となります。

第二の防衛線：主系・従系ストリーミングレプリケーション

サービス継続性に明確な要件がある場合、定期バックアップのみでは不十分です。主従ストリーミングレプリケーションは、その上に障害復旧能力をさらに高い水準へ引き上げます。

この方式は PostgreSQL ネイティブの streaming replication を用い、一主一従（Master–Standby）アーキテクチャを構築します。スタンバイ（従系）はプライマリ（主系）のデータ変更をほぼリアルタイムで追従し、プライマリ障害時にはスタンバイを新たなプライマリへ昇格させ、読み書き要求を引き継げます。フルバックアップからのリストアと比べ、切り替えは数分程度で完了することが多いです。

OpenResty Edge には対話型セットアップスクリプトが用意されており、複数の PostgreSQL 設定ファイルを手作業で編集して主従を立ち上げる手順を、ノードアドレス・データディレクトリ・レプリケーション用ユーザー情報などを順に入力する質疑応答形式へ置き換えます。スクリプトが設定適用とサービス再起動まで自動で行います。設定後は、pg_stat_replication ビューを照会し、レプリケーションが正常に張れているか検証できます。

明確にしておきたいのは、主従レプリケーションは定期バックアップの代替にはならないという点です。ストリーミングレプリケーションは誤操作を含むあらゆるデータ変更をスタンバイへ伝播するため、任意の過去時点へロールバックすることはできません。一方、定期バックアップは複数の歴史的スナップショットを残します。両者が解く課題の次元は異なるため、併用が前提です。

この方式の制約は、フェイルオーバーに人的介入が必要で、昇格後はアプリケーション側のデータベース接続情報を手作業で更新しなければならない点です。人的負荷をさらに下げたい場合には、第三層の仕組みがより包括的な答えとなります。

第三の防衛線：自動フェイルオーバークラスター

可用性要件が最も厳しいミッションクリティカル環境向けに、OpenResty Edge は高可用データベースクラスタ管理ツールを提供し、障害復旧を自動化フェーズへ進めます。

この方式は主従アーキテクチャに加え、独立した監視ノードを導入します。監視ノードはデータノードのヘルスを継続的にモニタし、プライマリ障害時にはスタンバイを自動昇格させ、フェイルオーバーに人手を要しません。クラスタは監視ノード 1 台と、データノードを二台以上（一主一従または一主多従）で構成します。

01

ノードのインストール、起動・停止、ステータス参照、HBA 設定管理、監視ノードの切り替えといったクラスタ操作は、すべて CLI ツール openresty-edge-db-cluster-manager.sh から実行します。ツールのドキュメントには、監視ノードのみ故障しデータノードは正常な場合、監視ノードとスタンバイが同時故障した場合、監視ノードとプライマリが同時故障した場合など、複数の現実的な障害シナリオごとのオペレーション手順が明示され、それぞれに対応する復旧ステップが示されています。

リソース面では監視ノード専用のサーバーが必要であり、ノード間はすべてネットワーク疎通が必須です。各ノードのハードウェア要件（メモリ、ディスクなど）についても文書に最低ラインが記されており、導入前に照合すべきです。

なお、自動化スクリプト向けに対話確認をスキップする -y オプションがありますが、ドキュメントは注意喚起しています。この指定は破壊的操作を含むすべての確認に自動で応答するため、利用には十分な配慮が必要です。

三層の比較と選定の指針

前文で述べたデータベース全消去の事例を踏まえると、次の点が明確になります。主従レプリケーションと自動フェイルオーバークラスター（ホットスタンバイ）は、ハードウェア障害には強く、ビジネスの高可用性を支えられますが、「誤操作」や「悪意ある破壊」には対処できません。DROP DATABASE のような破壊的な SQL は瞬時に伝播し、プライマリとスタンバイが同時に失われます。

したがって、定期バックアップ（コールドバックアップ）は、いかなる高可用アーキテクチャにも代替し得ない絶対的な下限です。下表では、主要な観点から三者を比較します。

比較項目定期バックアップ主従構成（ストリーミングレプリケーション）自動フェイルオーバークラスター
主な保護目的データ損失の防止と履歴の復元単一障害点（SPOF）に起因するサービス停止の回避障害復旧における手動介入の排除
復旧速度時間単位（フルリストア）分単位（手動切り替え）自動切り替え
意図しない削除からのデータ復旧過去のバックアップによる復元が可能（バックアップ間隔に依存）ホットスタンバイ構成では削除操作も同期されるため、これ単体での復旧は不可主従構成と同様：誤った削除も同期されるため、過去のバックアップが必須
フェイルオーバー方式手動手動自動
追加リソースディスク容量 + リモートサーバースレーブサーバー 1 台監視ノード + 1 台以上のスレーブサーバー
運用上の複雑さ低中中〜高
推奨環境全ての環境（必須）サービス継続性が求められる本番環境可用性要件が最も厳しい基幹業務

選定の指針： 第一層は、OpenResty Edge のデプロイ規模を問わず必須の選択肢です。第二層は本番環境すべてへの導入を推奨します。第三層は、復旧所要時間や人的介入に厳しい要件を持つミッションクリティカルな業務シナリオに適合します。リソースと体制が許すかぎり三層を併用すれば、データ保護のカバレッジは最も広く取れます。

まとめ

データベースバックアップは、運用体制の成熟度を測る基本的な指標の一つであり、その設定コストはデータ損失後の復旧コストをはるかに下回ります。前述の PocketOS におけるデータベース削除インシデントが示すように、最大の教訓は、プライマリデータベースが破壊されたことだけでなく、むしろ「バックアップデータと本番環境が同一の障害範囲（ブラスト・ラディウス）内にあった」ことにより、セキュリティの防御線が完全に崩壊した点にあります。そのため、OpenResty Edge の本番環境では、以下の点を運用規範に盛り込むことを推奨します。

  • Edge Admin DB と Edge Log Server DB の両方で、定期的なバックアップを設定すること。
  • ローカルのバックアップディレクトリとデータベースディレクトリには、それぞれ異なる物理ハードディスクを使用し、物理的な単一障害点を排除すること。
  • 同時にリモート同期も設定し、バックアップファイルのオフサイトコピーを確保すること（同一ボリュームやデータセンターの同時障害による全滅を回避するため）。
  • バックアップタスクの実行ステータスとファイルの完全性を定期的にチェックすること。
  • 非本番環境で、定期的に復旧プロセスの演習を実施すること。

参考ドキュメント

データベースのバックアップ設定については、以下の公式ドキュメントをご参照ください。

データベースの高可用性（HA）設定についても併せて確認する場合は、以下をご参照ください。

OpenResty Edge の試用を申請する

OpenResty Edge について

OpenResty Edge は、マイクロサービスと分散トラフィックアーキテクチャ向けに設計された統合型ゲートウェイソフトウェアで、当社が独自開発しました。トラフィック管理、プライベート CDN 構築、API ゲートウェイ、セキュリティ対策などを一つにまとめ、現代のアプリケーションの構築・運用・保護を支援します。OpenResty Edge は業界トップクラスの性能とスケーラビリティを備え、高同時接続・高負荷下の要求に応えます。Kubernetes などコンテナ化されたアプリケーショントラフィックのスケジューリングにも対応し、大規模なドメイン運用を支え、大規模ウェブサイトや複雑な業務アプリケーションの要件に応えられます。

著者について

章亦春（Zhang Yichun）は、オープンソース OpenResty® プロジェクトの創始者であり、OpenResty Inc. の CEO 兼創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省出身で、現在は米国サンフランシスコ・ベイエリア在住です。中国における初期のオープンソース技術と文化の提唱者・リーダーの一人であり、Cloudflare、Yahoo!、Alibaba などの国際的ハイテク企業に勤務した経歴を持ちます。「エッジコンピューティング」「動的トレーシング」「マシンプログラミング」の先駆者として知られ、プログラミング歴 22 年超、オープンソース活動歴 16 年超です。世界 4000 万以上のドメインで採用されるオープンソースのリーダーとして、OpenResty® を基盤に米国シリコンバレー中心部へ OpenResty Inc. を創設しました。主力製品は、OpenResty XRay（動的トレーシング技術に基づく非侵襲的プロファイリング・トラブルシューティングツール）と OpenResty Edge（マイクロサービスおよび分散トラフィック向けの統合ゲートウェイソフトウェア）で、国内外の上場企業および大企業に広く採用されています。OpenResty 以外にも、Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl などへ累計 100 万行超のコードを寄与し、60 を超えるオープンソースソフトウェアライブラリを公開してきました。

翻訳

英語版（English）、中国語版（中文）、および本日本語訳をご用意しています。他言語への全文翻訳のご提供も歓迎します。省略のない全文翻訳であれば、採用を検討いたします。深くお礼申し上げます。