技術を知る：PostgreSQLの災害対策 ～ 地震や豪雨からデータを守る災害対策 ～
PostgreSQLインサイド

地震大国の日本では震災に加えて、近年の異常気象による豪雨災害も多発しています。こうした災害がビジネスに与える脅威と損害は計り知れません。また、情報システムの長期の停止は、ビジネスの損失だけでなく、社会に与える影響も大きいため、遠隔地に災害対策システム（災害対策センター）を構築することがとても重要となっています。

ここでは、PostgreSQLにより、広域災害からデータベースを守る「災害対策」について解説します。

1. 災害対策を考える上で重要な「3つの指標」

災害対策では、「災害からシステム（データ）を守る」ことはもちろんですが、「災害などの不測の事態が起きてもシステムが停止しない」「システムが停止した場合には、効率よく・迅速にシステムを復旧し、いつも通りに稼働させる」という観点から、事業継続計画（BCP：Business Continuity Planning）を策定することが重要です。
業務継続に必要な資産には、ハードウェアやソフトウェアの物的資産、オペレーターやシステム管理者といった人的資産、そして、業務で利用するデータがあります。これらを考慮し、「いつまで（RTO）」、「どの時点まで（RPO）」、「どのレベルまで（RLO）」にシステムを復旧させるのかを考え、目標値を設定します。

例えば、「災害発生後16時間以内に、災害発生1分以内の状態に復旧し、通常の70％程度の人がシステムを利用できるレベルまで復旧させ、業務を再開する」と目標を設定した場合は、以下のようになります。

2. 復旧目標から災害対策を考察

データベースでは、「RTO」、「RPO」、「RLO」の観点で、どのような対策がとれるのか考えてみましょう。
データベースの遠隔地へのデータ転送方式には、「データバックアップ方式」と「レプリケーション（複製）方式」の2つがあります。「データバックアップ方式」は、運用中のデータベースのデータや定義ファイルをバックアップして遠隔地の拠点へ送り、災害時にそのデータを基にデータベースを再構築する方式です。一方、「レプリケーション方式」は、運用中のデータベース（システム）の複製を遠隔地の拠点に用意しておき、双方のデータベースで同じデータを保持することで、災害時には複製に切り替えて業務を継続 / 再開する方式です。

「RTO」は、システム停止やサービス中断が許される時間となります。RTOを短くするには、災害発生後、速やかにシステムの復旧作業に着手し、完了させることがポイントとなります。システムの復旧作業にかかる時間は、「データバックアップ方式」を採用しているか、「レプリケーション方式」を採用しているかで、大きく異なります。
「RPO」は、災害発生直前に戻すのか、何分前・何時間前の状態に戻すのかなど、どの時点まで復旧するのか、となります。例えば、金融機関で扱う数字データは最新性が重要なため、災害発生直前に戻す必要があります。この場合、データの更新に応じてバックアップを行う必要があるため、「レプリケーション方式」が適しています。逆に、更新頻度の低いデータや参照系システムのデータの場合は、損失するデータとコストの観点から、「データバックアップ方式」が適しています。
「RLO」は、サービスの範囲（レベル）、応答時間、接続数などを、いつまで（RTO）に、どのレベルに復旧したら業務を再開させるかの指標です。例えば、「災害発生後16時間以内に、通常の70%程度の人がシステムを利用できるレベルまで復旧させ、業務を再開する」などの目標値です。RLOはRTOと合わせて決定する必要があります。

災害に備えRTOとRPOをより高い目標値に設定する場合、システムが継続して稼働できるよう、システムを高可用構成にすることが重要です。高可用構成にするには、運用センター側のハードウェア・ソフトウェア、災害対策センター側のハードウェア・ソフトウェア、また、それらを繋ぐネットワークの冗長化が必要になります。冗長化することにより、設備コストや構築 / 運用 / メンテナンスなどの人的コストがかかります。
そのため、RTO、RPOの設定で重要なことは、業務に応じた目標値を設定し、十分な事前設計をすることです。すべての目標値を高く設定することは理想ですが、コストが高くなりすぎないように、何を最優先とするか検討し、それぞれの目標値を設定し、それに適した災害対策システムを考えてください。

3. データバックアップ方式による災害対策

