TOP>企業情報>コラム>技術情報>PGEConsのドキュメントからPostgreSQLの「今」を知る! Vol.2

PGEConsのドキュメントからPostgreSQLの「今」を知る! Vol.2

エンタープライズ領域でのPostgreSQLの普及促進を目指して設立されたPostgreSQLエンタープライズ・コンソーシアム(略称:PGECons)。本連載では、3年目となった2014年度の活動を通じて新たに提示された性能、移行、設計運用に関する数百ページにわたるドキュメントを項目ごとに分かりやすく要約していきます。2回目となる今回は災害対策、セキュリティに焦点を当てご紹介します。

Vol.2 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を高めるには、災害に備えたソリューションや機器に相応のコストがかかるため、費用対効果を十分検討します。

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

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

DR要件を満たすPostgreSQLの代表的なシステム構成


災害などによって発生する障害に備えたシステム構成を「データ保全」および「サービス継続」の観点で考えた場合、PostgreSQLでは代表的な構成として9種類があります。図2の表はシングルやアクティブ・スタンバイなど構成パターンをはじめ、前述の3つの指標や運用性、構築期間など複数の視点をもとに分類されています。

図2:DR要件を満たすPostgreSQLの代表的なシステム構成

図2:DR要件を満たすPostgreSQLの代表的なシステム構成

成果ドキュメントでは、すべての種類の特徴およびメリット、デメリットがまとめられていますが、本記事ではPostgreSQLの標準レプリケーション機能「ストリーミング・レプリケーション」を利用し、RTO、RPOの高い構成である「構成7」と「構成9」において実機での検証結果も交えてご紹介します。

※PostgreSQLの代表的な構成の詳細は「2014年度WG3報告 -可用性編-」p7-p17をご参照ください。
https://www.pgecons.org/downloads/99

ストリーミング・レプリケーションを利用した柔軟なDR構成


PostgreSQL 9.0で実装された「ストリーミング・レプリケーション」は、変更履歴が格納されたWALを操作単位でマスタデータベースからスタンバイデータベースへ転送することにより可用性を実現する仕組みです。スタンバイを参照系データベースとして活用できるため、参照処理を分散しマスタの負荷を低減することができます。

構築可能な構成として、図3にあるようにメインサイトとDRサイトそれぞれにスタンバイデータベースを配置したマルチスタンバイ構成とメインサイトのスタンバイデータベース、DRサイトのスタンバイデータベースによるカスケード構成があります。

いずれの構成もメインサイトにスタンバイデータベースの1つを配置し、同期モードでWALの転送を行うことにより、データの鮮度を保ち、マスタデータベースの障害から迅速な復旧が可能になります。DRサイトに配置するスタンバイデータベースは、マルチスタンバイ構成ではマスタデータベースから、カスケード構成ではメインサイトのスタンバイデータベースからWALの転送を行います。いずれの構成もDRサイトのスタンバイデータベースは常時稼働しているため、メインサイトの障害からの復旧時間もかなり短縮でき、さらにデータ同期性も高く、DRサイトのRTO、RPOともに高いレベルが維持できる構成と言えます。

図3:ストリーミング・レプリケーションによるDR構成

図3:ストリーミング・レプリケーションによるDR構成

構成ごとの障害復旧の違い


マスタ1台とスタンバイ1台の計2台でのストリーミング・レプリケーションによる可用性構成は一般的になりつつあるものの、3台以上のマルチスタンバイ構成やカスケード構成の構築や障害発生時の復旧手順などの技術情報が少ないのが現状です。そこで、運用設計WGでは実機での検証を行い、情報を整理しました。

本記事では、障害からの復旧手順をご紹介します。尚、障害は図4にあるように①マスタデータベース、②メインサイトのスタンバイデータベース、③メインサイト全体の3つのパターンを想定しています。構築は、コマンドレベルの詳細な手順を成果ドキュメントで紹介していますので、ぜひご参照ください。

※レプリケーション環境の構築手順と障害復旧手順の詳細は「2014年度WG3報告 -可用性編-」p18-p43をご参照ください。
https://www.pgecons.org/downloads/99

図4:障害検証のパターン

図4:障害検証のパターン

①マスタデータベースに障害が発生

