info talk #36

ホスティング事業者から見たソーシャルゲーム

InfoTalk 第36回 2011.11.18（金）

株式会社リンク

at+link事業部ディベロッパーサポート部

文屋宏

自己紹介

○氏名

文屋宏（ぶんやひろし）

○所属

株式会社リンク at+link事業部ディベロッパーサポート部

○業務

プロジェクトマネジメント，広報活動，営業活動，ユーザサポート，

他社との協業，たまに現地作業，面白いネタ探し

○活動

日本 Red5 ユーザー会，tokyoLinuxStudy 主催

○Twitter アカウント

@bun_hiroshi

会社紹介（at+link とは）

at+link の営業窓口

ディベロッパーサポート

◇開発者のためのサービス開発

◇開発者の悩み相談

◇新しい技術・面白い技術の

研究・サービス化

データセンター常駐

現場担当マシン製造

24/365 サポート

講演内容

・ソーシャルゲームならではの特徴

・at+link アプリプラットフォームの概要

・ioDrive とは

・分散型KVS 「okuyama」

・okuyama キャッシュサービス

・okuyama 画像ストレージ

・今後の予定

ソーシャルゲームならではの特徴

～ホスティング事業者から見て～

ソーシャルゲームならではの特徴

・アクセス数が事前に読めない

・ヒットすると、とんでもないことになる

・ 5秒ルールなんてのがあるらしい・・・

・朝、昼、夜と３回ピークがある

・そのくせ、ド深夜（午前４時～５時）にも

アクセスがある

・少しの接続断も許されない・・・

・ゲームによって（作りによって）、

サーバへの負荷がまちまち

ソーシャルゲームのトラフィック

通勤・通学時

昼休み

夜間のピーク

LAN ケーブルの性能

これまではカテゴリー5e

カテゴリー6にした方がいい？

比較方法

カテゴリー5eおよび6の性能比較を行う。

比較対象は、ケーブル間の通信

MySQLのトランザクション性能(SysBench)

検証環境

カテゴリー5e・6でスイッチ間と結線された4台

サーバ①

L2 スイッチ

サーバ② サーバ③ サーバ④

Cat 6 Cat 5e

LANケーブルの性能評価

結局、主要箇所はカテゴリー6に

LAN ケーブルの性能まで気に

することになるとは・・・

こんなソーシャルゲームを

受け止めるために・・・



at+link アプリプラットフォーム

2010年11月17日提供開始！



at+link アプリプラットフォーム

2010年11月17日提供開始！

かなり後発・・・ (;´Д｀)

at+link アプリプラットフォームのコンセプト

・初期費用が無料・サーバの増減が簡単かつ迅速

・パフォーマンス、信頼性が高い・コストが明確

クラウドのメリット

専用サーバのメリット



・転送料課金・パフォーマンスがいまいち


・初期費用がかかる・納期が遅い



クラウドのデメリット

専用サーバのデメリット










クラウドと専用サーバの“いいとこ取り”をしよう！！！










クラウドと専用サーバの“いいとこ取り”をしよう！！！

後発だからこそ！後発で良かったかも？

at+link アプリプラットフォームの特徴

初期費用０円＆固定料金

ハイスペックサーバ＆冗長回線・LB/FW

基本契約は 5-DAY，サーバ追加は９０分以内

レスポンス監視（5秒ルールに対抗）

Munin によるリソース監視

ioDrive 搭載サーバ

KVS サービス

at+link アプリプラットフォームの構成

Web Web Web Web DB Web

共用ファイアウォール共用ロードバランサ（冗長構成）

インターネット

バックボーン 4Gbps

冗長構成ロードバランサ

ファイアウォール

冗長構成が標準

Xeon 4コアの

ハイスペックマシンアプリ公開後５日間

５台無償！！ ioDrive 搭載マシン

初期費用無償！


Web Web Web Web DB Web Web







追加は90分以内！

Xeon 4コアの





Cache Web Web Web Web DB Web Web








Xeon 4コアの




okuyama

キャッシュサーバ


Cache Web Web Web Web DB Web Image Web








Xeon 4コアの




okuyama


okuyama

画像ストレージ

at+link アプリプラットフォームの管理画面

サーバ追加申請

ioDrive とは








KVS サービス

ioDrive って何？

写真で見てみよう

ioDrive 写真①

ioDrive 本体

Fusion-io 社が提供する超高速半導体ストレージ

ioDrive 写真②

