ホスティング事業者から見たソーシャルゲーム  InfoTalk 第36回 2011.11.18(金)  株式会社リンク  at+link事業部 ディベロッパーサポート部  文屋 宏
自己紹介 ○氏名  文屋 宏(ぶんや ひろし) ○所属  株式会社リンク at+link事業部 ディベロッパーサポート部 ○業務  プロジェクトマネジメント,広報活動,営業活動,ユーザサポート,  他社との協業,たまに現地作業,面白いネタ探し ...
会社紹介(at+link とは)                    ディベロッパーサポートat+link の営業窓口      ◇開発者のためのサービス開発                   ◇開発者の悩み相談              ...
講演内容  ・ソーシャルゲームならではの特徴  ・at+link アプリプラットフォームの概要  ・ioDrive とは  ・分散型KVS 「okuyama」  ・okuyama キャッシュサービス  ・okuyama 画像ストレージ  ・今後...
ソーシャルゲームならではの特徴 ~ホスティング事業者から見て~
ソーシャルゲームならではの特徴  ・アクセス数が事前に読めない  ・ヒットすると、とんでもないことになる  ・ 5秒ルールなんてのがあるらしい・・・  ・朝、昼、夜と3回ピークがある  ・そのくせ、ド深夜(午前4時~5時)にも   アクセスがあ...
ソーシャルゲームのトラフィック        夜間のピーク                     昼休み            通勤・通学時
LAN ケーブルの性能これまではカテゴリー5eカテゴリー6にした方がいい?
比較方法 カテゴリー5eおよび6の性能比較を行う。 比較対象は、ケーブル間の通信   MySQLのトランザクション性能(SysBench) 検証環境   カテゴリー5e・6でスイッチ間と結線された4台                 ...
LANケーブルの性能評価
結局、主要箇所はカテゴリー6にLAN ケーブルの性能まで気にすることになるとは・・・
こんなソーシャルゲームを受け止めるために・・・
こんなソーシャルゲームを受け止めるために・・・at+link アプリプラットフォーム2010年11月17日提供開始!
こんなソーシャルゲームを受け止めるために・・・at+link アプリプラットフォーム2010年11月17日提供開始!           かなり後発・・・ (;´Д`)
at+link アプリプラットフォームのコンセプト     クラウドのメリット  ・初期費用が無料  ・サーバの増減が簡単かつ迅速    専用サーバのメリット  ・パフォーマンス、信頼性が高い  ・コストが明確
at+link アプリプラットフォームのコンセプト     クラウドのメリット       クラウドのデメリット  ・初期費用が無料          ・転送料課金  ・サーバの増減が簡単かつ迅速    ・パフォーマンスがいまいち    専用サ...
at+link アプリプラットフォームのコンセプト     クラウドのメリット       クラウドのデメリット  ・初期費用が無料          ・転送料課金  ・サーバの増減が簡単かつ迅速    ・パフォーマンスがいまいち    専用サ...
at+link アプリプラットフォームのコンセプト     クラウドのメリット           クラウドのデメリット  ・初期費用が無料             ・転送料課金  ・サーバの増減が簡単かつ迅速       ・パフォーマンスがい...
at+link アプリプラットフォームの特徴   初期費用0円&固定料金   ハイスペックサーバ&冗長回線・LB/FW   基本契約は 5-DAY,サーバ追加は90分以内   レスポンス監視(5秒ルールに対抗)   Munin によるリソース監...
at+link アプリプラットフォームの構成                 インターネット      ロードバランサ                   バックボーン 4Gbps      ファイアウォール                  ...
at+link アプリプラットフォームの構成                     インターネット          ロードバランサ                   バックボーン 4Gbps          ファイアウォール      ...
at+link アプリプラットフォームの構成                     インターネット          ロードバランサ                   バックボーン 4Gbps          ファイアウォール      ...
at+link アプリプラットフォームの構成                     インターネット          ロードバランサ                   バックボーン 4Gbps          ファイアウォール      ...
at+link アプリプラットフォームの管理画面
サーバ追加申請
サーバ追加申請
ioDrive とは
at+link アプリプラットフォームの特徴   初期費用0円&固定料金   ハイスペックサーバ&冗長回線・LB/FW   基本契約は 5-DAY,サーバ追加は90分以内   レスポンス監視(5秒ルールに対抗)   Munin によるリソース監...
ioDrive って何?写真で見てみよう
ioDrive 写真①  Fusion-io 社が提供する超高速半導体ストレージ          ioDrive 本体
ioDrive 写真②         この辺に装着する          サーバ 本体
ioDrive 写真③              この辺に装着する     サーバ 本体 別の角度から
ioDrive 写真④              ここに装着!       サーバ 本体 拡大!
ioDrive 写真⑤              装着完了!
ioDrive の特徴  ・桁違いの速さで I/O のボトルネックを   解消できる  ・ソーシャルゲームのデータベースとして   容量は十分  ・同時アクセスにも強いので、マシンを   集約できる  ・高い信頼性  ・SSD に比べて寿命が長い
ioDrive の性能
ioDrive の性能①        ioDrive は同時接続に強い!
ioDrive の性能②                     loadaverage 8000 超                 激しく latency 発生      同時アクセス数をもっと増やしてみると・・・
ioDrive の性能③           SSD よりも速い!
ioDrive は、・速い!・大量の同時アクセスに強い!⇒ DBサーバを集約できる!!
分散型 KVS 「okuyama」サービス
・・・の前に、分散型 KVS って何?
データベースソフトウェアの分類    RDBMS              NoSQL   ・Oracle         ・カラム指向型   ・MySQL          ・ドキュメント指向型   ・PostgreSQL     ・キー・バ...
分散処理 の必要性      サービスが成長してきたとき、どうする?   スケールアップ              スケールアウト                  or ・ハードウェア的な限界がある        ・ハードウェア的な限界がない...
でも・・・どんなシステムでも、必ず何かを犠牲にしなきゃいけない・・・
CAP 定理による NoSQL の分類                    Availability                    可用性        A         CA                            ...
KVS には得意・不得意が     分散多重保存が得意     Flare, kumofs     データ永続化が得意     Tokyo Tyrant, Flare, kumofs     データの一貫性を保つのが得意     memcach...
国産 KVS  国内だけでも、こんなにたくさんの開発者が      ○Tokyo Tyrant   平林幹雄 氏(当時 mixi)      ○kumofs         古橋貞之 氏(筑波大)      ○Flare          藤本...
国産 KVS  国内だけでも、こんなにたくさんの開発者が      ○Tokyo Tyrant   平林幹雄 氏(当時 mixi)      ○kumofs         古橋貞之 氏(筑波大)      ○Flare          藤本...
分散型 KVS 「okuyama」
okuyama の特徴       分散多重保存できるか      ⇒ 得意!!       データを永続化できるか      ⇒ 4段階レベルを選択可能!!       データの一貫性を保てるか      ⇒ 3段階レベルを選択可能!!
okuyama って、CAP 定理だとどこ?                    Availability                    可用性        A         CA                         ...
okuyama って、CAP 定理だとどこ?                    Availability                    可用性        A         CA                         ...
okuyama って、CAP 定理だとどこ?                    Availability                    可用性        A         CA                         ...
okuyama の構成イメージ                                  Data Node   Data Node   Data Node                    Master Node   Data N...
okuyama クライアント                         Client okuyamaへの問い合わせを実現                  Client 専用クライアントはJavaと、PHPを実装             ...
okuyama マスターノード・クライアントからのI/F ・データノード管理・サポートプロトコル        >データ入出力>オリジナル             サポート分散アルゴリズム                            ...
okuyama データノード                  Data Node   Data Node   Data Node ・データの保存を実現 ・データ保存方式を選択可能    Data Node   Data Node   Data...
データ保存方式の選択1.全てのデータをメモリに保存 >非永続型 (key=メモリ、value=メモリ)2.データ操作履歴のみファイルに保存 >永続型(key=メモリ、value=メモリ)+操作記録ファイル3.データ本体をファイルに保存 >永続型...
データの一貫性について  複数のノードに同一の値を保持していると、  データに異なる時間が発生する  データ保存       保存         保存        未保存             DataNode   DataNode   ...
データ一貫性レベルの選択 1.弱一貫性  >全てのデータノードにランダムにアクセス 2.中一貫性  >常に最後に保存したデータノードからアクセス 3.強一貫性  >データノードの値を検証
okuyama に単一障害点は無い! マスターノード障害発生                  障害発生!!        Data Ndoe   DataNode          データ取得                   Master...
okuyama に単一障害点は無い! データノード障害発生                               もう一つのノードから取得                 データ保持                 ノード割り出し    ...
okuyama の長所    サービス化する際に重視した点  ・単一障害点がない!  ・設定を変えるだけで、様々な用途   に使える!  ・マシン性能を限界まで引き出せる!
詳しくは、岩瀬氏の資料をご覧ください○Think IT 連載記事 http://thinkit.co.jp/story/2011/02/03/1990 http://thinkit.co.jp/story/2011/10/12/2303○講演資...
「okuyama」 サービス
at+link アプリプラットフォームの特徴   初期費用0円&固定料金   ハイスペックサーバ&冗長回線・LB/FW   基本契約は 5-DAY,サーバ追加は90分以内   レスポンス監視(5秒ルールに対抗)   Munin によるリソース監...
KVS の必要性  参照性能を向上するためにキャッシュ機能が必要   ⇒ memcached,Tokyo Tyrant  大量の画像を保存する環境が必要   ⇒ CDN  大量のログを保存する環境が必要   ⇒ 短期間で削除,大容量ディスク
「okuyama」 キャッシュサービス
KVS の必要性  参照性能を向上するためにキャッシュ機能が必要   ⇒ memcached,Tokyo Tyrant  大量の画像を保存する環境が必要   ⇒ CDN  大量のログを保存する環境が必要   ⇒ 短期間で削除,大容量ディスク
at+link アプリプラットフォームの構成                     インターネット          ロードバランサ                   バックボーン 4Gbps          ファイアウォール      ...
okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス                                     データノード   データノードクライアントアクセス  ...
okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス                                     データノード   データノードクライアントアクセス  ...
okuyama キャッシュの構成イメージ  クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス                                     データノード   データノード          障...
okuyama キャッシュのメリット ・ ユーザでキャッシュサーバを用意する必要がない ・ サーバ運用開始と同時に接続可能 ・memcached プロトコルに対応 ・ 「分散」を意識することすらない ・ 障害を意識しなくていい ・ コントロール...
「okuyama」 画像ストレージ
KVS の必要性  参照性能を向上するためにキャッシュ機能が必要   ⇒ memcached,Tokyo Tyrant  大量の画像を保存する環境が必要   ⇒ CDN  大量のログを保存する環境が必要   ⇒ 短期間で削除,大容量ディスク
at+link アプリプラットフォームの構成                     インターネット                                    バックボーン 4Gbps          ロードバランサ       ...
okuyama 画像ストレージの構成          クライアントは、画像ストレージ用に指定したドメインへアクセス                   okuyama 用クライアント                         マスターノ...
okuyama 画像ストレージ       デモ  画像データを保存してみる
okuyama 画像ストレージ性能評価①    ブラウザで体感!    okuyama v.s. Apache
okuyama 画像ストレージ性能評価②
okuyama 画像ストレージ性能評価③
okuyama キャッシュのメリット  ・   ユーザでイメージサーバを用意する必要がない  ・   サーバ運用開始と同時に接続可能  ・   REST プロトコルに対応  ・   「分散」を意識することすらない  ・   障害を意識しなくてい...
管理画面で使用状況確認
KVS サービス使用状況①
KVS サービス使用状況②
KVS サービス使用状況③   キャッシュ使用容量    画像ストレージ使用容量
今後の予定       アプリプラットフォーム& KVS サービス                                          2011.12  2010.11      2011.03          2011.09 ...
まとめ  ・ソーシャルゲームの運用は大変・・・  ・DB サーバは ioDrive で I/O の   ボトルネックを解消  ・okuyama いいね!  ・うまくキャッシュを使おう  ・画像データは、画像ストレージへ  ・ログストレージ、ログ...
イベント告知○オープンソースカンファレンス東京 https://www.ospn.jp/osc2011-fall/modules/eguide/event.php?eid=46 会場:明星大学 日程:11/19 (土) 15:15~ (11/1...
ご清聴ありがとうございました!
Upcoming SlideShare
Loading in …5
×

Info talk #36

1,604 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,604
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Info talk #36

  1. 1. ホスティング事業者から見たソーシャルゲーム InfoTalk 第36回 2011.11.18(金) 株式会社リンク at+link事業部 ディベロッパーサポート部 文屋 宏
  2. 2. 自己紹介 ○氏名 文屋 宏(ぶんや ひろし) ○所属 株式会社リンク at+link事業部 ディベロッパーサポート部 ○業務 プロジェクトマネジメント,広報活動,営業活動,ユーザサポート, 他社との協業,たまに現地作業,面白いネタ探し ○活動 日本 Red5 ユーザー会,tokyoLinuxStudy 主催 ○Twitter アカウント @bun_hiroshi
  3. 3. 会社紹介(at+link とは) ディベロッパーサポートat+link の営業窓口 ◇開発者のためのサービス開発 ◇開発者の悩み相談 ◇新しい技術・面白い技術の 研究・サービス化 データセンター常駐 マシン製造 現場担当 24/365 サポート
  4. 4. 講演内容 ・ソーシャルゲームならではの特徴 ・at+link アプリプラットフォームの概要 ・ioDrive とは ・分散型KVS 「okuyama」 ・okuyama キャッシュサービス ・okuyama 画像ストレージ ・今後の予定
  5. 5. ソーシャルゲームならではの特徴 ~ホスティング事業者から見て~
  6. 6. ソーシャルゲームならではの特徴 ・アクセス数が事前に読めない ・ヒットすると、とんでもないことになる ・ 5秒ルールなんてのがあるらしい・・・ ・朝、昼、夜と3回ピークがある ・そのくせ、ド深夜(午前4時~5時)にも アクセスがある ・少しの接続断も許されない・・・ ・ゲームによって(作りによって)、 サーバへの負荷がまちまち
  7. 7. ソーシャルゲームのトラフィック 夜間のピーク 昼休み 通勤・通学時
  8. 8. LAN ケーブルの性能これまではカテゴリー5eカテゴリー6にした方がいい?
  9. 9. 比較方法 カテゴリー5eおよび6の性能比較を行う。 比較対象は、ケーブル間の通信  MySQLのトランザクション性能(SysBench) 検証環境  カテゴリー5e・6でスイッチ間と結線された4台 L2 スイッチ Cat 6 Cat 5e サーバ① サーバ② サーバ③ サーバ④
  10. 10. LANケーブルの性能評価
  11. 11. 結局、主要箇所はカテゴリー6にLAN ケーブルの性能まで気にすることになるとは・・・
  12. 12. こんなソーシャルゲームを受け止めるために・・・
  13. 13. こんなソーシャルゲームを受け止めるために・・・at+link アプリプラットフォーム2010年11月17日提供開始!
  14. 14. こんなソーシャルゲームを受け止めるために・・・at+link アプリプラットフォーム2010年11月17日提供開始! かなり後発・・・ (;´Д`)
  15. 15. at+link アプリプラットフォームのコンセプト クラウドのメリット ・初期費用が無料 ・サーバの増減が簡単かつ迅速 専用サーバのメリット ・パフォーマンス、信頼性が高い ・コストが明確
  16. 16. at+link アプリプラットフォームのコンセプト クラウドのメリット クラウドのデメリット ・初期費用が無料 ・転送料課金 ・サーバの増減が簡単かつ迅速 ・パフォーマンスがいまいち 専用サーバのメリット 専用サーバのデメリット ・パフォーマンス、信頼性が高い ・初期費用がかかる ・コストが明確 ・納期が遅い
  17. 17. at+link アプリプラットフォームのコンセプト クラウドのメリット クラウドのデメリット ・初期費用が無料 ・転送料課金 ・サーバの増減が簡単かつ迅速 ・パフォーマンスがいまいち 専用サーバのメリット 専用サーバのデメリット ・パフォーマンス、信頼性が高い ・初期費用がかかる ・コストが明確 ・納期が遅い クラウドと専用サーバの“いいとこ取り”をしよう!!!
  18. 18. at+link アプリプラットフォームのコンセプト クラウドのメリット クラウドのデメリット ・初期費用が無料 ・転送料課金 ・サーバの増減が簡単かつ迅速 ・パフォーマンスがいまいち 専用サーバのメリット 専用サーバのデメリット ・パフォーマンス、信頼性が高い ・初期費用がかかる ・コストが明確 ・納期が遅い クラウドと専用サーバの“いいとこ取り”をしよう!!! 後発だからこそ!後発で良かったかも?
  19. 19. at+link アプリプラットフォームの特徴 初期費用0円&固定料金 ハイスペックサーバ&冗長回線・LB/FW 基本契約は 5-DAY,サーバ追加は90分以内 レスポンス監視(5秒ルールに対抗) Munin によるリソース監視 ioDrive 搭載サーバ KVS サービス
  20. 20. at+link アプリプラットフォームの構成 インターネット ロードバランサ バックボーン 4Gbps ファイアウォール 冗長構成 共用ファイアウォール 冗長構成が標準 共用ロードバランサ (冗長構成) Web Web Web Web Web DB Xeon 4コアの アプリ公開後5日間 ioDrive 搭載マシン ハイスペックマシン 5台無償!! 初期費用無償!
  21. 21. at+link アプリプラットフォームの構成 インターネット ロードバランサ バックボーン 4Gbps ファイアウォール 冗長構成 共用ファイアウォール 冗長構成が標準 共用ロードバランサ (冗長構成)追加は90分以内!Web Web Web Web Web Web DB Xeon 4コアの アプリ公開後5日間 ioDrive 搭載マシン ハイスペックマシン 5台無償!! 初期費用無償!
  22. 22. at+link アプリプラットフォームの構成 インターネット ロードバランサ バックボーン 4Gbps ファイアウォール 冗長構成 共用ファイアウォール 冗長構成が標準 共用ロードバランサ (冗長構成)追加は90分以内!Web Web Web Web Web Web DB Cache Xeon 4コアの アプリ公開後5日間 okuyama ioDrive 搭載マシン ハイスペックマシン 5台無償!! キャッシュサーバ 初期費用無償!
  23. 23. at+link アプリプラットフォームの構成 インターネット ロードバランサ バックボーン 4Gbps ファイアウォール 冗長構成 共用ファイアウォール 冗長構成が標準 共用ロードバランサ (冗長構成) okuyama追加は90分以内! 画像ストレージWeb Web Web Web Web Web DB Cache Image Xeon 4コアの アプリ公開後5日間 okuyama ioDrive 搭載マシン ハイスペックマシン 5台無償!! キャッシュサーバ 初期費用無償!
  24. 24. at+link アプリプラットフォームの管理画面
  25. 25. サーバ追加申請
  26. 26. サーバ追加申請
  27. 27. ioDrive とは
  28. 28. at+link アプリプラットフォームの特徴 初期費用0円&固定料金 ハイスペックサーバ&冗長回線・LB/FW 基本契約は 5-DAY,サーバ追加は90分以内 レスポンス監視(5秒ルールに対抗) Munin によるリソース監視 ioDrive 搭載サーバ KVS サービス
  29. 29. ioDrive って何?写真で見てみよう
  30. 30. ioDrive 写真① Fusion-io 社が提供する超高速半導体ストレージ ioDrive 本体
  31. 31. ioDrive 写真② この辺に装着する サーバ 本体
  32. 32. ioDrive 写真③ この辺に装着する サーバ 本体 別の角度から
  33. 33. ioDrive 写真④ ここに装着! サーバ 本体 拡大!
  34. 34. ioDrive 写真⑤ 装着完了!
  35. 35. ioDrive の特徴 ・桁違いの速さで I/O のボトルネックを 解消できる ・ソーシャルゲームのデータベースとして 容量は十分 ・同時アクセスにも強いので、マシンを 集約できる ・高い信頼性 ・SSD に比べて寿命が長い
  36. 36. ioDrive の性能
  37. 37. ioDrive の性能① ioDrive は同時接続に強い!
  38. 38. ioDrive の性能② loadaverage 8000 超 激しく latency 発生 同時アクセス数をもっと増やしてみると・・・
  39. 39. ioDrive の性能③ SSD よりも速い!
  40. 40. ioDrive は、・速い!・大量の同時アクセスに強い!⇒ DBサーバを集約できる!!
  41. 41. 分散型 KVS 「okuyama」サービス
  42. 42. ・・・の前に、分散型 KVS って何?
  43. 43. データベースソフトウェアの分類 RDBMS NoSQL ・Oracle ・カラム指向型 ・MySQL ・ドキュメント指向型 ・PostgreSQL ・キー・バリュー型 etc. etc. 一貫性重視 パフォーマンス重視 スケールアップ スケールアウト KVS は NoSQL の一種 NoSQL = Not Only SQL RDBMS と NoSQL は互いに補完し合う存在 どちらが優れている、ということはない
  44. 44. 分散処理 の必要性 サービスが成長してきたとき、どうする? スケールアップ スケールアウト or ・ハードウェア的な限界がある ・ハードウェア的な限界がない ・ネットワーク集中 ・ネットワーク分散 ・コストパフォーマンスが悪い ・コストパフォーマンスが高い ・障害に弱い ・障害に強い(高可用性) Web サーバだけでなく、DB サーバも分散させたい!
  45. 45. でも・・・どんなシステムでも、必ず何かを犠牲にしなきゃいけない・・・
  46. 46. CAP 定理による NoSQL の分類 Availability 可用性 A CA AP リレーショナル型 キー・バリュー型 カラム指向 RDBMS Dynamo Cassandra Aster Data Voldermote Creenplum Tokyo Cabinet ドキュメント指向 KAI カラム指向 2つを選択 SimpleDB CouchDB Vertica Riack Partition Tolerance CConsistency 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. 47. KVS には得意・不得意が 分散多重保存が得意 Flare, kumofs データ永続化が得意 Tokyo Tyrant, Flare, kumofs データの一貫性を保つのが得意 memcached, Tokyo Tyrant 「何でも得意」な KVS は無い!
  48. 48. 国産 KVS 国内だけでも、こんなにたくさんの開発者が ○Tokyo Tyrant 平林幹雄 氏(当時 mixi) ○kumofs 古橋貞之 氏(筑波大) ○Flare 藤本真樹 氏(GREE)分散型 ○ROMA 西澤無我 氏(楽天) ○okuyama 岩瀬高博 氏(神戸デジタル・ラボ) 素晴らしい!!
  49. 49. 国産 KVS 国内だけでも、こんなにたくさんの開発者が ○Tokyo Tyrant 平林幹雄 氏(当時 mixi) ○kumofs 古橋貞之 氏(筑波大) ○Flare 藤本真樹 氏(GREE)分散型 ○ROMA 西澤無我 氏(楽天) ○okuyama 岩瀬高博 氏(神戸デジタル・ラボ) at+link&神戸デジタル・ラボでサービス化!
  50. 50. 分散型 KVS 「okuyama」
  51. 51. okuyama の特徴 分散多重保存できるか ⇒ 得意!! データを永続化できるか ⇒ 4段階レベルを選択可能!! データの一貫性を保てるか ⇒ 3段階レベルを選択可能!!
  52. 52. okuyama って、CAP 定理だとどこ? Availability 可用性 A CA AP リレーショナル型 キー・バリュー型 カラム指向 RDBMS Dynamo Cassandra Aster Data Voldermote Creenplum Tokyo Cabinet ドキュメント指向 KAI カラム指向 2つを選択 SimpleDB CouchDB Vertica Riack Partition Tolerance CConsistency P 分割耐性一貫性 カラム指向 CP キー・バリュー型 ドキュメント指向 BigTable Scalaris MongoDB Hypertable BerkeleyDB Terrastore HBase MemcacheDB Redis
  53. 53. okuyama って、CAP 定理だとどこ? Availability 可用性 A CA AP リレーショナル型 キー・バリュー型 カラム指向 RDBMS Dynamo Cassandra Aster Data Voldermote Creenplum Tokyo Cabinet ドキュメント指向 KAI カラム指向 2つを選択 okuyama SimpleDB CouchDB Vertica Riack Partition Tolerance CConsistency P 分割耐性一貫性 カラム指向 CP キー・バリュー型 ドキュメント指向 BigTable Scalaris MongoDB Hypertable BerkeleyDB Terrastore HBase MemcacheDB Redis
  54. 54. okuyama って、CAP 定理だとどこ? Availability 可用性 A CA AP リレーショナル型 キー・バリュー型 カラム指向 RDBMS Dynamo Cassandra Aster Data Voldermote Creenplum Tokyo Cabinet ドキュメント指向 KAI カラム指向 2つを選択 okuyama SimpleDB CouchDB Vertica Riack 一貫性レベルの 選択で補強!! Partition Tolerance CConsistency P 分割耐性一貫性 カラム指向 CP キー・バリュー型 ドキュメント指向 okuyama では BigTable Scalaris 一貫性のレベルを MongoDB Hypertable BerkeleyDB 3段階選択可能! Terrastore HBase MemcacheDB Redis
  55. 55. okuyama の構成イメージ Data Node Data Node Data Node Master Node Data Node Data Node Data NodeClient Client Master Node Data Node Data Node Data Node Client Data Node Data Node Data Node Client → Master Node → Data Node(×3) (以降 okuyama 関連資料 神戸デジタル・ラボ 岩瀬高博 氏 提供)
  56. 56. okuyama クライアント Client okuyamaへの問い合わせを実現 Client 専用クライアントはJavaと、PHPを実装 Client
  57. 57. okuyama マスターノード・クライアントからのI/F ・データノード管理・サポートプロトコル >データ入出力>オリジナル サポート分散アルゴリズム Master Node>Memcached 1. Mod ・set ・get ・add 2. ConsistentHash ・delete Master Node >生存監視 ・gets ・cas 起動時のデータリカバリ>HTTP ・制限台数なしに冗長化可能 ・GET
  58. 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. 59. データ保存方式の選択1.全てのデータをメモリに保存 >非永続型 (key=メモリ、value=メモリ)2.データ操作履歴のみファイルに保存 >永続型(key=メモリ、value=メモリ)+操作記録ファイル3.データ本体をファイルに保存 >永続型(key=メモリ、value=ファイル)+操作記録ファイル4.全てをファイルに保存 >永続型(key=ファイル、value=ファイル)+操作記録ファイル
  60. 60. データの一貫性について 複数のノードに同一の値を保持していると、 データに異なる時間が発生する データ保存 保存 保存 未保存 DataNode DataNode DataNode データ取得 != データ取得
  61. 61. データ一貫性レベルの選択 1.弱一貫性 >全てのデータノードにランダムにアクセス 2.中一貫性 >常に最後に保存したデータノードからアクセス 3.強一貫性 >データノードの値を検証
  62. 62. okuyama に単一障害点は無い! マスターノード障害発生 障害発生!! Data Ndoe DataNode データ取得 MasterNode Data Node DataNode Client MasterNode Data Node DataNode 別のマスターノードに Data Node DataNode 再接続して処理続行!
  63. 63. okuyama に単一障害点は無い! データノード障害発生 もう一つのノードから取得 データ保持 ノード割り出し Data Ndoe DataNode MasterNode Data Node DataNode データ取得Client MasterNode Data Node DataNode Data Node DataNode
  64. 64. okuyama の長所 サービス化する際に重視した点 ・単一障害点がない! ・設定を変えるだけで、様々な用途 に使える! ・マシン性能を限界まで引き出せる!
  65. 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. 66. 「okuyama」 サービス
  67. 67. at+link アプリプラットフォームの特徴 初期費用0円&固定料金 ハイスペックサーバ&冗長回線・LB/FW 基本契約は 5-DAY,サーバ追加は90分以内 レスポンス監視(5秒ルールに対抗) Munin によるリソース監視 ioDrive 搭載サーバ KVS サービス
  68. 68. KVS の必要性 参照性能を向上するためにキャッシュ機能が必要 ⇒ memcached,Tokyo Tyrant 大量の画像を保存する環境が必要 ⇒ CDN 大量のログを保存する環境が必要 ⇒ 短期間で削除,大容量ディスク
  69. 69. 「okuyama」 キャッシュサービス
  70. 70. KVS の必要性 参照性能を向上するためにキャッシュ機能が必要 ⇒ memcached,Tokyo Tyrant 大量の画像を保存する環境が必要 ⇒ CDN 大量のログを保存する環境が必要 ⇒ 短期間で削除,大容量ディスク
  71. 71. at+link アプリプラットフォームの構成 インターネット ロードバランサ バックボーン 4Gbps ファイアウォール 冗長構成 共用ファイアウォール 冗長構成が標準 共用ロードバランサ (冗長構成) okuyama追加は90分以内! 画像ストレージWeb Web Web Web Web Web DB Cache Image Xeon 4コアの アプリ公開後5日間 okuyama ioDrive 搭載マシン ハイスペックマシン 5台無償!! キャッシュサーバ 初期費用無償! ここの話
  72. 72. okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス データノード データノードクライアントアクセス メイン VIP LVS マスターノード データノード データノード LVS マスターノード データノード データノード スタンバイ マスターノードはロードバランシング 高負荷時はスケールアウト データノード データノード データノードで分散多重保存 容量不足・高負荷時はスケールアウト
  73. 73. okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス データノード データノードクライアントアクセス メイン 障害! VIP LVS マスターノード データノード データノード LVS マスターノード データノード データノード スタンバイ マスターノードはロードバランシング 高負荷時はスケールアウト データノード データノード データノードで分散多重保存 容量不足・高負荷時はスケールアウト
  74. 74. okuyama キャッシュの構成イメージ クライアントは、VIP とクライアント毎に割り振られたポート番号へアクセス データノード データノード 障害対応 LVS マスターノード データノード データノードクライアントアクセス VIP LVS マスターノード データノード データノード メイン マスターノードはロードバランシング 高負荷時はスケールアウト データノード データノード データノードで分散多重保存 容量不足・高負荷時はスケールアウト
  75. 75. okuyama キャッシュのメリット ・ ユーザでキャッシュサーバを用意する必要がない ・ サーバ運用開始と同時に接続可能 ・memcached プロトコルに対応 ・ 「分散」を意識することすらない ・ 障害を意識しなくていい ・ コントロールパネルから無停止で容量変更可能 ・ コントロールパネルで実使用量を可視化 ・ 価格も手ごろ(初期無償、2GB で月額 18,000円) ・ KDL・LINK 2社のサポート体制
  76. 76. 「okuyama」 画像ストレージ
  77. 77. KVS の必要性 参照性能を向上するためにキャッシュ機能が必要 ⇒ memcached,Tokyo Tyrant 大量の画像を保存する環境が必要 ⇒ CDN 大量のログを保存する環境が必要 ⇒ 短期間で削除,大容量ディスク
  78. 78. at+link アプリプラットフォームの構成 インターネット バックボーン 4Gbps ロードバランサ ここの話 ファイアウォール 冗長構成 共用ファイアウォール 冗長構成が標準 共用ロードバランサ (冗長構成) okuyama追加は90分以内! 画像ストレージWeb Web Web Web Web Web DB Cache Image Xeon 4コアの アプリ公開後5日間 okuyama ioDrive 搭載マシン ハイスペックマシン 5台無償!! キャッシュサーバ 初期費用無償!
  79. 79. okuyama 画像ストレージの構成 クライアントは、画像ストレージ用に指定したドメインへアクセス okuyama 用クライアント マスターノード データノード データノード Web アプリアクセス メイン okuyama 用 LB マスターノード データノード データノード Web アプリドメイン指定 okuyama 用 LB マスターノード データノード データノード Web アプリ スタンバイ okuyama 用 マスターノード データノード データノード Web アプリ ロードバランサ2重化 okuyama 用 Web アプリ、マスターノード 複数でロードバランシング データノード2重化・ロードバランシング
  80. 80. okuyama 画像ストレージ デモ 画像データを保存してみる
  81. 81. okuyama 画像ストレージ性能評価① ブラウザで体感! okuyama v.s. Apache
  82. 82. okuyama 画像ストレージ性能評価②
  83. 83. okuyama 画像ストレージ性能評価③
  84. 84. okuyama キャッシュのメリット ・ ユーザでイメージサーバを用意する必要がない ・ サーバ運用開始と同時に接続可能 ・ REST プロトコルに対応 ・ 「分散」を意識することすらない ・ 障害を意識しなくていい ・ コントロールパネルから無停止で容量変更可能 ・ コントロールパネルで実使用量を可視化 ・ 価格も手ごろ(初期無償、100GB 当たり月額 15,000円) ・ KDL・LINK 2社のサポート体制 ・ アプリと画像データのネットワークを分けられる ( トラフィック出し放題・・・)
  85. 85. 管理画面で使用状況確認
  86. 86. KVS サービス使用状況①
  87. 87. KVS サービス使用状況②
  88. 88. KVS サービス使用状況③ キャッシュ使用容量 画像ストレージ使用容量
  89. 89. 今後の予定 アプリプラットフォーム& KVS サービス 2011.12 2010.11 2011.03 2011.09 2011.11 2012. ? 2012. ?2010 2011 2012 アプリプラットフォーム ログストレージ 革命的監視サービス! ログ解析 画像ストレージ HDD 保管サービス キャッシュサーバ
  90. 90. まとめ ・ソーシャルゲームの運用は大変・・・ ・DB サーバは ioDrive で I/O の ボトルネックを解消 ・okuyama いいね! ・うまくキャッシュを使おう ・画像データは、画像ストレージへ ・ログストレージ、ログ解析はこれから・・・
  91. 91. イベント告知○オープンソースカンファレンス東京 https://www.ospn.jp/osc2011-fall/modules/eguide/event.php?eid=46 会場:明星大学 日程:11/19 (土) 15:15~ (11/19・11/20 2日間ブースも出展!)○ at+link サービスセミナー http://atnd.org/events/22097 会場:IBM 新渋谷事業所 (東京都渋谷区道玄坂1-12-1 渋谷マークシティウエスト18F) 日程:12/9(金) 14:00~
  92. 92. ご清聴ありがとうございました!

×