1. ホスティング事業者から見たソーシャルゲーム
InfoTalk 第36回 2011.11.18（金）
株式会社リンク
at+link事業部 ディベロッパーサポート部
文屋 宏

2. 自己紹介
○氏名
文屋 宏（ぶんや ひろし）
○所属
株式会社リンク at+link事業部 ディベロッパーサポート部
○業務
プロジェクトマネジメント，広報活動，営業活動，ユーザサポート，
他社との協業，たまに現地作業，面白いネタ探し
○活動
日本 Red5 ユーザー会，tokyoLinuxStudy 主催
○Twitter アカウント
@bun_hiroshi

3. 会社紹介（at+link とは）
ディベロッパーサポート
at+link の営業窓口 ◇開発者のためのサービス開発
◇開発者の悩み相談
◇新しい技術・面白い技術の
研究・サービス化
データセンター常駐 マシン製造
現場担当 24/365 サポート

4. 講演内容
・ソーシャルゲームならではの特徴
・at+link アプリプラットフォームの概要
・ioDrive とは
・分散型KVS 「okuyama」
・okuyama キャッシュサービス
・okuyama 画像ストレージ
・今後の予定

5. ソーシャルゲームならではの特徴
～ホスティング事業者から見て～

6. ソーシャルゲームならではの特徴
・アクセス数が事前に読めない
・ヒットすると、とんでもないことになる
・ 5秒ルールなんてのがあるらしい・・・
・朝、昼、夜と３回ピークがある
・そのくせ、ド深夜（午前４時～５時）にも
アクセスがある
・少しの接続断も許されない・・・
・ゲームによって（作りによって）、
サーバへの負荷がまちまち

7. ソーシャルゲームのトラフィック
夜間のピーク
昼休み
通勤・通学時

8. LAN ケーブルの性能
これまではカテゴリー5e
カテゴリー6にした方がいい？

9. 比較方法
 カテゴリー5eおよび6の性能比較を行う。
 比較対象は、ケーブル間の通信
 MySQLのトランザクション性能(SysBench)
 検証環境
 カテゴリー5e・6でスイッチ間と結線された4台
L2 スイッチ
Cat 6 Cat 5e
サーバ① サーバ② サーバ③ サーバ④

10. LANケーブルの性能評価

11. 結局、主要箇所はカテゴリー6に
LAN ケーブルの性能まで気に
することになるとは・・・

12. こんなソーシャルゲームを
受け止めるために・・・

13. こんなソーシャルゲームを
受け止めるために・・・
at+link アプリプラットフォーム
2010年11月17日提供開始！

14. こんなソーシャルゲームを
受け止めるために・・・
at+link アプリプラットフォーム
2010年11月17日提供開始！
かなり後発・・・ (;´Д｀)

15. at+link アプリプラットフォームのコンセプト
クラウドのメリット
・初期費用が無料
・サーバの増減が簡単かつ迅速
専用サーバのメリット
・パフォーマンス、信頼性が高い
・コストが明確

16. at+link アプリプラットフォームのコンセプト
クラウドのメリット クラウドのデメリット
・初期費用が無料 ・転送料課金
・サーバの増減が簡単かつ迅速 ・パフォーマンスがいまいち
専用サーバのメリット 専用サーバのデメリット
・パフォーマンス、信頼性が高い ・初期費用がかかる
・コストが明確 ・納期が遅い

17. at+link アプリプラットフォームのコンセプト
クラウドのメリット クラウドのデメリット
・初期費用が無料 ・転送料課金
・サーバの増減が簡単かつ迅速 ・パフォーマンスがいまいち
専用サーバのメリット 専用サーバのデメリット
・パフォーマンス、信頼性が高い ・初期費用がかかる
・コストが明確 ・納期が遅い
クラウドと専用サーバの“いいとこ取り”をしよう！！！

18. at+link アプリプラットフォームのコンセプト
クラウドのメリット クラウドのデメリット
・初期費用が無料 ・転送料課金
・サーバの増減が簡単かつ迅速 ・パフォーマンスがいまいち
専用サーバのメリット 専用サーバのデメリット
・パフォーマンス、信頼性が高い ・初期費用がかかる
・コストが明確 ・納期が遅い
クラウドと専用サーバの“いいとこ取り”をしよう！！！
後発だからこそ！後発で良かったかも？

19. at+link アプリプラットフォームの特徴
初期費用０円＆固定料金
ハイスペックサーバ＆冗長回線・LB/FW
基本契約は 5-DAY，サーバ追加は９０分以内
レスポンス監視（5秒ルールに対抗）
Munin によるリソース監視
ioDrive 搭載サーバ
KVS サービス

