TOP>企業情報>コラム>技術情報>Postgres Plus 9.3 いかに進化したのか検証してみた

Postgres Plus 9.3 いかに進化したのか検証してみた

EDB Postgres

2013年9月にPostgreSQL最新バージョン 9.3がリリースされ、2014年2月に2回にわたり「PostgreSQL 9.3新機能を検証してみた」と題して注目すべき新機能をご紹介しました。続く本稿では、PostgreSQLに未実装のエンタープライズ向け機能を強力に補完したRDBMS「Postgres Plus」の最新情報をご紹介します。

PostgreSQLの今


Postgres Plusを紹介する前にPostgreSQLの今を見ておきましょう。

PostgreSQLは25年前から進化を続けるオープンソースのRDBMSで、利用しやすいライセンス形態であることや開発コミュニティおよび日本国内のユーザコミュニティ体制がしっかりしていること、また大規模データや複雑なアプリケーションに対応できるようパーティショニング機能や商用RDBMSと同じ表の結合方式をサポートしており、近年、日本国内でエンタープライズ向けRDBMSとしての採用が急速に拡大しています。

2013年9月にリリースされたPostgreSQL最新バージョン 9.3では、図1にあるようにデータウェアハウス(以下、DWH)や開発・運用などのカテゴリで今まで以上に使いやすくするための機能が数多く実装されており、全体では150を超える機能拡張や追加、改善が行われています。

PostgreSQL 9.3の主な新機能

図1:PostgreSQL 9.3の主な新機能

※機能詳細は、以下の記事をご覧ください▼

PostgreSQL 9.3新機能を検証してみた
  「PostgreSQL9.3 エンタープライズ領域で注目の新機能はコレ」(2014/02/21掲載)
  「PostgreSQL9.3 開発と運用を支える新機能」(2014/02/28掲載)

PostgreSQLはRDBMSとしての基本機能は充足しているものの、商用RDBMSの利用ユーザから見ると図2にあるようにいくつかの主要機能に課題があるのも事実です。

たとえば、PostgreSQLではストアドプログラムとして作成できるのはファンクションのみで、プログラム内でトランザクション制御ができません。また、性能障害が発生した際、Oracle Databaseでは待機イベントと呼ばれる実行プロセスの状態を特定できる情報を参照すればボトルネックが特定しやすいですが、PostgreSQLには同等機能が存在しません。Oracle Databaseの待機イベントに相当する情報を得るためには、動的追跡(Dtrace)やSystemtapによるトレーシングやプロファイリングを利用することになります。テスト環境上の性能評価や動作確認のためにトレーシングやプロファイリングを活用することはできますが、実運用しているデータベースにトレーシングやプロファイリングを行うことは難しく、その結果を評価するにも相応のスキルを要します。

PostgreSQLに未実装のエンタープライズ向け機能

図2:PostgreSQLに未実装のエンタープライズ向け機能

エンタープライズ向けで必要とされながら、現行のPostgreSQLに実装されていない機能を強力に補完するRDBMSがあります。それがEnterpriseDB社が提供するPostgres Plusです。

Postgres Plusとは


Postgres PlusはEnterpriseDB社 が開発、販売するRDBMSでサブスクリプション・ライセンス形式で提供されています。メーカーであるEnterpriseDB社にはPostgreSQL開発コミュニティの主要コミッタが複数名在籍しており、図3にあるようにPostgres Plusだけでなく、PostgreSQL本体の開発にも貢献している企業と言えます。

EnterpriseDB社の位置づけ

図3:EnterpriseDB社の位置づけ

Postgres Plusは「Postgres Plus Enterprise Edition(以下、PPEE)」と「Postgres Plus Standard Edition(以下、PPSE)」の2つのエディションで構成されています。

図4にあるように、PPEEはコミュニティ版のPostgreSQLにセキュリティやパフォーマンスを向上させたデータベースエンジンと、データベース管理・監視ツールや周辺データベースとのデータ連携機能、クラスタリング機能などエンタープライズ向けの様々なソフトウェア群で構成されています。

Postgres Plus Enterprise Editionの機能

図4:Postgres Plus Enterprise Editionの機能

