【背景】データ基盤整備プロジェクトの一環として、まず「データの標準化」から着手。  「そもそも銀行という業種は、サブ・システムが多いのです」と、今回のコンソリデーションを担当したNTTデータ フォース株式会社 ナレッジビジネス部 シニアマネージャ 清水英一氏。同社は横浜銀行をはじめ金融関係のソリューション・プロバイダーとして活動している。 横浜銀行では、勘定系預金、勘定系融資、証券系、EBなど複数のシステムに分かれ、それぞれにデータの意味内容の定義や重要度がシステムや部署ごとに異なる状態であった。いくつかの同じような情報が複数の部署からあげられ、別々のサーバに点在してしまう、ということも発生していたそうだ。 こうした複数のサブ・システムとデータの分散により、例えばデータ検索をかける際も、時には独自のテーブルを用意するなどのスキルが必要にもなっていた。また、各所にあるデータを有効に使いこなせていないのではないか、という危惧もぬぐえなくなっていた。 2002年の「データ基盤整備プロジェクト」の発足を機に、こうした事態にメスが入れられることになった。 まず、データを経営資源の一つとしてとらえ、その基盤を整備する全ての情報は経営の資産として行員が自由に活用できるべき、という方針のもと、全データの整備が進められた。 この時、「経営の資産」というコンセプトのもと、全データは業務プロセスの視点から再構築されたが、この指揮を執ったのが清水氏だ。「横浜銀行の業務にとって、そのデータがどのような意味を持っているのかその内容を明確にし、実際にコンピュータの中に保存される内容と業務内容を見比べ、ERを作りました。そうして可視的にデータ構造を明らかにして、データひとつひとつのアトリビュートも把握していく、そういう作業を地道に2年半をかけて真にエンドユーザが使い易い検索システムとしての『データ辞書システム』を構築していきました」と同氏は語る。

NTTデータ フォース株式会社 ナレッジビジネス部 シニア・マネージャ 清水 英一 氏 NTTデータ フォース株式会社 第2開発部 第3システム担当 マネージャ 富田 佳一 氏

いま金融機関では、システム内に散在する各種データを戦略的に活用するためのデータの標準化が模索されているが、横浜銀行はこの課題にいち早く取り組んだのだ。

ページ先頭へ

【課題】情報系のデータ・ハブとして、新DWHの構築へ。設定目標は「システムで5倍のスピード」。 

「今回構築したDWH（データ・ウェアハウス）の原型は、6年前に立ち上げたUNIX[R]サーバによるシステムです」と、NTTデータ フォース株式会社 第2開発部 第3システム担当マネージャ 富田佳一氏は語る。

そのシステムは当時、横浜銀行本部内でデータ検索用のシステムとして立ち上がっていた。それまで利用していた旧来のシステムよりも使い勝手が良くユーザを増やしていった。このため格納するデータ量も加速度的に増加。格納データが豊富なためさらにユーザを増やすといった循環が重なり、次第にスペックが追いつかなくなっていたのだ。

当然、パフォーマンスにも悪影響が出て処理速度が低下していた。「弊社にはサポートの部署もあるのですが、そこに銀行の担当者から電話で“まだですか”と、ジョブの処理状況の問い合わせなどもありました。データ供給元のサブシステム側の障害も重なった時などは当日内に処理できなくなるなど、ご迷惑をおかけしていました」と富田氏。

さらにマシンの老朽化も重なったため、横浜銀行は『データ辞書システム』を活用した次世代のDWHを構築することを決定。

新DWHは「ユーザにより分かりやすく使いやすく」「必要なデータが必ず格納されている」「横浜銀行内のデータが集まり、通過し、蓄積する情報基盤」を目指す、いわば情報系のデータ・ハブとして機能させたい、という要望が横浜銀行から出された。

さらにDBの更新速度が旧システムの5倍というハードルが課せられた。「5倍というのはCPUだけでなくシステム全体で達成すべき数値ですから、これは非常に難しい課題でした」と前出の清水氏は語る。

