分散キーバリューストア

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.1

KDL オリジナル開発分散キーバリューストア「 okuyama 」

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.2

分散キーバリューストア：特殊なデータベース

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.3

分散キーバリューストアリレーショナルデータベース

＜従来からのデータ管理手法＞※ メリット　データの関連性を管理することに向いている※ デメリット　大量のデータを高速に処理することには向かない　 1 台で管理するため障害耐久性が弱い

※ 導入例　基幹業務システム、情報系システム

※ 特性イメージ

＜新しい考えのデータベース＞※ メリット　大量のデータを高速に処理することに向いている　クラウドサービスでの活用が多い　システムの増強が容易※ デメリット　複雑なデータ管理には向かない

※ 導入例　 Google 、 Facebook 、 Twitter 、 mixi　楽天、 Yahoo! 、 Amazon　ウォールマート

※ 特性イメージ

データ連携 データ保全 権限管理

大量データ

高速処理

（ Facebook ）

（ Google ）

データの関連性を管理 機密性

※ 複雑な管理ができるため　データベースソフトウェアが複雑

※ 単純だから速い

分散キーバリューストアの特徴

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.4

A ：「 Availability 」

C ：「 Consistency

」

P ：「 Partition Tolerance 」

一貫性 （ Consistency ）1 つのデータへの操作は成功、失敗のどちらかしか発生しない

可用性 （ Availability ）システムへの障害発生の可能性が極めて低い、もしくは障害時も稼働し続けることができる

分割耐性（ Partition Tolerance ）ネットワーク障害が発生した場合もシステムは停止せず稼働し続けるまた、極端なスループットの低下も起こらない

【 RDBMS】 【分散キーバリューストア】

RDBMS は一貫性を強く意識している 。また、一貫性を優先するために、単一のサーバー資源上でデータを管理する設計になっている場合が多い 。

可用性や分割耐性のように、ネットワークを介して複数のサーバー資源を活用する使い方に対する意識が高い 。

A

CP

A

CP

A

CP

使いやすい分散キーバリューストア「 okuyama 」

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.5

Storage Type 永続化・非永続化の選択、一貫性レベルの選択保存先の選択 (Memory, Disk, Disk + Memory)

Support Protocol Original, memcached, HTTP

冗長性 複数台のサーバで構成されており、サーバ追加も無停止で可能 ( アルゴリズム分散 )

可用性 全てのデータは多重化されて保存され、全ての構成要素が多重化可能となっているsingle point of failure が存在しない

無停止データリカバリ 障害復旧時のデータの差異を修復するデータのリカバリは全て無停止で自動的に行われる

無停止データ再配置 サーバ追加後のデータ再配置は全て無停止で自動的に行われる

データ一貫性の強度の選択 取得するデータの一貫性を弱・中・強の中から選択可能

3 　層　構　造

client

client

client

MasterNode

MasterNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

DataNode

client

AP からokuyama を操作

する IF

MasterNode

分散処理制御する管理ノード

DataNode

データ保管される管理ノード

ストレージ特性の自由度

• メモリに保存するか、ディスクに保存するかを選択することができる• 利用シーンに合わせて設定を選択できる• メモリ：高速だが、データが永続保存されない• ディスク：データが永続保存されるが、メモリに比べて速度が劣化する

Tag 付加機能

• Key 以外にタグを追加することができるので、複数件のデータにアクセスできる• タグは理論上、無制限に付加できるので、利用シーンに合わせて自由にタグを付加することができる

JavaScript 実行機能

• DataNode 上で処理できるプログラムを配置でき、最もサーバ台数が確保されるノードで実行することにより、高速な処理が可能

パーティション機能

• 1 つのクラスタに用途毎に合わせた領域を確保することができる• パーティション毎に設定を変えることができる

Value への全文検索機能

• Key だけでしか検索できない分散キーバリューストアだが、 Value項目に対して全文検索を行うことができる

• 全文検索用のインデックス情報をグルーピングすることができるので、検索したいデータ群を絞り込んだ上で全文検索が可能

Hadoop 連携

• 分散処理基盤としてメジャーな Hadoop に対応• パーティションやタグを指定して Hadoop側で処理できるので、 okuyama 上のある一群のデータを対象に高速な分析処理ができる

どういった場面で分散キーバリューストアを使うべきか

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.6

分散キーバリューストアを理解することが重要 適材適所

分散キーバリューストアの特徴（ RDBMSとの違い）を理