本稿では、PPEEに実装された機能の中から「性能」、「可用性」、「連携」、「運用管理」の各分野ごとに「パーティショニング」「Failover Manager」「xDB Replication Server」「Postgres Enterprise Manager」の4つを紹介します。

パーティショニング


パーティショニングとはデータを複数に分割して格納する機能です。データが格納されたパーティションをそれぞれ異なるディスク上へ配置することで図5のように検索処理の性能向上や負荷分散を図ることができます。また、パーティション単位でバックアップやデータの挿入ができるため管理性が向上します。

パーティショニングのメリット

図5:パーティショニングのメリット

PPEEではPostgreSQLと同様に「継承」「制約」「トリガ」の3つの機能を組み合わせてパーティショニング機能を実現していますが、PostgreSQLに比べて設定手順が簡略化されている点が特徴です。

図6にあるようにPostgreSQLでは親テーブルを作成後にパーティションの位置づけとなる子テーブルを作成します。そして親テーブルにデータ挿入のためのINSERTトリガを作成し、加えて、子テーブル間の移動を伴う更新のためのUPDATEトリガを子テーブルごとにそれぞれ作成する必要があります。一方、PPEEでは親テーブル作成のコマンド1つで必要なすべての作業が内部で行われるため、設定時の負荷が軽減されます。

図6:パーティショニングの設定

パーティショニングの設定

PPEEでのパーティションテーブル作成例

PPEEでのパーティションテーブル作成例

パーティショニング機能のメリットとして検索処理の性能向上があります。一般的にパーティション・プルニングと呼ばれ、WHERE句にパーティションキーを指定した場合、アクセス対象のパーティションが絞り込まれることによってディスクI/Oを抑制する仕組みです。PostgreSQLのドキュメントでは「制約による除外」と表現され、CHECK制約を利用して子テーブルを絞り込みます。そのため、子テーブルの数が多くなるに従い、CHECK制約による絞り込みのオーバヘッドが発生する可能性があり、子テーブルの上限数は100個程度までと言われています。

PPEEではこの点も改善が加えられています。図7は250、500、1000の子テーブルに分かれるテーブルに対して複数セッションから検索処理を行った場合の1秒間あたりのトランザクション数を表しており、9.2と比較して9.3では最大76倍の性能向上が確認されています。

パーティショニングを利用したSELECT処理性能

図7:パーティショニングを利用したSELECT処理性能

また、図8は100、250、500、1000の子テーブルに分かれるテーブルに100万行のデータをINSERTした際の処理時間を9.2と9.3で比較した結果です。9.3では9.2と比べて450倍以上の性能向上が確認されており、DWH環境での利用拡大が期待されます。

パーティショニングを利用したINSERT処理性能

図8:パーティショニングを利用したINSERT処理性能

Failover Managerによる可用性構成の強化


可用性構成を採用するミッションクリティカルなシステムにおいて、サーバを常に監視し、万が一障害が発生した場合にサーバを切り替えて迅速にサービスが再開できるかどうかは極めて重要です。

PostgreSQLの標準機能「Streaming Replication」による可用性構成では、商用またはオープンソースのクラスタソフトを別途インストールしてサーバおよびデータベースの死活監視とフェイルオーバの仕組みを用意する必要がありました。今回、PPEEに実装されたFailover Managerを利用することでデータベースのインストールと同時にクラスタソフトもインストールでき、より容易な死活監視の設定と自動フェイルオーバの仕組みが提供されます。

Failover Managerは図9にあるようにStreaming Replication環境を構成する2台のサーバに加えて、マスタとスレーブサーバの状態を監視し、障害発生時にフェイルオーバを行うかどうかを判断する「Witness」と呼ばれるサーバの計3台で構成されています。各ノードに導入したAgentがJGroups Toolkitを使ってサーバ間通信を行います。

Failover Managerの構成要素

図9:Failover Managerの構成要素

JGroupsはJavaで作成された複数のアプリケーションを相互に通信させるためのネットワーク通信ライブラリで、Failover Managerのノード間通信はJGroupsにより実現されています。※JGroupsの詳細情報はWebページ を参照ください。