サーバ本体

この辺に装着する

ioDrive 写真③

サーバ本体別の角度から

この辺に装着する

ioDrive 写真④

サーバ本体拡大！

ここに装着！

ioDrive 写真⑤

装着完了！

ioDrive の特徴

・桁違いの速さで I/O のボトルネックを

解消できる

・ソーシャルゲームのデータベースとして

容量は十分

・同時アクセスにも強いので、マシンを

集約できる

・高い信頼性

・SSD に比べて寿命が長い

ioDrive の性能

ioDrive の性能①

ioDrive は同時接続に強い！

ioDrive の性能②

激しく latency 発生

loadaverage 8000 超

同時アクセス数をもっと増やしてみると・・・

ioDrive の性能③

SSD よりも速い！

ioDrive は、

・速い！

・大量の同時アクセスに強い！

⇒ DBサーバを集約できる！！

分散型 KVS 「okuyama」サービス

・・・の前に、分散型 KVS って何？

データベースソフトウェアの分類

RDBMS NoSQL

一貫性重視

スケールアップ

・Oracle

・MySQL

・PostgreSQL

etc.

パフォーマンス重視

スケールアウト

・カラム指向型

・ドキュメント指向型

・キー・バリュー型

etc.

KVS は NoSQL の一種

NoSQL = Not Only SQL

RDBMS と NoSQL は互いに補完し合う存在

どちらが優れている、ということはない

分散処理の必要性

スケールアップ

or

サービスが成長してきたとき、どうする？

スケールアウト

・ハードウェア的な限界がある

・ネットワーク集中

・コストパフォーマンスが悪い

・障害に弱い

・ハードウェア的な限界がない

・ネットワーク分散

・コストパフォーマンスが高い

・障害に強い（高可用性）

Web サーバだけでなく、DB サーバも分散させたい！

でも・・・

どんなシステムでも、必ず何かを

犠牲にしなきゃいけない・・・

CAP 定理による NoSQL の分類

Ａ

P C

RDBMS

Aster Data

Creenplum

リレーショナル型

Vertica

カラム指向

カラム指向

カラム指向

ドキュメント指向キー・バリュー型

キー・バリュー型

CA

CP

AP

BigTable

Hypertable

HBase

MongoDB

Terrastore

Scalaris

BerkeleyDB

MemcacheDB

Redis

Dynamo

Voldermote

Tokyo Cabinet

KAI ドキュメント指向

SimpleDB

CouchDB

Riack

Cassandra

[参考]

・Visual Guide to NoSQL Systems

http://blog.nahurst.com/visual-guide-to-nosql-systems

・NoSQL登場の背景、CAP定理、データモデルの分類

http://www.publickey1.jp/blog/10/nosqlcap.html

・WEB+DB PRESS Vol.58

Cassandra 実践入門

２つを選択

Availability

可用性

Consistency

一貫性

Partition Tolerance

分割耐性










http://www.publickey1.jp/blog/10/nosqlcap.html

KVS には得意・不得意が

分散多重保存が得意

Flare, kumofs

データ永続化が得意

Tokyo Tyrant, Flare, kumofs

データの一貫性を保つのが得意

memcached, Tokyo Tyrant

「何でも得意」な KVS は無い！

国産 KVS

○Tokyo Tyrant 平林幹雄氏（当時 mixi）

○kumofs 古橋貞之氏（筑波大）

○Flare 藤本真樹氏（GREE）

○ROMA 西澤無我氏（楽天）

○okuyama 岩瀬高博氏（神戸デジタル・ラボ）

分散型

国内だけでも、こんなにたくさんの開発者が

素晴らしい！！

国産 KVS

○Tokyo Tyrant 平林幹雄氏（当時 mixi）

○kumofs 古橋貞之氏（筑波大）

○Flare 藤本真樹氏（GREE）

○ROMA 西澤無我氏（楽天）

○okuyama 岩瀬高博氏（神戸デジタル・ラボ）

分散型

国内だけでも、こんなにたくさんの開発者が

at+link＆神戸デジタル・ラボでサービス化！

分散型 KVS 「okuyama」

okuyama の特徴

分散多重保存できるか

⇒ 得意！！

データを永続化できるか

⇒ 4段階レベルを選択可能！！

データの一貫性を保てるか

⇒ 3段階レベルを選択可能！！

okuyama って、CAP 定理だとどこ？

Ａ

P C

RDBMS

Aster Data

Creenplum


