私の所属している会社が作成したokuyamaの説明資料

1. 分散キーバリューストア
2012/1/18 1 Copyright (C) Kobe Digital Labo Inc. All Reserved.

2. KDLオリジナル開発
分散キーバリューストア「okuyama」
2012/1/18 2 Copyright (C) Kobe Digital Labo Inc. All Reserved.

3. 分散キーバリューストア：特殊なデータベース
リレーショナルデータベース 分散キーバリューストア
（Facebook）
（Google）
＜従来からのデータ管理手法＞ ＜新しい考えのデータベース＞
※メリット ※メリット
データの関連性を管理することに向いている 大量のデータを高速に処理することに向いている
※デメリット クラウドサービスでの活用が多い
大量のデータを高速に処理することには向かない システムの増強が容易
1台で管理するため障害耐久性が弱い ※デメリット
複雑なデータ管理には向かない
※導入例
基幹業務システム、情報系システム ※導入例
Google、Facebook、Twitter、mixi
※特性イメージ 楽天、Yahoo!、Amazon
ウォールマート
※特性イメージ
大量データ
高速処理
データ連携 データ保全 権限管理
※単純だから速い
データの関連性を管理 機密性
※複雑な管理ができるため
データベースソフトウェアが複雑
2012/1/18 3 Copyright (C) Kobe Digital Labo Inc. All Reserved.

4. 分散キーバリューストアの特徴
A：「Availability」
一貫性 （Consistency）
1つのデータへの操作は成功、失敗のどちらかしか発生しない
可用性 （Availability）
システムへの障害発生の可能性が極めて低い、もしくは障害時も稼働し続けることができる
P：「Partition C：
分割耐性（Partition Tolerance）
Tolerance」 「Consistency」 ネットワーク障害が発生した場合もシステムは停止せず稼働し続ける
また、極端なスループットの低下も起こらない
【RDBMS】 【分散キーバリューストア】
A A A
P C P C P C
RDBMSは一貫性を強く意識している 。 可用性や分割耐性のように、ネットワークを介して複
また、一貫性を優先するために、単一のサーバー資源 数のサーバー資源を活用する使い方に対する意識が高
上でデータを管理する設計になっている場合が多い 。 い。
2012/1/18 4 Copyright (C) Kobe Digital Labo Inc. All Reserved.

5. 使いやすい分散キーバリューストア「okuyama」
3 層 構 造 Storage Type 永続化・非永続化の選択、一貫性レベルの選択保存先の
選択(Memory, Disk, Disk + Memory)
Data Data Data Support Protocol Original, memcached, HTTP
client
Node Node Node
Master
Node 冗長性 複数台のサーバで構成されており、
Data Data Data サーバ追加も無停止で可能(アルゴリズム分散)
client
Node Node Node
可用性 全てのデータは多重化されて保存され、全ての構成要素
Master が多重化可能となっている
Node Data Data Data single point of failureが存在しない
client
Node Node Node
無停止データリカバリ 障害復旧時のデータの差異を修復するデータのリカバリ
client MasterNode DataNode は全て無停止で自動的に行われる
無停止データ再配置 サーバ追加後のデータ再配置は全て無停止で自動的に行
APから 分散処理制 データ保管
われる
okuyamaを 御する管理 される管理
操作するIF ノード ノード データ一貫性の強度の選択 取得するデータの一貫性を弱・中・強の中から選択可能
ストレージ特性の自由度 パーティション機能
• メモリに保存するか、ディスクに保存するかを選択することができる
•1つのクラスタに用途毎に合わせた領域を確保することができる
• 利用シーンに合わせて設定を選択できる
•メモリ：高速だが、データが永続保存されない
•パーティション毎に設定を変えることができる
•ディスク：データが永続保存されるが、メモリに比べて速度が务化す Valueへの全文検索機能
る
•Keyだけでしか検索できない分散キーバリューストアだが、Value
Tag付加機能 項目に対して全文検索を行うことができる
• Key以外にタグを追加することができるので、複数件のデータにアクセ •全文検索用のインデックス情報をグルーピングすることができる
スできる ので、検索したいデータ群を絞り込んだ上で全文検索が可能
• タグは理論上、無制限に付加できるので、利用シーンに合わせて自由に
タグを付加することができる Hadoop連携
JavaScript実行機能 •分散処理基盤としてメジャーなHadoopに対応
•パーティションやタグを指定してHadoop側で処理できるので、
• DataNode上で処理できるプログラムを配置でき、最もサーバ台数が確
保されるノードで実行することにより、高速な処理が可能 okuyama上のある一群のデータを対象に高速な分析処理ができる
2012/1/18 5 Copyright (C) Kobe Digital Labo Inc. All Reserved.