Failover Managerはマスタ側で図10のようなデータベース障害やノード障害を検知した場合、スレーブAgentとWitness Agentそれぞれが直接マスタデータベースに接続を試みます。接続ができないことが判明すると即座にフェイルオーバを実施し、スレーブデータベースをマスタに昇格させます。また、Failover Managerは新マスタサーバへの仮想IPアドレス(以下、VIP)の再割り当ても行うため、透過的にアプリケーション処理の再実行が可能です。弊社検証では、VIPの再割り当てを含むマスタデータベースの切り替え処理が60秒以内で完了することを確認しており、今後、これまで以上に可用性構成の採用が増えることが期待されます。

Failover Managerによる障害検知とフェイルオーバの動作

図10:Failover Managerによる障害検知とフェイルオーバの動作

尚、Failover Managerでは障害時にマスタの状態を正確に把握するため、スレーブとWitnessの間で認識に相違がないかどうかを確認しており、認識に相違がある場合はフェイルオーバを行いません。この動作によって、マスタとスレーブの両ノードが同時にアクティブな状態になるスプリットブレインを防止しています。そのため、Witnessノードを物理的にマスタとスレーブノードとは異なるネットワークセグメントに配置することをお奨めします。

xDB Replication Serverによるスムーズなデータ連携


基幹システムと周辺システムなど、システムをまたいだデータ連携がスムーズに行えるかどうかは企業にとって大変重要です。

各システムで稼働するRDBMS製品が異なる場合、商用やオープンソースのETLツールを利用して差分データを取得するためのトリガを作成するといったデータ連携の仕組みを準備する必要があります。PPEEに実装されるxDB Replication Serverは商用RDBMSとの連携もサポートしており、管理用GUIコンソールから簡単な環境設定が実現できます。

xDB Replication Serverは複数サーバ間でテーブル単位でのデータ連携を行う機能で、シングルマスタレプリケーションとマルチマスタレプリケーションの2種類の構成をとることができます。

シングルマスタレプリケーションは連携対象のテーブルに対して1つのマスタサーバと1つ以上のスレーブサーバでの構成が基本で、スレーブサーバ側でデータを参照することができます。図11にあるようにPublication ServerとSubscription Serverと呼ばれるプロセスがサーバ間でテーブル定義と実データの連携を行います。表1は対応RDBMSのマトリクスで、縦軸がソースDB(連携元)、横軸がターゲットDB(連携先)を表しています。シングルマスタレプリケーションでは表1にあるようにPPEEに加えてPostgreSQLおよびOracle Database、MS SQLServerをサポートしているため、異種RDBMS間での円滑なデータ連携を実現します。

シングルマスタレプリケーションの構成イメージ

図11:シングルマスタレプリケーションの構成イメージ

シングルマスタレプリケーションの対応RDBMS

表1:シングルマスタレプリケーションの対応RDBMS

シングルマスタレプリケーションにおけるサーバ構成は、マスタサーバ1台とスレーブサーバ1台のシンプルな構成に加え、図12にあるように複数のマスタサーバと1台のスレーブサーバの構成や1台のマスタサーバと複数のスレーブサーバの構成など多種多様な構成をとることができます。さらにテーブル全体ではなく、一部のデータのみ連携したいというニーズにも対応しており、WHERE句で条件を絞ったデータのみをフィルタリングした連携も可能です。

多種多様なレプリケーション構成

図12:多種多様なレプリケーション構成

マルチマスタレプリケーションは図13のように2つ以上のマスタサーバで構成され、Publication Serverがデータ連携を担います。尚、対応RDBMSは表2のとおりPPEE間およびPostgreSQLとの間でデータ連携を行うことができます。

マルチマスタレプリケーションの構成イメージ

図13:マルチマスタレプリケーションの構成イメージ

マルチマスタレプリケーションの対応RDBMS

表2:マルチマスタレプリケーションの対応RDBMS

xDBでは図14のとおり2種類のデータ連携方式をサポートしています。1つは「Snapshot」と呼ばれる方式で、表の全データを対象として連携先のデータをTRUNCATEし全データを再投入します。もう1つは「Synchronization」と呼ばれる方式で、連携元のテーブルに作成されたトリガによりテーブルに加えられた変更をシャドウテーブルに格納し、その情報を元に連携先のテーブルに対して差分更新を行います。