Vertica

カラム指向

カラム指向

カラム指向



CA

CP

AP

BigTable

Hypertable

HBase

MongoDB

Terrastore

Scalaris

BerkeleyDB

MemcacheDB

Redis

Dynamo

Voldermote

Tokyo Cabinet

KAI

ドキュメント指向

SimpleDB

CouchDB

Riack

Cassandra

２つを選択

Availability

可用性

Consistency

一貫性

Partition Tolerance

分割耐性


Ａ

P C

RDBMS

Aster Data

Creenplum


Vertica

カラム指向

カラム指向

カラム指向



CA

CP

AP

BigTable

Hypertable

HBase

MongoDB

Terrastore

Scalaris

BerkeleyDB

MemcacheDB

Redis

Dynamo

Voldermote

Tokyo Cabinet

KAI

okuyama


SimpleDB

CouchDB

Riack

Cassandra

２つを選択

Availability

可用性

Consistency

一貫性

Partition Tolerance

分割耐性


Ａ

P C

RDBMS

Aster Data

Creenplum


Vertica

カラム指向

カラム指向

カラム指向



CA

CP

AP

BigTable

Hypertable

HBase

MongoDB

Terrastore

Scalaris

BerkeleyDB

MemcacheDB

Redis

Dynamo

Voldermote

Tokyo Cabinet

KAI

okuyama


SimpleDB

CouchDB

Riack

Cassandra

２つを選択

Availability

可用性

Consistency

一貫性

Partition Tolerance

分割耐性

一貫性レベルの

選択で補強！！

okuyama では

一貫性のレベルを

３段階選択可能！

okuyama の構成イメージ

Client → Master Node → Data Node(×3)

Master Node

Data Node Data Node

Data Node Data Node

Client

Client

Master Node Client

Data Node

Data Node

Data Node Data Node Data Node


（以降 okuyama 関連資料

神戸デジタル・ラボ岩瀬高博氏提供）

okuyama クライアント

okuyamaへの問い合わせを実現

専用クライアントはJavaと、PHPを実装

Client

Client

Client

okuyama マスターノード

・クライアントからのI/F

・サポートプロトコル

>オリジナル

>Memcached

・set ・get ・add

・delete

・gets ・cas

>HTTP

・GET

・データノード管理

>データ入出力

サポート分散アルゴリズム

1. Mod

2. ConsistentHash

>生存監視

起動時のデータリカバリ

・制限台数なしに冗長化可能

Master Node

Master Node

okuyama データノード

・データの保存を実現

・データ保存方式を選択可能

・最大3ノードにデータを保存

・アクセスバランシング

・連鎖的ダウンの予防

Data Node Data Node

Data Node Data Node

Data Node

Data Node



データ保存方式の選択

1.全てのデータをメモリに保存

>非永続型（key=メモリ、value=メモリ）

２.データ操作履歴のみファイルに保存

>永続型（key=メモリ、value=メモリ）＋操作記録ファイル

3.データ本体をファイルに保存

>永続型（key=メモリ、value=ファイル）＋操作記録ファイル

4.全てをファイルに保存

>永続型（key=ファイル、value=ファイル）＋操作記録ファイル

データの一貫性について

複数のノードに同一の値を保持していると、

データに異なる時間が発生する

DataNode DataNode DataNode

データ保存保存保存未保存

データ取得データ取得 !=

データ一貫性レベルの選択

1.弱一貫性

>全てのデータノードにランダムにアクセス

２.中一貫性

>常に最後に保存したデータノードからアクセス

3.強一貫性

>データノードの値を検証

okuyama に単一障害点は無い！

マスターノード障害発生

別のマスターノードに

再接続して処理続行！

障害発生!!

MasterNode

DataNode MasterNode

データ取得

DataNode

DataNode

DataNode

Data Ndoe

Data Node

Data Node

Data Node

Client

okuyama に単一障害点は無い！

データノード障害発生

MasterNode

DataNode MasterNode データ取得

DataNode

もう一つのノードから取得

データ保持

ノード割り出し

DataNode

DataNode

Data Ndoe

Data Node

Data Node

Data Node

Client

okuyama の長所

・単一障害点がない！

・設定を変えるだけで、様々な用途に使える！

・マシン性能を限界まで引き出せる！

サービス化する際に重視した点

詳しくは、岩瀬氏の資料をご覧ください

○Think IT 連載記事

http://thinkit.co.jp/story/2011/02/03/1990