クリックで拡大

この他、大量のデータも短時間で転送、ローディングできること、万一の停止時間をできる限り短くすること、セキュリティと将来的な拡張性を確保することなど、銀行業務に求められる可用性、迅速性、信頼性がそのまま新DWH構築にあたっても要求された。

加えて、このシステムを「適正なスペック」により「適正なコスト」で実現することも求められた。

ページ先頭へ

【選択】難題だからこそ、パフォーマンスとパートナーシップに優れた、サン。 

今回、清水氏たちのチームがコンソリデーションのプラットフォームとして選んだのはSun Fire 12KサーバとSolaris 8だ。選定にあたっては他社製品なども検討したが、「決め手となったのは、Sunサーバのコストパフォーマンスと、Solarisの信頼性です」と清水氏はその理由を語る。

UltraSPARC[R]アーキテクチャと大容量メモリがもたらす、Sun Fire 12Kの優れた可用性、信頼性は銀行というミッションクリティカルな業務を知り尽くした清水氏も高く評価している。

加えて、NTTデータフォースは横浜銀行のシステム部門のアウトソースを担当する会社を前身の一つとしており、そこでは以前からサンの各製品を扱い、その経験や知識に長けた SEも清水氏や富田氏をはじめ社内に多く抱えていることから「我々としても技術的な裏付けがあるから、相応のレベルのものを提供できる自信がある。また、インハウスで保守を行うなどすればコストダウンも期待できる」と清水氏。

さらに、サンのベンチマーク・センターも有効だったと富田氏は語る。今回、データベース更新、ユーザ・サイドからのSQLレスポンス、ETL（データ収集・加工ツール）稼動時のリソース確認などに同センターを利用したという。

「実際に、弊社が導入するシステムと同じものを用意してベンチマークさせて頂いたのです。通常ですと、いくら厳密にシステム設計しても、いざ構築してみるとメモリが足りないなどの情況が発見されるのですが、そうなる前に検証できたのが相当大きいですね」

「また、システムとしてどのくらいのスピードでDB更新できるか、などの目標値も取れました。これができたので、最後に運用設計をする際も助かりました。今まではデータを流してみないと分からない、ということもありましたので」（富田氏）。これら検証作業を含めた技術的な裏付けにより5倍以上という性能を自信を持って提供することができたそうだ。

また清水氏は続けて「オープン系ですと、ついフルスペックを載せたくなりがちですが、そうするとコストが跳ね上がる。こうして事前に、これだけ CPUやメモリを確保すれば動くという確証を得ていればムダな投資が省け、つまりは顧客要求を満たすことができるわけです」。その他、より円滑な導入のために、Solarisシステム管理などのエデュケーション・サービスも活用したそうだ。

このように「何か問題があれば、サンは必ずサポートしてくれる。顧客要求がますます厳しくなる中、サンとのこうした強力なパートナーシップは欠かせません」と清水氏は語る。

当初、横浜銀行から提示された「システムで5倍のスピード向上」「適正なスペック」「適正なコスト」などの課題は、金融業務に精通し、システムを熟知した清水氏たちのチームの豊富なスキルと経験、Sun Fire 12Kの優れたパフォーマンス、そして富士通株式会社とNTTデータとサンとの強力なパートナーシップのもとに解決されたのだった。

ページ先頭へ

【構成】現在のニーズを満たす「受信DB」と、将来を見すえた「正規化DB」による構成。 

この新システムで特徴的なのは2つのDBで構成されていることだ。

ひとつは、勘定系や証券系などのデータ発生源から広範囲のデータを受け取りそのままの形で集約・蓄積する「受信DB」。もうひとつが、先のデータ基盤整備に基づいたデータ構造で蓄積する「正規化DB」だ。どちらのDBからもサブ・システムやエンドユーザにデータを受け渡し、二次利用などに活用可能だが、正規化DBの方がより汎用性の高いデータを提供することができる。