20. at+link アプリプラットフォームの構成
インターネット
ロードバランサ バックボーン 4Gbps
ファイアウォール 冗長構成
共用ファイアウォール
冗長構成が標準
共用ロードバランサ
（冗長構成）
Web Web Web Web Web DB
Xeon 4コアの アプリ公開後５日間
ioDrive 搭載マシン
ハイスペックマシン ５台無償！！
初期費用無償！

21. at+link アプリプラットフォームの構成
インターネット
ロードバランサ バックボーン 4Gbps
ファイアウォール 冗長構成
共用ファイアウォール
冗長構成が標準
共用ロードバランサ
（冗長構成）
追加は90分以内！
Web Web Web Web Web Web DB
Xeon 4コアの アプリ公開後５日間
ioDrive 搭載マシン
ハイスペックマシン ５台無償！！
初期費用無償！

22. at+link アプリプラットフォームの構成
インターネット
ロードバランサ バックボーン 4Gbps
ファイアウォール 冗長構成
共用ファイアウォール
冗長構成が標準
共用ロードバランサ
（冗長構成）
追加は90分以内！
Web Web Web Web Web Web DB Cache
Xeon 4コアの アプリ公開後５日間 okuyama
ioDrive 搭載マシン
ハイスペックマシン ５台無償！！ キャッシュサーバ
初期費用無償！

23. at+link アプリプラットフォームの構成
インターネット
ロードバランサ バックボーン 4Gbps
ファイアウォール 冗長構成
共用ファイアウォール
冗長構成が標準
共用ロードバランサ
（冗長構成） okuyama
追加は90分以内！ 画像ストレージ
Web Web Web Web Web Web DB Cache Image
Xeon 4コアの アプリ公開後５日間 okuyama
ioDrive 搭載マシン
ハイスペックマシン ５台無償！！ キャッシュサーバ
初期費用無償！

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

25. サーバ追加申請

26. サーバ追加申請

27. ioDrive とは

28. at+link アプリプラットフォームの特徴
初期費用０円＆固定料金
ハイスペックサーバ＆冗長回線・LB/FW
基本契約は 5-DAY，サーバ追加は９０分以内
レスポンス監視（5秒ルールに対抗）
Munin によるリソース監視
ioDrive 搭載サーバ
KVS サービス

29. ioDrive って何？
写真で見てみよう

30. ioDrive 写真①
Fusion-io 社が提供する超高速半導体ストレージ
ioDrive 本体

31. ioDrive 写真②
この辺に装着する
サーバ 本体

32. ioDrive 写真③
この辺に装着する
サーバ 本体 別の角度から

33. ioDrive 写真④
ここに装着！
サーバ 本体 拡大！

34. ioDrive 写真⑤
装着完了！

35. ioDrive の特徴
・桁違いの速さで I/O のボトルネックを
解消できる
・ソーシャルゲームのデータベースとして
容量は十分
・同時アクセスにも強いので、マシンを
集約できる
・高い信頼性
・SSD に比べて寿命が長い

36. ioDrive の性能

37. ioDrive の性能①
ioDrive は同時接続に強い！

38. ioDrive の性能②
loadaverage 8000 超
激しく latency 発生
同時アクセス数をもっと増やしてみると・・・

39. ioDrive の性能③
SSD よりも速い！

40. ioDrive は、
・速い！
・大量の同時アクセスに強い！
⇒ DBサーバを集約できる！！

41. 分散型 KVS 「okuyama」サービス

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

43. データベースソフトウェアの分類
RDBMS NoSQL
・Oracle ・カラム指向型
・MySQL ・ドキュメント指向型
・PostgreSQL ・キー・バリュー型
etc. etc.
一貫性重視 パフォーマンス重視
スケールアップ スケールアウト
KVS は NoSQL の一種
NoSQL = Not Only SQL
RDBMS と NoSQL は互いに補完し合う存在
どちらが優れている、ということはない

44. 分散処理 の必要性
サービスが成長してきたとき、どうする？
スケールアップ スケールアウト
or
・ハードウェア的な限界がある ・ハードウェア的な限界がない
・ネットワーク集中 ・ネットワーク分散
・コストパフォーマンスが悪い ・コストパフォーマンスが高い
・障害に弱い ・障害に強い（高可用性）
Web サーバだけでなく、DB サーバも分散させたい！

45. でも・・・
どんなシステムでも、必ず何かを
犠牲にしなきゃいけない・・・

