「PostgreSQLエンタープライズ・コンソーシアム」（PGEC）の活動報告会のレポート、第4回は、設計運用ワーキンググループによるディザスタリカバリーとセキュリティ項目調査の結果を紹介する。
2014年度の設計運用ワーキンググループは可用性とセキュリティの2テーマで活動した。可用性は2013年度から取り組んでおり、2013年度はHA（High Availability）クラスターやレプリケーションの特徴を整理して実機で検証した。
2014年度は災害対策を想定しPostgreSQLの機能を用いたディザスタリカバリー（DR）を実機検証した。ディザスタリカバリーは、関心が高いもののPGECとしては未検証の分野であった。セキュリティは新規テーマで、クレジットカード情報を保護する世界基準であるPCI DSS（Payment Card Industry Data Security Standard）準拠のための対処策をまとめた。
災害対策のためのストリーミングレプリケーション検証
可用性について発表したのはTIS IT基盤技術本部 IT基盤技術推進部 OSS推進室 主査の中西剛紀氏（写真1）。中西氏は「DRのサービスレベルは高ければよいとは限らない。災害発生時にITシステムをどのレベルで継続するのか、事前に検討しておくことがポイント」と話す。災害は起こるか分からない。目標レベルを定めてから計画する必要がある。
中西氏は、DRを検討するに当たり主要な目標が三つあるとした。災害発生からサービス再開までの「復旧時間目標」（RTO：Recovery Time Objective）、どの時点のデータに戻すかの「復旧時点目標」（RPO：Recovery Point Objective）、機能や性能の低下を許容するレベルとなる「復旧レベル目標」（RLO：Recovery Level Objective）だ。
ワーキンググループは、「DR要件を実現するPostgreSQLの代表的なシステム構成」として9パターンを挙げた（図1）。データ保全までの構成と、サービス継続までする構成でまず大きく分け、PostgreSQLを単体で動かす「シングル」、待機サーバーを設けておく「Active-Standby」、待機サーバーで別のクエリーなどを実行することで稼働率を高める「Active-Active」でさらに分類した。RTOやRPOに優れている方式は、障害復旧の面では良いがコストが高くなったり運用の複雑さが増す。構築期間も長くなる傾向にある。
ワーキンググループはその中で、RTOやRPOが短い半面、システムとしては複雑になる「構成7」と「構成9」で実機検証した。いずれもActive-Activeの構成で、PostgreSQLの機能の一つである「ストリーミングレプリケーション」を利用する。ストリーミングレプリケーションは、マスターからスタンバイ側にトランザクションログを転送し、ログを基にスタンバイ側のPostgreSQLがデータを複製する仕組みだ。
