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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「星空バータウン」アプリ状況 2010/07会員数「星空バータウン」アプリ状況 2010/07新規インストールユーザ推移「星空バータウン」サーバ構成　2011/05FW：2台LB：2台PROXY：5台Web：25台Flash合成：3台Cache：5台DB：9台

「星空バータウン」アプリ状況 2011/05会員数「星空バータウン」アプリ状況 2011/05新規インストールユーザ推移memcachedのおさらい引用元：「memcachedを知り尽くす » 第1回　memcachedの基本」http://gihyo.jp/dev/feature/01/memcached/0001

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

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

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

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

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

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

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

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

memcachedでトラブル発生

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

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

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

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

「105MBpsだと・・・・」

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

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

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

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

弊社おまけのトラブル

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

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

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

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

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

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

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

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

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

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

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

More Related Content

Viewers also liked

More from Suguru Shirai

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