6. どういった場面で分散キーバリューストアを使うべきか
情報量が
日々増え
続ける RDBMSを全て
分散キーバ
リュースト 全てを解決
置き換えるので
アの特徴 する魔法の はなく、必要な
ネット
（RDBMS 技術ではな 箇所に最適な構
ワーク品
質が向上 との違い） い 成で導入するこ
してきた を理解する とが重要
分散キーバリューストア 分散キーバリューストア
適材適所
が発展してきた時代背景 を理解することが重要
●商品/顧客等のマスタ情報 ●分析
管理 →複数データを跨った計算
たとえば →単純な情報の管理 処理はAP側での計算処理
ECサイトで導入するとしたら・・・ が必要
●ログデータ管理
→増え続けるデータの管理 ●ロック処理
→単一更新ではない制御が
●セッション管理 必要な場合、ロック制御が
→同時処理性能が必要とさ できないため
れるデータの管理
2012/1/18 6 Copyright (C) Kobe Digital Labo Inc. All Reserved.

7. キーバリューストアの比較
特性 memcached Cassandra okuyama
参照高速性 ◎ △ ○
メモリのみので稼働するた メモリを利用しないため メモリとディスク両方を利
め高速 読み取り性能は低速 用出来利用シーンに合わせ
て調整が可能
堅牢性 × ○ ◎
1台での構築が前提であり 冗長化は可能であるが 冗長化が可能であり、既に
冗長化出来ない 高負荷時に不安定に 高負荷や長時間での無停止
なる場合が多い 運用実績がある
無停止拡張 × ◎ ◎
拡張する機能なし 無停止での拡張をサポート 無停止での拡張をサポート
国内実績 ○ ○ ○
既に多くのWebシステムで 国内でもソーシャル系を中 50億円以上の売上げ規模
の利用実績あり 心に利用され出している ECサイトでの利用実績あ
ECサイトでの利用は未確 り
認 インフラ事業社のプラット
フォームでの利用実績もあ
り
国内サポート × △ ◎
サポート企業なし 国内で個人が技術サポート 国内企業でのサポート体制
をされている程度 あり
2012/1/18 7 Copyright (C) Kobe Digital Labo Inc. All Reserved.

8. 導入事例から見る分散キーバリューストアの活用方法
2012/1/18 8 Copyright (C) Kobe Digital Labo Inc. All Reserved.

9. 大手アパレル企業様 ネットショップサイト：ECでの活用方法
※以前のシステム ※導入後のシステム
クライアント様が KDLの提案 ネットショップ ネットショップ
抱えていた課題 • NOSQL+RDBMSによ サイト サイト
• 急成長を続けるEC事 るハイブリッドシステ
業に対してシステム改 ムによりシステム全体 商品情報 在庫情報
善スピードを上げるこ の負荷を分散
とが急務 • 既存カートシステムか 在庫情報 購買履歴情報
• 閑散期と繁忙期でシス らアクセスするIFを準 購買履歴情報
テム負荷が大きく異な 備し、変更リスクを抑
り最適なIT投資が必要 制
商品情報
商品情報をokuyamaで管理する狙い・効果
キャンペーンページ
ECサイト上で数多く登場する商品情報に着目
・マスタという単純なデータ構造：キーバリューストアに向いている
・アクセス頻度が高い：分散処理のメリットが活かせる
ブランドトップページ
システム システム システム システム システム システム
A B C A B C
どれが最新？
項目が異なる
バッチが終わらない
購買履歴ページ ・RDBMSでは耐えれない処理能力を実現
ひとつ止まると全てに影響 ・情報の一元管理
容量の無駄
事業の中心となるデータであり、数多くのシステムが利用する
商品詳細ページ これまでは各システム間を夜間バッチ等でコピーしていた
→企業内での統一基盤を構築し、各システムから直接参照
2012/1/18 9 Copyright (C) Kobe Digital Labo Inc. All Reserved.