SnapshotとSynchronizationはそれぞれ次のような条件のテーブルで効果を発揮します。

 ・Snapshot
   - テーブルのサイズが比較的小さい場合
   -レプリケーションによって変更される行数が多い場合

 ・Synchronization
   -テーブルのサイズが大きい場合
   -レプリケーションによって変更される行数が少ない場合

データ連携の方式

図14:データ連携の方式

シャドウテーブルには図15のように対象テーブルの全列の更新前と更新後の値が格納されており、スケジューリングされたタイミングでPublication Serverがデータを連携します。

シャドウテーブルの構成例

図15:シャドウテーブルの構成例

xDB Replicationには図16のようなxDB Replication Consoleと呼ばれるGUI管理ツールが提供されているため、環境構築からデータ連携のスケジューリング、監視まで一元的に行うことができ、担当者の負荷を軽減します。

xDB Replication Consoleによる一元管理

図16:xDB Replication Consoleによる一元管理

あわせてxDB Replication Server CLIと呼ばれるCUIベースのJavaアプリケーションを利用することでxDB Replication Consoleが稼働する同一サーバ上でConsoleと同様の操作を行うことができるため、スクリプトなどへ処理を組み込んだバッチ実行にも便利です。

SCOTT.EMPテーブルをSynchronizationモードで連携するPublication「Pub1」を設定

SCOTT.EMPテーブルをSynchronizationモードで連携するPublication「Pub1」を設定

弊社ではOLTP系トランザクションの動作傾向からxDB Replicationの有効性を評価しました。フロント処理をPostgres Plusで受け、バックエンドのOracle Databaseへデータを集約する図17のようなWebシステムを想定して、PPEEをマスタサーバ、Oracle Databaseをスレーブサーバとしたシングルマスタレプリケーション構成です。

xDB検証構成イメージ

図17:xDB検証構成イメージ

PPEE単体のシングル構成とOracle Databaseとのレプリケーション構成それぞれにおいてマスタサーバの処理性能に違いがあるかどうかを確認した結果、データ連携は非同期で行われるため図18のとおりシングル構成とほぼ同等の性能を発揮することが確認されており、マスタサーバへの負荷を最小限に抑えたデータ連携が可能です。ただし、同時接続数に比例して連携対象のデータ量も増加するため、1回のフェッチで読み込む行数を多くしたり、複数の表に対して同時にデータ連携が必要な場合はスレッドを増やすなど各パラメータの調整が必要です。

xDB Replicationの有効性評価

図18:xDB Replicationの有効性評価

xDB Replicationによるデータ連携は様々なシステム構成で利用できます。例えば、Web系サービスの場合、図19のようにユーザからの要求をフロントに配置した複数のPPEEサーバで分散処理し、バックエンドに配置したOracle DatabaseにxDB Replicationを利用して定期的にデータを集約することでデータベースのライセンスコストを抑えた構成が可能です。また、図20のように基幹データベースで一元管理するデータを必要に応じて外向けサービスのデータベースや社内のサブシステムへ連携することでセキュリティを考慮したサーバ構成が実現できます。

xDB Replicationの利用例1

図19:xDB Replicationの利用例1

xDB Replicationの利用例2

図20:xDB Replicationの利用例2

DBの管理・監視を一元化するPostgres Enterprise Manager


データベースの運用・管理作業は、バックアップやデータベースの稼働監視、SQLおよびDBパラメータチューニングなど多岐に渡ります。これらの作業をすべてコマンド操作で行うには深い知識が必要で、さらに工数もかかります。

商用RDBMSではシステム全体を運用・管理するGUIツールが提供されており、ユーザはそのGUIツールを利用することでデータベースの管理作業を簡略、効率化することができます。PostgreSQLではPgAdminIIIと呼ばれるGUIツールにより、ユーザやオブジェクトの作成やデータベースのバックアップなど運用上の基本的な作業を行うことができますが、データベースサーバ全体の監視やチューニングは別途仕組みを検討しなければなりません。

Postgres Plusで提供されるPostgres Enterprise Manager(以下、PEM)は、図21のように複数サーバで稼働するPPEEおよびPostgreSQLデータベースの一元的な管理、監視、チューニングを実現します。

PEMによる複数データベースの一元管理

図21:PEMによる複数データベースの一元管理