マスタデータベースに障害が発生した場合、手動でメインサイトのスタンバイデータベースをマスタに昇格させ、クライアントからの更新先を変更することでサービスを復旧します。尚、レプリケーションの再構成には、マルチスタンバイ構成ではDRサイトの設定ファイルを書き換え、データベースの再起動が必要ですが、カスケード構成では対処は不要で、自動で再構成が行われます。

②メインサイトのスタンバイデータベースに障害が発生

マスタデータベースは正常に稼働しているため、サービス復旧の対処は必要ありません。しかし、カスケード構成ではDRサイトのスタンバイデータベースへレプリケーションができなくなるため、レプリケーションの再構成には、DRサイトの設定ファイルを書き換え、データベースの再起動が必要です。

③メインサイト全体に障害が発生

メインサイト全体が停止した場合、DRサイトのスタンバイデータベースを手動でマスタに昇格させ、クライアントからの更新先を変更することでサービスを復旧します。

性能、運用面で押さえておくべきポイント


ストリーミング・レプリケーションを利用したDR構成で、性能と運用面で考慮すべき基本的なポイントとして、それぞれ以下があります。

  • レプリケーション方式による性能特性の違い(性能)
  • レプリケーション遅延(運用)

今回、図5のようにAmazon Web Service(以下、AWS)を利用してメインサイトを東京、DRサイトをシンガポールに配置した構成を用意し、構成による動作や対処の違いを検証しました。

図5:AWSを利用したDR構成

図5:AWSを利用したDR構成

まず、レプリケーション方式による性能特性ですが、マルチスタンバイ構成とカスケード構成の主な違いは、マスタに直接紐付くスタンバイの数です。マスタから直接WALを転送するスタンバイの数が多くなればなるほど、マスタの負荷は高くなります。今回の検証では、各構成のマスタデータベースに対してpgbenchを利用して大量のトランザクションを実行した際の1秒間あたりのトランザクション数を比較しましたが、2つの構成で大きな性能差はみられませんでした。詳細な数値は成果ドキュメントを参照いただきたいと思いますが、スタンバイが1~2台という構成であればマスタ側の処理に大きな影響はないと言えます。

ストリーミング・レプリケーションは、マスタからスタンバイへWALを転送し、スタンバイで順次適用することで可用性を実現しています。この特性上、スタンバイが遠隔地にある場合、ネットワーク性能がネックとなりレプリケーション遅延が発生する可能性があります。検証ではマルチスタンバイ構成で大量の更新処理を継続的に実行し、メインサイトとDRサイトそれぞれのスタンバイデータベースで未適用のWALサイズがどの程度になるかを測定しました。その結果、DRサイトのスタンバイは時間の経過に伴い、メインサイトと比較して最大6倍にも増加する結果となりました。図6でDRサイトのスタンバイデータベースの値を示す赤色の折れ線グラフが途切れていますが、この時点でWALの転送そのものが停止するという状態に陥りました。

図6:スタンバイデータベースの未適用のWALサイズ

図6:スタンバイデータベースの未適用のWALサイズ

WALの転送が停止したのは、マスタの更新処理によって未転送のWALが転送前に削除されたためです。これを防ぐにはいくつか手法があります。1つ目はマスタのアーカイブファイルを転送する方法です。ストリーミング・レプリケーションでは、一般的に構築時にマスタのアーカイブファイルをコピーするコマンドの設定も行うため、レプリケーション停止を検知したタイミングでアーカイブファイルの転送に切り替わります。しかし遠隔地への場合、転送に時間を要する可能性が高いため、常時アーカイブファイルを転送する仕組みを個別に組み込むことでレプリケーションの停止時間を大幅に短縮することができます。

2つ目は、wal_keep_segmentsパラメータを設定し、WALを確保する方法です。この場合はWALの要不要にかかわらず、設定された個数分のWALが確保され続けるため、ディスク容量を考慮する必要があります。今回の検証では、PostgreSQL 9.4の環境でwal_keep_segmentsパラメータの効果を確認しましたが、9.4にはレプリケーション・スロットと呼ばれる新機能が実装されており、これを利用してレプリケーション環境を構築するとスタンバイのレプリケーション情報がマスタで管理され、未適用のWALが自動的に保持されるようになります。