10. 日本ユニシス株式会社様 通販ソリューション：商品検索エンジンでの活用方法
多種な検索方法 検索エンジンAP okuyama標準機能 KVSの一般的機能
検索種別 Web-IF 全文検索 検索結果
キーワードから探す
事業展開に合わせた商品 日本語対応の全文検索エ 検索結果をそのままの形
検索 ンジン 式で保存
ジャンルから探す
EC/コールセンター/カタ 商品属性に対する全文検 高速に処理できるため、
ログ 索が可能 非正規化
サイズから探す
カタログから探す インデキシング タグ管理 分散高速処理
カラーから探す 高速なレスポンスのため 複数のデータを纏めて取 大量のリクエストを同時
のインデキシング 得 処理できる
価格帯から探す
24時間稼働しているため 理論上、無制限に設定可 分散処理基盤によるス
処理時間短縮が必須 能 ケールアップが容易
ソート順
売れている順 ◆Webサイトに於いて検索機能が一番使われる 接客で商品
訴求は基本
サイト全体の中で閲覧される割合
評価が高い順 （某大手ECサイトの場合）
・検索機能：15.97%！！
口コミが多い順 ・セールページ：13.92％ お客様は
・トップページ：2.26% 商品を探
している
価格が安い順
◆ECではほとんどのページで商品を検索している
売りたい商品を
積極的に露出
価格が高い順 商品詳細 商品一覧
カテゴリトップ キャンペーン
新着順
2012/1/18 10 Copyright (C) Kobe Digital Labo Inc. All Reserved.

11. 株式会社リンク アプリプラットフォーム：ソーシャルアプリ向け基盤での活用方法
• at+linkアプリプラットフォーム
– ソーシャルアプリ向け専用サーバパッケージ
– クラウドと専用サーバの両メリットを活かし
たサービス
– サービスの特徴として、okuyamaを利用した
サービスを提供
• キャッシュサーバサービス
• 画像サーバサービス
• 高速な処理基盤が必要なソーシャルアプリに
必要な機能をokuyamaで実現
– 大量アクセスに対する参照性能の向上
– アイテム・アバター等の大量画像を保存する
環境
◆関連掲載記事
【 @IT】at+link が分散 KVS「okuyama」を採用した理由
キャッシュサーバ 画像サーバ http://www.atmarkit.co.jp/ad/atlink/1103okuyama/1103okuyama.html
【レンタルサーバ完全ガイド】ソーシャルアプリに特化した専用サーバーで分
散 KVS キャッシュサーバーが利用可能に
• 一般的に利用されている • スケールアップがし易い http://rs.impressrd.jp/node/930
【gihyo.jp】アプリプラットフォームにKVSを使った高機能キャッシュサーバ登
memcachedの互換プロ 分散技術の特徴を活用 場 ソーシャルアプリ向け専用サーバパッケージ登場
トコルを活用し、導入 し、データ量が増え続け http://gihyo.jp/admin/serial/01/atlink/0005
ハードルを下げることが やすい画像を効率的に保
できた 存できる環境を構築する クライアント様 KDLの提案
• パーティション機能を使 ことが出来た が抱えていた課 •分散キーバリュー
用し、同じクラスタを別 題 ストアによる差別
化だけでなく、ク
ユーザに割り当てること •価格競争に陥りや
ライアント企業へ
により、インフラ投資コ すい業種で特徴付
同行訪問し、サー
けが急務だった
ストを抑えることができ ビス企画やクライ
アント企業の信頼
た 獲得に貢献
2012/1/18 11 Copyright (C) Kobe Digital Labo Inc. All Reserved.

12. 某化粧品会社様 キャッシュサーバ：memcachedからの置き換え
okuyama
を使うメ Memcached互換プロトコルを標準
Webサーバ memcachedは分散できないので1台 リット で準備しているので、Webアプリ
で構成される ケーションの改修をすることなく
↓ 導入することができる
仮にダウンすると、memcached（メ
モリ上）で処理していたものが全て
memcached DBサーバに集中し、システム全体が
ダウンしてしまうリスクがある
冗長構成によるシステムの信頼性
確保を取ることができず、システ
ム全体に於けるボトルネック（負
DBサーバ 荷・信頼性の面）となってしまう
ことが回避できる
複数台を論理的に1台に構成させる
ことができるため、大量のメモリ
Webサーバ を搭載した高価なマシンを準備す
okuyamaを使って分散構成とするこ る必要がない
とができる （memcachedの場合、搭載できる
↓ メモリ量が上限となってしまう）
システムダウンのリスク回避だけで
なく、リクエスト数増加に対するス
okuyama ケールアップにも対応可能
パーティション機能を利用して、1
つのクラスタ基盤を複数のシステ
ムで共用することができ、いくつ
かのシステムを運用する企業に
とっては全体的なコストメリット
DBサーバ がある
2012/1/18 12 Copyright (C) Kobe Digital Labo Inc. All Reserved.

