クラスタリング機能を自作
 |
| 図2●独自作成したDBアクセス・モジュールの主な機能 1つのデータベースを複数のサーバーに分割する「クラスタリング機能」と，テープからリストアする際にダウン直前までの状態を復元する「ロールフォワード機能」を独自に作成した |
検索処理で時間がかかるのは全件検索であり，一般的に全件検索ではディスクI/Oがボトルネックになりやすい。NTTデータが作成した「DBアクセス・モジュール」を使えば，ディスクを共有しないクラスタリング構成が実現でき，ディスクI/Oを分散できる。DBアクセス・モジュールは，参照時には複数のサーバーにSQL文を発行し，それぞれの結果をマージして返す機能がある（図2左[拡大表示]）。
また，DBアクセス・モジュールにはデータの更新時に2台のサーバーにSQL文を発行する機能があり，データを2重化させることができる。2重化しておけば1台のディスク装置が壊れても，もう一方のディスクで処理が継続できる。
そのほか，障害からの復旧機能も独自に作成した。PostgreSQLが標準で備えるバックアップ・テープからのリストア機能では，ダウン直前の状態にまで戻すことができない。そこでデータベースへの更新情報を独自に取得し，テープからのリストア後にログを順番に適用する「ロールフォワード機能」を作成した。この機能があれば，ダウン直前の状態にまでデータベースを戻すことができる（図2右[拡大表示]）。
 |
| 図3●システム/アプリケーション構成図 ソフトウエアはLinux，Apache，Perl，PostgreSQLを採用。ハードウエアはオンライン処理用のWeb/APサーバーとDBサーバーがそれぞれ3台あり，そのほかにバッチ処理用のサーバーなどがある。写真はシステム構築を担当した，NTTデータ 第四公共ビジネスユニット オープン技術統括部 渡部広志氏（真ん中），同市原俊治氏（左），同矢作浩氏（右） |
 |
| 図4●データベースの分割案 検索性能と可用性を高めるために，1つのデータベースを複数のディスクに分割格納する方法を検討した。「サーバー2分割案」はサーバー・ダウンの縮退運転時に処理能力が半分になり，「サーバー3分割案」は縮退運転時に負荷が片寄る。そこで縮退運転時にも均等に負荷が分散する「サーバー3分割，ディスク6分割案」を採用した |
データベースを6分割
データベースの設計は工夫した。まず，バッチ処理の影響をオンライン処理に与えないために，バッチ処理とオンライン処理で利用するテーブルを明確に分けた。バッチ処理ではデータを更新するため対象データをロックするが，オンライン処理で利用するテーブルと分かれていれば，ロック待ちによる影響を無くす事ができる。
また可用性と検索性能を高めるために，オンライン処理で利用するテーブルを物理的に分割した。分割方法は試行錯誤の結果，サーバー3台にデータを6分割している。サーバー2台では1台のサーバーが壊れると処理能力は半分になってしまうが，サーバー3台では処理能力は3分の1しか低下しない。ただサーバー3台でデータを3分割していると，1台が故障すると残りの2台の負荷に片寄りができてしまう。1台が故障した後の縮退運転時に負荷が片寄らないように検討した結果，データを6台のディスクに均等に6分割すればいいと判断した（図4[拡大表示]）。データのユニークなキーである会員番号を6で割り，その余りの値を基に格納するディスクを決めている。
