企業システムのユーザー拡大~社員から社会へ
今回は、ユビキタス時代のもう一つのシステム要件である“ノンストップ化”を考えてみたい。ユビキタス時代とは、以前の回で指摘したように、インターネット経由で企業情報システムが社会に開かれる時代のことである。それまでの社内あるいは関連会社の社員を主なユーザーとするシステムでは、ユーザーである社員が勤務していない時間帯を利用して夜間バッチ処理を行う仕組みで基本的に問題がなかった。しかし、基幹系のシステムが社会に開かれるようになると、システム要件に変化が生じる。第一には、前回議論したように、Googleの検索エンジンが遭遇したデータ爆発、あるいはビックデータへの対応が求められることだ。第二には、システムは24時間365日、基本的に停止することが出来なくなる。そして、そのことは、従来のようにバッチ処理のための時間が取れなくなることを意味する。今回は、このことをテーマに議論を行う。
ユビキタス化の求めるノンストップ、リアルタイム処理
基幹系システムをノンストップ対応にするための最大の問題点は、データ分析帳票処理の中にあると筆者は考えている。即ち、従来は多様な集計・分析帳票類はバッチ処理で作成されていた。そして、これと同じことをリアルタイム環境で作成できるようにすることが実は容易ではないのである。例えば、多くの顧客に多様な商品を全国の支店網を使って販売している企業を想定してみよう。仮にファッション関係の商品を販売しているような企業の場合、ユニクロで有名になったSPA(製造小売り)業態のように、売れ筋を素早く掴んで、迅速に生産し店頭に並べることが重要視される。そのような企業では、現在でも当日の売れ行きデータを各支店のPOS情報からリアルタイムで集計し、売れ筋を把握できる体制を組んでいる。このようなリアルタイム集計の仕組みをビッグデータ対応を前提にして、システムに組み込むことが求められるのである。
このような集計処理の場合、求めるキー項目の順序、例えば、【支店別―顧客別―商品別】というような分類で集計を取ることが必要になる。しかし、【支店別―商品別】という集計も同時に必要とされることが多い。また、全社集計の【商品別】ももちろん必要になる。このような分類キーの異なる集計は、従来はバッチ処理で、蓄積された入力データを当該キー順にソーティングすることで処理が行われた。つまり、この三つの集計が必要な場合は、三回異なるキー順でソーティングと集計が行われ、その結果がマージされ、求める帳票が完成する。しかし、リアルタイム環境では、このようにデータを溜めておいてソーティングするという手法をとることはできない。つまり、バッチ処理が使えなくなると、集計処理に使われていたソーティングも使用できなくなる。そして、ソーティングにより行われてきた特定のキー順への並べ替えと全く同じ効果を持つリアルタイム環境での写像技術とそれを組込んだ集計技術が必要とされるのである。
必要なものは「オブジェクト指向データベース」同等のもの
従来のソフト技術を使うだけで、果たしてリアルタイム処理が可能なのであろうか。以下、従来技術を用いたソリューションを検討してみる。
<リアルタイム集計の実装可能性>
(1)配列(Array):従来の言語仕様の中で、このような組合せものを表現する手段として配列がまず思い浮かぶ。しかし、配列の利用には、次のような問題がある。まず第一に、配列の大きさを最初に定義しておく必要があり、件数不定の状況では使いにくい。第二には、現実のデータを配列で扱うと、ほとんどの値が0か空になってしまう。この問題は、スパース(sparse:まばらな)配列問題として、従来より良く知られている。第三には、所要のコマの数が各項目の要素数の掛算になり、あっという間に巨大な数になることである。従って、配列は現実的ソリューションにはなりにくいのである。

