「PostgreSQL」はエンタープライズでどこまで使える？ ”SIエンジニア連合”が技術検証：Database Watch（2015年6月版）（2/2 ページ）

[加山恵美，＠IT]

移行ワーキンググループ：移行データの検証

　移行ワーキンググループでは企業でアプリケーションを稼働している環境において、アプリケーションはそのままに、RDBMSだけ商用のもの（主にOracle Databaseを想定）からPostgreSQLに置き換える際のプロセスを検証、ドキュメント化しています。

　具体的には、全体でどのような作業が発生し、各段階でどのようなことに注意しなくてはいけないかについて、詳細をまとめています。技術的な面だけでなく、工数見積もりの目安なども示されており、データベース移行に役立つものになっています。

移行ワーキンググループの検証における前提環境

　移行ワーキンググループが検証を行う際、データ移行で使用したのが「ora2pg」というツールです。これはOracle Databaseからスキーマやデータを抽出してPostgreSQL用に整形するフリーのツールです。ただし「FROM」のような予約語を用いたカラム名があると、手動で調整が必要となるなど追加作業が発生します。ここはよく確認しておくべきでしょう。

　2014年度は本当にスキーマやデータが正しく移行できたかどうかを確認する移行試験に重点を置きました。移行結果で確認すべきはスキーマとデータ、それからアプリケーションです。

　スキーマ移行結果の確認では、テーブルの定義情報を抽出して差分を比較しました。

　データ移行結果の整合性は、データをCSVで抽出してdiffを使った比較で調査しています。ただし製品ごとにタブや改行の扱い、出力文字制限などが異なるため、そう簡単に比較はできないようです。カラムによってはハッシュ値に変換して比較するなど工夫をこらしていました。アプリケーションの挙動については、同じSQLで同じ結果が返ってくるかどうか、画面操作に変更がないか、性能が変わらないかなどを調べました。

　データベース移行についてはとても具体的かつ実践的なノウハウがまとまってきています。詳細なものなので本稿では紹介し切れませんが、PGECのWebサイトで公表しているドキュメントは参考になるでしょう。

設計運用ワーキンググループ：ストリーミングレプリケーションを使ったDR

　これまで設計運用ワーキンググループではHA（High Availability：高可用性）クラスターやレプリケーションについて実機検証を行ってきました。2014年度は多くの企業で関心が高い災害対策としてのディザスターリカバリ（Disaster Recovery：災害復旧）を実現する手法として、遠隔地サイトにあるスタンバイサーバーに対してPostgreSQLの機能である「ストリーミングレプリケーション」（PostgreSQLに実装されているレプリケーション実装の一つ）を使ってデータを送る構成で実機検証しました。

ストリーミングレプリケーション機能検証の概要　マスター1台／スタンバイ2台で、ストリーミングレプリケーション実行時とカスケードレプリケーション実行時を比較

　今回検証したのはマスター1台にスタンバイ2台という構成です。メインサイトから2台のスタンバイ（2方向）にストリーミングレプリケーションを行うパターンと、メインサイトから1台ずつカスケード式でストリーミングレプリケーションを行うパターンの2通りで、それぞれ復旧に必要な作業がどう変わるか検証しました。

　さらに設計運用ワーキンググループでは、高負荷を掛けた場合の動作も検証しました。あまりに高負荷でレプリケーションの遅延が一定量を超えると、レプリケーションそのものが停止してしまう場合があると分かりました。

　この問題への対策としては、PostgreSQL 9.3ではアーカイブログのみをスタンバイに転送する方法を利用することが考えられます。また、PostgreSQL 9.4では「レプリケーションスロット」という機能を用いる方法があります。後者はストリーミングレプリケーションがまだ適用されていない「WAL（Write Ahead Logging：ログ先行書き込み）」のデータを削除しないようにする機能です。

PostgreSQLでPCI DSS対応する際に必要な対策も資料を整備

　他にも設計運用ワーキンググループでは初めての試みとして、セキュリティに関する要件についても調査・検証しています。データベースのセキュリティを検討する「DataBase Security Consortium」がクレジットカード業界のセキュリティ基準である「PCI DSS」についてまとめた資料を基に、PostgreSQLを使う場合にどこまで要件に対応できるかどうかを確認しました。

　結果としては幾つかのケースでPostgreSQLそのものの機能では要件を満たすことができず、外部のツールを組み合わせて使う必要があると分かりました。セキュリティ要件が厳しい場合には、追加で必要となるツールの選定や生じるコストも見積もる必要がありそうです。

　そして2015年6月4日、PGECは2015年度のキックオフミーティングを開催しました。多くの参加者が集まる中、各ワーキンググループの新主査（リーダー）が決まり、本格的に新年度の活動がスタートしました。来年の発表も楽しみですね。

2015年度の活動でリーダーシップを採るメンバーも決定した 写真左から運営委員長代理 川畠輝聖氏（NEC クラウドプラットフォーム事業部 主任）、WG1新主査 坂田哲夫氏（NTT オープンソースソフトウェアセンタ マネージャ）、WG3新主査 稲垣毅氏（日立ソリューションズ 技術開発本部 技師）、WG2新主査 黒澤彰氏（NECソリューションイノベータ 第四PFソフトウェア事業部）