13. よくあるご質問
2012/1/18 13 Copyright (C) Kobe Digital Labo Inc. All Reserved.

14. よくあるご質問
• Q：何件程度のデータの場合に分散キーバ • Q：okuyamaが利用されている事例の規模感
リューストアを導入すべきか？ は？
– A：単純な件数やアクセス数ではなく、システ – A：リクエスト数：秒間数万リクエスト
ムのスケールアップがどの程度必要か（成長 – A：レコード数：100億レコード
性）を考慮すると、特性を活かすことができ – A：データ容量：数TB
ます。
• Q：画像を保存することはできるか？ • Q：okuyamaクライアントとmemcachedク
ライアントとの違いは？
– A：可能です。画像データを細切れでokuyama
に保存させることにより、管理できます。 – A：memcachedクライアントの場合、
okuyamaの特殊機能が使えなくなります。
• Q：RDBMS上で複数のテーブルで管理して
いるデータを分散キーバリューストアで管理 • Q：ECシステムのセッション情報を管理す
するには、どうすればいいか？ る様なことには向いてるか？
– A：そのデータが利用される形式に合わせて – A：使い捨てる様な情報の管理にも向いてい
JSON形式で保存することが効果的です。 ます。
• Q：検索結果をソートすることはできます • Q：メール送信の仕組みをokuyamaで実現す
か？ るメリットはあるか？
– A：基本的にソートはできないので、AP側で – A：okuyamaにはキューイングの機能がある
処理する必要があります。 ので、大量のメール送信をする様な場合には
向いています。
2012/1/18 14 Copyright (C) Kobe Digital Labo Inc. All Reserved.

15. okuyama参考情報
• Facebookページ
– http://facebook.com/okuyama.jp
• Twitterアカウント
– @okuyamaoo
• プレスリリース
– 神戸デジタル・ラボ、Web時代に対応した国内初のNOSQLサポートサービス開始
http://www.atpress.ne.jp/view/22288
• ThinkIT
– okuyamaとその関連技術に関する紹介
http://thinkit.co.jp/story/2011/02/03/1990
– okuyamaの導入・運用に関する紹介
http://thinkit.co.jp/story/2011/10/12/2303
• 株式会社リンク様との事例関連
– 【 @IT】at+link が分散 KVS「okuyama」を採用した理由
http://www.atmarkit.co.jp/ad/atlink/1103okuyama/1103okuyama.html
– 【レンタルサーバ完全ガイド】ソーシャルアプリに特化した専用サーバーで分散 KVS キャッ
シュサーバーが利用可能に
http://rs.impressrd.jp/node/930
– 【gihyo.jp】アプリプラットフォームにKVSを使った高機能キャッシュサーバ登場 ソーシャ
ルアプリ向け専用サーバパッケージ登場
http://gihyo.jp/admin/serial/01/atlink/0005
2012/1/18 15 Copyright (C) Kobe Digital Labo Inc. All Reserved.

16. サポートサービス
2012/1/18 16 Copyright (C) Kobe Digital Labo Inc. All Reserved.

17. サポートの種類
サポートサービ
ス
構築の一部サ
構築は自ら対応 構築全般の依頼
ポートを希望す
する場合 を希望する場合
る場合
キャッシュサー
開発者/上級開発 ビフォア/アフ
サポート基本 電話/メール/オン バ/画像サーバ/検
者/運用者トレー ターDBコンサル 勉強会
パック サイトサポート 索エンジン構築
ニング ティング
パック
サポート基本パック 構築時・運用中のトラブルやお問合せに対する電話・メールでのサポート、受付時間：営業日9-18時、 月額5万円
月4チケットまで
電話/メールサポート 電話のみ、メールのみでのお問合せに対するサポート 1回1～1.5万円
オンサイトサポート オンサイトでのお問合せに対するサポート 応相談
開発者/上級開発者/運用者トレーニング 3時間程度で机上、もしくはハンズオン形式でのトレーニング、実際にokuyamaを使ったトレーニング 1人2～4万円
により開発・運用時の疑問を解決して頂くことが可能なサービス
ビフォア/アフターDBコンサルティング データベース設計に関するコンサルティング 応相談
勉強会 NOSQL/okuyama入門の講義形式の勉強会 無償
キャッシュサーバ構築パック システムのレスポンス改善を目的としたキャッシュサーバを構築しご提供（※1）（※2） 150万円
画像サーバ構築パック 大量の画像データの保管先としての画像サーバを構築しご提供（※1）（※2） 300万円
検索エンジン構築パック サイト内検索の最適化、検索処理負荷の低減を目的とした検索エンジンを構築しご提供（※1）（※2） 200万円～
（※1）別途、各種サーバを利用する様にアプリケーションの改修を行う作業をご依頼頂くことも可能
（※2）1年間のサポート契約を別途必要とします
2012/1/18 17 Copyright (C) Kobe Digital Labo Inc. All Reserved.

