節電・省エネ提案事例集 · 「省エネ提案書」作成までのプロセス 「省エネ提案書」の作成依頼 ・お客様が当社営業マンに依頼 ・お客様のご要望をヒアリング
平成 23 年度 次世代高信頼・省エネ型 IT 基盤技術開発・実証事業 事業 ...
87
平成 23 年度 次世代高信頼・省エネ型 IT 基盤技術開発・実証事業 （クラウド・コンポーザビリティをサポートする PaaS システムの開発） 事業報告書 平成 24 年 3 月 30 日 株式会社 IIJ イノベーションインスティテュート
Transcript of 平成 23 年度 次世代高信頼・省エネ型 IT 基盤技術開発・実証事業 事業 ...
平成 23年度
次世代高信頼・省エネ型 IT基盤技術開発・実証事業
（クラウド・コンポーザビリティをサポートする PaaSシステムの開発）
事業報告書
平成 24年 3月 30日
株式会社 IIJ イノベーションインスティテュート
1． 本事業の目的と背景 ........................................................................................................... 1
1.1. 目的 .................................................................................................................................... 1
1.2. 背景 .................................................................................................................................... 2
2． 本事業で開発する技術 ....................................................................................................... 3
2.1. クラウド・コンポーザビリティ ........................................................................................ 3
2.1.1. クラウド・オントロジーから考察できるクラウド間連携 .......................................... 4
2.1.2. 本事業が提案するクラウド間連携 .............................................................................. 7
2.1.3. クラウド間でのデータベース連携 – 本開発でのモデルケース .............................. 10
2.1.4. ウェブ・サービスのオブジェクト的理解 ................................................................. 11
2.2. 統一的クエリーインターフェース ................................................................................... 13
2.2.1. 統一的クエリーインターフェースの導入シナリオ................................................... 14
2.2.2. 平成 22年度開発「バックエンド・ストレージのサポート」 .................................. 16
2.2.3. Google AppEngine のサービス ................................................................................. 17
2.2.4. Google AppEngine for Python のストレージ・アーキテクチュア ............................ 18
2.2.5. GAE/P Datastore の低水準 API ................................................................................. 19
2.2.6. クエリーインターフェースの標準化 ........................................................................ 20
2.2.7. 統一的クエリーインターフェースの初期バージョン ............................................... 22
2.2.8. 統一的クエリーインターフェース初期バージョンの課題 ........................................ 25
3． 平成 23年度の開発 .......................................................................................................... 27
3.1. バックエンド・ストレージのサポート ........................................................................... 28
3.1.1. サポートする KVS の選定......................................................................................... 28
3.1.2. CQI の課題 ................................................................................................................ 29
3.1.3. PHP Data Objects（PDO）対応版 CQI .................................................................... 30
3.1.4. CQI Cache Driver ...................................................................................................... 32
3.1.5. ZipBench .................................................................................................................... 36
3.1.6. Wisconsin Benchmark ............................................................................................... 40
3.2. PaaSアプリケーション ................................................................................................... 51
3.2.1. PaaSアプリケーション開発を支援する機能の検討 ................................................. 51
3.2.2. CQIと併用可能な既存の PHPアプリケーション開発支援ツール・ライブラリ ...... 52
3.2.3. YCSB Web UI の開発 ................................................................................................ 53
3.2.4. SPECweb2009 Web UI 開発 ..................................................................................... 60
3.3. リソース・ディレクトリ ................................................................................................. 66
3.3.1. リソース・ディレクトリのコンセプト ..................................................................... 66
3.3.2. クラウド・システム内の管理情報の集約・共有 ...................................................... 68
3.3.3. リソース・ディレクトリの実装 ............................................................................... 69
4． 開発成果の外部リリース ................................................................................................. 70
4.1. Cloudbusting Machine（CBM）0.1 .................................................................................. 70
4.2. Cloudbusting Machine（CBM）0.2 .................................................................................. 71
4.3. 今後のリリース ................................................................................................................ 71
5. 今後の課題 .............................................................................................................................. 72
5.1. クラウド・コンポーザビリティ ...................................................................................... 72
5.2. 統一的クエリーインターフェース ................................................................................... 72
付録 A. YCSBによる Key-Value Storeの性能評価 ..................................................................... 73
A.1. Key-Value Store の概要 .................................................................................................... 73
A.2. YCSBについて ................................................................................................................ 74
A.2.1. YCSBの評価方法 ...................................................................................................... 74
A.2.2. Benchmark Workload ................................................................................................ 75
A.3. ベンチマーク ................................................................................................................... 77
A.3.1. Benchmarking Cloud Serving System with YCSB との相違点 ................................ 77
A.3.2. 測定条件 ................................................................................................................... 77
A.4. 測定結果 .......................................................................................................................... 78
A.4.1. Workload A ................................................................................................................ 78
A.4.2. Workload B ................................................................................................................ 80
A.4.3. Workload C ................................................................................................................ 82
A.4.4. Workload D ................................................................................................................ 83
A.5. 考察 ................................................................................................................................. 84
1
1．本事業の目的と背景
1.1. 目的
本事業はクラウド・コンポーザビリティに基づくクラウド間連携技術は運営主体（事業者）
の異なるクラウド間でのサービス連携やサービス移行を容易にする機能を提供することを
目的としている。これを活用するとエンドユーザーが開発するクラウド・アプリケーショ
ン（およびそれを使ったサービス）の特定のクラウド・サービス事業者への依存性を回避
でき、複数のクラウド・サービス事業者が提供するクラウド・インフラストラクチュアに
またがるサービス構築が可能となる。ロケーション的な分散を大前提とする災害等への耐
性を持つサービスの実現には必須の機能である。
●平成 23 年度の開発項目
平成 23 年度は前年度の開発成果である PaaS システムとバックエンド・ストレージのサポ
ートの機能充実を図るとともに、クラウド・コンポーザビリティに基づくクラウド内連携
の技術確立の達成を目的とする。
バックエンド・ストレージのサポート
平成 22年度の開発成果に加え新たなKey-Value Storeを 3件程度追加サポートすると
ともに、ベンチマーク等を活用して性能評価・チューニングを実施し、商業レベルの
需要に応え得る性能と品質の達成を目指す。
PaaS アプリケーションの開発
商業レベルでのアプリケーション実行環境を想定し、複数のスクリプト言語によるア
プリケーションが混在する環境での実行環境のモデリングを行って、PaaSがサポート
すべきシステム・コンポーネントを規定するとともに、それを活用したアプリケーシ
ョン事例を作成する。
クラウド・サービスの技術調査
既存クラウド・サービスが提供する仮想サーバー環境の CPU・ディスク・ネットワー
クといった基礎的コンポーネントの性能の把握を行った平成 22年度の調査に引き続き、
平成 22 年度の開発成果を活用して PaaS システムによるアプリケーション・レベルで
の総合的な性能評価を実施する。
リソース・ディレクトリの開発
クラウド・コンポーザビリティによる各種連携のデータ共有基盤となるリソース・デ
ィレクトリの開発を行う。平成 22 年度に検討したクラウド間連携に関する想定モデル
に基づきメタデータの定義を行い、リソース・ディレクトリを介したメタデータ情報
の共有を確認する。
2
1.2. 背景
本事業では提案時に下記の 2 つの要求に対応可能な PaaS サービスの必要性を述べ、その事
業化の前提となる主に PaaS システムの開発、および開発成果のオープンソース・ソフトウ
ェアとしての配布を提案した。
ハイブリッド・クラウドおよびコミュニティクラウドのサポート
情報の収集・分析に優れたクラウド・アプリケーションの開発支援
● 平成 22 年度の開発項目
平成 22 年度はクラウド・コンポーザビリティをサポートする PaaS システムの基盤を形成
するクラウド・アプリケーション実行環境（PaaS コア）の開発を行った。PaaS コアの開
発では一般的なウェブ・アプリケーションの実行環境をベースに次の要件を満たす追加実
装を行うことを目的としていた。
HTTP トラフィックに対するスケールアウトを考慮したロードバランシング
一般的なウェブ・サービスを行うアプリケーションは複数の HTTP サーバー上で並列
的に実行されるが、特定の HTTP サーバーにアクセスが集中しないようロードバラン
シングを行う。特にクラウド・コンピューティングではスケールアウトにより HTTP
サーバーの稼動数が動的に増減するため、それを考慮したロードバランシングが必要
となる。
クラウド・コンポーザビリティ属性を含むメタデータのサポート
クラウド・コンポーザビリティを実現するためには個々のウェブ・アプリケーション
において外部インターフェースを定義する必要がある。クラウド・コンポーザビリテ
ィ属性を含むメタデータを規定し、ウェブ・アプリケーションが稼動する全てのホス
トの間で共有・管理する機構が必要となる。
複数のバックエンド・ストレージ実装のサポート
一般的なウェブ・アプリケーションでは処理データはデータベースなどに格納される
が、一般的なデータベースはスケーラビリティに劣りクラウド環境への適用には適さ
ない。クラウド環境特有のスケールアウトに対応可能なストレージ・システムである
Key-Value Store などをバックエンド・ストレージとしてサポートする必要がある。
既存の複数のクラウド・サービスでの動作のサポート
PaaS コアをデファクトスタンダードとして普及させるためには、前項の要件を満たす
実行環境が既存の複数のクラウド・サービス上で動作しなければならない。
3
2．本事業で開発する技術
本事業はクラウド・コンポーザビリティのコンセプトに基づくクラウド間連携技術の開発
を目的としている。同技術ではクラウド間連携において今後規定されるであろう各種のデ
ータ交換プロトコルやデータフォーマットの仕様を規定するのではなく、クラウド間連携
そのものをサポートするプログラミング・プラットフォームを提供することにより仕様定
義に対する最大限の自由度を担保することを目指している。同技術を検討する過程で、ク
ラウド間で連携するサービスの提供者と利用者の間を取り持つ抽象的なインターフェース
の定義が必要であった。その解決策として本事業は統一的クエリーインターフェース（CQI）
を定義した。以降、クラウド・コンポーザビリティのコンセプト、そのコンセプトに基づ
くクラウド間連携、統一的クエリーインターフェースについて順次説明をする。
2.1. クラウド・コンポーザビリティ
クラウド・コンポーザビリティは “Toward a Unified Ontology of Cloud Computing”
(http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf) で紹介されているコ
ンセプトで「1 つ以上のクラウド・サービスを組み合わせて新たなクラウド・サービスを生
成する能力」と定義されている。
一般に情報システムにおける「コンポーザビリティ」とは、コンポーネントの相互関係を
扱うシステムの設計原理であり、多様で複雑なシステム構成（コンフィグレーション）が
可能なシステムでは組換え可能なコンポーネントを提供しており、個々のユーザーのニー
ズを満たすために様々な組み合わせで選択して組み立てることができる。コンポーネント
を構成可能にするためには「自己完結型」や「ステートレス」といった基本的な特性を備
えている必要があるが、同論文ではこのコンセプトは「サービス指向アーキテクチュア
(SOA)におけるサービス・コンポーザビリティのアイデアをクラウド・サービスに適用した」
と説明されており、異なるクラウド・コンポーネント（クラウド・サービス）の相互関係
を規定するための手段として活用されている。この考え方に基づいてクラウド・サービス
を分類し、レイヤー化したものが図 1 に示すクラウド・オントロジー (Cloud Ontology) で
ある。
4
図 1
2.1.1. クラウド・オントロジーから考察できるクラウド間連携
“Toward a Unified Ontology of Cloud Computing”ではレイア毎に独立したサービスが実
現でき、あるレイアのクラウド・サービスはそれよりも下位レイアに位置するクラウド・
サービスを活用して実装ができると主張している。例えば「仮想マシンを提供する IaaSを
活用して PaaS を実現する」といったアプローチで、図 2 の例では IaaS が運用されるパブ
リック・クラウド（黄色の円）やプライベート・クラウド（緑色の楕円）の環境の上に多
数の PaaS が稼働するイメージが想定している。
プログラミング・プラットフォームである PaaS はパブリック・クラウドやプライベート・
クラウドなどの IaaS の上のみならず、物理サーバーから構成されるクラスタでも稼働する
ことができる。しかしながら複数の IaaS やクラスタで稼働する PaaS を連動させ 1 つの
PaaSサービスとして統合させるクラウド間連携を実現させるためには PaaS間での連携機
能を必要とする。図 2 での青色の矢印はこの PaaS 間連携を意味している。図 3 および図
4 はこのようなクラウド間連携のより具体的な事例を示したものである。
5
図 2
図 3 は二つの DaaS を束ねて一つの DaaS サービスに見せるモデルである。このモデルは
ハイブリッド・クラウドに対する実際的な要求、例えばプライマリとセカンダリの二つの
ストレージを用意してクラウド・サービスのデータ信頼性を向上させる。
図 3
6
図 4 は既存の IaaSを連携させて一つの Meta IaaS（仮想的な IaaS）として機能させるこ
とを想定したモデルである。IaaS の生成時あるいは起動時に必要なサーバーの初期イメー
ジなどは予め DaaS に展開しておいて、それを参照して IaaS の生成・起動を行う。スケー
ルアウト可能な IaaS を連携させる必要性に疑問を持つ向きもあろうが、実際には IaaS の
サービス内容やコストの問題からこのような連携が必要になるケースは多いと思われる。
図 4
7
2.1.2. 本事業が提案するクラウド間連携
前節で説明したようにクラウド・コンポーザビリティはクラウド・サービスをある種のサ
ービス・コンポーネントとして捉える視点を提示しているが、本事業ではこの考え方を更
に押し進め、クラウド間連携を「既存のクラウド・サービスをコンポーネントとして理解
して、これらを組み合わせた仮想的なコンポーネントを定義する」試みと捉えた。すなわ
ち「比較的小規模なクラウド・データセンターを水平統合して仮想的な大規模クラウド（メ
タ・クラウド）を実現する技術」と位置づけ、そのための基本原理として「クラウド・コ
ンポーザビリティ」を採用した。
本事業が提案する Platform as a Service (PaaS) はクラウド・コンポーザビリティに基づく
クラウド・コンポーネント間の相互関係を定義するインターフェースの設計・実装を支援
するプログラミング・プラットフォームを提供する。一般にクラウド・サービスの外部イ
ンターフェースのほとんどはウェブ・サービスとして実装されていることから、クラウド・
サービスの連携にウェブ・サービス連携の技術を活用する試みは非常に自然なアプローチ
である。
しかしながら、ビッグデータ処理が暗黙のうちに期待されることが多いクラウド・サービ
スにおいてその処理効率を高めるには、処理対象とするデータのコンピュータ間の移動を
最小限に留め極力分散並列的に処理を行うことが望ましいとされており、従来とは処理と
データの取り扱いが逆転する。例えば分散環境おいて任意のデータ処理を行う場合、従来
の方法ではデータ処理を行うソフトウェア（実行形式プログラムやスクリプト）は特定の
サーバーなど処理装置に固定的に配置し、その処理装置に対し何らかの手段を使って処理
対象となるデータを送り込む方式を取るが、ビッグデータ処理を行うクラウド環境では処
理対象となるデータが格納されているストレージ装置にデータ処理ソフトウェアを送り込
んでデータ処理を行う方が効率的である。このようなビッグデータ処理を念頭においたク
ラウド向けデータ処理フレームワークの事例としては Googleの MapReduce などが広く知
られている。ビッグデータ処理を前提としたクラウドの相互連携の効率性では次のような
課題がある。
データ交換サイズの最小化
従来のウェブ・サービス連携を支える技術では主にデータ移動に焦点を当てた標準化や技
術開発が進められ、データフォーマットやプロトコルでは汎用性を高めるため冗長なデー
タ構成になることが多い。前述のクラウド・サービスでの処理効率改善を図るためには必
要最小限のデータのみを交換する方式が望まれる。
8
伸縮性のある計算リソースの活用
伸縮性のある計算リソースを抱えるクラウド・サービスの場合、従来のウェブ・サービス
とは異なりサーバーサイドの計算リソースを利用者毎に動的に割り当てることが可能であ
る。この計算リソースを前項の「データ交換サイズの最小化」に活用することもできる。
本事業ではこのようなクラウド環境特有の特性を踏まえ、クラウド間相互連携に適したデ
ータ交換モデルを考案した（図 5）。図の上段は従来のウェブ・サービス連携に置けるデー
タ交換のモデルで、アプリケーションはサービス側が公開している WebAPI を利用してサ
ービス連携を実現するが、これはサービス側にのみ任意性が担保される比較的にクローズ
ドなサービスとして機能する。
図 5
図 5 の下段は本事業が提案するサービス連携の概要を示したものである。その特徴は従来
のウェブ・サービス連携ではアプリケーションの一部に組み込まれていた外部サービスか
ら収集したデータの選択やフォーマット変換などの処理を別プログラムとして実装し、サ
ービス提供側に送り込んで実行するところにある。この方式のメリットはアプリケーショ
ン−サービス間のデータ交換をアプリケーション側で作り込むことで、そのニーズにより転
9
送データのサイズやデータ取得頻度を決定できるため、効率良いサービス連携が可能にな
る。またデータ転送の秘匿化も容易になるのでサービス連携の安全性を向上することも可
能になる。
この方式での解決すべき本質的な課題は「サービス側に送り込むプログラムをどのように
作成し実行するのか？」という問題である。本事業が提案する PaaS システムではクラウド
間連携において今後規定されるであろう各種のデータ交換プロトコルやデータフォーマッ
トについて、その具体的な仕様を規定するのではなく、そのサポート・プラットフォーム
を提供することにより仕様定義に対する最大限の自由度を担保することを目指す。
このプラットフォームでは、クラウド連携機能の開発者に対しクラウド間連携に必要なデ
ータ交換プロトコルやデータフォーマットを任意に選択できることを許容するが、連携を
行うサービスの提供者と利用者との間の標準的インターフェースだけは規定する必要があ
る。本事業ではそのための手段として統一的クエリーインターフェース（CQI）を考案した
が、その詳細は後述する。
オープンソース・ソフトウェアの普及に伴いプログラミング・プラットフォームの可搬性
は著しく向上したが、さらにクラウド・サービスが急速に普及しつつある今日、利用者が
望む任意のプラットフォームが任意のロケーションで稼働できる状況は現実のものとなり
つつある。本事業が提案するクラウド関連携に伴うデータ交換への PaaS の活用は今後のク
ラウド・コンピューティング応用の 1 つの方向性を示すと考えている。
10
2.1.3. クラウド間でのデータベース連携 – 本開発でのモデルケース
本事業では、クラウド・コンポーザビリティに基づくクラウド間連携をより具体的に検討
するために現実的かつ単純なモデルケースとして、図 6 に示すようなデータベースの連携
を定義した。
図 6
図中のパブリック・クラウドではウェブ・サービスが稼働しており、そのコンテンツはパ
ブリック DB に納められていると仮定する。（注: パブリック DB は公開されているわけで
はない。「パブリック・クラウド上で稼働するデータベース」の意味である）次に、プライ
ベート・クラウドにおいて、オリジナルのウェブ・サービスをベースにしたプライベート・
ネットワーク内限定の拡張サービスを稼働させるとする。単にサービスを複製するのであ
ればパブリック DB に納められている（サービスを実現する）ウェブ・アプリケーション
とコンテンツをその変更に応じて随時プライベート・クラウドにコピーすれば良いのだが、
ここではプライベート・クラウドでは独自に改変を行った拡張サービスを運用したいと想
定する。通常、従来のウェブ・サービス構築ではオリジナル・サービスとは独立した拡張
サービスを構築し両者を組み合わせるマッシュアップ手法が使われる。しかしそのような
組み合わせでは両者はサービスとして統合されている訳ではない。サービスを統合し 1 つ
の仮想的なサービスとして見せるためにはデータベースを抽象化し、常時そのコンテンツ
の同期を行う機構が必要である。
11
2.1.4. ウェブ・サービスのオブジェクト的理解
本事業では、ここで言う「統合」をオブジェクト指向でのオブジェクトの継承のイメージ、
すなわち「既存のウェブ・サービスを継承する新たなウェブ・サービス」を実現すること
がクラウド・コンポーザビリティ的なクラウド間連携だと理解した。そのために既存のウ
ェブ・サービスを下記のようなオブジェクト指向のような枠組みで理解することとした。
（図 7）
ウェブ・サービスはスクリプトとコンテキストから構成される
アプリケーション毎に 1 組のコンテキスト（状態データ）が存在する
アプリケーション毎に複数のスクリプト（実行プログラム）が存在する
各スクリプトは各々URL と 1 対 1 にマップされる
ウェブ・サービスの継承とは原則としてスクリプトとコンテキストのコピー
スクリプトの更新を考えなければ、既存スクリプトのコピーは原則として 1 回だ
けである
コンテキストのコピーはサービスレベルにもよるが原則としてデータ同期を維持
する必要がある
ウェブ・サービスを拡張するためには
同一コンテキストを参照する独自スクリプトを追加する
同一フォーマット（スキーマ）に基づいて独自データをコンテキストに追加する
この考え方に基づくとクラウド・コンポーザビリティとは「ウェブ・サービスを継承する
能力」と規定することができ、具体的には「ウェブ・サービスをスクリプトとコンテキス
ト単位で外部からの参照を許容する」機能を提供することとなる。ウェブ・サービスを継
承する機能はプラットフォームでサポートされるが、継承するサービス側では外部のコン
ポーザビリティを有するウェブ・サービスを参照する機能が、継承されるサービス側では
外部からの参照の許可・拒絶を行う機能が必要となる。
12
図 7
13
2.2. 統一的クエリーインターフェース
本事業が提案するクラウド間連携機能では、サービスの提供者が運営する環境においてサ
ービスの利用者が作成したソフトウェアを実行することにより、クラウド間連携に関わる
データ交換処理をサービスの提供者−利用者間のインターフェースから分離することによ
りクラウド間連携の効率性を向上させるが、その実現にはサービス利用者が作成するソフ
トウェアから利用可能な形でサービス提供者のデータにアクセスできなければならない。
その際に問題になるのが提供者−利用者間の標準的なインターフェースである。本事業では
この問題の解決手段として統一的クエリーインターフェース（CQI）を規定した。CQIでは
サービス利用者はストレージ・システムを介してサービス提供者のデータにアクセスする
ことを前提したクエリー処理をサポートする。サービス利用者はCQIを活用して、サービス
提供者が開示するデータ・セットから必要なデータのみを選択して取得することが可能で
ある。
通常のウェブ・アプリケーションではRDBをストレージとして利用することが一般的だが、
クラウド環境ではスケーラビリティに優れ大規模データを格納することができる
Key-Value Store（KVS）などのクラウド向けストレージ・システムの活用を検討する事例
も多い。その背景には大規模データの格納・参照に関わる技術的な困難さが存在する。テ
ラバイトあるいはペタバイト級の巨大データは既存のRDBには格納することは困難であり、
KVS はそのようなデータが現実のものとなっている今日のニーズに対応するために登場し
た技術である。
しかしながらプログラミング・インターフェースのサポートを考えた場合、歴史が古い RDB
では SQL のような標準的なアクセス方法が定着しているので、そのインターフェースの定
義は比較的容易であるが、歴史が浅く未だ標準的なアクセス方法が定着しているとは言い
がたいKVSをサポートするとなると標準的なインターフェースの定義は格段に困難な作業
となる。基本的なアプローチは次のいずれかであろう。
サポート対象となる KVSを限定しインターフェースを定義する。
複数の KVSをサポートする抽象化インターフェースを定義する
ストレージ・システムを任意に選択できるサービス事業者ならば前者は現実的な選択肢と
なるであろう。しかしながら開発成果が複数のクラウド・サービス事業者にプラットフォ
ームとして導入されることを目指す本事業は後者のアプローチを選択せざるを得ない。そ
こで「複数の KVS をサポートする抽象化インターフェース」として統一的クエリーインタ
ーフェース（CQI）を定義することとした。
14
CQI はクラウド向けストレージとして利用される多種多様なシステムを同時併用可能な環
境を提供する。アプリケーション開発者はこの抽象化インターフェースを学習すれば、本
プラットフォームがサポートするすべてのストレージ・システムを利用することが出来る。
平成 22 年度開発の過程で生まれたこのアイデアに基づき、平成 22 年度開発成果のオープ
ンソース公開の際に初期の実装を取りまとめた。その後、平成 23 年度開発の過程で全面的
な改訂を行い現在の CQI に至っている。現在の CQI の詳細は次章に譲り、ここでは CQI
開発の経緯や背景、初期の実装について説明する。
2.2.1. 統一的クエリーインターフェースの導入シナリオ
CQI は本来、クラウド・コンポーザビリティに基づくクラウド間連携において、サービス−
利用者間のデータアクセスをサポートする抽象化インターフェースを定義する目的で開発
に着手したのであるが、初期のバージョンがまとまった段階で将来の事業化を踏まえそれ
単体でのソリューションを検討することとなった。ここではその検討結果である CQI の導
入シナリオについて説明する。
図 8
●クラウド・サービスへの段階的移行
図 8は一般的なRDBに格納されているデータベースをKVSに移行する状況を想定した事
例で、CQI を活用して段階的な移行が図れることを説明したものである。このような状況
は現在のクラウド・サービスの利用において頻繁に見られる事例であり、そういったニー
ズに CQI が有効であることを示すことで SI ビジネスにおける資産化を企図している。
15
一般的なウェブ・アプリケーションは RDBMS をストレージ・システムとして利用するこ
とが多いが、これらのウェブ・アプリケーションをクラウド環境に移行するためにはスト
レージを RDBMSから KVS へのデータベース移行が必須となる。そこで次のような段階的
移行のシナリオを想定した。
Step1:オリジナル・アプリケーションを PaaS に搭載
Step2:クエリー処理のみを GQL ベースに書き換え
Step3:データベース自体を KVSに移行
このシナリオに従えば、ターゲットとなる KVS の機能やサポートの範囲を確認しながら段
階的なデータベース移行が可能となる。
●データ一貫性への対処策
もう 1 つの導入シナリオは、KVS の弱点とされているデータ一貫性を考慮しなければなら
ない処理への対応に CQI が活用できることを示すものである。以下で述べる状況も実際の
クラウド・サービスを活用したシステム構築の現場では頻繁に議論されるトピックである。
KVS はクラウド向けストレージとして本命視されているが、データベースとして利用す
ることを仮定した場合、トランザクション処理などデータベースのデータ一貫性が重視
されるアプリケーションでは、データ一貫性を犠牲にしてスケ―ラビリティを確保して
いるKVSの利用には限界がある。しかしながらアプリケーションからの視点で見た場合、
データベースに格納するすべてのデータに対して厳格なデータ一貫性が保証される必要
はないことが多い。現実的な対策としてデータ一貫性が厳格に求められるデータに関し
ては RDB に、そうではない大容量あるいは大量のデータに関しては KVS に、とデータ
の特性に合わせたストレージ・システムを使い分ける方法が有効である。CQI は RDB と
KVS の両者へのクエリーを共通化する機能を提供しているので、両者を併用したシステ
ム構築の効率化に寄与する。
以上の 2 つの導入シナリオはいずれも「今後、既存システムをクラウド環境へと移行する
ニーズが顕在化する」という仮定に基づくもので、クラウド・サービス事業の局面では需
要が顕在化している。
16
2.2.2. 平成 22年度開発「バックエンド・ストレージのサポート」
現在の CQI の起源は、平成 22 年度の開発項目である「バックエンド・ストレージのサポ
ート」に始まる。本事業ではプログラミング・プラットフォームの基本設計の際の参考と
して Google AppEngine（GAE）を調査したことから開発システムは多くの点で GAE と共
通するが、「バックエンド・ストレージのサポート」でも GAE のストレージ・アーキテク
チュアの踏襲が見られる。図 9 にそのアーキテクチュアを示す。
図 9
Google AppEngine の技術については次節以降で説明するが、GAE が利用できるストレー
ジはGoogle自身が開発したBigTableに限定している。BigTableはKey-Value Store（KVS）
の代表的な実装事例であるがその実装は非公開であり、更にクラウド・ストレージ分野で
の機能的に優れたオープンソース KVSが多数公開されている技術動向を鑑み、今後 Google
ではないクラウド・サービス事業者では複数のクラウド・ストレージを目的に応じて選択
する需要が顕在化すると考えた。そこで平成 22 年度開発の「バックエンド・ストレージの
サポート」では GAE のストレージ・アーキテクチュアを踏襲し、多種多様なストレージ・
システムをサポートすることを提案した。
17
2.2.3. Google AppEngine のサービス
ここで本事業のプログラミング・プラットフォームの基本設計の参考とした Google
AppEngine（GAE）の技術について触れておく。
Google AppEngine はウェブ・アプリケーションを開発するためのプラットフォームであ
り、開発されたアプリケーションは Google が提供するクラウド環境において SaaSとして
利用することが可能である。GAE のアプリケーションは一般的な PaaSのソフトウェア構造
に準じており、Google が提供する各種サービスへのプログラミング・インターフェースを
サポートしている。既存のウェブ・アプリケーション・フレームワークと併用することも
可能で、アプリケーション開発者とって GAE の SDK は「Google が提供する各種サービス
を利用できるアプリケーション・フレームワークの拡張 API」と見なすこともできる。
図 10
図 10 に GAE がサポートするサービスを示す。データストア（DataStore）は GAE の中
核的なサービスであるが、それ以外にも上記のサービスがサポートされている。これらの
GAEのサービスのほとんどはGAEとは独立したノード・セットで運営されているようで、
GAE の SDK で提供されるサービス API は原則的にそれらのサービスとのインターフェー
ス・ライブラリとして実装されている。
したがって GAE のサービスはバックエンド・サーバーとインターフェース・ライブラリを
18
基本的な構成要素とするアーキテクチュアである。また GAE は複数のプログラミング言語
（Python/Java）をサポートすることから、インターフェース・ライブラリは言語毎に複数
の実装（SDK）が用意されている。ここで注意しなければならないのはサービスによって
各言語向けのインターフェース・ライブラリが全く異なる仕様で実装されている場合もあ
ることである。例えば次節で説明するデータストア・サービスは Python 版と Java 版では
全く仕様が異なり、Python 版ではサポートされている GQL は Java 版ではサポートされて
いない。
2.2.4. Google AppEngine for Python のストレージ・アーキテクチュア
本事業ではクラウド環境でのストレージ・サポートの事例として GAE を参考にしたので、
その関心は主にデータストア・サービスに注がれた。特に KVS に対するクエリー処理に注
目していたので、GQL のサポートを行っている Google AppEngine for Python（GAE/P）
の SDK を調査対象とした。
図 11 に GAE/P のストレージ・アーキテクチュアを示す。前述の通り、サービスはバック
エンド・サーバー（右側）とインターフェース・ライブラリアを含むクライアント・アプ
リケーション（左側）から構成される。両者は Google Protocol Buffer で知られている高速
RPC を使用して接続されると思われる。データストア・サービスの場合にはバックエンド・
サーバーは BigTable として一般に認知されていることが多いが、実際には Google
Filesystem (GFS)/BigTable/MegaStore の異なる 3 つのサービスの集合体で動作している。
格納データの検索は BigTable により管理されているテーブルにより行われるが、実際にデ
ータが格納されるのはストレージサービスを行う GFS である。また GQL に関わるトラン
ザクション処理は MegaStore で一貫性の保証が行われている。MegaStore は BigTable を
隠蔽し、BigTable は GFS を隠蔽しているので、データストア・サービスを利用する場合に
はクライアント・アプリケーションは MegaStore にアクセスをする。
GAE/P のクライアント・アプリケーションでは、MegaStore に直接アクセスするのはデー
タストアの低水準 API である。（詳細は次節）その上位に GAE のデータモデルが実装され
ている。GAE のデータストアが利用するデータモデルはすべてのサポート言語で共通であ
る。GAE データストアの単位となるデータオブジェクトである「エンティティ」、エンティ
ティの識別子である「キー」、エンティティに含まれる「プロパティ」の 3 つが基本的なデ
ータモデルである。しかしながら、このデータモデルにアクセスする API はサポート言語
によって異なり、GAE/P の場合はモデル・インターフェースに基づく。これが GAE/P で
Datastore API として説明されているインターフェースである。
19
図 11
2.2.5. GAE/P Datastoreの低水準 API
Datastore の低水準 API は GAE/P のデータストア・サポートの要と言える。本事業では調
査の一環で GAE/P SDK に収録されている関連ソースコードの解析を行ったが、それに基
づく低水準 API の基本構造を図 12 に示す。
主要なコンポーネントは次の 3 つである。1
api/datastore.py 外部インターフェース（API）
datastore/datastore_query.py クエリーエンジン
datastore/datastore_rpc.py バックエンド・サーバーとの通信
その他には次のソースも重要であると思われる。
api/datastore_types.py 主要なデータオブジェクトの定義
datastore/datastore_index.py カスタムインデックスの定義
datastore/entity_pb.py 各種プロパティの定義
1 低水準 API の外部インターフェース関連のソースは「google/appengine/api」に、本体のソースは
「google/appengine/datastore」に格納されている。
20
図 12
図 12 からも分かるように低水準 API は KVS では一般的な GET/PUT/DELETE のインタ
ーフェースに、クエリー処理に対応するための低水準の Query クラスが追加された構造に
なっている。GAE/P ではこの低水準 Query クラスを活用して、Google Query Language
（GQL）など各種のクエリーをサポートしている。
2.2.6. クエリーインターフェースの標準化
GAE/P のストレージ・アーキテクチュアは本項の冒頭で述べた「複数の KVS をサポート
する抽象化インターフェース」の実現を考える上で、多くの示唆を与えるものである。KVS
本来の外部インターフェースに関わる特性を考慮して、GAE/P は次のように非常に現実的
なアプローチを取っている。
原則的には KVS の典型的な外部インターフェースである GET/PUT/DELETE の API
を踏襲し、データの格納・削除に関しては KVSの API をそのまま使用する。
格納データのクエリー処理に限定して検索条件を指定できる API を追加する。これに
伴うクエリー処理の実装（クエリーエンジン）はインターフェース・ライブラリ内に
実装する。
このアプローチに沿った GAE/P の GQL は「データの格納・削除は KVS 風に、データの
検索は SQL 風に」といった折衷案的なサポートを行っており、SQL に慣れた一般的なデー
タベース利用者には違和感があるものの、KVS への機能追加を回避しながら SQL ライクな
クエリー処理をサポートできる点ではメリットがある。本事業のプラットフォームでこの
アプローチによるクエリー処理を実装すると図 13 の上段のようになるであろう。
21
図 13
しかしながら近年のKVSに関する技術動向を見ると何らかのクエリー機能を提供する事例
が増えてきている。例えば MongoDB の Mongo Query や Cassandra の CQL、あるいは
HyperTable の HQL などの事例があげられる。これらの事例は「格納データのクエリーが
可能である」という意味では旧世代の KVS から進化を遂げたと言えるのだが、そのクエリ
ーエンジンを実装するにあたり幾つもの利用上の仮定や制限を設けている。その結果とし
て SQLライクな独自のクエリー言語を定義するアプローチに向かわざる得なくなっている。
仮に本事業のプラットフォームでこのような「独自のクエリー言語をサポートする KVS」
に対応するのであれば図 13 の下段のような構造を考えなければならない。
更に難題なのは、本事業のプラットフォームにおいてこれらの旧世代と新世代の KVSを同
時にサポートすることである。図 13 の中段に模式的に示すが、上段のアーキテクチュアと
下段のアーキテクチュアを両立するクエリーエンジンを実現することは非常に困難な課題
に見える。
このように「複数の KVSをサポートする抽象化インターフェース」の定義は本事業の提案
当初の目論見よりも非常に大きな課題を孕んでいた。本事業でサポートする統一的クエリ
ー・インターフェース（CQI）は、まず図 13 の上段のアーキテクチュアに基づきサポート
を行ったが、現在は図 13 の下段のアーキテクチュアに転換している。現在の CQI のアー
キテクチュアについては次章に説明を譲り、以降は図 13 の上段のアーキテクチュアに基づ
く CQI を説明する。
22
2.2.7. 統一的クエリーインターフェースの初期バージョン
CQI の初期バージョンは平成 22 年度の「バックエンド・ストレージのサポート」の成果を
ベースにソフトウェアの各種インターフェースの明確化を行うアプローチで取りまとめら
れたパッケージである。図 14 にそのアーキテクチュアを示す。
図 14
図 14 からも分かるように CQI の初期バージョンは GAE/P のストレージ・アーキテクチュ
アが色濃く反映されおり、原則として GQL と同様のサービスを提供する。GQL との違い
は「CQI がサポートする複数の KVSから任意に選んで対象ストレージとして利用できる」
ことである。この機能を実現するため、CQI 全体は個々の KVS に対応するドライバー部分
と全ての KVS アクセスで利用する共通部分に明確に区分されている。両者を繋ぎ合わせる
Datastore Bridge はごく単純なディスパッチャーとして実装されており、CQI の初期化時
にドライバーの名称を指定することにより任意の KVS を指定できる仕組みになっている。
23
●統一的クエリーインターフェース初期バージョンの API
前節の「クエリーインターフェースの標準化」で述べたように、CQI の初期バージョンは
クエリー機能を持たない旧世代の KVS の標準的な API（GET/PUT/DELETE）をベースに
クエリーのための API が追加された構造なっている。C により記述された低水準の API は
次の 9 つのインターフェースを規定している。
CQI 構造体の生成・破壊
CQI_t *cqi_new(char *driver, char *user, char *passwd, char *host, int port);
void cqi_free(CQI_t *cqi);
GQL によるクエリーの解釈
query_t *cqi_analyze(CQI_t *cqi, char *gqlstr);
ストレージへの接続・解除
int cqi_attach(CQI_t *cqi, char *aux);
int cqi_detach(CQI_t *cqi);
ストレージへのアクセス
int cqi_put(CQI_t *cqi, entity_t *ep);
int cqi_delete(CQI_t *cqi, entity_t *ep);
entity_t *cqi_fetch(CQI_t *cqi, query_t *qp, int *count);
int cqi_count(CQI_t *cqi, query_t *qp);
24
統一的クエリーインターフェース アーキテクチュア
図 15 に CQI 初期バージョンの内部ソフトウェア構造を示す。
図 15
CQI 自体は 3 レイア構造になっており GQL に準拠したクエリー言語を解釈する「Query
Engine」、各 Storage Driver の処理ルーチンにディスパッチである「Datastore Bridge」、
GAE/P の DatastoreAPI に相当し、各 KVS、RGB 毎に用意する「Query Engind」の 3 つ
のコンポーネントから構成される。
Query Engine
クエリーとしては GQL と同様に SELECT のみをサポートし、SELECT 文を解釈して
Condition と Ordering の情報のみを抽出する。ANCESTOR は未対応である。
Datastore Bridge
各 Storage Driver へのディスパッチを行う。
Storage Driver
各 KVS/RDB のクライアント・ライブラリへのインターフェース変換を行っている。
最上位のレイアはサポートするプログラミング言語に対するバインディングを行うレイア
である。CQI 初期バージョンには複数のプログラミング言語をサポートする構想があり、
言語毎独立してバインディングを実装できる構造を採用していたが、実際に実装したのは
PHP バインディングだけで PHP の拡張モジュールとして実装を行った。
25
2.2.8. 統一的クエリーインターフェース初期バージョンの課題
●CQI 初期バージョンに対する外部評価
本事業では CQI 初期バージョンがまとまったタイミングで Cloudbusting Machine（CBM）
のオープンソース公開を行ったが（詳細は 4 章で述べる）、それと並行して非常限定された
範囲ではあるが対外プロモーションを実施した。プロモーションでは潜在ニーズを持って
いると思われるコンタクト可能な事業者やコミュニティに対し CQI を紹介して、自身のニ
ーズに関するコメントを収集したのだが、その結果幾つかの考慮すべき課題が明らかにな
った。以下にその概要を示す。
○ウェブ・アプリケーション開発業
ウェブ・アプリケーション開発業はクラウド・コンピューティングの潜在的需要が高い業
種だと考えたが、実際の事業者からのヒアリングでは CQI に対する期待感はあまり感じら
れなかった。「ウェブ・アプリケーションのコンテンツ格納に RDB を使用することは一般
的であり、ストレージとしてスケーラビリティには関心があるのではないか？」という質
問に対しては「今日ではウェブ・アプリケーションからの RDB 利用は OR マッパー経由で
行うケースがほとんどであり KVS へのアクセスに SQL が使えることに特に魅力は感じな
い」との回答であった。また注目している KVS とその理由を尋ねたところ「MongoDB」「従
来の RDB と良く似た操作性だから」との回答を得た。
○分散システムの開発コミュニティ
オープンソースKVSなどの開発を手がける開発コミュニティに対してもコンタクトを行っ
たが、CQI に対するソリューションとしての期待感は感じられなかった。その理由は「CQI
に対するエンドユーザーの需要がイメージできない」という主張が多かった。これには開
発者としては「ネーティブな API を利用してほしい」という思いが強いことが感じられた。
彼らが注目している KVS とその理由を尋ねたところ「Cassandra」「KVS がそのメリット
を最大限に生かせる大規模運用での実績を持っている数少ない KVS だから」との回答を得
た。
○エンタープライズ系エンドユーザー
CQI 単独での事業化の潜在需要が最も大きいと思われるエンタープライズ系エンドユーザ
ーへもコンタクトをしてみたが「現段階での具体的なニーズは見当たらない」というのが
結論であった。その理由として「オープンソース系 KVSの運用実績のなさに懸念を持って
いる」「実業務で KVS を必要とするような大規模なデータを抱えているわけでもない」
「GQL 互換ではサポートが中途半端」などがあげられる。
26
●プロモーションからの考察
プロモーションの過程では様々な立場の方々から多数のコメントをもらったが、事業化を
念頭にそれらを総合すると次のようなことが考察できる。
大規模データのニーズを高めるにはそれを必要とするソリューションが必要
CQI がサポートするクラウド・ストレージには、今のところ積極的に利用しなければなら
ない具体的なニーズが存在していないように思われる。クラウド・ストレージのニーズを
顕在化するためには、それを必要とする具体的なソリューションの登場が不可欠である。
昨今の「ビッグデータ」ブームもこのようなソリューションの登場を喚起している側面が
ある。
データクエリーに対する期待は厳格な SQL サポート
SQL に対する需要は依然として大きいが、それは SQL を直接的に利用するニーズよりも
「内部で SQL を利用するソフトウェア・コンポーネントが多数存在する」ことに起因する
ように見える。すなわち既存のソフトウェア・コンポーネントが正しく機能するために、
クラウド・ストレージには厳格な SQL サポートが求められている。したがって SQL ライ
クなクエリー言語、いわゆる NoSQL の市場性は予想外に小さい可能性がある。むしろ「SQL
を利用するソフトウェア・コンポーネントの KVS 版」の方がニーズは高いかもしれない。
前者の「大規模データを必要とするソリューション」は CQI の付加価値を高めるために検
討を要する中長期的課題であろう。そして後者の「厳格な SQL サポート」はその必要性も
含め熟慮して直ちに対策をまとめる必要のある短期的な課題である。
本事業では後者の「厳格な SQL サポート」を検討し CQI の全面的な改訂を行った。
その詳細は次章で説明する。
27
3．平成 23年度の開発
平成 23 年度、本事業は次の 3 項目の開発を行った。
バックエンド・ストレージのサポート
統一的クエリーインターフェース（CQI）の定義と実装
新たな KVS3 種のサポート
性能評価
PaaS アプリケーション
下記のベンチマークプログラムを対象に PaaS アプリケーション化
SPECWeb2009
Yahoo! Cloud Serving Benchmark（YCSB）
リソース・ディレクトリ
クラウド内管理情報の収集・共有の設計・実装
クラウド間での管理情報共有の設計
以降、開発の詳細を説明する。
28
3.1. バックエンド・ストレージのサポート
平成 23 年度、本開発項目では次の目標を掲げた
新たな Key-Value Store を 3 件程度追加サポートする
ベンチマーク等を活用して性能評価・チューニングを実施する
前者に関しては新たな KVS として Hypertable、Cassandra 0.7、Memcached のサポート
を行った。Cassandra 0.7 への対応は東工大が開発している MyCassandra2のサポートを目
的としている。また YCBM 論文（付録 A）で紹介されているハッシュ型 KVS のサポート
実例を示すため Memcached のサポートを行った。
後者に関しては CQI の性能計測のために独自に開発したベンチマークである
ZipBenchmark、および SQL による DB ベンチマークとして WisconsinBenchmark による
計測を行った。なお Cassandra に関してはその基本性能を把握するため Yahoo! Cloud
Serving Benchmark（YCSB）による計測も行った。この結果は付録 A に記載する。
3.1.1. サポートする KVSの選定
Key-Value Store（KVS）はクラウド環境でのストレージ・システムの代表格として広く認
知されているが、そのシステム・アーキテクチュアは様々なバリエーションが存在してお
り、システム特性も異なる。論文 ”Bnechmarking Cloud Serving Systems with YCSB”
(http://www.brianfrankcooper.net/pubs/ycsb.pdf)（付録 A）ではこの問題を取り上げて次の
ようなデータモデルの違いによる分類を示している。
ドキュメント型 CouchDB, MongoDB
カラムグループ型 BigTable, Cassandra, HBase, Hypertable
ハッシュテーブル型 Voldemort
CQIのストレージ・ドライバーの実装ではターゲットとなるKVSの特性に応じて実装方法、
特にクエリー実現方式を個別に変えなければならないが、YCSB 論文の分類に基づくと次
のように実装方法もある程度分類できる。
ドキュメント型 基本的には API の変換だけで OK
カラムグループ型 インデックスの実装が必要
ハッシュテーブル型 基本的に連想配列なので CQI のクエリー対象外
2 http://www.slideshare.net/mobile/sunsuk7tp/mycassandra-8499189
MyCassandra は Cassandra を拡張してリード性能の向上を図った派生システムである。
CQI は Cassandra 1.0 に対応するサポートを行っているが、MyCassandra はこれとは互換性のない
Cassandra 0.7 をベースバージョンとしているため、独立して Cassandra 0.7 をサポートする必要があっ
た。
29
平成 22 年度の開発ではドキュメント型の代表例として MongoDB、カラムグループ型の代
表例として Cassandra をサポートしたが、平成 23 年度の開発では次のような要件の元に
追加サポートのターゲット選定を行った。
未サポートのハッシュテーブル型の実装事例を追加する
KVS の特徴を明確に提示してくれるカラムグループ型の実装例を増やす
KVS の応用システムにも CQI が対処できる事例を示す
このような要件に基づき Memcached、Hypertable、Cassandra 0.7（MyCassandra）を選
定した。さらにハッシュテーブル型のサポートではクエリーキャッシュとして用例を示す
意図から CQI Cache Driver なる機構も新設した。（詳細は後述）
3.1.2. CQI の課題
本事業の事業期間を通じてクラウド関連技術の動向は目紛しく変化を続けているが、特に
クラウド・ストレージの分野では様々な「新たな試み」が提示され、平成 23 年度当初の計
画は期間半ばで CQI 開発はシーズとニーズの両面で戦略的な見直しを余儀なくされた。
まずシーズ側面では、オープンソース系 KVSの幾つかが独自のクエリー機能のサポートを
始めたことにある。元々RDB との機能的親和性を重視するドキュメント型 KVS では何ら
かのクエリー機能をサポートする事例が多いのだが、KVS の実装事例の主力であるカラム
グループ型 KVSでは当初クエリー機能をサポートする事例は皆無に近かった。本事業では
この点が CQI のニッチ的なニーズと見込んでいたのだが、平成 23 年度には Cassandra の
CQI や Hypertable の HQL のようにカラムグループ型 KVS において SQL ライクなクエ
リー言語をサポートする試み、いわゆる NoSQL への取り組みが顕著になった。これは CQI
の存在意義が一気に薄れることを意味している。次にニーズ側面では前章でも述べたよう
に、クラウド・ストレージに対して「厳格な SQL サポート」を求めるニーズが強まった。
文字通りに対応するとなるとマイクロソフトの Windows Azure のように完全な SQL サポ
ートが必要となるのだが、これには膨大な開発コストが見込まれる。独自のヒアリングを
行ったところ「内部で SQL を利用するソフトウェア・コンポーネントが多数存在する」こ
とが厳格な SQL サポートの理由だと思われた。
以上のシーズとニーズ両面からの要請に応じて CQI（およびプラットフォーム）の開発方
針を以下の通り転換することとした。
GQL 互換の方針を放棄し、SQL との互換性を追求する
多言語プラットフォームの方針を放棄し、PHP に特化したストレージ・サポート
（SQL データベースだけでなくその上位コンポーネントを含む）を追求する
30
3.1.3. PHP Data Objects（PDO）対応版 CQI
「PHP に特化したストレージ・サポート」を検討するため、まず PHP Data Objects（PDO）
に着目した。PDOはPHP標準のデータベース・インターフェースである。MySQLやSQLite
といった著名なオープンソース系 RDB に対して共通のインターフェースを提供する。
（C/C++による）PHP 拡張モジュールとして実装されているため、PHP でのもう 1 つのデ
ータベース・インターフェースである PEAR:DB よりも高速に動作に動作する。PHP でサ
ポートされる ORM など、より高水準のストレージ・コンポーネントは PDO のインターフ
ェースを介して RDB にアクセスする事例が多いので、
PDO のインターフェース仕様をサポートするメリットは非常に大きい。
● PDO の実装
PDO の実装は PHP のディストリビューションにバンドルされており、ソースコード自体
はコア・モジュールとドライバー・モジュールの 2 種類のコンポーネントから構成されて
いる。コア・モジュールでは PDO としてのインターフェース機能など全ての RDB で共通
する機能が記述される。PDO の外部インターフェースは PDO クラスおよび
PDOStatement クラスで定義されている3。また個々の RDB に依存するコードは各々のド
ライバー・モジュールに記述する。したがって CQI が対応している各種 KVS をサポート
するには、ドライバー・モジュールのみを実装すれば良いことになる。
● PDO 対応版 CQI の開発課題
PDO 対応版 CQI を開発する上での課題は PDO が前提としている SQL サポートの実現に
尽きる。PDO は基本的に RDB の抽象化インターフェースであるので、データベースへの
アクセスは全て SQL による。これを個々の KVS がサポートするネーティブ API へ変換す
るためには SQL の構文解釈等の実装コストの高い処理を見込まざるを得ない。
本開発項目では KVS の SQL サポートについて幾つかの方法を試みた。まず最も実装コス
トが最も小さいと見込まれる（一部の）KVSがサポートする SQL ライクなクエリー言語を
そのまま活用することを試みたが、KVS のクエリー言語のサポートが限定的で PDO のテ
ストが使用する簡単なクエリーすら動作しないことが分かった。次に SQL で記述されてい
る PDO のテスト・スクリプトを各 KVS がサポートするクエリー言語へ変換することを試
みた。このトライアルは当初は手作業での書き直し、次にその知見を元に単純変換を行う
プログラムを作成して行った。それによりSQL構文に一定の制約を設ければSQLからKVS
固有のクエリー言語への変換が可能であることが分かった。
3 http://www.php.net/manual/ja/class.pdo.php
http://www.php.net/manual/ja/class.pdostatement.php
31
最後に SQL構文を解釈し各KVSのクエリー言語に変換可能な SQL文を抽出する機構の実
現を検討した。SQL 構文の解釈は一般性のある技術課題だが、言語としての SQL は歴史が
古い故に網羅的な解釈ができる方策はあまり見当たらない。結局、パブリック・ドメイン
として公開されている SQLite の構文解釈機構を流用して変換可能な SQL 文の抽出を行う
コードを実現した。
図 16
●PDO 対応版 CQI 内部構造
PDO 対応版 CQI は次の 3 つのコンポーネントから構成される。（図 16）
PDO Driver PDO Core に対するインターフェース
PDO のコア・モジュールをそのまま流用している
SQL Parser SQL 構文の解釈
現時点でサポートしているのは次の 5 つのコマンドのみ
CREATE TABLE/INSERT/SELECT/DELETE/DROP TABLE
各コマンドのオペラントのサポートは KVS ドライバーによる
KVS Driver KVS に対するインターフェース
各 KVSのクライアント・ライブラリに対するインターフェース
従来の KVS Driver をベースに PDO 向けインターフェースに改変
32
3.1.4. CQI Cache Driver
PDO 対応版 CQI ではドライバー・インターフェースの明確化が図れた。このメリットを生
かす具体例として CQI Cache Driver なる機構を新設した。Cache Driver はいわゆるクエ
リーキャッシュを実現する疑似ドライバーで CQI のドライバー・インターフェースをサポ
ートする全ての KVS ドライバーを対象にクエリーキャッシュを実現することができる。
同時に CQI でのハッシュテーブル型 KVSのサポート用例を示すことも企図した。
本事業では Memcached を用いた CQI Cache Driver を実装したが、その特徴は以下の 3 つ
である。
クエリー結果をキャッシュする
ストレージに依存しないキャッシュ機構
キャッシュの On/Off の設定
CQI Cache Driver では、クエリー実行時にストレージからクエリー結果を取得後、
Memcached にクエリー結果をキャッシュする。キャッシュが保存されている間に同じクエ
リーが再度実行された場合は、ストレージへアクセスせずに Memcached からクエリー結
果を取得する。そうすることで頻繁に実行されるクエリーがストレージへ毎回問い合わせ
る必要がなくなり、ストレージの負荷を軽減することができる。また、クエリーキャッシ
ュの生成方法を統一することで、異なるストレージ間でキャッシュを共有することができ
る。Memcached はハッシュテーブル型の KVS のため、オンメモリで動作する。そのため、
クエリーキャッシュは整合性を厳密に保証することができない。整合性をある程度担保す
るため、常に最新のデータを取得できるようにキャッシュの On/Off を動的に選択可能にし
ている。
●Memcached にキャッシュするデータの概要
クエリーキャッシュをハッシュテーブル型の KVS に格納する場合、実行されたクエリーを
Key、クエリー結果を Value として格納されることが理想である。しかし、PDO は RDB
データベース接続ライブラリのため、クエリー結果のカラム数やカラム名、カラム名の順
序は常に同じであることが前提で実装されている。そのため、ハッシュテーブル型の KVS
である Memcached をクエリーキャッシュとして実装する場合、以下の情報を Value とし
てキャッシュする必要がある。
クエリー結果のカラム数
クエリー結果のカラム名の集合
クエリー結果
これらの Value に対応する Key は、実行されるクエリーを Prefix として、末尾に Value を
識別するための識別子を付加したものを使用する。
33
● Memcached へのキャッシュ方法
Cassandra、MongoDB は共にクエリー結果を取得する場合、fetch を実行して結果を 1 件
ずつ取得している。そのため、クエリーを Key に、クエリー結果全体を Value とするため
には、fetch が終わるまでクエリー結果をバッファに溜め、最後の 1 件を fetch したら
Memcached へ格納する、という方法になる。ここでは、最適なキャッシュ方法を模索する
ため、MongoDB に対し ZipBench（後述）を用いて以下の 3 つのキャッシュ方法とキャッ
シュ機能を Off にした場合とで実行速度の比較を行った。
① クエリー結果全体を 1 つの Value とする方法
クエリーの結果全体がmemcachedの1アイテムなのでアイテムサイズを大きくし
ないとキャッシュできない場合が多い
格納：1 回
取得：1 回
② クエリー結果 1 件を 1 つの Value とする方法
クエリー結果の 1 行が Memcached の 1 アイテムなので 1 アイテムのサイズは小
さい
キャッシュが途中で途切れてしまった場合、検知する手段がなく、整合性が大き
く崩れてしまう可能性がある
格納：クエリー結果の件数
取得：クエリー結果の件数
③ 格納時はクエリー結果 1 件ごとに同じ Key で後方追加する方法
①、②の特徴を合わせた方法
格納：クエリー結果の件数
取得：1 回
④ キャッシュ機能 Off
各キャッシュ方法がキャッシュ機能を使わない場合に比べどの程度の速さになる
かを比較するために測定
34
キャッシュ方法ごとでの ZipBench 計測結果
以下にターゲットのストレージを MongoDB とした場合の性能計測結果を示す。
クエリー結果全体を 1 つの Value とする方法
クエリー結果 1 件を 1 つの Value とする方法
格納時はクエリー結果を 1 行ごとに同じ Key で後方追加する方法
キャッシュ機能 Off
上記の結果から、クエリー結果をキャッシュする際は 1 件ごとに、取得する際は 1 回で取
得する方法が最も効率が良いことが分かった。また、クエリーキャッシュがない場合は
Memcached へクエリーキャッシュを登録するためキャッシュ機能を Off にした場合より
も数倍遅いが、クエリーキャッシュからクエリー結果を取得する場合、最大で 50%近く実
行速度が向上していることが分かる。
●キャッシュ方法の選択
これらのキャッシュ方法をユーザーが任意に選択できるようにコンパイル時に設定可能と
する。また、キャッシュの有効期間も同様にコンパイル時に設定するものとする。キャッ
シュの有効/無効は、 PDO インスタンス生成時、もしくは PDO の属性値をセットする
PDO::Attribute()メソッドにて動的に変更可能とする。
35
● 課題・検討事項
Memcached に格納するクエリーキャッシュの Key の prefix
対象ストレージが分散構成の場合もあるため、
ストレージの物理 IP アドレスなどを prefix に設定するのは不適。
分散構成を考慮した prefix のルールを設定する必要がある。
UPDATE などでキャッシュの元データが変更された場合
特定のテーブルを使用しているキャッシュのみを flush することは困難なため、データ
の変更に対しては Eventual Consistency として扱う。
CQI Cache Driver で接続する Memcached のサーバリスト、ポート番号がハードコー
ディングされている
36
3.1.5. ZipBench
ZipBench は、CQI がサポートするストレージの性能評価を行うための PHP によるベンチ
マークプログラムである。ベンチマークの対象となるデータは、RDB の性能評価でよく使
われる、日本郵便が公開する郵便番号データを使用している。
郵便番号データについて
総データ数は 123,004 件
※詳細は日本郵便のホームページを参照
http://www.post.japanpost.jp/zipcode/dl/oogaki.html
郵便番号データベースのスキーマ構造
カラム名 データ型 説明
Jis varchar(5) 全国地方公共団体コード(JIS X0401、X0402)
zip_old varchar(5) (旧)郵便番号(3～5 桁)
zip varchar(7) 郵便番号(7 桁)
addr1_kana varchar(100) 都道府県名(半角カタカナ)
addr2_kana varchar(100) 市区町村名(半角カタカナ)
addr3_kana varchar(100) 町域名(半角カタカナ)
addr1 varchar(100) 都道府県名(漢字)
addr2 varchar(100) 市区町村名(漢字)
addr3 varchar(100) 町域名(漢字)
c1 int(11) 町域が二以上の郵便番号で表される場合の表示
c2 int(11) 小字毎に番地が起番されている町域の表示
c3 int(11) 丁目を有する町域の場合の表示
c4 int(11) 一つの郵便番号で二以上の町域を表す場合の表示
c5 int(11) 更新の表示
c6 int(11) 変更理由
37
● ベンチマークの内容
ZipBench の前提条件として予め郵便番号データを対象ストレージに挿入していること仮
定している。ZipBench は、実行時の引数により対象ストレージの郵便番号データベースに
対し、以下の 4 種類の条件によるクエリーを複数プロセスで実行する。クエリーの実行後
はクエリー結果を最後まで fetchするが、fetch内容については結果に出力せずに破棄する。
カラム jis(全国地方公共団体コード)によるクエリー
このコードを指定したクエリーは 1 件を除き、全てのクエリー結果は 1000 件以内
に収まる。
総実行クエリー数：1898
1 クエリーあたりの結果件数：64.8 件
カラム addr2(市区町村情報) によるクエリー
この市区町村情報を指定したクエリーは 1 件を除き、すべてのクエリー結果は
1000 件以内に収まる。
総実行クエリー数：1896
1 クエリーあたりの結果件数：61.9 件
カラム zip_old (旧郵便番号)によるクエリー
このコードを指定したクエリーは全て 100 件以内に収まる。
総実行クエリー数：5020
1 クエリーあたりの結果件数：24.5 件
カラム zip(郵便番号)によるクエリー
このコードを指定したクエリーは全て 50 件以内に収まる。
総実行クエリー数：118958
1 クエリーあたりの結果件数：1.03 件
38
● ZipBench の実行結果
ZipBench の実行結果は、1 クエリーごとの実行時間を実時間、ユーザー時間、システム時
間を csv ファイルへプロセスごとに出力する。ZipBench の対象となるストレージは、RDB
の代表例として MySQL、CBM-0.2 でサポートしている MongoDB、Cassandra とし、以
下の条件で ZipBench を実行した結果を示す。
条件
各ストレージのバージョン
MySQL：5.0.77
MongoDB：2.0
Cassandra：1.0
MySQL、MongoDB は ZipBench で使用する各カラムに対し Index をあらかじめ
生成済み
ZipBench と各ストレージは同一マシン上で動作
MongoDB、Cassandra は 1 台構成
実行プロセス数は 1
ZipBench の実行結果(実時間)
■総実行時間
addr2 jis zip_old zip
MySQL 2.787 2.213 3.098 32.050
MongoDB 2.125 2.446 2.652 30.760
Cassandra 17.998 17.973 20.783 115.456
[sec]
■1 クエリーごとの実行時間
addr2 jis zip_old zip
MySQL 0.0015 0.0012 0.0006 0.0003
MongoDB 0.0011 0.0013 0.0005 0.0003
Cassandra 0.0095 0.0095 0.0041 0.0010
[sec]
39
● ZipBench の実行結果のグラフ
図 17
以上の結果から、MongoDB は MySQL よりクエリーの実行速度が速く、逆に Cassandra
は MySQL よりも遅いことが分かった。また、MongoDB と MySQL を比較した場合、カラ
ムzipによるベンチマークは他のカラムに比べて1クエリーあたりの実行時間の差が小さい。
このことから、クエリーの実行速度そのものよりも、クエリー結果を fetch する部分で
MongoDB が MySQL を上回っていると考えられる。ZipBench は全て string 型でのクエリ
ーを実行しているため、int 型でのベンチマークを行う必要がある。
40
3.1.6. Wisconsin Benchmark
ZipBench は CQI の評価には一定の成果を上げることが出来たが、KVS を用いた性能評価
としては十分とは言えないものであった。たとえば、テストデータの件数が KVSをテスト
するには少ないと言う問題や、テストケースにしても「ストレージ構成によって負荷をか
けると実行時間はどのように変化するか」の言う 1 点に絞られている。そこで KVS のベン
チマークとして良く知られている Yahoo Cloud Serving Benchmark（YCSB）が参考した
ベンチマークである WisconsinBenchmark に着目した。本稿では WisconsinBenchmark
は、「The Wisconsin Benchmark: Past, Present, and Future」による拡張版のベンチマー
クを指すこととする。WisconsinBenchmark は主にパラレルデータベースのための初期の
性能測定である。まず、「The Wisconsin Benchmark: Past, Present, and Future」の論文
に書かれている、オリジナルと拡張版の WisconsinBenchmark について簡単に述べる。次
に、WisconsinBenchmark を参考に定義した CQI 性能測定のベンチマークについて述べ、
最後のこのベンチマーク結果について述べる。
●WisconsinBenchmark について
WisconsinBenchmark のオリジナルのテストデータ構造を図 18 に示す。
unique1
unique2
two
four
ten
twenty
hundred
thousand
twothous
fivethous
tenthous
odd100
even100
stringu1
stringu2
string4
int
int
int
int
int
int
int
int
int
int
int
int
int
char
char
char
0 - 9999
0 - 9999
0 - 1
0 - 3
0 - 9
0 - 19
0 - 99
0 - 999
0 - 1999
0 - 4999
0 - 9999
50
50
random
random
rotating
rotating
rotating
rotating
rotating
random
random
random
random
rotating
rotating
random
rotating
rotating
candidate key
declared key
0,1,0,1,...
0,1,2,3,0,1,...
0,1,…,9,0,...
0,1,…,19,0,...
0,1,…,99,0,...
candidate key
1,3,5,…,99,1,...
2,4,6,…,100,2,...
candidate key
candidate key
Name Type Range Order Comment
図 18
41
TENKTUP1 と TENKTUP2 という名前の 10000 データのテーブルと ONEKTUP と言う
名前の 1000 データのテーブルの 3 つのテーブルを使用する。データは、13 種類の整数値
(integer)、3 種類の 52 バイトの文字列からなり、ストレージのオーバヘッドを考慮しなけ
れば、1 データ 208 バイトである。これ以外に以下のような特徴がある。
unique1 と 2 は、0 から MAXRUPLES-1 間のランダムな数字。
unique2 に対してクラスタインデックスを構築する。
unique1 に対して非クラスタインデックスを構築する。
hundred に対してユニークでない非クラスタインデックスを構築する。
その他の整数値は、範囲指定をモデル化する体系的な方法を提供する。
例えば、fore は、0～3 までの値が繰り返し指定され、fore = 2 を指定すれば、デ
ータ数に関わらず、25%のデータを取得することができる。
文字列は、1 番目、真ん中、最後に「任意の文字列」を、その他には「x」のみを
含んでいる 52 個の文字列である。
●オリジナルの WisconsinBenchmark の問題点
テストデータが 10000 件では現在のシングル・プロセッサ・マシンには小さすぎ、また、
文字列の構造体が現実的ではありません。（Bitton, D. and C. Turbyfill, “A Retrospective on
the Wisconsin Benchmark,” in “Readings in Database Systems", edited by Michael
Stonebraker, Morgan Kaufman, 1988.）また、2001 年発表のパワーポイント「Wisconsin
benchmark」よりオリジナルの問題点として次のようなことが書かれている。
2 バイトの整数である。
ほとんどの文字列が、最初の数文字で区別できる。
すべてが一様分布であるのは非現実的である。
データベース拡張が難しい。
42
●WisconsinBenchmark のテストデータ構造
unique1
unique2
two
four
ten
twenty
onePercent
tenPercent
twentyPercent
fiftyPercent
unique3
evenOnePercent
oddOnePercent
stringu1
stringu2
string4
0 - (maxtuples - 1)
0 - (maxtuples - 1)
0 - 1
0 - 3
0 - 9
0 - 19
0 - 99
0 - 9
0 - 4
0 - 1
0 - (maxtuples - 1)
0,2,4,…,198
1,3,5,…,199
random
sequential
random
random
random
random
random
random
random
random
random
random
random
random
random
cyclic
unique, random order
unique, sequential
(unique1 mod 2)
(unique1 mod 4)
(unique1 mod 10)
(unique1 mod 20)
(unique1 mod 100)
(unique1 mod 10)
(unique1 mod 5)
(unique1 mod 2)
unique1
(onePercent * 2)
(onePercent * 2) + 1
candidate key
candidate key
Name Range Order Comment
図 19
オリジナルとの違いは、unique2 の値が、0 から MAXTUPLES-1 まで連続する値である。
two、four、ten、twenty は、unique1 から生成される（例：two = unique1 mod 2）その
他の、整数値は、選択クエリーを簡素化するために変更されている。例えば、twentyPercent
= 3 を指定すれば、データ数に関係なく 20%のデータを選択できる。また、stringu1 と 2
は、7 個の文字とそれに続く 45 個の「x」である。そして 7 個の文字は、unique1 及び 2
を使用して生成される。最後に string4 は、「AAAAxxx...、HHHHxxx...、OOOOxxx...、
VVVVxxx…」をローテーションする。
43
●Query の種類
WisconsinBenchmark は 32 のクエリーが定義されている。
Selection Querys
Query1～6は、2つの異なる選択範囲（1%と10%）を、3つのストレージ組織（no-index、
clustered index、non-clustered index）に対して調査する。クエリー結果は、ストレ
ージに挿入する。Query7 は、データを 1 行取得することによりシステムのパスの長さ
を知ることが出来る。Query8 は、1%のデータを取得し、フォーマットのコストと、
ユーザー側の表示コストをはかる。Query3 の結果から Query8 の結果を引くと、フォ
ーマットと表示のコストを見積もることができる。
Join Querys
Query9～17 は、下の 3 つの結合方法を、3 つのストレージ組織（no-index、clustered
index、non-clustered index）に対して調査する。
JoinABprime
単純な結合であり、A と Bprime のテーブルの関係の濃度が 10%である。A が 10
万データの時、Bprime は 1 万データ持っていることとなる。結果は、Bprime と
同じデータ件数となる。
JoinASelB
1 つの結合と 1 つの選択であり A と B は同じデータを持っているが、B の選択に
は 10%の選択要因がある。A が 1 万データの時、B に対して「B.unique2<1000」
の条件が付く。結果は、A（B）と同じデータ件数ある。
JoinCselASelB
2 つの選択と 2 つの接合であり、A と B は同じデータ数を持っている。関係性を
図 20 に示す。
その他のクエリー
Query18、19 は、射影を調査する。Query20～25 は、3 つの集計（MIN スカラー計数、
MIN 集約関数、SUN 集約関数）を 2 つのストレージ組織（no-index、clustered index）
に対して調査する。Query26～32 は、INSERT、UPDATE、DELETE を 2 つのスト
レージ組織（no-index、 index）に対して調査する。
「clustered index」は、「unique2」に付けられ、「 non-clustered indices 」は、「unique1」
に付けられる。
44
図 20
●テストの種類
Speedup
データベース関係のサイズ(the size of the relations in the database)と使用クエリー
を固定し、プロセッサとディスクの数を変更させて、応答時間を計測する。ハードウ
ェアを 2 倍にすると、応答時間が半分になった場合、「線形のスピードアップ」と言え、
理想的である。注意点としては、ベンチマーク関係のサイズ（ the size of the
benchmark relations ）や、人為的なスピードアップ結果が生まれるような、ディス
ク数の増加、また十分なデータの数を設定しなければならない。またプロセス間連絡
を考慮しなければならない。
Scaleup
使用するクエリーを固定し、プロセッサとディスクの数と、データの数を比例して増
加させ、応答時間を計測する。例えば、「5 プロセッサ／1 ディスクにて、100 万デー
タ」「10 プロセッサ／2 ディスクにて、200 万データ」など。基本の構成の選択が、重
要な影響を及ぼし、1 ディスクにつき 5～10 プロセッサが合理的な妥協である。応答時
間が一定である場合が理想的である。
Sizeup
プロセッサとディスクの数と使用するクエリーを固定して、データの数を増加し、応
答時間を計測する。データ・セットのサイズを 2 倍にしても、応答時間が 2 倍以下の
場合、良いサイズアップ特性を示すと言える。
45
●WisconsinBenchmark を参考にしたベンチマーク
WisconsinBenchmark を参考に CQI の性能測定を行うためのベンチマークを定義した。参
考にしたものは、
1. テストデータ生成方法
2. Sizeup、Speedup、Scaleup の 3 種類のテストケース
3. 計測方法（クエリの実行時間）
テストデータ生成方法は、WisconsinBenchmark の説明に詳しく書かれている。
WisconsinBenchmark では、32 のクエリーが定義されているが、CQI や各 KVS ドライバ
ーの制限により下の 3 種類のクエリーを定義した。
no1：SELECT onePercent FROM TABLE_NAME WHERE onePercent = :param;
no2：SELECT tenPercent FROM TABLE_NAME WHERE tenPercent = :param;
no3：SELECT * FROM TABLE_NAME WHERE unique2 = :param;
no1 は挿入データ件数の 1%分のデータを取得する。no2 は挿入データ件数の 10%分のデー
タを取得する。no3 は、1 行分のデータを取得する。例えば、100 万件のデータが挿入され
ている場合、no1 では、1 万件分のクエリー結果が返され、no2 では 10 万件分のクエリー
結果が返される。性能を計測するのは、Cassandra、MongoDB、Cassandra の 0.7 バージ
ョン（以下、Cassandra0.7）の 3 種類である。Cassandra は、CQI の Cassandra ドライ
バー、MongoDB は、CQI の MongoDB ドライバー、Cassandra0.7 は、CQI の MyCassandra
用ドライバー（以下、Cassandra0.7 ドライバー）を用いて接続する。
テストパターンは次の 13 種類である
1. sizeup1 8 ノードの分散環境 10 万件のデータを挿入
2. sizeup2 8 ノードの分散環境 100 万件のデータを挿入
3. sizeup3 8 ノードの分散環境 1000 万件のデータを挿入
4. speedup1 シングルノード 1000 万件のデータを挿入
5. speedup2 2 ノードの分散環境 1000 万件のデータを挿入
6. speedup4 4 ノードの分散環境 1000 万件のデータを挿入
7. speedup6 6 ノードの分散環境 1000 万件のデータを挿入
8. speedup8 8 ノードの分散環境 1000 万件のデータを挿入
9. scaleup1 シングルノード 125 万件のデータを挿入
10. scaleup2 2 ノードの分散環境 250 万件のデータを挿入
11. scaleup4 4 ノードの分散環境 500 万件のデータを挿入
12. scaleup6 6 ノードの分散環境 750 万件のデータを挿入
13. scaleup8 8 ノードの分散環境 1000 万件のデータを挿入
46
テストパターンの示す構成の KVS に対して、no1~3 のクエリーを投げて、実行時間を計測
する。実際の計測では、複数回計測してその平均を測定値とする。なお、Speedup や Scaleup
の計測は、KVS に対するベンチマークとしてはノードの数が 8 とクラウド環境としては少
ないため、ベンチマーク結果が期待する特性を示さない可能性がある。また、MongoDB
測定結果を以下に示す。
0.0001
0.001
0.01
0.1
1
10
100
1000
sizeup1 sizeup2 sizeup3 sizeup1 sizeup2 sizeup3 sizeup1 sizeup2 sizeup3
Cassandra Cassandra07 MongoDB
sec no1
no2
no3
図 21 sizeup 測定結果
図 21 は、sizeup の測定結果である。no1 から no3 のクエリーを実行し、その結果を棒グ
ラフで表わしている。縦軸は実行時間であり、対数で表わされている。実行時間の単位は
秒である。WisconsinBenchmark の Sizeup では、データ件数は 10 倍になっても実行時間
が 10 倍以下ならば、その構成のストレージは良い特性を示すと言える。測定結果より以下
のようなことが言える。
全てのテストケースにて CassandraよりもMongoDBの方が速いと言う結果が出てい
る。
Cassandra（0.7）はデータ取得件数が 10 倍になると実行時間もほぼ 10 倍となってい
る。しかし、1 件のデータを取得する no1 では、実行時間はほとんど変わらないため、
データ取得件数に比例して実行時間が長くなると言う傾向があると言える。
47
Cassandra と Cassandra0.7 では、実行時間の増加に差がある。前者は sizeup2 まで
はデータ件数が 10 倍になっても実行時間は 10 倍以下に抑えられているが、sizeup3
からは、データ取得件数に比例している。後者は、sizeup1 から sizeup3 までデータ取
得件数に比例した実行時間になっている。
データを 1 件取得する no3 では、Cassandra よりも Cassandra0.7 の方が速いことが
分かる。
Cassandra が MongoDB よりも遅いのはデータ取得方法の差のためだと思われる。
MongoDB が検索結果のカーソルのみを返すのに対し、Cassandra は、全てのデータを 1
つのオブジェクトにしてクライアントに渡すため、どうしても取得データ件数に比例して
実行時間が遅くなっていると推測される。
Cassandra と Cassandra07 の違いは、「1．thriftAPI のバージョンの違い」「2．CQL を投
げているか、他の thriftAPI を使用しているかの違い」「3．セカンダリインデックスを使用
しているか、自前のカスタムインデックスを使用しているかの違い」である。
Cassandra0.7 の結果がリニアに上がっているのは、自前のカスタムインデックスのためで
あると推測される。Cassandra では、no3 の結果では、Cassandra0.7 の方が速いのは、次
のようなことが推測される。1 つ目は、カスタムインデックスが KVS の基本的な入出力で
ある「get」と「put」を使用したためと考えられる。2 つめは Cassandra のドライバーは
「CQL」をストレージ側に投げているためこの「CQL の構文解釈」の時間がプラスされて
いるとも考えられる。
数万件以上の大量のデータを取得するようなクエリーには、Cassandra よりも MongoDB
の方が向いていると推測される。しかし数件～数千件程度のデータを取得するようなクエ
リーに対しては実行時間にそれほど差があるとは言えない。
48
0.0001
0.001
0.01
0.1
1
10
100
1000
speedup1 speedup2 speedup4 speedup6 speedup8
sec
no1 cassandra
no1 cassandra07
no1 MongoDB
no2 cassandra
no2 cassandra07
no2 MongoDB
no3 cassandra
no3 cassandra07
no3 MongoDB
図 22 speedup 測定結果
図 22 は、speedup の測定結果である。no1 から no3 のクエリーをテストケースごと実行し
た結果の変化を折れ線グラフで表している。縦軸は実行時間であり、対数で表わされてい
る。実行時間の単位は秒である。WisconsinBenchmark の Speedup では、ノードが増える
ごとに実行時間が速くなれば、その構成のストレージは良い特性を示すと言える。測定結
果より以下のようなことが言える。
全体的に Cassandra よりも MongoDB の方が実行時間が速い。また MongoDB は実行
時間がほぼ一定である。
Cassandra は、少しではあるがノード数が増えるごとに実行時間が速くなっている。
Cassandra が MongoDB よりも遅い理由は、sizeup と同じ理由であると推測される。また、
MongoDB がノードの数を増やしてもほぼ一定の値を示すのは、ノードを増やしてもデータ
が分散される箇所が増えるのみで、実際に処理を行っているのは 1 台のマスターノードの
ため、あまり変化がないものと推測できる。
前述にて、クラウド環境での使用が考えられる KVS のベンチマークとしては、データ量や
ノード数が少ないため、KVS の特徴が表れていない可能性を上げていたが、図 22 を見る
限りでは、「ノード数を上げていくとクエリーの実行結果が速くなる」と言う特性が表れる
ように見える。
49
0.0001
0.001
0.01
0.1
1
10
100
1000
scaleup1 scaleup2 scaleup4 scaleup6 scaleup8
sec
no1 Cassandra
no1 Cassandra07
no1 MongoDB
no2 Cassandra
no2 Cassandra07
no2 MongoDB
no3 Cassandra
no3 Cassandra07
no3 MongoDB
図 23 scaleup 測定結果
図 23 は、scaleup の測定結果である。no1 から no3 のクエリーをテストケースごと実行し
た結果の変化を折れ線グラフで表している。縦軸は実行時間であり、対数で表わされてい
る。実行時間の単位は秒である。WisconsinBenchmark の scaleup では、ノード数とデー
タ件数の割合が同じならば、クエリーの実行時間は一定であることが望ましいとされる。
測定結果より以下のようなことが言える。
全体的に Cassandra よりも MongoDB の方が実行時間が速い。また Cassandra が、
データ件数が増えると実行時間が遅くなっているのに対し、MongoDB がある一定の時
間に集約されているようにも見える。
Cassandra は、ノードが増えてもデータ取得件数が増えれば実行時間は遅くなること
が分かる。
no1 と no2 の実行結果は、Cassandra の方が、Cassandra0.7 よりも早いが、no3 は
Cassandra0.7 の方が速い。
この結果も、ノード数が少ないために、期待したような傾向が出なかったと推測される。
ノード数を増やしてベンチマークを実行していくと、「ノード数とデータ件数の割合が同じ
ならば、クエリーの実行時間は一定である」と言う傾向がみられるグラフが描けるのでは
ないかと推測される。
50
●ベンチマーク結果による考察
SQL をベースにしたベンチマークを行った結果、KVS には様々なバリエーションがあるこ
とが分かった。MongoDB は Cassandra に比べてクエリーの実行時間は速いと言う傾向が
みられた。また、10 万件、100 万件のデータを取得するには MongoDB を使用することが
向いていることが推測される。しかし、「データを 1 件取得する」検索に対しては、1000
万件程度が格納されているストレージでは、Cassandra と MongoDB を比較してもそれほ
ど差がないことも確認できた。
Cassandra は P2P の仕組みを利用している。つまり全てが同等である。そのためスケール
アウトは簡単に行えるが、データを探すためには、全てのノードに対してデータの有無を
尋ねる必要がある。また、Cassandra はクエリーが投げられたノードに対して全てのデー
タを集めて 1 つのオブジェクトにしてクライアントに返すため、通信時間がかなり影響す
ると推測される。また、検索に使用されるセカンダリインデックスも全ノードに分散して
いる。そのため、ノード数を増やして大容量のデータを格納することはできても、クエリ
ーを投げて検索を行うと言うような場合には、ある一定の時間が必要になることが推測さ
れる。また Cassandra は scan が遅いと言う YCSB の結果がある、Cassandra 内部にてど
のように行っているかは不明であるが、SQL のような検索条件を投げた場合、scan を何回
も使っているだろうことは推測できる。つまり、Cassandra は検索が遅いと言う傾向をそ
もそも持っていることが分かる。
それに対して、MongoDB は、固定され 1 つのマスターがデータの管理を行っているため検
索に対しては効力を発揮する。ただし、スケールアウトと言う面では、それほど大容量の
データを格納することは想定されていない。
51
3.2. PaaSアプリケーション
平成 23 年度、本開発項目では次の目標を掲げた
PaaS アプリケーションの想定を検討する
PaaS アプリケーション開発を支援する機能を検討する
PaaS を活用したアプリケーション事例を作成する
1 番目の項目については実施計画書でも述べたように既存アプリケーションにウェブ・サー
ビスのユーザーインターフェースを付加するアプローチは SaaS 化が比較的容易で、事業化
当初の PaaS システムの需要を支える主要なユースケースとなると考えている。2 番目の項
目については既存の PHP 向けアプリケーション・フレームワークを活用できるシステム・
コンポーネントのモデルを検討した。3 番目の項目については前 2 項目の検討を踏まえ、具
体的には PaaS システムを活用した SPECweb2009 および Yahoo! Cloud Serving
Benchmark（YCSB）のユーザーインターフェースを試作した。
3.2.1. PaaSアプリケーション開発を支援する機能の検討
実施計画書において本項目は下記の細目について検討することを掲げた。
ソフトウェア管理用フレームワークの定義
ソフトウェア実行の制御
サポート・コンポーネントの共通化
ユーザーインターフェースの開発支援
このうち 1番目および 2番目の項目はリソース・ディレクトリの詳細設計での検討の結果、
対象サービスの管理機能と重複することがわかった。そこでこれらの機能はリソース・デ
ィレクトリに統合して実装することとし、本項目では残る 3番目と 4番目の検討を行った。
ウェブ・アプリケーション開発における「サポート・コンポーネントの共通化」および「ユ
ーザーインターフェースの開発支援」はいずれもアプリケーション・フレームワークとし
て検討するべき課題である。本事業では当初 PHP を皮切りに「複数のスクリプト言語に対
応できるアプリケーション・フレームワーク」の開発を目指したが、3.1.2 で述べた理由に
より「PHP に特化したアプリケーション開発支援」へと開発方針の転換をおこなった。そ
れにより本開発項目では CQI と併用可能な既存 PHP 向けアプリケーション・フレームワ
ークの活用を念頭にした開発を検討することとなった。
52
3.2.2. CQIと併用可能な既存の PHPアプリケーション開発支援ツール・ライブラリ
3.1 で説明したように新たな CQI は PHP/PDO と互換性のあるインターフェースを採用し
ているので、原則として既存の PHP アプリケーション開発支援ツールやライブラリとは併
用可能である。まずユーザーインターフェースの開発支援で重要なのはアプリケーショ
ン・フレームワークである。著名な既存の PHP アプリケーション・フレームワークとして
は CakePHP、Symfony、Zend Framework などが知られているが、近年注目を集めるの
が CodeIgniterである。CodeIgniter は既存の PHP アプリケーション・フレームワーク（特
に Symfony と Zend Framework）に比較すると軽量・高速なアプリケーション・フレーム
ワークである。
図 24
図 24 に Google トレンドによる PHP アプリケーション・フレームワーク主要 4 種の注目
度を示す。CodeIgniter は 2011 年以降、先行するフレームワーク 3 種より高い注目を集め
ていることがわかる。これには様々な理由が考えられるが、特に非常に大規模なフレーム
ワークである Symfony や Zend Framework に比べて、小規模ゆえに学習が容易であること
が多くの支持を得ている理由だと推測される。この小規模なフレームワークであることは
CQI との併用を考える上でも優位であると考え、本開発では CodeIgniter を利用して開発
することとした。
更にウェブ・アプリケーションにおいてユーザーインターフェースのもう一つの要となる
のは JavaScript であるが、本開発項目では jQuery を利用することとした。jQuery はウェ
ブ・アプリケーションの JavaScript 対応では定番のライブラリなので詳細の説明は割愛す
る。
53
3.2.3. YCSB Web UIの開発
Yahoo! Cloud Serving Benchmark（YCSB）に付属するクライアントは、各種 KVSに対し
擬似的なリクエストを発行して負荷を生成する CLI ベースのソフトウェアである。多くの
CLI ソフトウェアと同様に、コマンドを実行するためには予め Workload 等を定義したコン
フィグレーションファイルを作成しなければならない。YCSB Web UI は YCSB の
Workload の定義とコマンド実行を統合したユーザーインターフェースを提供するもので
ある。
● Workload
YCSB を利用するためにはまず Workload について理解しておかなければならない。
Workload の意義や背景、使用方法に関する説明は付録 A に譲るが、ここでは Workload の
詳細について説明する。Workload とはターゲットとなる KVS に発行するリクエストのリ
ードとライトの書込みを混合する割合やデータサイズ、データ分布などを定義であり、
YCSB において KVS の性能評価のための条件設定として使用される。1 つの Workload は
ある 1 つの視点での性能評価を定義するものであり、YCSB では複数の Workload を作成し
様々な視点から性能を計測することによりターゲット KVS の総合的な性能評価を行う。
Workload のパラメータは次の 21 項目である。本アプリケーションでは全てのパラメータ
を設定できるが値を指定しない場合には各値にデフォルト値が割り当てられる。
fieldcount（任意）
1 レコードのフィールド数（RDB でいうカラム数）
fieldlength（任意）
フィールドのバイト長（すべてのフィールドが String で定義される。）
readallfields（true/false）
レコード操作 read したとき、すべてのフィールドを取得するか否かの設定
（false の場合は、ランダムに 1 フィールドを選択し、取得する。）
writeallfields（true/false）
レコード操作 write したとき、すべてのフィールドに書込むか、ランダムに選択さ
れた 1 フィールに書込むかを選択する。
54
次の 5 つの proportion は、5 つの合計が 1 を超えないように設定する。
readproportion（任意（0.00 ～ 1.00））
実行されるオペレーション内の「read」操作の割合を指定。
updateproportion（任意（0.00 ～ 1.00））
実行されるオペレーション内の「update」操作の割合を指定。
insertproportion（任意（0.00 ～ 1.00））
実行されるオペレーション内の「insert」操作の割合を指定。
scanproportion（任意（0.00 ～ 1.00））
実行されるオペレーション内の「scan」操作の割合を指定。
readmodifywriteproportion（任意（0.00 ～ 1.00））
実行されるオペレーション内の「read」操作の割合を指定。
requestdistribution（任意）
発行させるリクエストの部分を指定する。一様分布（uniform）、Zipfine 分布、
lastest（新規に挿入されたデータを優先的に取得する分布）の 3 つが選択できる。
maxscanlength（任意）
Scan 操作を行った場合、一度に Scan を行う最大レコード数。
scanlengthdistribution（任意）
Scan 長の分布。一様分布、または Zipfine 分布から選択できる。
insertorder（任意）
insert 操作を行う場合のレコード順を定義している。昇順またはハッシュ値による
ソートが選択できる。
recordcount（任意）
アクセス対象となるレコード数を定義する。
operationcount（任意）
オペレーション（insert、update、read、scan）回数を定義する。
threadcount（任意）
Client が同時に使用する thread 数を設定。
target（任意）
任意の Throughput を指定することができる。
55
db（任意）
ベンチマーク対象のデータストアを指定する。本アプリケーションの場合、
Cassandra、または MongoDB
measurementtype（任意）
各操作の Latency の計測結果出力フォーマットの指定。histogram、または
timeserise を指定することができる。
timeseries.granularity（任意）
measurementtype で timeserise を選択した場合、任意の chunk サイズで平均化
することができる。
exporter（任意）
測定値のエクスポート設定。JSON 形式、または TEXT 形式を選択できる。
56
図 25
● アプリケーションの操作フロー
本アプリケーションはウェブ・インターフェースを介して、YCSB の「Workload 定義」と
「コマンド実行」を支援する。全体の操作フローを図 25 に示す。
初期画面は Run Workload（ベンチマーク実行画面）である。ここでは YCSB 実行パラメ
ータの入力（パラメータ値の入力）を行うが、「新規ワークロード作成（Workload の定義）」
を指定して新たな Workload を定義することも可能である。「新規ワークロード作成」を指
定した場合には所定のパラメータ定義を行った後に Run Workload に戻る。
YCSB 実行パラメータの入力が終了すると「execute（コマンド実行）」を押すことにより、
YCSB コマンドが実行される。ベンチマークが終了すると、ベンチマーク結果ファイルを
表示することができる。
57
図 26
● 新規ワークロード作成
新規ワークロード作成画面の画面イメージを図 26 に示す。
①で囲まれた部分は前述のパラメータを入力する欄である。画面に表示されていないパラ
メータに関しては②のリンクをクリックすることにより、さらに詳細なパラメータを設定
することが可能である。
各パラメータの入力後③の「save」ボタンを押すことにより、オリジナルな Workload を
作成することができる。
58
● ベンチマーク実行画面
ベンチマーク実行画面では、ベンチマーク実行に必要なパラメータを UI にて自動生成し実
行を行う画面である。
ベンチマーク実行時に、パラメータを指定することが可能であり、そのパラメータは新規
ワークロード作成画面で指定したパラメータを上書きしてベンチマークを実行することが
可能となっている。
実行コマンドに付加できるパラメータには以下の様なものがある。
recodecount
Workload の recodecount と同等
operationcount
Workload の operationcount と同等
threads
Workload の threadcount と同等
target
Workload の target と同等
measurementtype
Workload の measurementtype と同等
timeseries.granularity
Workload の timeseries.granularity と同等
exporter
Workload の exporter と同等
また、コマンドライン上でベンチマーク対象データストアの指定が可能となっている。
59
図 27
上の図は、ベンチマーク実行画面の画面イメージである。
①は、新規ワークロード作成画面で作成した workload、または YCSB がデフォルトで作成
した Workload があり、どの Workload を実行するか選択を行う。
②で、ベンチマーク対象データストアの選択、上記パラメータの指定を行う。なお、③の
エリアには、実際に実行されるコマンドラインが表示されるようになっている。
④では、フェーズの選択を行う。YCSB には 2 種類のフェーズがあり、1 つは「Loading
phase」、もう 1 つは「transaction phase」である。Loading phase は、データをデータス
トアに格納するフェーズであり、Workload で指定された recodecount の数分データの
insert を行う。Transaction phase は、Workload で指定されたオペレーションを実行し、
結果を取得するフェーズである。
④まで指定し終わったら⑤でベンチマークの実行が開始される。
なお、⑥の部分は、画面切り替えとなっている。
60
3.2.4. SPECweb2009 Web UI開発
SPECweb2009 は SPEC 社が開発した Web サーバーを対象としたベンチマークシステム
で、主に HTTP サーバーの応答性能に着目した性能評価を行う。
● SPECweb2009 の概要
SPECweb2009 では実在する大規模ウェブ・サービス・サイトの稼働ログを参考に 3 種類
の一般的なウェブ・サービスを想定して各々のサービスを模したのコンテンツ・セットが
用意されている。これらは PHP 及び JSP を使用し動的コンテンツとして実装されている
が、リクエスト処理時間に対するバックエンド・データベースの性能の影響を回避するた
めデータベースアクセスは等価なエミュレーションを行う。
● SPECweb2009 に付属するソフトウェア
SPECweb2009 では前述の 3 種のコンテンツを仮定した HTTP リクエストを生成するクラ
イアント・ソフトウェアも提供される。このソフトウェアのコンフィギュレーションを変
更することにより発生する HTTP リクエストの負荷を調節したり、負荷時間を自由に設定
したりすることができる。さらにアクセス対象となるコンテンツを絞ったりすることも可
能である。SPECweb2009 クライアントは次のソフトウェアから構成される。
Prime Client
SPECweb2009 の各構成要素を制御する。Client 動作制御、Client、Webserver、
BeSim の初期化、ベンチマークテスト結果の導出などを行っている。
Client
実際に負荷をかけるマシン。サーバーへのリクエスト送信、レスポンスの受信を
行っている。Prime Client 1 台に対して、複数台の設定が可能。
SPECweb2009 ではこの他に BeSim（Backend Simulator）と呼ばれるデータベース・シ
ミュレータも提供され、動的コンテンツのリクエストに対して乱数を使用し生成した検索
結果を模したパラメータを渡す。（トランザクション機能のエミュレート）
SPECweb2009 では以上のソフトウェアと計測対象となる HTTP サーバーを使用してウェ
ブ・サービスのシステムを構築し、所定のHTTPリクエストによる負荷を発生させて、HTTP
サーバーのパフォーマンスを計測する。
61
● SPECweb2009 Web UI
SPECweb2009 に付属するクライアントもまた CLI ベースのソフトウェアで、コマンドを
実行するためには予めコンフィグレーションファイルを作成しなければならない。
SPECweb2009 Web UI は SPECweb2009 のコンフィグレーション設定とコマンド実行を
統合したユーザーインターフェースを提供するものである。
前述のように SPECweb2009 では “Banking”、”Ecommerce”、”Support” の 3 種類のサー
ビス（コンテンツ）が想定されているが、本アプリケーションではそのうちの ”Support
Workload” のみをサポートしている。“Support Workload” は製品ベンダーの製品サポート
のページを模した負荷である。「製品検索」、「検索結果のブラウズ」、「検索結果リストから
の対象ファイル選択」、「ファイルのダウンロード実行」など実際のウェブ・サービスで提
供されている一連の操作が可能である。ファイルダウンロードのアクセス頻度に関しては
Zipf の法則で算出され、より実際のサポート・ページに近いアクセス・パターンを生成す
る。
● 本アプリケーションの操作フロー
本アプリケーションの操作フローを図 28 に示す。初期画面はベンチマーク実行画面である。
既存のコンフィグレーションを使用する場合は、一覧から選択を行い、実行確認画面へ遷
移する。実行確認画面は、コンフィグレーションの詳細が表示され、最終的にベンチマー
クを実行するかの判断を行う。既存コンフィグレーションの編集に関して、パラメータの
修正はもちろんのこと、別 IDでの登録も可能である。コンフィグレーション作成、及び編
集・削除は登録、上書き、削除が完了したときに各完了画面に遷移し、ベンチマーク実行
画面に遷移する。
62
図 28
● コンフィグレーションファイル生成画面
SPECweb2009 では、ベンチマークを実行するにあたり 2 つのコンフィグレーションファ
イルが必要となる。1 つが、ベンチマーク実行自体を設定する「Test.config」、もう 1 つが
各 Workload の設定を行うためのファイルである。今回は、Support Workload のみが対象
となるので、「SPECweb_Support.config」となる。
両ファイルには、様々なパラメータを設定できる半面、何を設定しなくてはならないのか
を判断することが非常に難しい。そこで本アプリケーションは、SPECweb2009 Support
Workload ベンチマーク実行に必要なパラメータのみを設定できるようにした。
63
実行に必要なパラメータは以下の通りである。
Test.config
CLIENT
ベンチマーク対象 Web サーバーにリクエストを発行するノードを指定する。
SIMULTANEOUS_SESSIONS
同時接続セッション数。
WEB_SERVER、WEB_PORT
ベンチマーク対象 Web サーバーとポート番号を指定する。
BESIM_SERVER、BESIM_PORT
BESIM サーバーとポート番号を指定する。
WARMUP_SECONDS
ベンチマーク実行前に、リクエストを発行し WARMUP する時間を指定する。
THREAD_RAMPUP_SECONDS
リクエストを発行するスレッドの生成時間を指定する。
THREAD_RAMPDOWN_SECONDS
上記スレッドの停止時間を指定する。
SPECweb_Support.config
RUN_SECONDS
ベンチマーク実行時間を指定する。
ITERATIONS
繰り返し回数を指定する。
DIRSCALING
アクセス対象コンテンツ数を指定する。Support WorkloadにはDownloadがあり、
その Download 対象コンテンツ数を指定することができる。
このほかのパラメータに関しては、すべてデフォルト値で問題ない。
64
図 29
図 29 に新規コンフィグレーションファイル生成画面の画面イメージを示す。
①は、コンフィグレーションファイルの識別のために、シナリオ名、Prime Client となる
サーバーを指定する。
②は、上記に記載した各パラメータの入力を行うことができる。
なお、「デフォルト値入力」、「ホスト一覧からの選択」は、弊社の実験環境にあったデフォ
ルト値、ホスト名が表示されるようになっている。
65
図 30
● ベンチマーク実行画面
図 30 にベンチマーク実行画面のイメージを示す。
画面で指定したシナリオを使用してベンチマークを実行する画面である。
①は、新規コンフィグレーション生成画面に遷移することができる。
②はシナリオ名で検索を行うことができるが、現在は完全一致のみをサポートしている。
③では、ページ制御を行っている。表示単位として 5,10,20,40 件が指定することができ、
ページ数も動的に変化する制御を行っている。
④は、各項目に対して昇順、降順を指定することができる。（ただし文字列表示されている
ところのみ）
⑤は、指定したコンフィグレーションファイルの編集・削除画面に遷移する。
一覧の「選択」ラジオボタンを選択し、⑥のベンチマーク実行ボタンを押下することによ
って、ベンチマーク実行確認画面に遷移を行う
66
3.3. リソース・ディレクトリ
本開発項目ではクラウド・コンポーザビリティによる各種連携のデータ共有基盤となるリ
ソース・ディレクトリの開発を目標に掲げた。当初、平成 23 年度は「クラウド内情報の集
約・共有の実装を行うが、続くクラウド間での情報共有の実装を踏まえてクラウド間連携
に関する想定モデルに基づくメタデータの定義を行う」としたが、「クラウド間での情報共
有の実装」が順延することとなったため、「クラウド内での情報の集約・共有」のみを実装
した。
3.3.1. リソース・ディレクトリのコンセプト
リソース・ディレクトリはクラウド間にまたがって任意のクラウドのサービス構成などの
管理情報を格納するサービスである。その実態は個々のクラウド・システムを構成する一
部（あるいは全部）のサーバーを集めて形成するデセントライズド（非中央集中型）なオ
ーバーレイ・ネットワークであり、これによりクラウド間での仮想的なディレクトリ・サ
ービスを実現する。（図 31 参照）
任意のクラウド・システムがリソース・ディレクトリのサービスを受けるためには、その
配下にある一部（あるいは全部）のサーバーがリソース・ディレクトリを形成するオーバ
ーレイ・ネットワークに参加している必要がある。このサーバーはオーバーレイ・ネット
ワークへの参加以降はリソース・ディレクトリに対するゲートウェイ的な役割を担う。各
クラウド・システムはその配下の少なくとも 1 台のサーバーをオーバーレイ・ネットワー
クに参加させる必要があるが、冗長化のために複数のサーバーを参加させることも可能で、
全てのサーバーをオーバーレイ・ネットワークに参加させる場合も考えられる。
任意のクラウド・システム配下の任意のサーバーは、そのサーバーがオーバーレイ・ネッ
トワークに参加しているか否かに関わらず、サポート API が提供する単一のインターフェ
ースによりリソース・ディレクトリへアクセスすることができる。任意のサーバーは任意
のクラウド・システムのリソース・ディレクトリに対し参加（および離脱）を通知するこ
とにより、そのクラウド・システム配下の他のサーバーから認識されるようになる。リソ
ース・ディレクトリはサーバーの稼働状態（参加・離脱）だけではなく、各サーバーに展
開されているアプリケーションやその実行状態、対応可能なサービスなどクラウド・シス
テムの稼働に関する各種の管理情報を格納・参照することができる。またリソース・ディ
レクトリは参加状態にあるサーバーの一時的な停止を原則として許容するので、これによ
りクラウド・システム内での障害による部分的な停止がクラウド・システム全体へ影響す
ることが回避できる。さらに、任意のサーバーはサポート API を使って外部のクラウド・
システムの（サービスなど一部の）管理情報を入手することも可能である。この機能によ
りクラウド・コンポーザビリティによるクラウド間連携が可能となる。
67
図 31
68
図 32
3.3.2. クラウド・システム内の管理情報の集約・共有
クラウド・システム内の管理情報の集約・共有では単一のクラウド・システムを構成する
サーバーおよびサービスの管理情報をリソース・ディレクトリへ集約・共有する機能を実
現する。具体的には図 32 に示すようにクラウド・システムを構成する複数のサーバーのう
ちの少数をリソース・ディレクトリを形成するものとする。その他のサーバーからは任意
のタイミングで自律的に管理情報がリソース・ディレクトリに格納され、リソース・ディ
レクトリを形成する少数のサーバー間で格納情報は共有される。任意のサーバーが他のサ
ーバーの管理情報を参照する場合、リソース・ディレクトリを形成するサーバーのいずれ
かにアクセスして情報を取得する。リソース・ディレクトリは複数のサーバーで冗長化さ
れて稼働するため、いずれかのサーバーに障害が発生してもリソース・ディレクトリのサ
ービス自体はその影響を受けない。
平成 23 年度の実施計画書においてリソース・ディレクトリの実現のために分散ハッシュテ
ーブル（DHT）技術の活用を想定していたが、次のような理由により設計方針の変更を行
った。
1 つのクラウド・システムを構成するサーバーは比較的少数であることが多い。
データセンターに設置されるサーバーのアベイラビリティは比較的高く、数台に
よる冗長化で耐障害性は十分に確保される。
管理情報は管理対象となるサーバーから頻繁に格納されるのでデータ格納に伴う
処理は高速かつ低コストでなければならない
これらの要件を満たすため管理対象となるサーバーからは UDP メッセージをブロードキ
ャストで送信することとし、リソース・ディレクトリを形成するサーバーはこのブロード
キャスト・メッセージを自律的に取り込んで内部データベースに格納すると共に、リソー
ス・ディレクトリを形成するサーバー間では定時的に内部データベースの整合性をチェッ
クする設計に変更した。
69
図 33
3.3.3. リソース・ディレクトリの実装
リソース・ディレクトリを形成するサーバーは今後のクラウド間での情報共有を考慮する
とインターネットからの接続が必須となる。本事業の提案においてインターネットとの接
続を必須とするサーバーは平成 22 年度に開発した HTTP フロントエンドなので、これにリ
ソース・ディレクトリのための実装を追加した。図 33 にその概要を示す。
図中の PaaS Core と記されたサーバーからは UDP によるブロードキャスト・メッセージ
を使ってアプリケーション・レベルでの PING メッセージが送られる。リソース・ディレ
クトリを形成する HTTP フロントエンドはメッセージ・ゲートウェイを介してこのメッセ
ージを受け取り、HTTP リクエストの転送先を決定するルートテーブルを更新する。この
メッセージ・ゲートウェイ機能により HTTP フロントエンドはバックエンドの PaaS Core
が稼働するサーバーからの PING メッセージを受け取ると自動的に HTTP リクエストを転
送するようになる。バックエンド・サーバーが PING を送信し続ける限り、ルートテーブ
ルの対応するエントリはメッセージ・ゲートウェイにより維持され続けるが、PINGが途絶
えて一定時間が経過するとルートテーブルの該当エントリはメッセージ・ゲートウェイに
より削除される。したがってバックエンド・サーバーの稼働状態に同期して HTTP リクエ
ストの転送が行われる。
なお、各サーバーの稼働情報は PING メッセージにピギーバック(Piggyback)してリソー
ス・ディレクトリに格納されるが、この実装は「クラウド間での管理情報の共有」の開発
時に実装するものとする。
70
4．開発成果の外部リリース
本事業での開発成果は Cloudbusting Mach（CBM）4として一般に公開している。
これまでに下記の 2 つのリリースを行った。
CBM 0.1 平成 22 年度の開発成果を収録
CBM 0.2 統一的クエリーインターフェース（PDO/CQI）を収録
CBM は Apache License に基づきリリースされている。
4.1. Cloudbusting Machine（CBM）0.1
CBM 0.1 は平成 22 年度の開発成果をベースとしており、次の内容のリリースを行った。
C による GQL 互換エンジン
PHP-C バインディング
Cassandra 0.7.2 サポート
MongoDB 1.8.2 サポート
郵便番号データベースによるベンチマーク（zipbench）
なお、このリリースではライセンスの問題により MySQL に関わるサポートコードは収録
されていない。
CBM 0.1 は都合 4 回のリリースを行っている。
その履歴は下記の通りである。
0.1α 2011 年 6 月 7 日 CQI C/C++パートの整備
リリースベースの構築
0.1β 2011 年 6 月 17 日 CQI PHP パートの整備
Cassandra サポート
0.1 2011 年 7 月 8 日 Web アプリケーションによるインターフェース
郵便番号データベースによるベンチマーク
0.1.2 2011 年 8 月 12 日 MongoDB サポート
4 http://www.gryfon.iij-ii.co.jp
71
4.2. Cloudbusting Machine（CBM）0.2
CBM 0.2 は 3.1 で説明した PDOに対応した CQI に伴うリリースである。次の内容を収録
している。
PDO 対応した CQI インターフェース
サポート KVS： Cassandra、MongoDB
その他の KVS サポート（Hypertable、Cassandra0.7(MyCassandra)、Memcached）は今
後のリリースにて収録する予定である。また MySQL 関連コードは PDO そのもので標準サ
ポートされているので対象から除外することした。
CBM 0.2 は都合 3 回のリリースを行っている。
その履歴は下記の通りである。
0.2 2011 年 11 月 11 日 Cassandra、MongoDB 対応版リリース
0.2.1 2011 年 12 月 2 日 PDO/CQI 統合化ドライバーの収録
0.2.2 2011 年 12 月 22 日 上記のバグフィックス・バージョン
4.3. 今後のリリース
本年度事業終了後に CBM 0.3 として平成 23 年度開発成果をベースとするリリースを行う
予定である。
72
5. 今後の課題
平成 23 年度は平成 22 年度開発成果を元に統一的クエリーインターフェース、PaaS アプリ
ケーションおよびリソース・ディレクトリの開発を行った。事業全体としては当初の計画
よりも統一的クエリーインターフェースの開発への比重が増した結果となった。
5.1. クラウド・コンポーザビリティ
本事業ではクラウド・コンポーザビリティによるクラウド間連携を目指しているが本年度
は結果的にその前提となる統一的クエリーインターフェースの開発に労力を割くこととな
ったため、開発成果としては当初計画よりは軽微なものになった感がある。
今後も本項目の開発は続行する予定であるが、今後の課題は「クラウド間での管理情報の
共有」である。本年度はクラウド内での管理情報の収集・共有のための機構を実装したが、
現時点ではこの機構を使って共有できる管理情報は最低限に留まっている。この機構は本
来、クラウド間での管理情報の共有までが実現できたところで大きな役割を果たすのでや
む得ない。現在の開発成果を見ると特に「クラウド間連携に必要な管理情報の具体化」は
検討が遅れている。この検討を踏まえた「共有すべきメタデータの定義」は非常に重要な
開発課題であるので、今後一層注力して行く予定である。
5.2. 統一的クエリーインターフェース
統一的クエリーインターフェース（CQI）はそれ単独での事業リソース化の構想もあり大い
に成果が上がった。しかしながら、現在の開発成果の性能を見る限りクラウド環境化で従
来の RDB と等価な性能を発揮するためには更なる性能向上が必要であろう。性能評価作業
を仔細に確認すると CQI はターゲットとなる KVS の性能や安定性に非常に大きな影響を
受けることが改めて確認できた。今のところ既存のオープンソース系 KVS の性能や特性は
非常にバラツキが大きい。これらを組み合わせる CQI の視点で考えると、従来の KVS を
公平に扱うアーキテクチュアではなく、適材適所が可能なより複雑なシステム構造をサポ
ートできるミドルウェアとして再考する必要があると考えている。
73
付録 A. YCSBによる Key-Value Storeの性能評価
伸縮自在のクラウド・サービスを支えるストレージ技術として Key-Value-Store（KVS）は
広く認知されている。KVS はクラウド環境でのストレージの役割を担うシステムの 1 例で、
特にスケーラビリティや耐障害性に優れている。今日の KVS は Cassandra や MongoDB
といったオープンソース・ソフトウェアとして広く配布されている事例も増えてきている
が、未だ一般的な性能指標がないためにオープンソース系 KVS の性能の比較は難しい。
Yahoo! Cloud Serving Benchmark（YCSB）は（少なくとも現時点では）数少ない KVS
に特化したベンチマークで、ワークロード（Workload）として定義できる任意の負荷を KVS
に与えて、そのスループット（Throughput）と平均遅延時間（AverageLatency）を計測す
ることができるソフトウェアである。
筆者のグループは KVS の性能的な特徴を調査するために YCSB を使用しているが、本項で
は我々のテスト環境において行った Cassandra 0.7 の性能評価ついて記載する。
A.1. Key-Value Storeの概要
Key-Value Store(KVS)はその名の通り「キーと値のペアを格納するストア（ストレージ）」
と定義され、保存したいデータ（value）とそのデータを識別するキー(key)を設定して、両
者を併せて格納できる機能を提供する。抽象的な概念としての KVSではキーとデータの関
係だけを規定するので、ファイル名（あるいはパス名）とデータの組み合わせと考えれば
一般的なファイルシステムも KVS と理解することができるし、多くのプログラミング言語
がサポートする連想配列も引数をキー、代入する値をデータと解釈すれば KVS であるとい
うことができる。このように KVS はデータを格納する仕組みを抽象化しているが、そこで
はキーとデータの格納(PUT)、キーによるデータの参照(GET)、キーによるデータの削除
(DELETE)の 3 つのオペレーションが定義できる。YCSB 論文ではこのようなオペレーシ
ョンが可能なインターフェースを備えたシステムを KVSと理解している。5
クラウド・ストレージとして利用される KVSの多くは、自律分散システムを構成すること
が前提となっているが、次のような特徴を有することが広く知られている。
スケーラビリティに優れている
任意のタイミングで構成ノードの追加や削除が可能なので、必要に応じてシステムの
規模を伸縮することができる。（スケールアウト、伸縮性）
耐障害性が高い
データを冗長化して格納するので、システムは個々の構成ノードの障害に影響される
ことなく運用を継続することができる。（高可用性）
5 このようなシステムを「分散 KVS」と表現する文献もある。
74
A.2. YCSBについて
YCSB は様々な「Key-Value Store」や「Cloud Serving Store」の性能測定フレームワーク
と、ワークロードの共通セットを提供している。YCSB はデフォルトセット内には
「Cassandra」、「MongoDB」、「HBase」、「Voldemort」のドライバーが同梱されており、
前述のデータストア以外のデータストアにも拡張可能な仕様となっており、ワークロード
のカスタマイズも可能である。YCSB によって個々のデータストアの特性を把握し、シス
テム構築に相応しいデータベースを見つけることが可能である。
A.2.1. YCSBの評価方法
クラウド・サービスを提供するシステムが必要としていることを評価するために 2 つの評
価軸を定義する。
A.2.1.1. パフォーマンス
YCSB におけるパフォーマンス測定では、データベースに負荷がかかっているときのリク
エストの Latency（遅延時間）に着目している。例えば Web サービスを提供する場合、
Latency は Web ページが表示されるまでの時間に直接の影響があるので非常に重要である。
また Latency と Throughput は常にトレードオフの関係にある。Throughput が増加して
いくとハードウェア（CPU、memory、ネットワーク等）に過度な負荷がかかるが、その場
合には受け付けたリクエストを処理することに時間を要す。その結果 Latency が増大する
と Throughput が減少していく。YCSB を使った計測では同様の状態を生成するために、
クライアントから発生する Throughput を増大させながら、各 Throughput の Latency を
記録し、データベースの処理能力が飽和したところで測定を完了させる。
通常、アプリケーション開発者がサービスを開発する場合、許容できる Latency やシステ
ムが想定するリクエストに耐えうる Throughput の範囲を決定する必要があり、サービス
に必要な Throughput で稼働させた際に Latency が許容範囲を超えてしまう場合にはサー
バーの台数を増やすなどの対策を取り負荷分散させる必要がある。YCSB のクライアント
にはこのような負荷状況を再現するベンチマークが可能で「データ・セットを定義し、デ
ータベースにデータローディングを行う」機能と「任意のデータベース操作を行いながら
パフォーマンス測定を行う」機能が実装されており、データ・セットとそのデータ・セッ
トに対する操作を定義できるようになっている。また任意の Throughput を指定すること
も可能で、ベンチマーク実行後は Throughput と Latency のグラフ化が容易な出力を生成
する。
75
A.2.1.2. スケーラビリティ
システムの伸縮性、すなわちスケーラビリティはクラウド・システムにおける重要な要素
の一つである。システムをスケールさせることによって、アプリケーションの機能追加や
データの蓄積による負荷増加に対応が可能となる。
YCSB ではシステムにマシンを追加したときの影響を検証することによって、スケーラビ
リティ特性を判定する。評価は「スケールアップ」と「エラスティック・スピードアップ」
の 2 つからなる。
スケールアップ
測定対象のシステムがスケールアップ特性に優れている場合、ある任意の台数からサ
ーバーを増やしたとき、Latencyは増加せずに Throughput が増加する。
エラスティック・スピードアップ
測定対象のシステムがエラスティック特性に優れている場合には、任意の台数のサー
バーでベンチマークを実行している間に新たなサーバーを追加すると、その直後に
Throughput が上昇するが Latency は劣化しない（または瞬間的な劣化で留まる）。
A.2.2. Benchmark Workload
YCSB が生成する負荷は Workload と呼ばれ、読込みと書込みを混合する割合、データサイ
ズ、データ分布などが定義する。1 つの Workload はシステムのある側面での評価を定義す
ることになるので、Workload をパッケージ化することによってシステム全体の性能や傾向
を評価することができる。利用者は Workload のパラメータを設定したり、必要であれば
YCSB に Java コードを追加したりすることで様々な検証を行うことが可能である。
YCSB で取り扱うデータは任意の数のフィールドからなるレコードを格納する 1 つのテー
ブルで構成されプライマリキーで識別される。フィールド名は ”field0”、”field1” の様に
‘field + 連番’ で命名され、格納される値はランダムに作成された任意長の ASCII 文字列で
ある。データベースに対して次のような操作が行える。
Insert 新規レコードを 1 件挿入する
Update 1 つのフィールドに対して内容を変更する
Read 設定によってランダムに選ばれた 1 フィールドまたは全フィールドを
読み込む
Scan 一連のレコードをキー順に読み込む。読込み開始キーはランダムに選択、
レコード数は任意に設定。
76
ワークロードクライアントは、ベンチマークを実行するためにランダムな値を多用してい
る。workload で使用する乱数分布アルゴリズムも選択することができる。
一様分布（Uniform）
完全にランダムに選択を行う。データストアのレコード選択に使用すると全ての
レコードが同確率で選択される。
Zipf 分布
ごく一部のデータが頻繁に選択され（ヘッド）、他多数（テール）が滅多に選ばれ
ない。
最新傾向（Latest）
Zipf分布に近いが最近挿入されたレコードがヘッドになり選択されることが多い。
多項分布（Multinominal）
項目ごとに任意に確率を設定できる。
Zipf 分布は一部のデータへアクセスが集中し、残りの大半にアクセスがないというモデル
から一般的な Web アプリケーションのアクセスモデルとして使用されることが多い。
● Workload のサンプル
前述のとおり、1 つの Workload で 1 つの側面しか評価することはできない。
そこでYCSBでは一般的な特性を持つ表 1のようなWorkloadのサンプルを定義している。
表 1
77
A.3. ベンチマーク
今回、本事業では「Benchmarking Cloud Serving System with YCSB」での評価方式に基
づき Cassandra 0.7.5 を対象としたベンチマークを行った。この計測では同論文と概ね同
等の評価環境を構築し、同論文と同じ計測条件でパフォーマンスを測定するべく配慮した。
以降は本事業での計測の概要について述べる。
A.3.1. Benchmarking Cloud Serving System with YCSB との相違点
ここでは計測環境に関わる相違点について説明する。
ベンチマーク対象データストア
Benchmarking Cloud Serving System with YCSB では ”PNUTS”、 ”HBase
0.20.3”、”Cassandra 0.5.0”、”Shard MySQL” の 4 つのデータストアについて測定を
行っているが、本事業では ”Cassandra 0.7.5” の測定を行った。
サーバースペック
下記のスペックのサーバーを使用した。
Intel Xeon 2.13GHz 4Core × 2
24GB RAM
4TB HDD
ギガビットイーサ
このサーバーは同論文でのサーバーよりもハイスペックのマシンである。
また同論文では計測にあたりシステムに各種の最適化を行ったと記されているが、その仔
細については示されていなかったため、我々は原則としてデフォルトのセットアップで測
定を行った。
A.3.2. 測定条件
測定条件は原則として同論文の評価方法に準じた。
1 レコード 1KB のデータを 1 億 2000 万レコード、総計 120GB のデータを作成し、サーバ
ー6 台に分散させて格納した。このデータに対して Workload A、B、C、D を実行した。
パラメータで指定可能な Throughput は Workload A、Dでは 600 ～ 3000 までに 600 刻
みで 5 段階、Workload B、C では 400 ～ 2000 まで 400 刻みで 5 段階の測定を行った。
なお、Workload E に関しては計測環境を占有できる時間的な制限により計測を見送ったが、
その代替計測としてスケールダウンした Workload E の試行を行った。（詳細は後述）
78
A.4. 測定結果
A.4.1. Workload A
Workload A は、Update50%、Read50%の Workload である。
図 34
図 35
図 34 は、本測定の Workload A の測定結果、図 35 は「Benchmarking Cloud Serving
Systems with YCSB」Workload A の測定結果である。
79
本来であれば、バージョンアップに伴いオペレーション性能は向上しているはずであるが、
今回の結果では、Cassandra0.5.0 の最大 Throughput は 12,000 ops、Cassandra0.7.5 の
最大 Throughput は 3,000 ops となってしまっている。この原因として考えられることとし
て、「Benchmarking Cloud Serving Systems with YCSB」における Cassandra は、有識
者によって限界までチューニングされているのに対して、我々の測定は Cassandra に関し
てはほぼデフォルト値で測定を行っているためではないかと推測できる。
図 34 より、Throughputを増加させた場合、Update はほぼ一定の Latency で安定してい
るのに対して、Read は Throughput が 2500ops を超えたあたりから Latency が急激に増
加していることが確認できる。
図 35（b）（update）の Cassandra0.5.0 のグラフを見ると、図 34 の Update と同様にほ
ぼ一定の値を示している。図 35（a）（Read）の Cassandra0.5.0 のグラフを見ると、
Throughputが 11,000 ops を超えたあたりから Latencyが急激に増加していることが確認
できる。
Throughput は違うが、Update に関して Average Latency はほぼ同値であり、read に関し
ても、ある Throughput の値を超えると急激に Latency が悪化するという点では共通して
いると考えられる。
80
A.4.2. Workload B
Workload B は、Update5%、Read95%の Workload である。
図 36
図 37
図 36 は、本測定の Workload B の測定結果、図 37 は「Benchmarking Cloud Serving
Systems with YCSB」Workload B の測定結果である。
Workload Bに関してもWorkload Aと同様に、Cassandra0.5.0の最大Throughputは9,000
81
ops、Cassandra0.7.5の最大Throughputは 2,000 opsとなっており、性能が低下している。
原因は Workload A と同様であると考えられる。
図 34 と図 36 を比較すると、Throughput の限界点が低いことが読み取れる。これは、Read
オペレーションの割合が増加したことにより、Workload 全体のレスポンスが悪化したこと
が起因していると考えられる。
図 36 より Workload A と同様に、一定の Throughput を超えると Read の Latency が増加
していることが読み取れる。
図 37（a）（Read）の Cassandra0.5.0 を見ると、図 36 の様に Read Latency が急増する
ことは確認できなかった。しかし、Throughput が 9,000 ops 付近を見てみると、やや増加
傾向が見られるため、Throughput がより大きくなった場合に、同一の傾向が確認できるこ
とが予想される。
82
A.4.3. Workload C
Workload C は、Read100%の Workload である。
図 38
図 38 は、本測定の Workload C の測定結果である。Benchmarking Cloud Serving Systems
with YCSB では、Workload C のグラフを示していない。
Workload C は Workload B の Read とほぼ同じ特性を示している。
Benchmarking Cloud Serving Systems with YCSB 文中に Workload B と同じ傾向にある
と示されているため、本測定と同じ傾向にあると考えられる。
83
A.4.4. Workload D
Workload Dは、Insert5%、Read95%の Workload である。
図 39
図 39は、本測定のWorkload Dの測定結果である。Benchmarking Cloud Serving Systems
with YCSB では、Workload D のグラフを示していない。
Workload D も Workload B と同じ傾向であると考えられが、Workload B に比べて全体的
に Latency が低いことがわかる。この要因として考えられることとして、Workload B は
Web アクセスの典型例として使用される「zipfian」であるが、Workload D は「latest」で
ある。この違いによって、Workload DでReadを行う場合、Readの対象データが、Memtable
に存在する確率が高いと考えられ、SSTable へのアクセスが Workload B より少ないことが
予想される。よって、Workload Dは Workload B よりも Latency が低い傾向になったと考
えられる。
84
A.5. 考察
今回のベンチマーク測定において1番ネックとなったのが、「Benchmarking Cloud Serving
System with YCSB」に比べてパフォーマンスが低いことが挙げられる。
当初、我々の使用しているサーバーのほうがリソースが豊富であるため、「Benchmarking
Cloud Serving System with YCSB」よりも高 Throughput、低 Latency な結果を予想して
いたが、実際に測定を行うと我々の測定のほうが 1/4 程度のパフォーマンスしか出なかった。
原因を調査してみると、「Benchmarking Cloud Serving System with YCSB」では有識者
たちによる限界までのチューニングが行われていることが大きいことが分かった。
我々も、有識者に意見を求め可能な限りのチューニングを行った。我々が可能なチューニ
ングとしては、Cassandra のパラメータの変更であったが、パラメータチューニングでは
あまり大きな性能向上は出来なかった。
調査をしていくとと、Cassandra のアーキテクチャにより、Commit Log と SSTable 各々
を物理的に分けたディスクに書込むなどハードウェアのチューニングが大きな影響を与え
ていることが分かった。
Cassandra のチューニングは、Read 性能に大きな影響を与えるため、本測定の様にデフォ
ルト値でベンチマークを行った場合、Throughput が小さくなってしまう考えられる。
Cassandra の性能を最大限に使用するためには、ハードウェア設計も重要な要素であるた
め、システム構築を行う場合、検討を行わなければならない。
測定結果から考えられることとして、「Benchmarking Cloud Serving System with YCSB」
に書かれている Cassandraの特徴が、我々の測定からも確認がとれた。Cassandraは、write
データの差分をシーケンシャルに書込んで、書込み時に lock を必要としないため Write が
高速であると言われている。一方 Read は、Memtable にデータがない場合は、SSTable の
データをすべて検索する必要があるため、低速になってしまう。よってある一定以上の負
荷がかかると、急激に Latency が上昇するのではと考えられる。
KVS の性能測定である以上、大規模データでのベンチマークが必須であることは明白であ
るが、今回の測定を通して Throughput が低い KVS の測定を行う場合、非常に時間がかか
ってしまう。本測定もすべてのデータを 1回取得するのに 3週間程度の時間を使っている。
今後新たにリリースされる KVS は、Read/Write の性能向上し、複数回のベンチマークが
実行できることによって、より正確な性能測定が行えるものであると考える。