解する

全てを解決する魔法の技術では

ない

情報量が日々増え続

ける

ネットワーク品質が向上してきた

RDBMS を全て置き換えるのではなく、必要な箇所に最適な構成で導入する

ことが重要

分散キーバリューストアが発展してきた時代背景

●商品 /顧客等のマスタ情報管理→単純な情報の管理

●ログデータ管理→増え続けるデータの管理

●セッション管理→同時処理性能が必要とされるデータの管理

●分析→複数データを跨った計算処理は AP側での計算処理が必要

●ロック処理→単一更新ではない制御が必要な場合、ロック制御ができないため

たとえばEC サイトで導入するとしたら・・・

キーバリューストアの比較

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.7

特性 memcached Cassandra okuyama

参照高速性 ◎メモリのみので稼働するため高速

△メモリを利用しないため読み取り性能は低速

○メモリとディスク両方を利用出来利用シーンに合わせて調整が可能

堅牢性 ×1 台での構築が前提であり冗長化出来ない

○冗長化は可能であるが高負荷時に不安定になる場合が多い

◎冗長化が可能であり、既に高負荷や長時間での無停止運用実績がある

無停止拡張 ×拡張する機能なし

◎無停止での拡張をサポート

◎無停止での拡張をサポート

国内実績 ○既に多くの Web システムでの利用実績あり

○国内でもソーシャル系を中心に利用され出しているEC サイトでの利用は未確認

○50億円以上の売上げ規模EC サイトでの利用実績ありインフラ事業社のプラットフォームでの利用実績もあり

国内サポート ×サポート企業なし

△国内で個人が技術サポートをされている程度

◎国内企業でのサポート体制あり

導入事例から見る分散キーバリューストアの活用方法

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.8

大手アパレル企業様　ネットショップサイト： EC での活用方法

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.9

ネットショップサイト

※ 以前のシステム

商品情報

在庫情報

購買履歴情報

ネットショップサイト

※ 導入後のシステム

商品情報

在庫情報

購買履歴情報

クライアント様が抱えていた課題•急成長を続ける EC事業に対してシステム改善スピードを上げることが急務

•閑散期と繁忙期でシステム負荷が大きく異なり最適な IT投資が必要

KDL の提案•NOSQL+RDBMS によるハイブリッドシステムによりシステム全体の負荷を分散

•既存カートシステムからアクセスする IF を準備し、変更リスクを抑制

商品情報を okuyama で管理する狙い・効果

キャンペーンページ

ブランドトップページ

商品詳細ページ

購買履歴ページ

EC サイト上で数多く登場する商品情報に着目・マスタという単純なデータ構造：キーバリューストアに向いている・アクセス頻度が高い：分散処理のメリットが活かせる

事業の中心となるデータであり、数多くのシステムが利用するこれまでは各システム間を夜間バッチ等でコピーしていた→企業内での統一基盤を構築し、各システムから直接参照

システムA

システムB

システムC

システムA

システムB

システムC

どれが最新？バッチが終わらないひとつ止まると全てに影響

項目が異なる

容量の無駄

・ RDBMS では耐えれない処理能力を実現・情報の一元管理

日本ユニシス株式会社様　通販ソリューション：商品検索エンジンでの活用方法

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.10

全文検索

日本語対応の全文検索エンジン

商品属性に対する全文検索が可能

KVS の一般的機能okuyama標準機能検索エンジン AP多種な検索方法

タグ管理

複数のデータを纏めて取得

理論上、無制限に設定可能

検索結果

検索結果をそのままの形式で保存

高速に処理できるため、非正規化

Web-IF

事業展開に合わせた商品検索

EC/コールセンター / カタログ

インデキシング

高速なレスポンスのためのインデキシング

24 時間稼働しているため処理時間短縮が必須

検索種別

キーワードから探す

ジャンルから探す

サイズから探す

カタログから探す

カラーから探す

価格帯から探す

ソート順

売れている順

評価が高い順

口コミが多い順

価格が安い順

価格が高い順

新着順

分散高速処理

大量のリクエストを同時処理できる

分散処理基盤によるスケールアップが容易

◆Web サイトに於いて検索機能が一番使われる

サイト全体の中で閲覧される割合（某大手 EC サイトの場合）

・検索機能： 15.97%！！・セールページ： 13.92％・トップページ： 2.26%

商品詳細

カテゴリトップ