18. サービス活用パターン：キャッシュサーバの構築
• 抱えておられる課題
仮にキャッシュ
キャッシュサーバ サーバを構築した
DBサーバの負荷が データの参照処理 を導入すれば効果 としても、その
増大し、システム がボトルネックで がありそうだが、 キャッシュサーバ
全体のレスポンス あることが明確で キャッシュサーバ を利用する様にア
が低下している ある を構築するスキル/ プリケーションの
時間がない 改修するスキル/時
間がない
• 解決までの流れ
ボトルネック
okuyama
キャッシュ となっている
勉強会等で キャッシュ
ボトル サーバの導入 キャッ アプリ 処理でキャッ ☆
okuyama okuyamaのメ サーバを構築
ネックを 効果が望める シュサー ケーショ シュサーバを
を知る リットを理解
洗い出す かを事前に把 バ構築
し利用できる
ンの改修 利用する様に 解
して頂きます 環境を準備し
握します
ます
改修を行いま 決
す ☆
効果を理解した上で採用する ボトルネックが参照処理であ インフラ設計やokuyamaの各 効果の高そうな部分から順に
ことが重要 れば導入効果が望める 種設定ノウハウをご提供 改修
• 費用
キャッシュサーバ構築パック
150万円 改修箇所毎に工数発生
お客様にてご対応頂ければ
無償
無償
1年間サポート 1箇所当たり、15万円～
5万円×12ヶ月
2012/1/18 18 Copyright (C) Kobe Digital Labo Inc. All Reserved.

19. キャッシュサーバ構築パック
どういった場合に効果が期待できるか？ キャッシュサーバが果たす役割
Webサイトのレスポンスが悪い
DB上の処理（SQL）は、ディスクの
特に検索・表示等、サーバ上の情報を検索・抽出する部分の
読み込みが多く発生
レスポンスが悪く、サーバの負荷が高まっているケース
また、冗長化が容易なWebサーバと比べ
DBサーバを冗長化させるのは困難
遅い・・・
メモリを活用したキャッシュサーバに
SQL結果を蓄積することにより、
ディスクの読み込みが行われるDBサーバと
比べ、高速に結果を返すことが可能
検索処理により 同時に
サーバ負荷が DBサーバの負荷が下がるため、
非常に高い状態 重要なデータ登録処理にDBサーバの
リソースを割り当てることが可能
サービス内容 サービスご提供までの流れ
キャッシュサーバ
負荷が高いサーバ（DBサーバ、Webサーバ） 構築
のフロント部分にキャッシュサーバを構築
（サーバ・ネットワーク等のインフラ環境は キャッシュサー ボトル キャッ アプリ
okuyama
別途必要） バライセンス提 ネックを シュサー ケーショ
を知る
供 洗い出す バ構築 ンの改修
サーバ構築作業
AP改修 キャッシュサー
（別費用） 改修箇所毎に
バ構築パック
キャッシュサーバ利用にはAPの改修が必要 お客様にてご 工数発生
150万円
無償 対応頂ければ
改修作業を請け負うことも可能
無償 1箇所当たり
1年間サポート
15万円～
5万円×12ヶ月
AP DB AP CACHE
DB
2012/1/18 19 Copyright (C) Kobe Digital Labo Inc. All Reserved.