(2)オブジェクト指向言語におけるClass定義:オブジェクト指向言語では、ユーザーが定義できるデータ型(Class)を自在に定義できる。図4-1に示すのは、会員間で受発注が同時に起こるようなケースでの各会員毎の集計用のクラス定義の構造を示したものである。このようにオブジェクト指向言語では、Class定義の中の変数の属性として、別のClass型を書くことができる。これを利用することで、複雑な集計構造を表現することは可能である。但し、このクラス構造に則してデータを集計する機能やこのクラス構造から必要なデータを照会する機能などは、プログラマが自分でコーディングすることを求められる。この方法の場合、処理可能な上限は実際上は動作しているコンピュータのメモリ空間の大きさに限定される。大きなデータを扱うには、この方法でもスケールアウト環境への拡張が求められることになる。
(3)RDBによる解決:従来型の方法では、RDBを使って何とか可決策を見つけることに尽力するのであろうが、複雑な集計構造の場合は対応が難しく、処理可能なケースは極めて限られることになる。
このような検討から見えてくることは、結局、(2)のケースの汎用的な管理ソフト、即ちオブジェクト指向データベース(OODB:Object Oriented Data-Base)と同等の機能を持つ何らかの基盤ソフトが必要であるという結論に落ち着く。しかし、これまでのところ、どんな問題にも対応可能なオブジェクト指向データベースは存在していない。Googleの開発したBigTableも、あくまでも同社の問題に特化した解決策である。つまり、この分野は、最も最先端の技術開発が行われている現在の焦点に位置するのである。
NoSQL技術の意味するもの
最近、NoSQLというデータ管理のソフトが注目を浴びている。それは、従来のデータ管理ソフトの標準技術であるSQL(Sequential Query Language)系のデータベースではできないデータ管理技術を提供するソフトのジャンルというような意味である。以下に上げるのが、NoSQLと呼ばれる技術である。
<NoSQL技術>
(1)Key-Value Data Store:キーとなる文字列からそれに該当する文字列を瞬時に取り出す機能を提供する。つまり、キー文字列と何らかのオブジェクトとの間の写像関係を表現できる技術なのである。オープンソース(OSS)のmemcachedが有名である。
(2)テーブル型データベース:テーブル型のインデックス部分を持ち、複数のキーの指定に対応して、該当のデータをアクセスする機能を提供する。代表例は、Googleの開発したBigTableやFacebookが以前に利用していたCassandraなどが有名である。
これらのNoSQL技術が出現する背景は、インターネットを基盤とするビジネスでは、ノンストップ、リアルタイムの処理技術が必要とされ、それに対応するために、これまでの標準的なデータ処理技術であるSQL技術では実現できない複雑な構造への対処やより迅速な写像処理能力が求められているということである。
リアルタイムDWH(Data Ware House)の登場
このような情勢を反映して、リアルタイムDWHというジャンルのソフトウェアが登場し始めている。つまり、従来の基幹系と情報系の双方を合わせたような機能で、特徴は、オンライン処理で入力されたデータがそのままバックエンドでリアルタイムDWHの中に分類・集計されてしまうというものである。つまり、ユビキタス化の特徴であるノンストップ環境で、データ分析機能を提供しようとするものである。このような製品は、今後、基幹系システムがユビキタス化していくに連れて、その必要性を増すことは間違いない。そして、この分野は、ここ暫くのソフトウェア開発競争の焦点になると筆者は考えている。このような基盤ソフトウェア群を筆者は「アプリケーション基盤ソフトウェア」と呼んでいる。つまり、ノンストップ環境下で利用者が欲しがる任意のデータ集計・分析機能を簡単に提供するようなソフトウェアのことである。巨大バッチ処理に関しては、Googleの開発したMapReduceが、そしてOSSではHadoopがまさにバッチ処理分野でのアプリケーション基盤ソフトウェアに該当すると思われる。そして、ノンストップ・リアルタイム処理環境で自在なデータ集計・分析機能を提供できる基盤ソフトウェアの開発が今、世界中で盛んに行われているのだ。これに成功し、クラウドにその機能を装備することができれば、そのクラウドベンダーは間違いなく、ユビキタス時代の最先端のクラウドになるに違いないだろう。
CIO諸氏におかれては、このような最先端の動向に注目する日々が続くことになるだろうと拝察する。そして、自社基幹系のユビキタス化、及び基幹系と情報系の統合などの再構築プロジェクトの発進時期がいつになるかを熟慮することになろう。そこで、次回は、システム開発プロジェクトを成功裏に制御する問題をテーマに取り上げる。






Follow CIO on Twitter
Fan CIO on Facebook
RSS
記事一覧

Header_Social_Icon