商品一覧

キャンペーン

◆EC ではほとんどのページで商品を検索している売りたい商品を積極的に露出

お客様は商品を探している

接客で商品訴求は基本

株式会社リンク　アプリプラットフォーム：ソーシャルアプリ向け基盤での活用方法

• at+linkアプリプラットフォーム– ソーシャルアプリ向け専用サーバパッケージ– クラウドと専用サーバの両メリットを活かした

サービス– サービスの特徴として、okuyamaを利用した

サービスを提供• キャッシュサーバサービス• 画像サーバサービス

• 高速な処理基盤が必要なソーシャルアプリに必要な機能をokuyamaで実現– 大量アクセスに対する参照性能の向上– アイテム・アバター等の大量画像を保存する環境

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.11

キャッシュサーバ

• 一般的に利用されているmemcached の互換プロトコルを活用し、導入ハードルを下げることができた

• パーティション機能を使用し、同じクラスタを別ユーザに割り当てることにより、インフラ投資コストを抑えることができた

画像サーバ

• スケールアップがし易い分散技術の特徴を活用し、データ量が増え続けやすい画像を効率的に保存できる環境を構築することが出来た

クライアント様が抱えていた課題•価格競争に陥りやすい業種で特徴付けが急務だった

KDL の提案•分散キーバリューストアによる差別化だけでなく、クライアント企業へ同行訪問し、サービス企画やクライアント企業の信頼獲得に貢献

◆関連掲載記事【 @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

某化粧品会社様　キャッシュサーバ： memcached からの置き換え

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.12

DB サーバ

memcached

Web サーバmemcached は分散できないので 1

台で構成される↓

仮にダウンすると、 memcached（メモリ上）で処理していたものが全て DB サーバに集中し、システム全体がダウンしてしまうリスクがあ

る

DB サーバ

okuyama

Web サーバokuyama を使って分散構成とする

ことができる↓

システムダウンのリスク回避だけでなく、リクエスト数増加に対するス

ケールアップにも対応可能

okuyamaを使うメリット

Memcached互換プロトコルを標準で準備しているので、 Web アプリケーションの改修をすることなく導入することができる

冗長構成によるシステムの信頼性確保を取ることができず、システム全体に於けるボトルネック（負荷・信頼性の面）となってしまうことが回避できる

複数台を論理的に 1 台に構成させることができるため、大量のメモリを搭載した高価なマシンを準備する必要がない（ memcached の場合、搭載できるメモリ量が上限となってしまう）

パーティション機能を利用して、 1 つのクラスタ基盤を複数のシステムで共用することができ、いくつかのシステムを運用する企業にとっては全体的なコストメリットがある

よくあるご質問

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.13

よくあるご質問

• Q：何件程度のデータの場合に分散キーバリューストアを導入すべきか？

– A：単純な件数やアクセス数ではなく、システムのスケールアップがどの程度必要か（成長性）を考慮すると、特性を活かすことができます。

• Q：画像を保存することはできるか？

– A：可能です。画像データを細切れでokuyamaに保存させることにより、管理できます。

• Q：RDBMS上で複数のテーブルで管理しているデータを分散キーバリューストアで管理するには、どうすればいいか？

– A：そのデータが利用される形式に合わせてJSON形式で保存することが効果的です。

• Q：検索結果をソートすることはできますか？

– A：基本的にソートはできないので、AP側で処理する必要があります。

• Q：okuyamaが利用されている事例の規模感は？

– A：リクエスト数：秒間数万リクエスト– A：レコード数：100億レコード– A：データ容量：数TB

• Q：okuyamaクライアントとmemcachedクライアントとの違いは？

– A：memcachedクライアントの場合、okuyamaの特殊機能が使えなくなります。

• Q：ECシステムのセッション情報を管理する様なことには向いてるか？

– A：使い捨てる様な情報の管理にも向いています。

• Q：メール送信の仕組みをokuyamaで実現するメリットはあるか？

– A：okuyamaにはキューイングの機能があるので、大量のメール送信をする様な場合には向いています。

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.14

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

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.15

サポートサービス

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.16

サポートの種類

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.17

サポートサービス

構築は自ら対応する場合

サポート基本パック 電話 / メール / オンサイトサポート

構築の一部サポートを希望する場合

開発者 / 上級開発者 /運用者トレーニ

ング

ビフォア / アフターDBコンサルティン

グ

構築全般の依頼を希望する場合