20. 画像サーバ構築パック
どういった場合に効果が期待できるか？ 画像サーバが果たす役割
Webサイトの表現力向上のため、 ※Webサーバのディスク容量を抑える
→画像サーバを分離することにより、
画像の数が増え続け管理が大変になる Webサーバに大量のHDDは不要
Webサーバそれ 画像の転送にネッ ※バックアップの必要なし
→分散保管されているので、基本的には
ぞれで画像ファイ トワークリソース
大量の画像データ 可用性を確保できる
ルを保管し、各 を食い潰してしま
をバックアップす
サーバでディスク い、サイト全体の ＊ネットワークリソースの確保
る領域がない
容量を圧迫してし レスポンスに影響 →画像の転送を別にすることにより、
まう を与える 他にリソースを割り当てることが
できる
サービス内容 画像サーバを構築する上で重要な要素
画像サーバ
画像サーバを構築 画像ファイルは、そのサイズがシステム全体に対する影響の
（サーバ・ネットワーク等のインフラ環境は 構築 ポイントとなる。
別途必要） 仮に画像サーバを別サーバとした場合にも、同じネットワーク
画像サーバライ
帯域を使用する場合には、システム全体のレスポンス改善に
センス提供
繋がらないケースがあるため、ボトルネックがどこにあるのかを
事前に見極めることが重要
サーバ構築作業
AP AP
AP改修 AP
（別費用）
画像 画像
画像サーバ利用にはAPの改修が必要 画像
改修作業を請け負うことも可能 ネットワーク帯域 CPU負荷 HDD容量
サイト AP
AP Webサーバ
サイト
画像
画像
2012/1/18 20 Copyright (C) Kobe Digital Labo Inc. All Reserved.

21. 検索エンジン構築パック – どの様な検索ができるか
検索エンジンの機能 商品を見せる＝検索
売りたい商品を最
豊富な検索軸 初に 分析機能 【フリーワード検索】
・キーワード検索 ※豊富なソート順 ・検索ログの蓄積 単純なワード検索だと関
・売れている順 係ない商品もヒットする
・ジャンル検索 ・検索の傾向分析 ため、最適化は重要
・価格帯検索 ・評価が高い順
・カラー検索 ・口コミが多い順 【詳細検索】
・価格が安い順 商品属性を基点とした検
・サイズ検索
索で、できる限り豊富な
・カタログ検索 ・価格が高い順
方が検索しやすい
・新着順
※検索ヒットの妥 【カテゴリ検索】
当性 複数のカテゴリ階層
・ヒット率を点数 他軸で検索した際にカテ 【おすすめ商品】
化 ゴリ毎のヒット数を表示 おすすめしたい
＝買って欲しい
・売りたい順も可
【ランキング】 ＝売りたい商品を上位へ
売上実績連動、もしくは
検索ヒットの妥当性 売りたい商品をランキン
グ上位へ意図的配置
キーワード「コート」で検索すると・・・
セラミックコート 検索エンジンでは、検索ヒットの妥当性をポイント化して、
フライパン ヒット品質が高い検索結果を上位表示させることができる
調理器具 1pt
ウール生地 フライパン 更にあらかじめ設定しておいたポイントも
コート セラミックコート フライパン 考慮することができるため、
例えば、売りたい商品にポイントを付けておけば、
コート ダジュール土産 売りたい商品がより上位に表示される
オーバル 2pt
チーズケーキ 1pt
コート
ウール生地 コート
1pt この商品は売りたいので
ビジネス向け 1pt追加
ビジネス向け レザーコート
レザーコート
土産物
「コート」で検索すれば、 海外土産 一番のおすすめ商品を
アパレルのコートが表示されるべきだが、 コート ダジュール土産 チーズケーキ 上位に表示できる ビジネス向け
一般的なキーワード検索では、 1pt レザーコート
単純に文字列で検索してしまう
2012/1/18 21 Copyright (C) Kobe Digital Labo Inc. All Reserved.