ストリーミング・レプリケーションを利用したDRサイトの構築自体はそれほど難しくはありません。しかし、運用面では構成に応じてリカバリ手順を確立する、また遠隔地へのWAL転送を円滑に行う工夫が必要です。災害対策としてストリーミング・レプリケーションを利用したDRサイトの構築を検討の際は、成果ドキュメントをぜひ参考にしてください。

※レプリケーションの性能面、運用面でのポイントは「2014年度WG3報告 -可用性編-」p44-p61をご参照ください。
https://www.pgecons.org/downloads/99

PostgreSQLで対応可能なセキュリティ要件


昨今、顧客情報などの機密情報の漏えい事件が数多く起きており、社会全体として情報システムへの頑強なセキュリティ対策が必要とされています。特にデータを格納するデータベースへのセキュリティ対策は必須要件となっています。

PostgreSQLがエンタープライズ領域のシステムに適応できる性能や拡張性を備えていることは、これまでの調査や検証で広く知られているところですが、セキュリティ要件への対応範囲の情報は少なく、PostgreSQLの採用判断が難しいケースがあります。

そこで今回、クレジットカード業界のセキュリティ標準であるPCI DSSの要件をPostgreSQLがどの程度満たしているかを整理しました。PCI DSSでデータベースに求められる要件は、「アクセス制御」「監査」「暗号化」の3つのカテゴリに分けられます。運用設計WGで選定した90個にのぼる項目に対してPostgreSQLで実現できる手法や方針を整理し、半数以上はPostgreSQLの標準機能で対応が可能であることがわかりました。また、残りの項目も外部ツールやOS機能と組み合わせることで実現できるものが多くあり、成果ドキュメントではこれらの具体的な対応策が提示されています。今回は、その中から以下3つの機能をご紹介します。

※PCI DSSへのPostgreSQL対応調査の詳細は「2014年度WG3報告 -セキュリティ編-」p9-p81をご参照ください。
https://www.pgecons.org/downloads/101

  • アカウントポリシーの設定(アクセス制御)
  • SQLの監査証跡(監査)
  • 格納データの暗号化(暗号化)

アカウントポリシーの設定


セキュリティ対策の基本は、アクセス制御とユーザの権限管理です。PCI DSSでは、データベースへアクセスするユーザアカウントに関して「最初の接続時にパスワードを変更」「パスワードには英数字を含む」といった様々な要件が定義されています。PostgreSQLでは標準でアカウントポリシー機能が備わっていないため、要件を満たすにはLDAP、GSSAPI、SSPI、RADIUS、PAMなどで外部認証サーバを組み合わせます。

一般的に広く使われているLDAPと組み合わせる場合、図7にあるようにオープンソースのLDAPサーバであるOpenLDAPを利用してLDAPディレクトリの「ou=dbusers,dc=example,dc=com」以下にPostgreSQL用のユーザアカウントのエントリを配置します。

図7:LDAPによるアカウントポリシーの設定例

図7:LDAPによるアカウントポリシーの設定例

LDAPを利用する場合は、ソースからPostgreSQLを導入する際にconfigureで-with-ldapオプションを指定してビルドします。尚、RedHat Enterprise LinuxのRPMパッケージは-with-ldap付きでビルドされています。また、LDAP認証を使用したデータベースへの接続にはpg_hba.confの認証メソッドとオプションに以下のように記述します。


上記の設定により、PostgreSQLへの接続時にLDAPサーバに設定されたエントリに対してパスワード認証が行われるようになります。パスワードは LDAPサーバ側で保持されているエントリごとのパスワードが使われます。尚、OpenLDAP側での設定も必要です。設定例は成果ドキュメントをご参照ください。

※アカウントポリシー設定の詳細は「2014年度WG3報告 -セキュリティ編-」p22-p26をご参照ください。
https://www.pgecons.org/downloads/101

SQLの監査証跡


不正な操作が万が一発生した際、それが不正なのかどうかを見分けるにはデータベースへのアクセス履歴やSQL文の実行履歴などを記録しておく必要があります。それが監査ログです。

PostgreSQLではlog_statementパラメータを設定することでSQLの監査ログを出力することができますが、DDL文、DML文またはすべてのSQL文の3パターンに限定されており、例えばSELECT文のみを対象とすることはできません。

