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

共通化や標準化、サービス化による、運用効率改善を狙う企業情報システム部門の取り組みが注目される中、基幹業務システムのデータベースは依然として散在している状況にあるケースが少なくない。データベースならではの、アプリケーションとの関係、パフォーマンスの課題を、先行企業はどのように克服していったのだろうか。前後編の2回にわたり、DBaaS環境実現の取り組みを追う。

[野本幹彦，＠IT]

　DB統合基盤としては、Oracle Exadata（以下、Exadata）を利用することを検討したという。

　「2011年当時は、われわれが求めるパフォーマンスを担保できる製品は限られていました」（片岡氏）

　DB処理専用のアプライアンス製品として作り込まれ、データ書き込み読み込み共に用途を限定している分の実装が盛り込まれていることから、「何もしなくても速い」環境は多くはない。現在であればストレージI/O性能改善にSSD環境を利用した構成など、多様な選択肢も考えられるが、ストレージファームソフトウェアなどのレベルでDB処理用に調整されているわけではないことから、ある程度の工夫が必要になる。

　同社はもともと各アプリケーションでOracle Databaseを使っていたことも、選定の後押しになったという。これまで蓄積してきた運用手法やナレッジ、ノウハウを使え、移行や構築をしやすい。

　「DWH（データウェアハウス）に特化したハードウェア／ソフトウェアはあったものの、オンライントランザクション、バッチ、DWHを全てこなせる製品も他にはありませんでした」と片岡氏は当時を振り返る。

　以降、統合DB基盤構築を目指した機能検証では多様なテストが行われた。

　WebベースのアプリケーションをWebブラウザーから実行して高負荷トランザクションの応答時間を計測、どの機能の組み合わせでパフォーマンスが向上し、ストレージ容量を抑制できるか、など詳細を調査している。

　取材では、その検証結果を幾つか見せてもらった。例えば、処理能力では、クエリ処理を8つに分割してパラレル実行し、大量データに有効なパーティション機能を使った検証パターンが最も速く、既存システムの621秒を1.06秒に短縮できている。

　また、8つのパラレル実行とHCC圧縮*を使った場合、非圧縮に比べて約7分の1の約14％まで圧縮が行え、OLTP圧縮の約43％よりも効果が高い。この他にもインデックスの有無による影響度合いなども検証して、製品の「クセ」を検証、十分に目的を達成できる、との結論を導き出している。

* HCC圧縮　Hybrid Columnar Compression。OracleがExadata向けに開発した列圧縮技術。問合せ時には、Exadata特有の「Smart Scans」を使い、ストレージ側で一定の処理を行うため、ストレージから読み出すデータ量そのものも削減できる。特に頻繁なInsert処理などが発生しないデータで高い圧縮率を得られる。