22. 検索エンジン構築パック
検索エンジンの機能 検索エンジンを導入すると実現できること
売りたい商品を最
豊富な検索軸 初に 分析機能
・キーワード検索 ※豊富なソート順 ・検索ログの蓄積
売上拡大 システムスケール 自社オリジナル
・ジャンル検索 ・売れている順 ・検索の傾向分析
・価格帯検索 ・評価が高い順 • 検索結果上位 • 検索処理 • オンプレミスでの
・口コミが多い順 ＝閲覧率向上 ＝DBサーバ負荷大 導入が可能
・カラー検索
・価格が安い順 • キャンペーンペー →検索エンジン導 • 自社要件に合わせ
・サイズ検索 入により分散でき、
ジでの商品紹介 た検索軸・商品表
・カタログ検索 ・価格が高い順 サーバ負荷を下げ
で、いま売りたい 示が可能
・新着順 商品を一番目に付 ることが可能 ＝どんな商品/カテ
※検索ヒットの妥 く位置に表示させ • アクセス増加時の ゴリでも対応可能
当性 ることができる スケールアウトが • ASPと比較し、ラ
・ヒット率を点数 容易なシステム構 ンニングコスト低
化 成
・売りたい順も可
サービス内容 システムの仕組み
基幹システムのマスタデー
検索エンジン タから、TSVファイルにて、
検索エンジン側へデータ投
ライセ サーバライセンス 入（バッチ処理）
ンス 年間サポート
投入されたデータを元に、
検索
検索用インデックスを生成
（バッチ処理）
データフォーマット 検索リクエストに対しては、
定義 導入支 検索用インデックス 検索エンジン内に生成され
ソート順定義 援 た検索用インデックスから
データ取得を行う
AP改
検索機能部分のAP改
修（別 修
マスタデータ蓄積
途）
基幹システム
※標準構成ですが、環境に合わせてカスタマイズ可能です
2012/1/18 22 Copyright (C) Kobe Digital Labo Inc. All Reserved.

23. okuyamaの性能（単体性能検証結果）
2012/1/18 23 Copyright (C) Kobe Digital Labo Inc. All Reserved.

24. 性能評価時のシステム構成
以下のスペックのサーバと、ネットワークを使用してテスト構成を構築した。
使用マシンは高価なサーバではなく、安価なデスクトップPCを使用。
使用サーバスペック サーバ構成図
サーバ名 Dospara Prime Magnate HB 16ポート
CPU Intel Core i5 650 3.20GHz Hub
メモリ 4GB(DDR3)
HDD 7200rpm 500GB×2
(ソフトウェアRAID/RAID0)
クライアント クライアント クライアント
ネットワーク ギガビットLANポート
OS CentOS5.5(64bit) クライアント クライアント クライアント
Java Java(TM) SE Runtime
Environment
(build 1.6.0_19-b04)
Master Master Master
Node Node Node
使用ネットワークスペック
Data Data
スイッチ BUFFALO Node Node
10/100/1000BASE-T 16ポート
HUB × 1
ケーブル カテゴリー6
Data Data Data Data
Node Node Node Node

25. テスト内容
テストは以下の登録処理、取得処理の2種類を実施する。
その際のテスト内容と前提条件は以下となる。
■データ登録処理
>事前登録件数：0
>永続化モード：永続化
>実行時間：5分
>負荷生成クライアント数：900クライアント
>登録データ：Key=100～105byte、Value=100～105byte
>登録方式：1クライアント単位で5万種類のデータのなかからランダムにデータを決定し、登録
>処理単位：クライアントは登録処理正しく終了したことを確認して1処理とする
■データ取得処理
>事前登録数：750万件
>永続化モード：永続化
>実行時間：５分
>負荷生成クライアント数：900クライアント
>取得データ：Key=100～105byte、Value=100～105byte
>取得方式：1クライアント単位で750万種類のデータのなかからランダムにデータを決定し、取得する
(存在しないKeyを指定することはない)
>処理単位：クライアントは取得したデータの妥当性検証まで行って1処理とする

26. テーストパターン
テスト時は以下のようにサーバ構成を変更させながら計測
MasterNode × 1 , DataNode × 1
MasterNode × 3 , DataNode × 6