46. CAP 定理による NoSQL の分類
Availability
可用性 Ａ
CA AP
リレーショナル型
キー・バリュー型 カラム指向
RDBMS
Dynamo Cassandra
Aster Data
Voldermote
Creenplum
Tokyo Cabinet
ドキュメント指向
KAI
カラム指向 ２つを選択 SimpleDB
CouchDB
Vertica
Riack
Partition Tolerance
C
Consistency
P 分割耐性
一貫性 カラム指向
CP キー・バリュー型
[参考]
・Visual Guide to NoSQL Systems
ドキュメント指向 http://blog.nahurst.com/visual-guide-to-nosql-systems
BigTable Scalaris ・NoSQL登場の背景、CAP定理、データモデルの分類
MongoDB
Hypertable BerkeleyDB http://www.publickey1.jp/blog/10/nosqlcap.html
Terrastore
HBase MemcacheDB ・WEB+DB PRESS Vol.58
Redis Cassandra 実践入門

47. KVS には得意・不得意が
分散多重保存が得意
Flare, kumofs
データ永続化が得意
Tokyo Tyrant, Flare, kumofs
データの一貫性を保つのが得意
memcached, Tokyo Tyrant
「何でも得意」な KVS は無い！

48. 国産 KVS
国内だけでも、こんなにたくさんの開発者が
○Tokyo Tyrant 平林幹雄 氏（当時 mixi）
○kumofs 古橋貞之 氏（筑波大）
○Flare 藤本真樹 氏（GREE）
分散型
○ROMA 西澤無我 氏（楽天）
○okuyama 岩瀬高博 氏（神戸デジタル・ラボ）
素晴らしい！！

49. 国産 KVS
国内だけでも、こんなにたくさんの開発者が
○Tokyo Tyrant 平林幹雄 氏（当時 mixi）
○kumofs 古橋貞之 氏（筑波大）
○Flare 藤本真樹 氏（GREE）
分散型
○ROMA 西澤無我 氏（楽天）
○okuyama 岩瀬高博 氏（神戸デジタル・ラボ）
at+link＆神戸デジタル・ラボでサービス化！

50. 分散型 KVS 「okuyama」

51. okuyama の特徴
分散多重保存できるか
⇒ 得意！！
データを永続化できるか
⇒ 4段階レベルを選択可能！！
データの一貫性を保てるか
⇒ 3段階レベルを選択可能！！

52. okuyama って、CAP 定理だとどこ？
Availability
可用性 Ａ
CA AP
リレーショナル型 キー・バリュー型 カラム指向
RDBMS
Dynamo Cassandra
Aster Data
Voldermote
Creenplum
Tokyo Cabinet ドキュメント指向
KAI
カラム指向 ２つを選択 SimpleDB
CouchDB
Vertica Riack
Partition Tolerance
C
Consistency
P 分割耐性
一貫性 カラム指向
CP キー・バリュー型
ドキュメント指向
BigTable Scalaris
MongoDB
Hypertable BerkeleyDB
Terrastore
HBase MemcacheDB
Redis

53. okuyama って、CAP 定理だとどこ？
Availability
可用性 Ａ
CA AP
リレーショナル型 キー・バリュー型 カラム指向
RDBMS
Dynamo Cassandra
Aster Data
Voldermote
Creenplum
Tokyo Cabinet ドキュメント指向
KAI
カラム指向 ２つを選択 okuyama
SimpleDB
CouchDB
Vertica Riack
Partition Tolerance
C
Consistency
P 分割耐性
一貫性 カラム指向
CP キー・バリュー型
ドキュメント指向
BigTable Scalaris
MongoDB
Hypertable BerkeleyDB
Terrastore
HBase MemcacheDB
Redis

54. okuyama って、CAP 定理だとどこ？
Availability
可用性 Ａ
CA AP
リレーショナル型 キー・バリュー型 カラム指向
RDBMS
Dynamo Cassandra
Aster Data
Voldermote
Creenplum
Tokyo Cabinet ドキュメント指向
KAI
カラム指向 ２つを選択 okuyama
SimpleDB
CouchDB
Vertica Riack
一貫性レベルの
選択で補強！！
Partition Tolerance
C
Consistency
P 分割耐性
一貫性 カラム指向
CP キー・バリュー型
ドキュメント指向 okuyama では
BigTable Scalaris 一貫性のレベルを
MongoDB
Hypertable BerkeleyDB ３段階選択可能！
Terrastore
HBase MemcacheDB
Redis