「データバックアップ方式」は、定期的にデータベースのバックアップを取得し、遠隔地の拠点へ送る方法です。
運用サーバーで定期的にデータを外部メディア（DVDやカートリッジテープなど）にバックアップし、それを遠隔地に輸送して保管することで、災害復旧時には、バックアップデータ取得時点にまで復旧することができます。また、データベースのバックアップファイルをそのまま遠隔地にデータ転送することで、バックアップデータ取得時点にまで復旧することができます。
バックアップした時点から、次回のバックアップまでの更新データは保持していないため、システムによってはデータの損失は多くなります。また、災害復旧時はデータベース全体をリストアするため、復旧時間が長くなります。しかし、通常実施するバックアップをそのまま災害対策にも生かせるため、災害対策を簡単に始められます。

データバックアップ方式をPostgreSQLで実現するには、バックアップ・リカバリー機能を利用します。PostgreSQLの標準機能を利用するため、別途、災害対策用のソフトウェアを用意する必要はありません。バックアップ・リカバリー機能の詳細については、「技術を知る：PostgreSQLのバックアップとリカバリー」を参照してください。

4. レプリケーション方式による災害対策

「レプリケーション方式」は、運用センターのデータベースの更新ログを、災害対策センターのデータベースに反映する方法です。
データベース（システム）の複製を作成するため、常に双方のデータベースで同じデータを保持することができます。随時、更新ログを転送・反映しているため、災害時のデータの損失は少なく済みます。また、災害復旧時は、センターを切り替えるだけで業務を継続することができます。しかし、運用センターまたは災害対策センターで常時稼働するためのハードウェアが追加で必要となり、コストが高くなります。また、システム構築、運用手順、監視、トラブル対応の手順が複雑になるため、災害対策の運用を開始するまでに多くの時間が必要となります。
レプリケーション方式で実現可能な災害対策の構成には、以下の3つがあります。災害発生後や障害発生後の信頼性、ハードウェアや人的コストの観点から、適した構成を選択してください。

レプリケーション方式をPostgreSQLで実現するには、ストリーミングレプリケーション機能を利用します。PostgreSQLの標準機能を利用するため、別途、災害対策用のソフトウェアを用意する必要はありません。
ストリーミングレプリケーション機能は、データベース全体をレプリケーション（複製）するので、簡単かつシンプルに複製を作成することができます。また、ストリーミングレプリケーション機能は「同期」と「非同期」を選択することができ、例えば、運用センター内の冗長化には「同期」を、災害対策センターとのレプリケーションには「非同期」を、とストリーミングレプリケーション機能だけで対応することができます。

FUJITSU Software Enterprise Postgresでより安全な災害対策を実現

PostgreSQLのストリーミングレプリケーション機能で運用センターを高可用構成にした場合、運用センターのプライマリーサーバーからスタンバイサーバーにログを同期する一方で、災害対策センターのスタンバイサーバー（プライマリー候補サーバー）に非同期でログを送信します。この2つが連動していないため、ネットワークやサーバーの負荷の関係で、運用センターのスタンバイサーバーへのログ送信が遅延した場合、災害対策センターへのログ送信が先行してしまう可能性があります。このような状況下で、運用センターのプライマリーサーバーで障害が発生し、スタンバイサーバーに切り替えを行うと、災害対策センターへのログ送信を停止し、災害対策センターを運用センターのプライマリーサーバーと同等の状態に巻き戻さなければなりません。災害対策センターが停止すること自体が好ましくないうえに、この巻き戻し中に災害が発生した場合、せっかく用意した災害対策センターを即時活用できないという課題があります。
FUJITSU Software Enterprise Postgres（以降、Enterprise Postgresと略します）は、PostgreSQLのストリーミングレプリケーション機能による災害対策センターへのログ送信が先行しないよう、運用センターのスタンバイサーバーへのログ送信が完了したあと、災害対策センターへログを送信します。運用センターのスタンバイサーバーへのログ送信と災害対策センターへのログ送信の順序性を保証することにより、災害対策センターの運用一時停止や巻き戻し作業が不要となります。別途、Enterprise Postgresを用意する必要はありますが、ログ送信の順序性を保証することで、常時から信頼性を高めることができます。

ここではPostgreSQLとEnterprise Postgresの災害対策を解説しました。PostgreSQLのストリーミングレプリケーション機能やEnterprise Postgresを活用し、地震や豪雨からデータを守る災害対策を検討してください。

2019年2月4日公開

こちらもおすすめ

• ストリーミングレプリケーション ～ 仕組み、構成のポイント ～
• ストリーミングレプリケーション ～ 運用のための機能 ～
• Pgpool-IIで高可用なシステム構成を考える
• 技術者に聞く：PostgreSQLの災害対策 ～ 災害への備えは万全に! ログの順序性保証で確実なレプリケーション ～
• 富士通の技術者に聞く!PostgreSQL最新技術 WALが損失するという課題の解決

本コンテンツに関するお問い合わせ