パナソニックグループはいかにして分散する基幹DBを集約したか【後編】：基幹業務システムのDB統合は可能か（2）（3/4 ページ）

[野本幹彦，＠IT]

最長3カ月のプロセスを30分に短縮する

夜間バッチが余裕ある処理時間に

　当初の導入目的であるパフォーマンスの向上については、満足できる結果が出ていると片岡氏は説明する。

　「受発注システムでは、オンライン処理が約900ミリ秒から300ミリ秒と3倍の高速化を実現しています」（片岡氏）

　片岡氏は、「それよりも」と言葉を続けた。「バッチ処理の中で、ある特定の処理の平均が約32分から4分に短縮できたことが大きいですね」。

　複雑なバッチ処理では、こうした“重い”処理を何重にも実行することが少なくない。翌営業開始時間に処理が間に合わなくなるケースは、同社に限った問題ではないだろう。

　「以前は、夜間バッチが失敗すると朝までに完了しない場合もありましたが、これだけ短縮できれば、万一、処理が途中で失敗した場合でも、再度実行するだけの時間的な余裕ができます。バッチ処理が完了しなければ、翌日の業務に大きな影響がありますから、こうした点で改善できたのは、大きなメリットです」（片岡氏）

レスポンススピードが顧客体験改善につながる

　同社は前編で紹介した通り、パナソニックES社のシステムを担当している。ホームファシリティ類を扱うES社では、照明器具やユニットバス、間取りなどの画像イメージをお客さまに見せながら提案するシステムも展開している。このシステムも、DB環境を刷新したことだけで、レスポンスが改善している。

　「オンラインでの平均処理時間が1773ミリ秒から272ミリ秒へと約6.5倍の高速化を実現し、お客さまを待たせることがなくなって業務担当者からの評価も非常に高くなっています」（片岡氏）

　統合DB基盤を導入することで、開発と運用を分離して内部統制に対応でき、専任チームによって安定したDBサービスを提供できるようになったことも大きな導入効果だ。また、導入前は、本番13台、開発9台の22台のサーバーを利用していたものを、Exadata 2台に集約でき、DB運用工数も6割程度の削減ができているという。

　統合DB基盤からのDB切り出しをメニュー化し、アプリ構成によって選択・統合することで既存システムの統合や新規システム用のDB提供も行えるようになった。「以前は、新しいシステムを構築するにはサーバーの手配から行わなければならず、在庫がなければ最悪の場合、調達に船便で2カ月かかり、環境の構築で1カ月かかることもありました。3カ月経ってやっとアプリケーションチームが着手できるような状況では、ビジネススピードについていけません。新たな統合DB基盤では、スキーマを切り出すだけでよく、DB機能だけが必要であれば30分程度で提供できます。アプリケーションチームは、スキーマの情報が分かればすぐにアプリケーション開発に着手でき、以前のように環境の違いから本番環境で再検証することなく、スムーズに移行できます」と片岡氏は話す。

　一方、課題が全くないわけではなかった。

　集約率を上げたためにパッチ適用時には、影響の範囲を調査・検証する必要があり、停止調整が困難となる。このため、ノード停止やDB停止を伴うパッチ適用時のフローは全て明確にして、運用担当者に理解してもらう必要が出てくる。

　同社では、システムの停止を伴うワークフローに関しては、開発環境兼スタンバイ環境を活用することで、この課題を解消している。

　事実、2013年5月の連休に行われたメンテナンスでは、前述のように本番機とバックアップ機（開発機）が用意されているため、DBサービスの提供をバックアップ機に切り替えてから本番機のメンテナンスをじっくりと行うことができ、スムーズなメンテナンスが行われたという。