55. okuyama の構成イメージ
Data Node Data Node Data Node
Master Node Data Node Data Node Data Node
Client
Client
Master Node Data Node Data Node Data Node
Client
Data Node Data Node Data Node
Client → Master Node → Data Node(×3)
（以降 okuyama 関連資料
神戸デジタル・ラボ 岩瀬高博 氏 提供）

56. okuyama クライアント
Client
okuyamaへの問い合わせを実現 Client
専用クライアントはJavaと、PHPを実装
Client

57. okuyama マスターノード
・クライアントからのI/F ・データノード管理
・サポートプロトコル >データ入出力
>オリジナル サポート分散アルゴリズム
Master Node
>Memcached 1. Mod
・set ・get ・add
2. ConsistentHash
・delete Master Node
>生存監視
・gets ・cas
起動時のデータリカバリ
>HTTP
・制限台数なしに冗長化可能
・GET

58. okuyama データノード
Data Node Data Node Data Node
・データの保存を実現
・データ保存方式を選択可能 Data Node Data Node Data Node
・最大3ノードにデータを保存
・アクセスバランシング Data Node Data Node Data Node
・連鎖的ダウンの予防
Data Node Data Node Data Node

59. データ保存方式の選択
1.全てのデータをメモリに保存
>非永続型 （key=メモリ、value=メモリ）
２.データ操作履歴のみファイルに保存
>永続型（key=メモリ、value=メモリ）＋操作記録ファイル
3.データ本体をファイルに保存
>永続型（key=メモリ、value=ファイル）＋操作記録ファイル
4.全てをファイルに保存
>永続型（key=ファイル、value=ファイル）＋操作記録ファイル

60. データの一貫性について
複数のノードに同一の値を保持していると、
データに異なる時間が発生する
データ保存 保存 保存 未保存
DataNode DataNode DataNode
データ取得 != データ取得

61. データ一貫性レベルの選択
1.弱一貫性
>全てのデータノードにランダムにアクセス
２.中一貫性
>常に最後に保存したデータノードからアクセス
3.強一貫性
>データノードの値を検証

62. okuyama に単一障害点は無い！
マスターノード障害発生
障害発生!! Data Ndoe DataNode
データ取得
MasterNode Data Node DataNode
Client
MasterNode Data Node DataNode
別のマスターノードに Data Node DataNode
再接続して処理続行！

63. okuyama に単一障害点は無い！
データノード障害発生
もう一つのノードから取得
データ保持
ノード割り出し Data Ndoe DataNode
MasterNode Data Node DataNode
データ取得
Client
MasterNode Data Node DataNode
Data Node DataNode

64. okuyama の長所
サービス化する際に重視した点
・単一障害点がない！
・設定を変えるだけで、様々な用途
に使える！
・マシン性能を限界まで引き出せる！

65. 詳しくは、岩瀬氏の資料をご覧ください
○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 から連載

66. 「okuyama」 サービス

67. at+link アプリプラットフォームの特徴
初期費用０円＆固定料金
ハイスペックサーバ＆冗長回線・LB/FW
基本契約は 5-DAY，サーバ追加は９０分以内
レスポンス監視（5秒ルールに対抗）
Munin によるリソース監視
ioDrive 搭載サーバ
KVS サービス

68. KVS の必要性
参照性能を向上するためにキャッシュ機能が必要
⇒ memcached，Tokyo Tyrant
大量の画像を保存する環境が必要
⇒ CDN
大量のログを保存する環境が必要
⇒ 短期間で削除，大容量ディスク

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

70. KVS の必要性
参照性能を向上するためにキャッシュ機能が必要
⇒ memcached，Tokyo Tyrant
大量の画像を保存する環境が必要
⇒ CDN
大量のログを保存する環境が必要
⇒ 短期間で削除，大容量ディスク

71. at+link アプリプラットフォームの構成
インターネット
ロードバランサ バックボーン 4Gbps
ファイアウォール 冗長構成
共用ファイアウォール
冗長構成が標準
共用ロードバランサ
（冗長構成） okuyama
追加は90分以内！ 画像ストレージ
Web Web Web Web Web Web DB Cache Image
Xeon 4コアの アプリ公開後５日間 okuyama
ioDrive 搭載マシン
ハイスペックマシン ５台無償！！ キャッシュサーバ
初期費用無償！
ここの話