通常のコンソリデーションであれば、できるだけ少ないDBに編成し直すのが理想だ。なぜ今回は2つのDBを構築したのか。

その疑問に富田氏は「例えば、従来からのデータを特殊なテーブルを使って検索し、報告書を作成して官公庁に提出するといった定型的な業務がすでに多く定着していたため、その対策としては既存データを利用する受信DBが適切でした」と語る。

従来データの使用を前提としたツールを使っているユーザや、特殊なテーブルを長年使用しているユーザも行内に数多く存在する。また資金決済などで使われることの多いSTP（Straight Through Processing）化には、投資対効果を考慮すると、基本データの受信DBを残し活用していくのが現実的だ。こうした状況分析を行なわずに正規化 DB1本に絞るのは「コストがどれだけかかるか分からない。また、そこまでやって得られるメリットはない」（清水氏）。行内業務の現実とコストの両面から考慮して導き出した結論、それがこの2つのDBというわけだ。金融業務を知り尽くしたNTTデータ フォースならではの対応といえる。

ただ、今後は正規化DBにウェイトが置かれる。新たに総合経営管理システムを参照するサブ・システムが立ち上げられた場合や、新たなサブ・システムを構築する場合などは正規化DBと接続する。そうすることで「横浜銀行の望む情報ハブがこの正規化DBを中心に形成されていくはずです」と富田氏は語る。

ページ先頭へ

【導入】比較的スムーズだった導入だが、膨大なツールの移行に悩まされることに。 

2003年2月から導入の検討が始まった今回のコンソリデーションは、8縲鰀9月に基本設計・開発・テスト、10縲鰀12月の3ヶ月間で構築、その後、ユーザが使用している様々なツールの移行作業を経て受信DBは2004年4月から、正規化DBは7月末から運用を開始している。実はこのツール移行作業が「最も大変でした」と富田氏は述懐する。

ツールは定例処理のもので50種類程度、非定例や臨時的なものを含めるとその3倍にふくれあがる。他にも旧システムで利用していたツールは約800、Excelはなんと2,000クエリにも及ぶ。

クリックで拡大

新システムで検証した際、動くことは動くのだが結果が違う、というツールがかなり出たそうだ。中には小数点以下20桁のところで違うということもあった。大したことないようだが、そのツールからデータをさらに展開して利用しており、一般業務では微少とされる違いでも後々に大きな誤差を生むためないがしろにできない。銀行ならではの要求精度の高さといえる。

「ツールはどれも個別にユーザが作ったものなので仕様も分からない。ですので問題があったツールを動かしながら調べてゆくしかなかった。そこが一番苦労した点です」（富田氏）

一方でサーバ構築の作業はスムーズに進展していたことから個別ツールへの対応も時間を割くことができたという。この点は、ベンチマーク・センターでの各種検証作業のたまものといえそうだ。

ページ先頭へ

【効果】膨大な検索にも5倍以上のスピードを達成。このゆとりが、次代の銀行経営を支える。 

「やはり処理速度でしょうね」と富田氏は今回のシステムの効果をあげた。

例えば顧客元帳のデータベース更新。1GBのファイルを20で合計20GB、レコード数で800万件近くのデータ更新作業を行うのに従来のシステムは6時間ちかくかかっていた。これが、わずか1時間足らずに短縮された。目標の5倍を上回るパフォーマンスだ。

また正規化DBの性能試験で、1回の検索で12万件の応答が見込まれるジョブでは「以前のシステムでは結果が得られないような検索だったのであまり期待していなかったのですが、それがわずか10分程度で結果が戻ってきたので、正直、驚きました」（富田氏）

