PostgreSQLで災害対策とセキュリティの2大テーマに挑む！運用設計ワーキンググループの活動成果

PostgreSQLを安定稼働させるための技術ノウハウの提供

　近年、ITを活用するシステムは企業の事業や経済活動を支える重要な基盤と言えます。さらに、ソフトウェアやネットワーク技術の発達・低コスト化により、システムの大規模化、複雑化が進んでおり、1つのシステムが複数の企業や地域の経済活動を支えるようになってきています。そのため、故障や災害によるシステムの停止はより広範囲に影響を及ぼす可能性があります。

　今回ご紹介する運用設計ワーキンググループ（運用設計WG）は、2013年度に新たに設立されたグループで、ミッションクリティカル性の高いシステムで必要とされるデータベースの非機能要件に着目し、可用性、バックアップ、監視の観点からPostgreSQLで構築可能なシステム構成の調査と動作検証を行い、PostgreSQLの安定稼働を実現するための技術ノウハウを整理しました。筆者もメンバーの一人として参画し、可用性に関する調査を担当しました。

［2013年度活動報告］https://www.pgecons.org/download/works_2013/

　そして2014年度は、可用性に関し、災害対策を想定したディザスタリカバリ（以下、DR）構成へ検討範囲を拡大して調査を進めました。また、新たなテーマとしてセキュリティを加え、クレジットカード業界のセキュリティ標準であるPayment Card Industry Data Security Standards（以下、PCI DSS）に照らし合わせてPostgreSQLでの対処策をまとめました。順にご紹介していきます。

DRを検討する際の3つの指標

　DRとは、自然災害などで被害を受けたシステムを復旧・修復すること、また、そのための備えとなる機器やシステム、体制のことを指します。DRは、システムを災害から守るだけでなく、故障や災害に起因するトラブルが発生した際に迅速かつ効率よくシステムを復旧するという観点から重要な対策です。しかしながら、ITシステムの復旧にはシステム規模や特性に相応のコストがかかります。そのため、システムごとにサービスの継続レベルをどこに置くのかを定義しておくことが重要です。

　DRは、以下3つの指標をもとに検討します。

• 復旧時間目標　：RTO（Recovery Time Objective）
  故障や災害発生後、システム再開までにどの程度の時間を要するのか
• 復旧時点目標　：RPO（Recovery Point Objective）
  故障や災害発生前のどの時点（ポイント）にシステムを戻すのか
• 復旧レベル目標：RLO（Recovery Level Objective）
  故障や災害発生後、システムの機能や性能の低下をどの程度許容できるのか

　3つの指標には図1のような関係性があります。RPOが「0（ゼロ）」に近くなるほど、データの損失は少なく、RTOが短いほどダウンタイムを短時間に抑えることができ、RLOが高いほど災害発生前の機能および性能に近い状態と言えます。ただし、RPOとRTOを短くし、RLOを高めるには、災害に備えたソリューションや機器に相応のコストがかかるため、費用対効果を十分検討します。