72. okuyama キャッシュの構成イメージ
クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス
データノード データノード
クライアント
アクセス
メイン
VIP LVS マスターノード データノード データノード
LVS マスターノード データノード データノード
スタンバイ
マスターノードはロードバランシング
高負荷時はスケールアウト
データノード データノード
データノードで分散多重保存
容量不足・高負荷時はスケールアウト

73. okuyama キャッシュの構成イメージ
クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス
データノード データノード
クライアント
アクセス
メイン
障害！
VIP LVS マスターノード データノード データノード
LVS マスターノード データノード データノード
スタンバイ
マスターノードはロードバランシング
高負荷時はスケールアウト
データノード データノード
データノードで分散多重保存
容量不足・高負荷時はスケールアウト

74. okuyama キャッシュの構成イメージ
クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス
データノード データノード
障害対応
LVS マスターノード データノード データノード
クライアント
アクセス
VIP LVS マスターノード データノード データノード
メイン
マスターノードはロードバランシング
高負荷時はスケールアウト
データノード データノード
データノードで分散多重保存
容量不足・高負荷時はスケールアウト

75. okuyama キャッシュのメリット
・ ユーザでキャッシュサーバを用意する必要がない
・ サーバ運用開始と同時に接続可能
・memcached プロトコルに対応
・ 「分散」を意識することすらない
・ 障害を意識しなくていい
・ コントロールパネルから無停止で容量変更可能
・ コントロールパネルで実使用量を可視化
・ 価格も手ごろ（初期無償、2GB で月額 18,000円）
・ KDL・LINK ２社のサポート体制

76. 「okuyama」 画像ストレージ

77. KVS の必要性
参照性能を向上するためにキャッシュ機能が必要
⇒ memcached，Tokyo Tyrant
大量の画像を保存する環境が必要
⇒ CDN
大量のログを保存する環境が必要
⇒ 短期間で削除，大容量ディスク

78. at+link アプリプラットフォームの構成
インターネット
バックボーン 4Gbps
ロードバランサ ここの話
ファイアウォール 冗長構成
共用ファイアウォール
冗長構成が標準
共用ロードバランサ
（冗長構成） okuyama
追加は90分以内！ 画像ストレージ
Web Web Web Web Web Web DB Cache Image
Xeon 4コアの アプリ公開後５日間 okuyama
ioDrive 搭載マシン
ハイスペックマシン ５台無償！！ キャッシュサーバ
初期費用無償！

79. okuyama 画像ストレージの構成
クライアントは、画像ストレージ用に指定したドメインへアクセス
okuyama 用
クライアント マスターノード データノード データノード
Web アプリ
アクセス
メイン
okuyama 用
LB マスターノード データノード データノード
Web アプリ
ドメイン指定
okuyama 用
LB マスターノード データノード データノード
Web アプリ
スタンバイ
okuyama 用
マスターノード データノード データノード
Web アプリ
ロードバランサ２重化
okuyama 用 Web アプリ、マスターノード 複数でロードバランシング
データノード２重化・ロードバランシング

80. okuyama 画像ストレージ
デモ
画像データを保存してみる

81. okuyama 画像ストレージ性能評価①
ブラウザで体感！
okuyama v.s. Apache

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

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

84. okuyama キャッシュのメリット
・ ユーザでイメージサーバを用意する必要がない
・ サーバ運用開始と同時に接続可能
・ REST プロトコルに対応
・ 「分散」を意識することすらない
・ 障害を意識しなくていい
・ コントロールパネルから無停止で容量変更可能
・ コントロールパネルで実使用量を可視化
・ 価格も手ごろ（初期無償、100GB 当たり月額 15,000円）
・ KDL・LINK ２社のサポート体制
・ アプリと画像データのネットワークを分けられる
（ トラフィック出し放題・・・）

85. 管理画面で使用状況確認

86. KVS サービス使用状況①

87. KVS サービス使用状況②

88. KVS サービス使用状況③
キャッシュ使用容量 画像ストレージ使用容量

89. 今後の予定
アプリプラットフォーム＆ KVS サービス
2011.12
2010.11 2011.03 2011.09 2011.11 2012. ? 2012. ?
2010 2011 2012
アプリプラットフォーム ログストレージ 革命的監視サービス！
ログ解析
画像ストレージ
HDD 保管サービス
キャッシュサーバ

90. まとめ
・ソーシャルゲームの運用は大変・・・
・DB サーバは ioDrive で I/O の
ボトルネックを解消
・okuyama いいね！
・うまくキャッシュを使おう
・画像データは、画像ストレージへ
・ログストレージ、ログ解析はこれから・・・

91. イベント告知
○オープンソースカンファレンス東京
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～

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