オンメモリ・データベース活用し
大規模バッチ処理と応答を高速化

前ページ 導入の背景・システム概要 |  導入の経緯・将来の展望 |

---

 導入の経緯 |  将来の展望 

導入の経緯

オンメモリDBで高速バッチ処理

新システムでは、全データの格納先を「セントラルDWHサーバ」に一元化した。ただし、それだけでは大量のバッチ処理や高速な応答に対応するのが難しいため、セントラルDWHサーバのほかに、富士通ビー・エス・シーのオンメモリ・データベース「Oh-Pa 1/3（オーパ・ワンサード）」を搭載した「フロントDB/バッチ・サーバ」を置くことにした。そして、このそれぞれにPRIMEQUEST 480を採用した。

オンメモリ・データベースでは、大量のメモリを搭載できなければ威力を発揮できない。最大2T（テラ）バイトまでのメモリ拡張が可能なPRIMEQUESTはまさにこの目的にかなったものだ。また大量のデータ処理に欠かせない処理性能の高さや、365日24時間稼働に必要な信頼性の高さなどが評価された。

フロントDB/バッチ・サーバの役割は大きく2つある。1つは大量のデータをバッチ処理してセントラルDWHサーバへロードすること。もう1つはSVからの照会に素早く応答するためのデータマートを作成することである。

夜間に基幹系システムから送られてきた大量のPOSデータを、いったんセントラルDWHサーバが受信する。ここでデータの桁合わせやマスター・コードの統一など、いわゆるデータ・クレンジング処理を実施し、その結果をフロントDB/バッチ・サーバに送る。ここで、Oh-Pa 1/3を使ってデータをバッチ集計・編集して、さらにデータマートを作成する。日々送られてくるトランザクション・データの量は1000万件以上、1G～2Gバイト程度。このバッチ処理は4時間で完了しなければならない。従来のSolaris搭載システムではほぼ時間ぎりぎりだったが、PRIMEQUESTによる新システムでは負荷的に半分以上の余力があるという。

通常のデータベース管理システムの場合、ディスクに格納するデータをキャッシュに保持して処理するが、キャッシュにヒットしない場合は性能が低下してしまう。これに対してOh-Pa 1/3はデータをすべてメモリ上に展開し、キャッシュを持たないので、キャッシュを使う一般的なデータベースに比べて格段に高速になる。このためフロントDB/バッチ・サーバには128Gバイトものメモリを搭載した。

セントラルDWHサーバには、約6300店舗から吸い上げた明細データが800日分格納される。週単位や月単位で集計したサマリー・データは、2～3年保持する。これらのデータ量は合計10T（テラ）バイト弱にも及ぶという。

SVやMDからの要求はすべて、ブレード・サーバ「PRIMERGY BX620」に配置したWebアプリケーション・サーバ経由で送られてくる。アプリケーション・サーバには「InterstageApplication Server」を採用した。

SVからの要求は定型的なものが多いので、一部の速報用データはフロントDB/バッチ・サーバで処理する。メモリ上のテーブルを検索し、必要なデータを返す。これにより、最も必要とされる機会が多い速報データの応答速度を確保した。

速報以外のデータ要求は、Webアプリケーション・サーバを経由してセントラルDWHサーバのOracle Database 10gに送られる。ここで検索・集計して結果を返す。

UIの構築にAdobe Flexを利用

ユーザー・インターフェースは、これまで使っていたVisual Basicを一新してWebベースに変えた。

ただしWebアプリケーションだと、そのままではユーザー・インターフェースの操作性を継承できない。そこでリッチ・クライアントとして、アドビ・システムズの「Flex」を採用した。「多少画面構成は変わりましたが、それほど違和感なく使えます。使い勝手も今までとそん色ないといえます」（渡部氏）。

Webアプリケーションに変えたことにより、外出先で必要なデータを参照できるようになった（写真）。端末からPHS経由で接続できるリモート・アクセス・サーバを設置している。「従来は、必要なデータを事前にオフィスで用意してから店舗に向かっていました。新しいシステムでは、例えば現地でもデータを用意できます。また、直前に必要なデータが不足していることに気付いても、その場で対処できます。時間の効率的利用も可能になります」（渡部氏）。

一方、MD用のシステムは、オラクル製BIツール「Oracle Discoverer」が提供するユーザー・インターフェースをそのまま使えるようにしている。「MDに聞いたところ、使いやすさよりもむしろ、新しい視点での分析や長期間の情報を参照したいという要望がありました。多少画面の表現力が乏しくても、自ら分析の視点を切り換えたり、再集計したりと、自由に分析できるほうがよいと判断し、ツールをそのまま使えるようにしました」（板倉氏）

将来の展望

3年間で30%のコスト削減

サークルKサンクスは、新旧システムとも運用/保守を富士通の「館林システムセンタ」へアウトソーシングしている。これだけのシステム規模になると、ユーザー企業側で最新のノウハウや技術を保持していくことが、コスト的に難しいと判断しているためだ。現在のシステム本部は20数人。「アウトソーシングしなければ、この人数ではやっていけないシステム規模です。それに、アウトソーシングしているからこそ、最新技術を利用できるという利点があります」（板倉氏）。

中でもストレージのアウトソーシングは、今後の必要量を見越して多めに契約するのではなく、必要ストレージ量に応じて、随時サービス利用料を増額していく「ストレージ・オン・デマンド」型の契約にした。これにより、運用コストを最適化することができる。

従来システムはSPARCベースのSolaris搭載サーバであり、安定して利用できていた。その意味では、今回、CPUをItaniumに、OSをLinuxに変更する必然性はなかった。しかし、メインフレーム並みの信頼性とオープン・システムの柔軟性を兼ね備え、最新技術を採用したPRIMEQUESTに移行することにより、レスポンスの向上とコストの削減が果たせるようになった。「今回のシステム更新により、今後3年間で30%の開発/運用費削減を目指しています。ほぼ目標を達成できそうな状況です」（板倉氏）。

前ページ     導入の背景・システム概要

---

【サークルKサンクス様 概要】

本事例中に記載の肩書きや数値、固有名詞等は掲載日現在のものであり、このページの閲覧時には変更されている可能性があることをご了承ください。