勉強会キャッシュサー

バ /画像サーバ /検索エンジン構築パック

サポート基本パック 構築時・運用中のトラブルやお問合せに対する電話・メールでのサポート、受付時間：営業日 9-18 時、月 4チケットまで

月額 5万円

電話 / メールサポート 電話のみ、メールのみでのお問合せに対するサポート 1回 1～ 1.5万円

オンサイトサポート オンサイトでのお問合せに対するサポート 応相談

開発者 / 上級開発者 /運用者トレーニング

3 時間程度で机上、もしくはハンズオン形式でのトレーニング、実際に okuyama を使ったトレーニングにより開発・運用時の疑問を解決して頂くことが可能なサービス

1人 2～ 4万円

ビフォア / アフター DBコンサルティング

データベース設計に関するコンサルティング 応相談

勉強会 NOSQL/okuyama 入門の講義形式の勉強会 無償

キャッシュサーバ構築パック システムのレスポンス改善を目的としたキャッシュサーバを構築しご提供（※ 1 ）（※ 2 ） 150万円

画像サーバ構築パック 大量の画像データの保管先としての画像サーバを構築しご提供（※ 1 ）（※ 2 ） 300万円

検索エンジン構築パック サイト内検索の最適化、検索処理負荷の低減を目的とした検索エンジンを構築しご提供（※ 1 ）（※2 ）

200万円～（※ 1 ）別途、各種サーバを利用する様にアプリケーションの改修を行う作業をご依頼頂くことも可能（※ 2 ） 1年間のサポート契約を別途必要とします

サービス活用パターン：キャッシュサーバの構築

• 抱えておられる課題

• 解決までの流れ

• 費用

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.18

DB サーバの負荷が増大し、システム全体のレスポンスが低下して

いる

データの参照処理がボトルネックであること

が明確である

キャッシュサーバを導入すれば効果がありそうだが、キャッシュ

サーバを構築するスキル / 時間がない

仮にキャッシュサーバを構築したとしても、そのキャッシュサーバを利用する様にアプリケーションの改修する

スキル / 時間がない

勉強会等でokuyama のメ

リットを理解して頂きます

okuyamaを知る

キャッシュサーバの導入効果が望めるかを事前に把握

します

ボトルネックを洗い出

す

okuyama キャッシュサーバを構築し利用できる環境

を準備します

キャッシュサーバ構築

ボトルネックとなっている処理でキャッシュサーバを利用する様に改

修を行います

アプリケーションの改

修

☆解決☆

効果を理解した上で採用することが重要

ボトルネックが参照処理であれば導入効果が望める

インフラ設計や okuyama の各種設定ノウハウをご提供

効果の高そうな部分から順に改修

無償 お客様にてご対応頂ければ無償

キャッシュサーバ構築パック150万円

1年間サポート5万円×12ヶ月

改修箇所毎に工数発生

1箇所当たり、 15万円～

キャッシュサーバ構築パック

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.19

どういった場合に効果が期待できるか？

Web サイトのレスポンスが悪い特に検索・表示等、サーバ上の情報を検索・抽出する部分のレスポンスが悪く、サーバの負荷が高まっているケース

遅い・・・

検索処理によりサーバ負荷が

非常に高い状態

サービスご提供までの流れサービス内容

キャッシュサーバが果たす役割

DB 上の処理（ SQL ）は、ディスクの読み込みが多く発生また、冗長化が容易な Web サーバと比べDB サーバを冗長化させるのは困難

メモリを活用したキャッシュサーバにSQL結果を蓄積することにより、ディスクの読み込みが行われる DB サーバと比べ、高速に結果を返すことが可能

同時にDB サーバの負荷が下がるため、重要なデータ登録処理に DB サーバのリソースを割り当てることが可能

負荷が高いサーバ（ DB サーバ、 Web サーバ）のフロント部分にキャッシュサーバを構築（サーバ・ネットワーク等のインフラ環境は　別途必要）

キャッシュサーバ利用には AP の改修が必要改修作業を請け負うことも可能

AP DB AP CACHE

DB

okuyamaを知る

ボトルネックを洗い出す

キャッシュサーバ構築

アプリケーションの改修

無償お客様にてご対応頂ければ

無償

キャッシュサーバ構築

パック150万円

1年間サポート5万円×12ヶ

月

改修箇所毎に工数発生

1箇所当たり15万円～

キャッシュサーバ構築

