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

[野本幹彦，＠IT]

　「基幹システムのDBに関しては、アプリケーションに密接に関係している部分があるため、なかなか手を付けられませんでした」とパナソニックISサービスビジネス本部 IDCサービス事業部 インフラ基盤サービスグループ アプリ基盤担当G グループリーダーの片岡光康氏は振り返る。

　当時、運用を担当するシステム全体では、8つのアプリケーションごとにDBシステムが置かれており、ものによって、DB運用管理者がメンテナンスするもの、アプリケーション担当者が個別に運用するものが混在、個々に導入していたDBそれぞれで扱う文字コードも異なっている状況だったという。

　個別に立ち上がったDBシステムの要件が多様であり、運用の責務も個別システムごとに持っている状況は、なにも当時の同社の状況に限ったことではない。多くの企業において、IT予算の持ち方は部門ごと、個別の目的ごとの場合が少なくなく、そうした環境で個別のアプリケーションごとに実装してきた経緯がある企業であれば、どこも似た状況を経験しているのではないだろうか。

　一方で、バズワードのようにビッグデータが注目され、データの増加量が「1年間に2割から1年間に2倍」（片岡氏）に増えるといわれている中、新たな統合DB基盤の構築は早急に対応しなければならない課題だった。新ビジネスのために迅速にDBを提供し、後手にまわっているパフォーマンスの課題を解決して、増え続ける運用コストを削減することが急務だったのである。

　「夜間バッチプロセスの実行時間や、業務時間中のレスポンス遅延問題など、アプリケーション側のチューニングだけでは太刀打ちできない状況が来ることは目に見えていました」（片岡氏）

　DBAならば分かるように、確かにクエリチューニングでは、ひどく悪いクエリをスムーズなクエリに変えていくことはできる。しかし、考え得るチューニングを施しながら運用してきたアプリケーションに対して対処できる余地はごくわずかだ。環境そのものを大幅に変える必要があることは明白だったという。

処理能力向上とコスト削減を目指した統合DB基盤

　こうした経緯から同社では、DB基盤環境の刷新を目指した。ただ、処理性能を高めるのではなく、「基盤」としてハードウェア、運用、アプリケーション基盤を一本化し、8つのアプリケーションごとに構築されていたDBサーバーを集約できる新たな統合DB基盤構築を目指したのである。これにより、パフォーマンスの問題と運用工数削減の両方で成果を出そうという試みだ。この取り組みは、2011年4月から検討し始めたものだ。

　「集約することで運用効率を上げ、運用工数を減らすことを考えました。また、4つのデータベースはインフラ基盤サービスグループが一括で運用管理していましたが、残り4つのDBは業務システムを運用しているグループが運用管理しており、運用品質にバラツキがあることも課題だったので、DB統合で専門のDB管理者が運用する必要がありました」と片岡氏は話す。