memcachedとトラブルとソーシャルアプリ
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 12,876 views

CyberX NoSQL semi 発表資料

CyberX NoSQL semi 発表資料

Statistics

Views

Total Views
12,876
Views on SlideShare
11,036
Embed Views
1,840

Actions

Likes
15
Downloads
43
Comments
0

12 Embeds 1,840

http://d.hatena.ne.jp 1762
http://webcache.googleusercontent.com 43
http://infra.rrdtool.net 14
http://hatenatunnel.appspot.com 8
http://s.deeeki.com 4
https://twimg0-a.akamaihd.net 3
http://cache.yahoofs.jp 1
http://slide.yoshiday.net 1
http://timprx.appspot.com 1
http://freeandroidgames.appspot.com 1
http://gaeforyou.appspot.com 1
http://slideshare-download.seesaa.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • ソーシャルメディア、
    ソーシャルアプリが育てたNoSQL技術
    2011/05/17
  • 初めにすこしだけ
    本セミナーは3月15日から延期になりましたが
    本日開催できたことに感謝します
    私は仙台に住んでいます
    幸い震災時は東京にいたため、無事でした
    家内が仙台の自宅にいましたが、家内も無事で、自宅の被害は少なかったです
    しかし震災の爪痕は今なお残っています
    復興への近道は日本経済が元気になることと思っています
    今日お集まりいただいた皆様とともに
    日本経済を盛り上げていければと思います
  • お前、誰よ
    株式会社 CyberX
    取締役兼CTO
    白井 英(しらい すぐる)
    PHP/JavaScriptがわりと好き
    仕事はインフラまわりから
    PHP/ActionScript3が多い
    携帯のソーシャルアプリ黎明期から開発従事
    Twitter: @goodoo
    Blog: http://ameblo.jp/goodoo
  • ソーシャルアプリといえば?
  • プラットフォーマーでは
    DeNAさん
    GREEさん
    Mixiさん
  • memcachedといえば?
  • Mixiさんの運用事例が有名ですね
  • 今日お話しするのはそこまで大規模な話ではありません
  • でも、よく陥りがちな話をしたいと思います
  • CyberXでは携帯のソーシャルアプリを作っています
    代表的アプリ「星空バータウン」(mixiモバイル)
  • 「星空バータウン」のmemcachedを切り口とした運用事例・トラブル事例の話をします
  • Agenda
    規模の話
    弊社アプリのサーバ構成
    memcachedのおさらい
    弊社CyberXの運用事例
    弊社CyberXのトラブル事例
    キャッシュの考え方
  • 規模
    超大規模(Google/Facebookクラス)
    Google
    サーバ台数100万台以上
    Facebook
    サーバ台数6万台以上
    大規模(プラットフォーマクラス)
    DeNA、Gree、Mixi
    サーバ台数数千台
    数十~数百億PV/Day
  • 「星空バータウン」の規模(1アプリ)
    ユーザ数約200万人
    約10億PV/Month
    75万(MonthlyActiveUser)
    ピーク時のトラフィック200Mbps
    サーバ台数 約50台
    参考【引用元:大規模サービス技術入門】より
    2009年のはてなのサービス
    ユーザ数100万人以上
    数十億PV/month
    ピーク時のトラフィック430Mbps
    サーバ台数 500台以上
  • ヒットするソーシャルアプリは2009年当時のはてなに近いインフラ技術が必要
  • 「星空バータウン」サーバ構成 2010/07
    Web:30台
    Flash合成:3台
    Cache:1台
    DB:4台
  • 「星空バータウン」アプリ状況 2010/07
    • 会員数
  • 「星空バータウン」アプリ状況 2010/07
    • 新規インストールユーザ推移
  • 「星空バータウン」サーバ構成 2011/05
    FW: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として管理するサーバの台数が増え管理コストは増大
  • memcachedのトラブル
  • といえば
  • 2010/08/10mixi大規模障害
  • 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サーバにアクセスが集中
    なぜかパケットがドロップされはじめる
    !!!!
    次のようなエラーメッセージが・・・・
    orz
    ip_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か月後・・・トラブル再び
  • 「教授(※) !ラック間のトラフィックが通常の3倍です!!!」
    ※ 私のことです
  • 「105MBpsだと・・・・」
  • ラック間通信の帯域圧迫!
  • 「すいません、他にもラック間通信するアプリあるんですけど・・・」
  • memcachedサーバを追加、分散
    トラフィックが特定のラックに集中するのを分散
    他のアプリに影響がでるのを回避
  • 弊社トラブルの教訓
    当たり前のことをちゃんとやろう
    Networkまわりのパラメータチューニング
    特にiptablesを動かしているなら注意
    特定のサーバに処理が集中するのはリスクだよね
  • 弊社おまけのトラブル
  • TokyoCabinet 64GBの壁事件
    FlashデータのキャッシュとしてTokyoTyrant + TokyoCabinetを使用
    データ量が日に日に増加
    データ容量が64GBを超えたその日・・・・
  • 「教授(※) !Flashのキャッシュ書き込みに失敗します!」
    ※ 私のことです
  • TokyoCabinetのHDBTLARGEオプション
    64bit環境で容量64GB以上のTokyoCabinetのデータファイルを扱うには「HDBTLARGE」オプションを指定する必要がある!
    #opts=l
  • マニュアルよめ(ry
  • トラブルの教訓
  • 当たり前のことをちゃんとやろう
    大事なことなので2回いいました
  • 最後にNoSQL的観点から弊社のキャッシュの考え方まとめ
  • NoSQLとDBのすみわけ
    DBは最終砦
    ここがボトルネックにならないように色々な策を打つ
    とはいえDBもデータがメモリに乗る量なら高速なレスポンスを返す
  • NoSQLの出番は?
    最悪データがロストしてもいいところ
    セッションデータ
    トランザクションどうしよう
    あくまでキャッシュとして割り切ってつかう!
    ロールバックできなくてもユーザが不利益を被らない処理に利用
    ログイン判定のフラグ管理など
    一番正しいデータはDB!
  • まとめ
  • まとめ
    ヒットするソーシャルアプリの規模は中~大規模といえる
    データ量を意識したサーバ構成、ネットワーク構成を
    memcachedといえど正しく設定、常に監視
    設定値、オプションに注意
    NoSQLは、弊社ではキャッシュに割り切って使用
  • ご清聴ありがとうございました