キャッシュサーバライセンス提

供

サーバ構築作業

AP改修（別費用）

画像サーバ構築パック

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.20

どういった場合に効果が期待できるか？

画像サーバを構築する上で重要な要素

画像サーバが果たす役割

※Web サーバのディスク容量を抑える　→画像サーバを分離することにより、　　 Web サーバに大量の HDD は不要

※ バックアップの必要なし　→分散保管されているので、基本的には　　可用性を確保できる

＊ネットワークリソースの確保　→画像の転送を別にすることにより、　　他にリソースを割り当てることが　　できる

Web サイトの表現力向上のため、画像の数が増え続け管理が大変になる

Web サーバそれぞれで画像ファイルを保管し、各サーバでディスク容量を圧迫

してしまう

大量の画像データをバックアップする領

域がない

画像の転送にネットワークリソースを食い潰してしまい、サイト全体のレスポンスに影響を与える

Web サーバ

画像

AP

画像

AP

CPU負荷 HDD 容量

画像

AP

ネットワーク帯域

画像ファイルは、そのサイズがシステム全体に対する影響のポイントとなる。仮に画像サーバを別サーバとした場合にも、同じネットワーク帯域を使用する場合には、システム全体のレスポンス改善に繋がらないケースがあるため、ボトルネックがどこにあるのかを事前に見極めることが重要

サービス内容

画像サーバを構築（サーバ・ネットワーク等のインフラ環境は　別途必要）

画像サーバ利用には AP の改修が必要改修作業を請け負うことも可能

サイト

AP画像

サイト AP

画像サーバ構築

画像サーバライセンス提供

サーバ構築作業

AP改修（別費用）

画像

検索エンジン構築パック　–　どの様な検索ができるか

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.21

検索エンジンの機能

・キーワード検索・ジャンル検索・価格帯検索・カラー検索・サイズ検索・カタログ検索

豊富な検索軸※豊富なソート順・売れている順・評価が高い順・口コミが多い順・価格が安い順・価格が高い順・新着順※検索ヒットの妥当性・ヒット率を点数化・売りたい順も可

売りたい商品を最初に・検索ログの蓄積・検索の傾向分析

分析機能

商品を見せる＝検索

【フリーワード検索】単純なワード検索だと関係ない商品もヒットする

ため、最適化は重要

【詳細検索】商品属性を基点とした検索で、できる限り豊富な

方が検索しやすい

【カテゴリ検索】複数のカテゴリ階層

他軸で検索した際にカテゴリ毎のヒット数を表示

【おすすめ商品】おすすめしたい＝買って欲しい

＝売りたい商品を上位へ【ランキング】売上実績連動、もしくは売りたい商品をランキン

グ上位へ意図的配置検索ヒットの妥当性

キーワード「コート」で検索すると・・・

セラミックコートフライパン

ウール生地コート

コート ダジュール土産チーズケーキ

ビジネス向けレザーコート

「コート」で検索すれば、アパレルのコートが表示されるべきだが、一般的なキーワード検索では、単純に文字列で検索してしまう

検索エンジンでは、検索ヒットの妥当性をポイント化して、ヒット品質が高い検索結果を上位表示させることができる

調理器具　フライパン　　セラミックコート　フライパン

オーバル　コート　　ウール生地　コート　　ビジネス向け　レザーコート

土産物　海外土産　　コート ダジュール土産　チーズケーキ

1pt

1pt

1pt

1pt

2pt

更にあらかじめ設定しておいたポイントも考慮することができるため、例えば、売りたい商品にポイントを付けておけば、売りたい商品がより上位に表示される

この商品は売りたいので1pt 追加

一番のおすすめ商品を上位に表示できる ビジネス向け

レザーコート

検索エンジン構築パック

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.22

検索エンジンの機能 検索エンジンを導入すると実現できること

サービス内容 システムの仕組み

・キーワード検索・ジャンル検索・価格帯検索・カラー検索・サイズ検索・カタログ検索

豊富な検索軸※豊富なソート順・売れている順・評価が高い順・口コミが多い順・価格が安い順・価格が高い順・新着順※検索ヒットの妥当性・ヒット率を点数化・売りたい順も可

売りたい商品を最初に・検索ログの蓄積・検索の傾向分析

分析機能 売上拡大

•検索結果上位＝閲覧率向上

•キャンペーンページでの商品紹介で、いま売りたい商品を一番目に付く位置に表示させることができる

