日本では海外と比較してPostgreSQLの普及率が高いと言われている。そこにはNTTデータの貢献も大きい。NTTデータは長らくPostgreSQLと関わってきているからだ。
日本PostgreSQLユーザ会（JPUG）設立は1999年。JPUG活動にはNTTデータ関係者が何人も関わり、時には勉強会会場を提供することもあり、NTTデータはJPUGを深く、長く支えてきた。そうした水面下の貢献もあり、2006年には正式にNTTグループとして戦略的にオープンソースを活用している体制を整えるべくNTT OSSセンタを設立したという経緯もある。
スタートが早いこともあり、NTTデータではPostgreSQLのノウハウが多く蓄積されており、人材も豊富に抱えている。今では同社ではOSSスタックは高い利用頻度となり、PostgreSQLのコモディティ化が進んでいる。
トップランナーであればこそ、未知の困難にも直面する。講演ではNTTデータ 笠原辰仁氏、澤田雅彦氏（写真）から世界有数のエネルギー元売会社に導入した情報系システムが紹介された。販売情報をもとに集計もほぼリアルタイムで行うものだ。
データベースの規模は当初1インスタンスで10TB、論理テーブル数は900弱、SQLの数は2万以上。かなりの規模である。OSはRHEL 6.2、RDBMSはPostgreSQL 9.2、アプリケーションはTomcatを用いた。PostgreSQLで利用可能な拡張モジュールはほぼ全て採り入れたという。澤田氏は5つの要件をどのように克服したかを解説した。
課題１：無停止メンテを
システムでは24時間データベースへのアクセスがあり、昼夜問わず大量バッチが行われているゆえ「止められない」。そのためシステムを止めずにメンテナンスを行わなくてはならない。PostgreSQLならメンテナンスのためのVACUUMやREINDEXがある。どうするか。
「何はなくともまずVACUUM設計」と澤田氏。小規模テーブルは性能への影響が少ないため「auto vacuum」、大規模テーブルは慎重にメンテナンス枠にて手動で実施することにした。オンラインテーブル再編成用の外部モジュール「pg_reorg」、加えてインデックスのための自作ツールも組み合わせた。
課題２：災害対策サイトを
重要なシステムならBCP（事業継続計画）は避けて通れない。東日本のメインサイトから西日本の災害対策サイトへデータをコピーすることとなった。
検討段階ではアーカイブログの転送やハードウェアレベルでのレプリケーションも候補に上ったが、結果的にはストリーミングレプリケーションを採用。これは当然である。もともとストリーミングレプリケーションはNTTデータが独自に開発した機能をPostgreSQLの本体に寄贈したようなものだ。
澤田氏はストリーミングレプリケーションを選択した決定打のひとつとして「頼れるサポート」の存在を挙げた。ストリーミングレプリケーションを開発したNTTデータ 藤井雅雄氏だ（参考「コアメンバーやコミッターに憧れて―ポスグレの若きエース、藤井雅雄さん」）。今ではPostgreSQLのコミッターである。
とはいえ「本当に高負荷でも大丈夫か？」という懸念もあった。設計では最大負荷量から必要な帯域をサイジングしたものの、レプリケーションが追いつかなくなったらPostgreSQLが自動でアーカイブログからの復旧に切り替える。「今のところレプリケーションに起因する問題はありません」と澤田氏は胸を張る。
