大規模分散処理システムの商用サービス例

対象とした商用のサービスの適用イメージを示す．検索サービスのシステムである CBoC タイプ 2 は，大規模で多種多様なデータの加工・分析を目的として，数百台の PC サーバで連続に安定し て大規模データを分散し蓄積・処理をする．

具体的なサービスの処理は図 6 に示すとおり，クローラーが Web サイトからのデータを収集し て CBoC タイプ 2 に書き込む．クローラーは，定期的に Web データを収集する．そのため，クローラ ーは CBoC タイプ 2 にランダムライト（不規則な書き込み）を行う．そして，データ分析が CBoC タイ プ 2 からデータを読み出して，検索エンジンに必要な検索インデックスを作成する．データを読み 出す際に，検索要求に対する内部の処理を行うアプリケーションとして，収集データ編成ツール

（MapReduce）とスマートキャッシュがある．収集データ編成ツールは，書き込まれたデータをシーケ ンシャルリード（順次読み出し）で CBoC タイプ 2 から読み出す．スマートキャッシュは，検索時のラ ンダムリード（不規則な読み出し）でキャッシュとして利用する．データ分析は，収集データ編成ツ ールによって CBoC タイプ 2 からシーケンシャルリードによるデータにより検索インデックスを作成し たり，テキストの内容（分析 AP）や画像などのマルチメディアデータ（マルチメディア分析）を分析し て結果をランダムライトで書き込んだりする．ユーザからのデータの検索問い合わせ時には，検索 エンジンがインデックスを利用し蓄積されたデータから検索をして，結果をユーザに返却する．シス テム検証では，上記に示した処理を検証項目として作成し機能要件を確認する．

これらのユースケースを表 5 に，処理のタイミングを図 7 示す．ユースケースにおけるランダムラ イト，シーケンシャルリード，ランダムリードは，ワーカにあるデータに対してランダム(不規則)にアク セスするか，シーケンシャル（順次）にアクセスするかということである．各 AP は，それぞれのタイミ ングで動作しているため，タイミングにより同時に動作する．また，それぞれの AP はマシンの集約 により同一マシンで動作する設計が可能である．同一マシンで動作する場合，各 AP が同時に動 作することを考慮し，マシンのメモリやネットワーク（NW）を互いに共有して動作する必要がある．そ のため，キャッシュメモリの使用量やネットワークのバッファの上限値を決めて，互いの動作に影響 が及ばないようにしている．もし大量のデータを書き込む場合は，バッファの上限値を変更しなけれ ばならない．

バック

エンド データ 分析

検索エンジン

MapReduce

インデクサ 分析AP

検索 インデクス 検索

検 フロント 索

蓄積

・解 析

検索エンジン 検索 インデクス 検索

インデクス更新

分散ファイル 分散テーブル

分散 ロック

クローリング 収集

携帯サイト Webサーバ

クローラ クローラ クローラ クローラ

CBoC タイプ2

読み出し

書き込み

データ収集

マルチメディア 分析

図 6. CBoC タイプ 2 の検索サービスにおける適用イメージ

表 5. ユースケース(例）

ユースケース AP 処理

（タイミング）

説明

データ収集 処理

クローラー ラ ン ダ ム ラ イ ト

（定期的）

Web データを収集してそのデータを システムに書き込む

検索要求 処理

収集データ編成 ツール

シーケンシャル リード（定期的）

Web データを分析用に編成する

スマートキャッシュ ラ ン ダ ム リ ー ド

（随時）

検索を高速化させるための事前の データキャッシュ機能

データ分析 処理

テキスト内容分析 ランダムライト，

ラ ン ダ ム リ ー ド

（随時）

検索の問い合せに対しテキストの内容 を分析し結果を返却する

マルチメディア分析 検索の問い合せに対しマルチメディア

データを分析し結果を返却する

時間 クローラによる書き込み

収集データ編成ツールによる読み出し

テキスト内容分析による書き込み・読み出し マルチメディア分析による書き込み・読み出し スマートキャッシュによる読み出し

インデックス生成

図 7. AP の走行タイミング

一方，非機能要件としては，耐障害性や性能や精度の検証がある．表 6 に CBoC タイプ 2 にお いて，１行目のデータ格納規模で規定されている耐障害性，性能要件，精度を例として示す．

耐障害性は，システムを構成する 1 台のサーバで故障が発生しても，システム全体は継続して 運用が可能であることを確認する．

性能の確認は，ユースケースにおいて，設計された必要な性能である性能要件を満たしている ことを確認する．CBoC タイプ 2 のシステム検証における性能の確認は，サーバ数百台規模でデー タの読み出し／書き込みが規定された性能要件の数値以上であることを確認する．

精度の確認は，テキストの内容分析とマルチメディア分析では異なる．テキストの内容分析では，

問い合わせにキーワードを使用し，パターンマッチングによって返却された結果を確認する．マル チメディア分析では，特徴量を使用し，類似度検索によって返却された結果を確認する．特徴量を 使うことにより，検索時間を短縮し，検索精度を向上することができる．（付録 4 参照）

表 6. 要件（例）

要件 データ

格納規模

サーバ数百台規模で 30 億レコードのデータを格納

（1 レコードは，1Web ページの情報を格納）

耐障害性 単一障害が発生しでもシステム全体は継続して運用が可能であること データ

書き込み性能

テキスト： 30 億レコードを 1 日で書き込みができること

マルチメディア： 30 億レコードの 1/100 を 1 日で書き込みができること データ

読み出し性能

テキスト： 30 億レコードを半日で読み出しができること

マルチメディア：30 億レコードの 1/100 を 1 日で読み出しができること

精度 テキスト： パターンマッチングでキーワード検索できること マルチメディア： 類似検索ができること