PEMによるPostgreSQL、PPEEの監視


PEMでは、プローブと呼ばれるスケジューリングされたタスクによってデータベースの稼働情報を定期的に収集しています。デフォルトで定義されているプローブは約50に及び、データベースの状態だけでなくCPU使用率やディスクI/Oなどサーバ全体の情報も対象としており、監視に必要な情報は網羅されています。尚、収集された情報はプローブで定義された期間中リポジトリデータベース上に保持されます。

PEMのプローブの一部

図22:PEMのプローブの一部

各プローブの情報収集のタイミングと保持期間はデフォルトで設定されていますが、図23のようなPEMの画面から簡単に変更ができるため、システムごとに適切な情報収集とデータの管理が可能です。

プローブの定義変更

図23:プローブの定義変更

通常、データベースになんらかの問題が発生した際、図24のような流れで収集された情報を元に問題点を調査、把握し、解決策を適用して効果を確認します。

問題発生時の対応

図24:問題発生時の対応

PEMでは問題を検知した際に通知する仕組みとしてアラート機能が提供されています。各アラートにはしきい値が設定されており、収集した情報からしきい値を超えたと判断するとPEMコンソール上に「High」「Medium」の警告とともに詳細情報が表示されます。また、図25のように管理者にメールを送信したり、SNMPでトラップし統合監視ツールと連携することができます。デフォルトで主要なアラートは設定されていますが、図26のようにユーザ定義のアラートを新規で作成することができます。

メール送信の設定

図25:メール送信の設定

PEMのアラート定義

図26:PEMのアラート定義

図27はデータベースが停止した際のアラートですが、PEMの監視対象のデータベースが停止すると、PEMコンソール上に赤い「!」マークとともに該当のアラートが表示されます。また、図28のように「どのデータベースが停止したのか」「いつアラートが検知されたのか」といった情報が担当者へメールで通知されるため、迅速な対応が可能です。

PEMコンソール上のアラート表示

図27:PEMコンソール上のアラート表示

メールによるアラート通知

図28:メールによるアラート通知

PEMによるSQLチューニング


PEMにはSQLのチューニングを行う際に非常に便利なコンポーネントがあります。例えば、SQL Profilerを利用するとデータベースとユーザを指定して図29のように一定期間に実行されたSQLを実行時間の長い順やアクセスバッファの多い順など任意の項目でSQLを並べ替えて表示することができるため、チューニング対象となるSQLの判断に役立ちます。

SQL Profiler

図29:SQL Profiler

SQL Profilerから特定のSQLを選択し、Index Advisorを利用するとSQLの性能改善に必要な索引をアドバイスします。

図30の画面下「Suggested Indexes」にはIndex Advisorが作成した方が良いと判断した索引の情報が表示され、画面左の「Actual Plan」には現在選択されている実行計画、画面右の「Hypothetical Plan」にはアドバイスされた索引を作成した後に予想される実行計画が表示されます。このように、PEMの「Index Advisor」を利用すると、索引作成後に予想される実行計画を確認することができるため、索引を実装するかどうかの判断に役立ちます。

Index Advisor

図30:Index Advisor

本稿でご紹介した機能以外にもデータベースパラメータの最適値やデータベースセキュリティに関する情報をアドバイスする「Postgres Expert」や、システムの増強や再配置を行う際に過去に収集した情報から有用なレポートを表示する「Capacity Manager」など、PEMでは多くの機能が提供されています。機能の詳細は、次の機会をお楽しみに。

今後のロードマップ


これまでPostgres Plusは、PostgreSQLのメジャーバージョンリリースから数ヵ月を経てリリースされています。Postgres Plus 9.4ではパラレルクエリやパラレルソート、Materialized Viewの機能強化などPostgreSQL 9.4に実装予定の機能はもちろんですが、図31にあるようにFailover Managerでの3台以上のレプリケーション構成のサポートや複数サーバにデータを分散配置することでスケールを実現するShardingが実装される予定です。

Postgres Plus 9.4への実装機能(予定)

図31:Postgres Plus 9.4への実装機能(予定)

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

高瀬 洋子(Youko Takase)

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

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

高瀬の紹介記事はこちら

関連製品/サービス


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

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



ページの先頭へ戻る