memcachedとトラブルとソーシャルアプリ

14,641 views
14,376 views

Published on

CyberX NoSQL semi 発表資料

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

No Downloads
Views
Total views
14,641
On SlideShare
0
From Embeds
0
Number of Embeds
2,210
Actions
Shares
0
Downloads
49
Comments
0
Likes
18
Embeds 0
No embeds

No notes for slide

memcachedとトラブルとソーシャルアプリ

  1. 1. ソーシャルメディア、<br />ソーシャルアプリが育てたNoSQL技術<br />2011/05/17<br />
  2. 2. 初めにすこしだけ<br />本セミナーは3月15日から延期になりましたが<br />本日開催できたことに感謝します<br />私は仙台に住んでいます<br />幸い震災時は東京にいたため、無事でした<br />家内が仙台の自宅にいましたが、家内も無事で、自宅の被害は少なかったです<br />しかし震災の爪痕は今なお残っています<br />復興への近道は日本経済が元気になることと思っています<br />今日お集まりいただいた皆様とともに<br />日本経済を盛り上げていければと思います<br />
  3. 3. お前、誰よ<br />株式会社 CyberX<br />取締役兼CTO<br />白井 英(しらい すぐる)<br />PHP/JavaScriptがわりと好き<br />仕事はインフラまわりから<br />PHP/ActionScript3が多い<br />携帯のソーシャルアプリ黎明期から開発従事<br />Twitter: @goodoo<br />Blog: http://ameblo.jp/goodoo<br />
  4. 4. ソーシャルアプリといえば?<br />
  5. 5. プラットフォーマーでは<br />DeNAさん<br />GREEさん<br />Mixiさん<br />
  6. 6. memcachedといえば?<br />
  7. 7. Mixiさんの運用事例が有名ですね<br />
  8. 8. 今日お話しするのはそこまで大規模な話ではありません<br />
  9. 9. でも、よく陥りがちな話をしたいと思います<br />
  10. 10. CyberXでは携帯のソーシャルアプリを作っています<br />代表的アプリ「星空バータウン」(mixiモバイル)<br />
  11. 11. 「星空バータウン」のmemcachedを切り口とした運用事例・トラブル事例の話をします<br />
  12. 12. Agenda<br />規模の話<br />弊社アプリのサーバ構成<br />memcachedのおさらい<br />弊社CyberXの運用事例<br />弊社CyberXのトラブル事例<br />キャッシュの考え方<br />
  13. 13. 規模<br />超大規模(Google/Facebookクラス)<br />Google<br />サーバ台数100万台以上<br />Facebook<br />サーバ台数6万台以上<br />大規模(プラットフォーマクラス)<br />DeNA、Gree、Mixi<br />サーバ台数数千台<br />数十~数百億PV/Day<br />
  14. 14. 「星空バータウン」の規模(1アプリ)<br />ユーザ数約200万人<br />約10億PV/Month<br />75万(MonthlyActiveUser)<br />ピーク時のトラフィック200Mbps<br />サーバ台数 約50台<br />参考【引用元:大規模サービス技術入門】より<br />2009年のはてなのサービス<br />ユーザ数100万人以上<br />数十億PV/month<br />ピーク時のトラフィック430Mbps<br />サーバ台数 500台以上<br />
  15. 15. ヒットするソーシャルアプリは2009年当時のはてなに近いインフラ技術が必要<br />
  16. 16. 「星空バータウン」サーバ構成 2010/07<br />Web:30台<br />Flash合成:3台<br />Cache:1台<br />DB:4台<br />
  17. 17. 「星空バータウン」アプリ状況 2010/07<br /><ul><li>会員数</li></li></ul><li>「星空バータウン」アプリ状況 2010/07<br /><ul><li>新規インストールユーザ推移</li></li></ul><li>「星空バータウン」サーバ構成 2011/05<br />FW:2台<br />LB:2台<br />PROXY:5台<br />Web:25台<br />Flash合成:3台<br />Cache:5台<br />DB:9台<br />
  18. 18. 「星空バータウン」アプリ状況 2011/05<br /><ul><li>会員数</li></li></ul><li>「星空バータウン」アプリ状況 2011/05<br /><ul><li>新規インストールユーザ推移</li></li></ul><li>memcachedのおさらい<br />引用元:「memcachedを知り尽くす » 第1回 memcachedの基本」<br />http://gihyo.jp/dev/feature/01/memcached/0001<br />
  19. 19. memcachedの特徴<br />シンプルなプロトコル<br />基本 Get、Set<br />内蔵のオンメモリストレージ<br />速い、軽い<br />LRU(Least Recently Used)<br />手軽<br />
  20. 20. 「星空バータウン」の運用事例<br />CyberXのソーシャルアプリはPHPで構築<br />CakePHPにて実装<br />PHPのセッション共有にmemcachedを使用<br />実はPHPのファイルでのセッション管理よりmemcachedのセッション管理のほうが負荷が低い<br /> ⇒ FileI/O > memory R/W<br />
  21. 21. え?これじゃないの?<br />引用元:「memcachedを知り尽くす » 第1回 memcachedの基本」<br />http://gihyo.jp/dev/feature/01/memcached/0001<br />
  22. 22. 「星空バータウン」の運用事例<br />DBのデータを見に行ってもデータがDBサーバのメモリに乗っているのであれば、十分なレスポンスを返す<br />innodbは思ったより早い<br />memcachedにSQLの結果をキャッシュさせた別アプリもあるがさほどメリットがなかった<br />むしろmemcachedとして管理するサーバの台数が増え管理コストは増大<br />
  23. 23. memcachedのトラブル<br />
  24. 24. といえば<br />
  25. 25. 2010/08/10mixi大規模障害<br />
  26. 26. mixi大規模障害おさらい<br />memcachedの接続限界数に達した時に発生する不具合<br />接続限界数に達したのちクライアントの切断処理後、新規接続を受け付ける時に、排他制御が崩れる瞬間あり<br />memcachedが落ちる<br />詳しくは、mixiさんのengineers_blogを参照<br />http://alpha.mixi.co.jp/blog/?p=2211<br />
  27. 27. mixi大規模障害の教訓<br />memcachedを運用する場合には -c による接続数の制限はできるだけ大きくする<br />もちろん、CPU/Load/Memory/<br />  cache hit/response timeなどをきちんと監視<br />
  28. 28. いっぽうその頃弊社では・・・・<br />
  29. 29. 「教授(※)!    セッションデータがドロップされています!!!」<br />※ 私のことです<br />
  30. 30. memcachedでトラブル発生<br />
  31. 31. 「星空バータウン」ちょっと恥かしいトラブル事例<br />セッション管理用のmemcachedサーバにアクセスが集中<br />なぜかパケットがドロップされはじめる<br />!!!!<br />次のようなエラーメッセージが・・・・<br />orz<br />ip_coontrack: maximum limit of 65535 entries exceeded<br />
  32. 32. いいわけ<br />memcachedサーバもグローバルIP接続可能なため、iptablesを動作させていた<br />そのため/proc/net/ip_conntrackにパケット情報を記録<br />/proc/sys/net/ipv4/ip_conntrack_maxの上限に達してた・・・<br /> ⇒ip_conntrack_maxを2,621,400へ引き上げ<br />
  33. 33. 3か月後・・・トラブル再び<br />
  34. 34. 「教授(※) !ラック間のトラフィックが通常の3倍です!!!」<br />※ 私のことです<br />
  35. 35. 「105MBpsだと・・・・」<br />
  36. 36. ラック間通信の帯域圧迫!<br />
  37. 37. 「すいません、他にもラック間通信するアプリあるんですけど・・・」<br />
  38. 38. memcachedサーバを追加、分散<br />トラフィックが特定のラックに集中するのを分散<br />他のアプリに影響がでるのを回避<br />
  39. 39. 弊社トラブルの教訓<br />当たり前のことをちゃんとやろう<br />Networkまわりのパラメータチューニング<br />特にiptablesを動かしているなら注意<br />特定のサーバに処理が集中するのはリスクだよね<br />
  40. 40. 弊社おまけのトラブル<br />
  41. 41. TokyoCabinet 64GBの壁事件<br />FlashデータのキャッシュとしてTokyoTyrant + TokyoCabinetを使用<br />データ量が日に日に増加<br />データ容量が64GBを超えたその日・・・・<br />
  42. 42. 「教授(※) !Flashのキャッシュ書き込みに失敗します!」<br />※ 私のことです<br />
  43. 43. TokyoCabinetのHDBTLARGEオプション<br />64bit環境で容量64GB以上のTokyoCabinetのデータファイルを扱うには「HDBTLARGE」オプションを指定する必要がある!<br />#opts=l<br />
  44. 44. マニュアルよめ(ry<br />
  45. 45. トラブルの教訓<br />
  46. 46. 当たり前のことをちゃんとやろう<br />大事なことなので2回いいました<br />
  47. 47. 最後にNoSQL的観点から弊社のキャッシュの考え方まとめ<br />
  48. 48. NoSQLとDBのすみわけ<br />DBは最終砦<br />ここがボトルネックにならないように色々な策を打つ<br />とはいえDBもデータがメモリに乗る量なら高速なレスポンスを返す<br />
  49. 49. NoSQLの出番は?<br />最悪データがロストしてもいいところ<br />セッションデータ<br />トランザクションどうしよう<br />あくまでキャッシュとして割り切ってつかう!<br />ロールバックできなくてもユーザが不利益を被らない処理に利用<br />ログイン判定のフラグ管理など<br />一番正しいデータはDB!<br />
  50. 50. まとめ<br />
  51. 51. まとめ<br />ヒットするソーシャルアプリの規模は中~大規模といえる<br />データ量を意識したサーバ構成、ネットワーク構成を<br />memcachedといえど正しく設定、常に監視<br />設定値、オプションに注意<br />NoSQLは、弊社ではキャッシュに割り切って使用<br />
  52. 52. ご清聴ありがとうございました<br />

×