システムスケール

•検索処理＝ DB サーバ負荷大→検索エンジン導入により分散でき、サーバ負荷を下げることが可能

•アクセス増加時のスケールアウトが容易なシステム構成

自社オリジナル

•オンプレミスでの導入が可能

•自社要件に合わせた検索軸・商品表示が可能＝どんな商品 / カテゴリでも対応可能

•ASP と比較し、ランニングコスト低

ライセンス

サーバライセンス年間サポート

導入支援データフォーマット

定義ソート順定義

AP改修（別途）

検索機能部分の AP改修

検索エンジン

基幹システム※標準構成ですが、環境に合わせてカスタマイズ可能です

マスタデータ蓄積

検索

検索用インデックス

基幹システムのマスタデータから、 TSV ファイルにて、検索エンジン側へデー

タ投入（バッチ処理）

投入されたデータを元に、検索用インデックスを生成

（バッチ処理）

検索リクエストに対しては、検索エンジン内に生成された検索用インデックスから

データ取得を行う

okuyama の性能（単体性能検証結果）

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.23

使用サーバスペック

サーバ名

CPU

メモリ

HDD

ネットワーク

OS

Java

Dospara Prime Magnate HBIntel Core i5 650 3.20GHz

4GB(DDR3)

7200rpm 500GB×2( ソフトウェア RAID/RAID0)

ギガビット LANポート

CentOS5.5(64bit)

Java(TM) SE Runtime Environment (build 1.6.0_19-b04)

使用ネットワークスペック

スイッチ

ケーブル

BUFFALO10/100/1000BASE-T 16ポート HUB × 1

カテゴリー 6DataNode

DataNode

DataNode

DataNode

MasterNode

MasterNode

MasterNode

DataNode

DataNode

クライアント

クライアント クライアント

クライアント

クライアント

クライアント

16ポート

Hub

サーバ構成図

以下のスペックのサーバと、ネットワークを使用してテスト構成を構築した。使用マシンは高価なサーバではなく、安価なデスクトップ PC を使用。

性能評価時のシステム構成

テスト内容

■データ登録処理　 >事前登録件数： 0　 > 永続化モード：永続化　 > 実行時間： 5 分　 >負荷生成クライアント数： 900 クライアント　 >登録データ： Key=100～ 105byte 、 Value=100～ 105byte　 >登録方式： 1 クライアント単位で 5万種類のデータのなかからランダムにデータを決定し、登録　 > 処理単位：クライアントは登録処理正しく終了したことを確認して 1 処理とする

■データ取得処理　 >事前登録数： 750万件　 > 永続化モード：永続化　 > 実行時間：５分　 >負荷生成クライアント数： 900 クライアント　 > 取得データ： Key=100～ 105byte 、 Value=100～ 105byte　 > 取得方式： 1 クライアント単位で 750万種類のデータのなかからランダムにデータを決定し、取得する ( 存在しない Key を指定することはない ) 　　 > 処理単位：クライアントは取得したデータの妥当性検証まで行って 1 処理とする

テストは以下の登録処理、取得処理の 2種類を実施する。その際のテスト内容と前提条件は以下となる。

テスト時は以下のようにサーバ構成を変更させながら計測

MasterNode 　 × 1 　 , 　 DataNode 　× 1

MasterNode 　 × 3 　 , 　 DataNode 　 × 6

テーストパターン

1秒間での処理実行件数は以下のようになった。

