CyberX NoSQL semi 発表資料

1. ソーシャルメディア、 ソーシャルアプリが育てたNoSQL技術 2011/05/17

2. 初めにすこしだけ 本セミナーは3月15日から延期になりましたが 本日開催できたことに感謝します 私は仙台に住んでいます 幸い震災時は東京にいたため、無事でした 家内が仙台の自宅にいましたが、家内も無事で、自宅の被害は少なかったです しかし震災の爪痕は今なお残っています 復興への近道は日本経済が元気になることと思っています 今日お集まりいただいた皆様とともに 日本経済を盛り上げていければと思います

3. お前、誰よ 株式会社 CyberX 取締役兼CTO 白井 英（しらい すぐる） PHP/JavaScriptがわりと好き 仕事はインフラまわりから PHP/ActionScript3が多い 携帯のソーシャルアプリ黎明期から開発従事 Ｔｗｉｔｔｅｒ： ＠goodoo Blog: http://ameblo.jp/goodoo

4. ソーシャルアプリといえば？

5. プラットフォーマーでは DeNAさん GREEさん Mixiさん

6. memcachedといえば？

7. Mixiさんの運用事例が有名ですね

8. 今日お話しするのはそこまで大規模な話ではありません

9. でも、よく陥りがちな話をしたいと思います

10. CyberXでは携帯のソーシャルアプリを作っています 代表的アプリ「星空バータウン」（mixiモバイル）

11. 「星空バータウン」のmemcachedを切り口とした運用事例・トラブル事例の話をします

12. Agenda 規模の話 弊社アプリのサーバ構成 memcachedのおさらい 弊社CyberXの運用事例 弊社CyberXのトラブル事例 キャッシュの考え方

13. 規模 超大規模（Google/Facebookクラス） Google サーバ台数100万台以上 Facebook サーバ台数6万台以上 大規模（プラットフォーマクラス） DeNA、Gree、Mixi サーバ台数数千台 数十～数百億PV/Day

14. 「星空バータウン」の規模（1アプリ） ユーザ数約200万人 約10億PV/Month 75万(MonthlyActiveUser) ピーク時のトラフィック200Mbps サーバ台数 約50台 参考【引用元：大規模サービス技術入門】より 2009年のはてなのサービス ユーザ数100万人以上 数十億PV/month ピーク時のトラフィック430Mbps サーバ台数 500台以上

15. ヒットするソーシャルアプリは2009年当時のはてなに近いインフラ技術が必要

16. 「星空バータウン」サーバ構成 2010/07 Web：30台 Flash合成：3台 Cache：1台 DB：４台

19. memcachedの特徴 シンプルなプロトコル 基本 Get、Set 内蔵のオンメモリストレージ 速い、軽い LRU（Least Recently Used） 手軽

20. 「星空バータウン」の運用事例 CyberXのソーシャルアプリはPHPで構築 CakePHPにて実装 PHPのセッション共有にmemcachedを使用 実はPHPのファイルでのセッション管理よりmemcachedのセッション管理のほうが負荷が低い ⇒ FileI/O > memory R/W

21. え？これじゃないの？ 引用元：「memcachedを知り尽くす » 第1回 memcachedの基本」 http://gihyo.jp/dev/feature/01/memcached/0001

22. 「星空バータウン」の運用事例 DBのデータを見に行ってもデータがDBサーバのメモリに乗っているのであれば、十分なレスポンスを返す innodbは思ったより早い memcachedにSQLの結果をキャッシュさせた別アプリもあるがさほどメリットがなかった むしろmemcachedとして管理するサーバの台数が増え管理コストは増大

23. memcachedのトラブル

24. といえば

25. 2010/08/10mixi大規模障害

26. mixi大規模障害おさらい memcachedの接続限界数に達した時に発生する不具合 接続限界数に達したのちクライアントの切断処理後、新規接続を受け付ける時に、排他制御が崩れる瞬間あり memcachedが落ちる 詳しくは、mixiさんのengineers_blogを参照 http://alpha.mixi.co.jp/blog/?p=2211

27. mixi大規模障害の教訓 memcachedを運用する場合には -c による接続数の制限はできるだけ大きくする もちろん、CPU/Load/Memory/ cache hit/response timeなどをきちんと監視

28. いっぽうその頃弊社では・・・・

29. 「教授(※)！ セッションデータがドロップされています！！！」 ※ 私のことです

30. memcachedでトラブル発生

31. 「星空バータウン」ちょっと恥かしいトラブル事例 セッション管理用のmemcachedサーバにアクセスが集中 なぜかパケットがドロップされはじめる ！！！！ 次のようなエラーメッセージが・・・・ orz ip_coontrack: maximum limit of 65535 entries exceeded

32. いいわけ memcachedサーバもグローバルIP接続可能なため、iptablesを動作させていた そのため/proc/net/ip_conntrackにパケット情報を記録 /proc/sys/net/ipv4/ip_conntrack_maxの上限に達してた・・・ ⇒ip_conntrack_maxを2,621,400へ引き上げ

33. ３か月後・・・トラブル再び

34. 「教授(※) ！ラック間のトラフィックが通常の3倍です！！！」 ※ 私のことです

35. 「105MBpsだと・・・・」

36. ラック間通信の帯域圧迫！

37. 「すいません、他にもラック間通信するアプリあるんですけど・・・」

38. memcachedサーバを追加、分散 トラフィックが特定のラックに集中するのを分散 他のアプリに影響がでるのを回避

39. 弊社トラブルの教訓 当たり前のことをちゃんとやろう Networkまわりのパラメータチューニング 特にiptablesを動かしているなら注意 特定のサーバに処理が集中するのはリスクだよね

40. 弊社おまけのトラブル

41. TokyoCabinet 64GBの壁事件 FlashデータのキャッシュとしてTokyoTyrant + TokyoCabinetを使用 データ量が日に日に増加 データ容量が64GBを超えたその日・・・・

42. 「教授(※) ！Flashのキャッシュ書き込みに失敗します！」 ※ 私のことです

43. TokyoCabinetのHDBTLARGEオプション 64bit環境で容量64GB以上のTokyoCabinetのデータファイルを扱うには「HDBTLARGE」オプションを指定する必要がある！ #opts=l

44. マニュアルよめ(ry

45. トラブルの教訓

46. 当たり前のことをちゃんとやろう 大事なことなので２回いいました

47. 最後にNoSQL的観点から弊社のキャッシュの考え方まとめ

48. NoSQLとDBのすみわけ DBは最終砦 ここがボトルネックにならないように色々な策を打つ とはいえDBもデータがメモリに乗る量なら高速なレスポンスを返す

49. NoSQLの出番は？ 最悪データがロストしてもいいところ セッションデータ トランザクションどうしよう あくまでキャッシュとして割り切ってつかう！ ロールバックできなくてもユーザが不利益を被らない処理に利用 ログイン判定のフラグ管理など 一番正しいデータはDB！

50. まとめ

51. まとめ ヒットするソーシャルアプリの規模は中～大規模といえる データ量を意識したサーバ構成、ネットワーク構成を memcachedといえど正しく設定、常に監視 設定値、オプションに注意 NoSQLは、弊社ではキャッシュに割り切って使用

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