http://thinkit.co.jp/story/2011/10/12/2303

○講演資料

http://www.slideshare.net/okuyamaoo/20110517-okuyama-8035077

○ WEB+DB PRESS Vol.65 から連載

「okuyama」サービス








KVS サービス

KVS の必要性

参照性能を向上するためにキャッシュ機能が必要

⇒ memcached，Tokyo Tyrant

大量の画像を保存する環境が必要

⇒ CDN

大量のログを保存する環境が必要

⇒ 短期間で削除，大容量ディスク

「okuyama」キャッシュサービス

KVS の必要性




⇒ CDN












Xeon 4コアの




okuyama


okuyama


ここの話

okuyama キャッシュの構成イメージ

マスターノード

データノード

LVS

メイン

スタンバイ

VIP

マスターノード LVS

クライアント

アクセス

クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス

データノード

データノードデータノード



マスターノードはロードバランシング

高負荷時はスケールアウト

データノードで分散多重保存

容量不足・高負荷時はスケールアウト



データノード

LVS

メイン

スタンバイ

VIP

マスターノード LVS

クライアント

アクセス


データノード








障害！



データノード

LVS

障害対応

メイン

VIP マスターノード LVS

クライアント

アクセス


データノード








okuyama キャッシュのメリット

・ユーザでキャッシュサーバを用意する必要がない

・サーバ運用開始と同時に接続可能

・memcached プロトコルに対応

・「分散」を意識することすらない

・障害を意識しなくていい

・コントロールパネルから無停止で容量変更可能

・コントロールパネルで実使用量を可視化

・価格も手ごろ（初期無償、2GB で月額 18,000円）

・ KDL・LINK ２社のサポート体制

「okuyama」画像ストレージ

KVS の必要性




⇒ CDN












Xeon 4コアの




okuyama


okuyama


ここの話

okuyama 画像ストレージの構成


データノード

LB

メイン

スタンバイ

ドメイン指定

LB

クライアント

アクセス

クライアントは、画像ストレージ用に指定したドメインへアクセス

データノード







okuyama 用

Web アプリ

okuyama 用

Web アプリ

okuyama 用

Web アプリ

okuyama 用

Web アプリ

ロードバランサ２重化

okuyama 用 Web アプリ、マスターノード複数でロードバランシング

データノード２重化・ロードバランシング

okuyama 画像ストレージ

デモ

画像データを保存してみる

okuyama 画像ストレージ性能評価①

ブラウザで体感！

okuyama v.s. Apache

okuyama 画像ストレージ性能評価②

okuyama 画像ストレージ性能評価③

okuyama キャッシュのメリット

・ユーザでイメージサーバを用意する必要がない

・サーバ運用開始と同時に接続可能

・ REST プロトコルに対応

・「分散」を意識することすらない

・障害を意識しなくていい

・コントロールパネルから無停止で容量変更可能

・コントロールパネルで実使用量を可視化

・価格も手ごろ（初期無償、100GB 当たり月額 15,000円）

・ KDL・LINK ２社のサポート体制

・アプリと画像データのネットワークを分けられる（トラフィック出し放題・・・）

管理画面で使用状況確認

KVS サービス使用状況①

KVS サービス使用状況②

KVS サービス使用状況③

キャッシュ使用容量画像ストレージ使用容量

今後の予定

アプリプラットフォーム＆ KVS サービス

2010 2012 2011

2010.11

アプリプラットフォーム

2011.03 2011.09 2011.11 2012. ?



ログストレージ

ログ解析

2011.12

HDD 保管サービス

2012. ?

革命的監視サービス！

まとめ

・ソーシャルゲームの運用は大変・・・

・DB サーバは ioDrive で I/O の

ボトルネックを解消

・okuyama いいね！

・うまくキャッシュを使おう

・画像データは、画像ストレージへ

・ログストレージ、ログ解析はこれから・・・

イベント告知

○オープンソースカンファレンス東京

https://www.ospn.jp/osc2011-fall/modules/eguide/event.php?eid=46

会場：明星大学

日程：11/19 （土） 15:15～

（11/19・11/20 ２日間ブースも出展！）

○ at+link サービスセミナー

http://atnd.org/events/22097

会場：IBM 新渋谷事業所

（東京都渋谷区道玄坂1-12-1 渋谷マークシティウエスト18F）

日程：12/9（金） 14:00～

ご清聴ありがとうございました！

info talk #36

Education