27. テスト結果
1秒間での処理実行件数は以下のようになった。
ノード数
1台 2台 3台 4台 5台 6台
処理
データ登録処理 48,503 68,796 84,368 100,444 110,428 124,739
データ取得処理 88,613 108,372 121,703 171,427 177,053 187,753
データノード数を増やすことにより、登録性能、取得性能ともに向上させることができる。
マスターノードの台数を増やした3台=>4台時点でデータ取得性能が大幅に向上して
いることから、マスターノードも同様に増やことで性能向上が見込める。
また、上記性能でありながらデータの永続化(ファイル書き出し)を実現していることが特徴である。
同様のカテゴリーに属する2つの代表的なソフトウェアの結果は以下となっている。
※情報元：さくらインターネット研究所
(http://research.sakura.ad.jp/2010/06/14/flare-measure1/)
1.memcached 2.Flare
概要：完全オンメモリベース 概要：GREE社にて開発、使用
多くのWebサービスにて使用 データ永続化機能あり
データ永続化機能なし 性能：1台での性能
性能：1台での性能 データ登録処理> 31,933回
データ登録処理> 80,838回 データ取得処理> 73,681回
データ取得処理>111,420回

28. 登録処理性能グラフ
登録処理の性能グラフは以下のようになった

29. 取得処理性能グラフ
取得処理の性能グラフは以下のようになった
MasterNodeを追加し
たため、大幅に性能が
向上した

30. okuyamaの性能（Cassandraとの比較検証結果）
2012/1/18 30 Copyright (C) Kobe Digital Labo Inc. All Reserved.

31. データ登録速度検証
縦軸：1 秒間に登録した件数 C a ssa n d ra o ku ya m a
同時処理数
横軸：ベンチマークツールを同時に処理させた数 2 ノード 3 ノード 4 ノード 2 ノード 3 ノード 4 ノード
5 15434 13611 13422 9441 9102 9918
10 20674 19011 19826 17565 17524 20373
W ri
te性能 15 23438 21752 22312 29589 27059 29461
45000 20 24011 24105 24210 39912 33407 35784
40000
o ku yam a は並行処理数に比例して
35000
登録件数が伸びる
30000
C assan d ra は並行処理数が増えると
25000 登録件数が伸びなくなる
件数/ 秒
20000
15000
・Cassnadraは同時アクセス数が10以下であればokuyamaよりも書き込みが高速
・okuyamaは同時アクセス数が10以上になるとCassandraよりも高速
10000
・okuyamaの登録速度は並行処理数に比例して増加する
・Cassandraは並行処理数が増加すると登録速度が伸びなくなる
5000 ・大量のデータを並行して登録する場合ではokuyamaの方が登録速度が早い
0
5 10 15 20
並行処理数
Cassandra 4ノード Cassandra 3ノード Cassandra 2ノード
okuyama 2ノード okuyama 3ノード okuyama 4ノード
2012/1/18 31 Copyright (C) Kobe Digital Labo Inc. All Reserved.

32. データ読込速度検証
縦軸：1 秒間に登録した件数 C a ssa n d ra o ku ya m a
同時処理数
横軸：ベンチマークツールを同時に処理させた数 2 ノード 3 ノード 4 ノード 2 ノード 3 ノード 4 ノード
5 5041 5385 8705 7316 11723 13631
10 9338 11817 14377 15062 25422 27555
R ead性能 15 9987 14005 15387 24465 35300 38675
20 10796 12426 16861 36650 49574 49855
60000
50000
o ku yam a は並行処理数に比例して
登録件数が伸びる
40000
件数/ 秒 30000
C assan d ra は並行処理数が増えると
登録件数が伸びなくなる
20000
10000
0
5 10 15 20
並行処理数
Cassandra 4ノード Cassandra 3ノード
Cassandra 2ノード okuyama 2ノ ード ・okuyamaの読込速度は並行処理数に比例して増加する
okuyama 3ノ ード okuyama 4ノ ード
・Cassandraは並行処理数が増加すると読込速度が伸びなくなる
・okuyamaの読み込み速度はCassandraの読み込み速度より早い
2012/1/18 32 Copyright (C) Kobe Digital Labo Inc. All Reserved.

33. 大量データ登録検証
・Cassnadraは9100万件を超えたあたりから挙動が安定しなくな
縦軸：１０００件登録するのにかかった時間 り、最後は応答なしとなる
横軸：総登録件数 ・okuyamaは1000件でも１億件でも登録速度は大きく変化しない
180000
C assan d ra から反応がなくなる
160000
140000
120000
91,0
ms / 1000 Set
100000
91,0
91,0
80000 91,0
o ku yam a の登録速度が C assan d ra の速度が Cassandra
91,0
C assan d ra の登録速度を上回る 急激に低下し始める okuyama
60000 91,0
91,0
91,0
40000
C assan d ra の登録 91,0
速度が低下 91,0
20000
91,0
91,0
0 91,0
1,000
91,010,000
91,089,000
91,102,000
91,118,000
91,286,000
91,302,000
91,318,000
91,334,000
91,350,000
91,081,000
91,095,000
91,110,000
91,126,000
91,134,000
91,142,000
91,150,000
91,158,000
91,166,000
91,174,000
91,182,000
91,190,000
91,198,000
91,206,000
91,214,000
91,222,000
91,230,000
91,238,000
91,246,000
91,254,000
91,262,000
91,270,000
91,278,000
91,294,000
91,310,000
91,326,000
91,342,000
91,0
91,0
91,0
o ku yam a の登録速度は
総登録件数
変わらない
2012/1/18 33 Copyright (C) Kobe Digital Labo Inc. All Reserved.