正規化DBでは、ERのモデルのようにテーブルが分割されている。このため、検索時はJoinが重なりCPUに過大な負担がかかる。「単独で検索した場合でも全体のCPU使用率が20％位になるのですが、さらに大量の検索をかけた場合でも60%を下回っているのです。サーバの能力は、かなり高いですね」「このときはデータベースはチューニングしていません。マシンパワーだけでこのパフォーマンスをたたき出しているのです」と、富田氏はSun Fire 12Kのハイパフォーマンスぶりを説明してくれた。

小さいファイルでは1分とかからずに検索が終了してしまう。あまりの速さに運用監視サーバが追いつかなくなることもあるそうだ。さらにユーザからは「速すぎると言われたこともありました」と富田氏は苦笑しながら説明してくれた。「銀行担当者が自ら、各種検索のタイミングに合わせてスケジュールを組んでいらっしゃる場合があるのですが、以前のシステムの処理スピードを前提にしていたため、新システムに移行したら、そのスケジュールが合わなくなってしまったのです」。

業務本位に使いやすく再構築されたデータ構造、実用性も将来性も兼ね備えた受信と正規化の2つのDB、そしてSun Fire 12Kがもたらす圧倒的なパフォーマンス。この新しいDWHシステムは横浜銀行の経営基盤のひとつとして、多くのアイデア発想や俊敏な対応力を実現する源となるであろう。

ページ先頭へ

【パートナー】金融業務の知識と経験、ベンダーとしての自信が、このソリューションを成功に導いた。 

最後に、今回のコンソリデーションを実施したパートナー、NTTデータ フォースを紹介しよう。

同社はNTTデータ100パーセント出資の会社だが、文中でもふれたように横浜銀行のシステム部門のアウトソース会社が母体のひとつとなっている。そのため、内部には銀行業務を熟知した人材をはじめ、金融系のアプリケーション開発に長けた人材、さらに基盤系や制御系に強いNTTデータ出身者などを豊富に抱える。

「これはつまり、金融業務をシステムに実装する上でのノウハウが豊富にある、ということです」と清水氏は解説する。「一番の違いは、勘定系で培ったシステムの精度や信頼性の高さでしょうか」。

しかし、同社はNTTデータの子会社であり、横浜銀行からみればひとつのベンダーに過ぎない。このため「我々にすれば競争力を付けるよう努力せざるを得ない。切磋琢磨できる環境」と清水氏が語るように、スキル向上や品質の追求に余念がない。

同社はISO9001を取得しているが、特に大きな業務変更もなくスムーズに取得できたそうだ。「それまでの仕事の進め方や順序立てで、ISOが求める基準に合致してしまうのです。品質管理は今までできていたのですが、それが社内で体系立てられていなかったのですね」（清水氏）。これなどは、同社の品質管理の徹底ぶりを示すひとつのエピソードといえる。また今回のシステム構築にあたっても横浜銀行とSLA（Service Level Agreement）を締結するなど緊張感の中、ビジネスを展開している。

こうした第一線のベンダーとしての自信やプライドを胸に、清水氏をはじめとするスタッフはこれからも新しい挑戦を続けることだろう。

本誌の全部または一部をサン・マイクロシステムズ株式会社の許可なく、無断で転用することは禁止します。

© 2006 Sun Microsystems, Inc. All rights reserved. ●Sun、Sun Microsystems、サンのロゴマーク、Solaris、Solarisのロゴマーク、Java、Java Coffee Cupのロゴマーク、Sun Fireは、米国Sun Microsystems, Inc.の米国およびその他の国における商標または登録商標です。●すべてのSPARC商標は、米国SPARC International, Inc. のライセンスを受けて使用している同社の米国およびその他の国における商標または登録商標です。SPARC商標がついた製品は、米国Sun Microsystems, Inc. が開発したアーキテクチャに基づくものです。●本文中に記載の各社の社名、製品名は、各社の商標または登録商標です。

ご意見・ご感想をお聞かせください

この記事は参考になりましたか？ 参考にならない   参考になった   非常に参考になった コメントがございましたらご記入ください

ページ先頭へ