同様のカテゴリーに属する 2 つの代表的なソフトウェアの結果は以下となっている。※ 情報元：さくらインターネット研究所　 (http://research.sakura.ad.jp/2010/06/14/flare-measure1/)

1.memcached 概要：完全オンメモリベース 多くの Web サービスにて使用 データ永続化機能なし 性能： 1 台での性能 データ登録処理 > 80,838回 データ取得処理 >111,420回

2.Flare 概要： GREE社にて開発、使用 データ永続化機能あり 性能： 1 台での性能 データ登録処理 > 31,933回 データ取得処理 > 73,681回

データ登録処理

ノード数処理

データ取得処理

1 台 2 台 3 台 4 台 5 台 6 台

48,503

88,613

68,796

108,372 121,703

84,368

171,427

100,444

177,053

110,428

187,753

124,739

データノード数を増やすことにより、登録性能、取得性能ともに向上させることができる。マスターノードの台数を増やした 3 台 =>4 台時点でデータ取得性能が大幅に向上していることから、マスターノードも同様に増やことで性能向上が見込める。また、上記性能でありながらデータの永続化 ( ファイル書き出し ) を実現していることが特徴である。

テスト結果

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

登録処理性能グラフ

取得処理の性能グラフは以下のようになった

取得処理性能グラフ

MasterNode を追加したため、大幅に性

能が向上した

okuyama の性能（ Cassandra との比較検証結果）

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.30

1縦軸： 秒間に登録した件数

横軸：ベンチマークツールを同時に処理させた数

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

5 10 15 20

件数/秒

並行処理数

Write性能

Cassandra 4ノード Cassandra 3ノード Cassandra 2ノード

okuyama 2ノード okuyama 3ノード okuyama 4ノード

okuyamaは並行処理数に比例して

登録件数が伸びる

Cassandraは並行処理数が増えると

登録件数が伸びなくなる

データ登録速度検証

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.31

Cassandra okuyama

2ノード 3ノード 4ノード 2ノード 3ノード 4ノード

5 15434 13611 13422 9441 9102 9918

10 20674 19011 19826 17565 17524 20373

15 23438 21752 22312 29589 27059 29461

20 24011 24105 24210 39912 33407 35784

同時処理数

・ Cassnadra は同時アクセス数が 10 以下であれば okuyama よりも書き込みが高速・ okuyama は同時アクセス数が 10 以上になると Cassandra よりも高速・ okuyama の登録速度は並行処理数に比例して増加する・ Cassandra は並行処理数が増加すると登録速度が伸びなくなる・大量のデータを並行して登録する場合では okuyama の方が登録速度が早い

1縦軸： 秒間に登録した件数

横軸：ベンチマークツールを同時に処理させた数

0

10000

20000

30000

40000

50000

60000

5 10 15 20

件数/秒

並行処理数

Read性能

Cassandra 4ノード Cassandra 3ノードCassandra 2ノード okuyama 2ノードokuyama 3ノード okuyama 4ノード

okuyamaは並行処理数に比例して

登録件数が伸びる

Cassandraは並行処理数が増えると

登録件数が伸びなくなる

データ読込速度検証

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.32

Cassandra okuyama

2ノード 3ノード 4ノード 2ノード 3ノード 4ノード

5 5041 5385 8705 7316 11723 13631

10 9338 11817 14377 15062 25422 27555

15 9987 14005 15387 24465 35300 38675

20 10796 12426 16861 36650 49574 49855

同時処理数

・ okuyama の読込速度は並行処理数に比例して増加する・ Cassandra は並行処理数が増加すると読込速度が伸びなくなる・ okuyama の読み込み速度は Cassandra の読み込み速度より早い

大量データ登録検証

04/12/2023 Copyright (C) Kobe Digital Labo Inc. All Reserved.33

縦軸：１０００件登録するのにかかった時間

横軸：総登録件数

91,010,000

91,020,000

91,030,000

91,040,000

91,050,000

91,060,000

91,070,000

91,080,000

91,081,000

91,082,000

91,083,000

91,084,000

91,085,000

91,086,000

91,087,000

91,088,000

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

1,00

091

,010

,000

91,0

81,0

0091

,089

,000

91,0

95,0

0091

,102

,000

91,1

10,0

0091

,118

,000

91,1

26,0

0091

,134

,000

91,1

42,0

0091

,150

,000

91,1

58,0

0091

,166

,000

91,1

74,0

0091

,182

,000

91,1

90,0

0091

,198

,000

91,2

06,0

0091

,214

,000

91,2

22,0

0091

,230

,000

91,2

38,0

0091

,246

,000

91,2

54,0

0091

,262

,000

91,2

70,0

0091

,278

,000

91,2

86,0

0091

,294

,000

91,3

02,0

0091

,310

,000

91,3

18,0

0091

,326

,000

91,3

34,0

0091

,342

,000

91,3

50,0

00

ms

/ 10

00 S

et

総登録件数

Cassandra

okuyama

Cassandraの登録

速度が低下

okuyamaの登録速度が

Cassandraの登録速度を上回る

okuyamaの登録速度は

変わらない

Cassandraから反応がなくなる

Cassandraの速度が

急激に低下し始める

・ Cassnadra は 9100万件を超えたあたりから挙動が安定しなくなり、最後は応答なしとなる・ okuyama は 1000 件でも１億件でも登録速度は大きく変化しない