PostgreSQLの周辺ツールとして提供されているpgauditを利用することで、SELECT文やCOPY TOなどの参照系のSQL文に加え、GRANT、REVOKEなどアクセス権限のSQL文、ファンクションとファンクション内で実行されたSQL文を対象とするなど、細かい指定が可能になります。pgauditはgithubから別途ダウンロードしインストールします。

例えば、SELECTとUPDATEを含むファンクションを対象とした場合、サーバログには以下のようにファンクションの情報(①)とあわせて、ファンクション内で実行された情報(②と③)が出力されます。


※ファンクションのサンプルは以下のとおりです。


※pgauditによる監査の詳細は「2014年度WG3報告 -セキュリティ編-」p27-p29をご参照ください。
https://www.pgecons.org/downloads/101

※監査情報を専用ログで管理できるPostgres Plus

弊社アシストの取扱製品である「Postgres Plus Enterprise Edition」(以下、PPEE)はPostgreSQLをエンジンとし、パフォーマンス、セキュリティ、GUIツールなどPostgreSQLに未実装のエンタープライズ向け機能を補完したRDBMSで、監査情報を個別ログで管理する仕組みが実装されています。通常運用時の情報と監査情報がサーバログへ混在して出力されるPostgreSQLに対して、PPEEでは監査情報の管理と追跡が容易に実施できます。また、サイズや日時を元にファイルのローテーションが簡単にできるため、ローテーション後はファイルのアクセス権限を変更し、ログの改ざんを防止するといった運用も可能です。

PPEEの監査ログ出力機能は「2014年度WG3報告 -セキュリティ編-」p30をご参照ください。
https://www.pgecons.org/downloads/101


格納データの暗号化


データベースに格納された機密データを暗号化することは、データファイルが流出したとしても、内容が解析されることを防ぐ有効な手段です。PostgreSQLではcontribのpgcryptoモジュールを利用することで特定のテーブルや列を暗号化することができます。

pgcryptoモジュールをインストール後、CREATE EXTENSIONコマンドで対象データベースに対して有効にします。


暗号化、復号するためのキーペアを生成後、それらを管理するテーブルを作成し、挿入します。データを暗号化するには、pgp_pub_encrypto関数を使用します。引数には挿入データ、公開鍵を指定します。鍵はASCII-Armor形式になっているため、dearmor関数を利用して利用可能にします。挿入したデータは暗号化されたバイナリ形式の値になります。


暗号化データの復号にはpgp_pub_decrypto関数を使用します。引数には対象データ、秘密鍵、秘密鍵のパスワードを指定します。この時、鍵を管理するテーブルから副問い合わせを行うことで、PostgreSQLのサーバログへ鍵文字列が出力されることを防止します。


データを暗号化できたとしても、鍵の管理を適切に行わないと情報漏えいにつながります。鍵の管理テーブルは個別にバックアップを取得するなど、運用方法は十分に検討してください。

※pgcryptoによる暗号化の詳細は「2014年度WG3報告 -セキュリティ編-」p70-p73をご参照ください。
https://www.pgecons.org/downloads/101

災害対策を想定したDR構成の構築、運用手順の確立と考慮点の整理、そしてセキュリティ要件へのPostgreSQL対応範囲と各種手法についてご紹介してきましたが、いかがでしたか。PostgreSQLの評価や採用を検討される際は、ぜひ参考にしてください。

PostgreSQLエンタープライズ・コンソーシアム 2014年度活動報告
https://www.pgecons.org/download/works_2014/

連載最終回となる次回は、異種データベースからPostgreSQLへの移行手法、考慮点に関して移行ワーキンググループのドキュメントをご紹介します。お楽しみに。

  • Postgres Plus は、EDB Postgres の旧製品名です。


執筆者紹介

高瀬 洋子(Youko Takase)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Databaseのサポート業務を経て、2009年よりPostgreSQL、EDB Postgresのサービス立ち上げに参画。「PostgreSQLなら高瀬に聞こう」と社内外から言ってもらえる存在となることを目標に日々活動。2014年4月よりイギリスに拠点を移し、PostgreSQL、EDB Postgresの啓蒙活動と顧客対応の後方支援を担当。

高瀬の紹介記事はこちら

連載記事一覧

関連製品/サービス


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る