gumiStudy#2の実践memcached見て来た

gumiという会社を今まで知らなかったのですが、memcached勉強会ということで見に行ってきました。
内容的には、memcachedの活用と運用 実践編:特集|gihyo.jp … 技術評論社と、この前のYokohama.pmでの内容という感じ。


懇親会ではgumiの方と話をして、面白そうな会社だなぁという印象でした。
社長に魅力がありそうだとそれだけで惹かれますね。


以下、発表内容とメモ。
資料と動画も公開されてます。

実践memcached - 株式会社ライブドア 開発部 システム管理グループ 長野雅広

自己紹介
  • @kazeburo
  • 5月までmixi
  • 6月からライブドア
  • 運用担当
    • Webサービスの運用/スケーラビリティ
今日話すmemcached
  1. 起動オプション
  2. 監視
今memcachedが熱い
熱いわけ
  • 8/10-12のmixi大規模障害
    • memcachedの異常終了
mixi大規模障害
  • 日本のCTO達による解析
  • togetterにまとめられてる
  • 原因究明・判明
    • 複数のI/FをListenしていて、接続数が指定した最大数に達し、接続切断を繰り返す際にスレッド間の排他制御に失敗する
      • コネクション数の計算が合わなくなって正常終了の形で落ちる。coreも吐かない
      • MLにもフィードバックされているが、あまり起きない現象だし直るのに時間がかかるかも
今できる対処方法
  • 大きく2つ
    • 最大接続数を増やす
    • ListenするI/Fを1つにする
  • これらの設定をするためには?
memcachedとは
  • 1回目のアクセスはDBへアクセス、それをmemcachedに入れておき、2回目のアクセスはmemcachedから取得することで高速にレスポンスを返す
    • DBだけじゃなくてWebAPIとかでも利用する
  • kumofsの古橋さんが作ったmemstrikeでのベンチマーク
    • そんなに大したマシンじゃなくても73,000qps出る
      • DBで出そうとすると大変
分散
  • アプリ側で分散アルゴリズムを使って分散する
    • memcachedサーバ側には分散の仕組みはない
  • 6GBメモリのサーバ2台と2GBメモリのサーバ6台の分散なら後者の方がいい
    • 1台落ちたとき、再起動をしたいときに影響が少ない
    • サーバが用意できないときはアプリケーションサーバに同居させてしまう
  • アプリケーションサーバと同居させた場合はアプリケーションのメモリ使用量の見極めが必要
    • (Min|Max)SpareServersは使わない
      • リクエストがあるときにメモリ使用量が変化したりしないように、全部値を同じに設定しておく
      • メモリの使用量を一目でわかるようにした方がいい
デメリット
チューニング
  • 基本的にやる必要はないと思うけど、
最大接続数を変更する:-c
  • デフォルトは1024(macだともっと少ない)
  • 変更にはroot権限が必要
    • ただし、memcachedはrootで起動できないのでオプションでユーザを指定する
      • -u nobodyなど
  • 実装はsetrlimit(2)だけなので大したことはしてない
  • 最大接続数 != Max FDS(ファイルディスクリプタ
    • Listen Socketなども含まれているため
  • 大きな数値を指定しても問題は起きない
I/Fの制限:-l
  • デフォルトはすべてのInterfaceでListen
    • ethだけではなくloもListenしてるので意識せずに2個以上のListen
  • 個人的には運用上不便なのでイマイチだなぁと思う
    • 192だけ有効にしてた場合などに、memcachedのサーバにsshでつないでlocalhostから調査したいときに不便
安定稼働に必須オプション

sudo ./memcached -c 262144 -u nobody

  • 最大コネクション数が十分に足りていればとりあえず障害は発生しない
  • コネクション数が不足して接続できないこと自体が問題
冗長モード:-v, -vv, -vvv
  • -vvvは1.4系から
ポート番号とUDP:-p, -U
  • -p:TCPのポート番号
  • -U:UDPのポート番号
  • 0を指定すると無効化される
    • 指定した値がもう片方の値でも有効になる
      • -U 0ならTCPもListenしない
      • -p 11211ならUDPも11211をListenする
メモリサイズ:-m
  • slabの仕様上、指定したメモリサイズを100%使用するのは難しい
  • プロセスのサイズは指定したサイズよりも大きくなる
    • 専用サーバでも80%くらいに抑えるのがよい
CASを無効にする:-C
  • CASを使ってる人いないですよね?
    • CASのための予約領域を作らない
  • 1アイテムに対して8Byteずつの節約
  • mixiの前坂さんのやった機能
お勧め起動オプション

./memcached -c 32768 -u nobody -C -m 16G -p 11211 -U 0

    • メモリはサーバに適した値で
    • mixiでもこういう設定をしていた
設定の確認
  • memcachedに繋いでstats settingsを発行すると見れる
    • (ただし、maxbytesが間違った値で出てくる)
監視の基本
  • 稼働監視(死活監視)
  • リソース監視
稼働監視(死活監視)
  • 一定間隔での監視で「例外」を発見し通知する
  • 「例外」の例
    • ping応答、TCPポートの接続不可
    • HTTPステータスが200じゃないとか
    • CPU使用率が90%以上のサーバリソースの使用状況
リソース監視
  • リソース使用状況などの変化を継続的に記録し、グラフにして「見える化
  • 様々なリソース
監視ツール
  • 稼働監視
  • リソース監視
    • Cacti
    • cloudforecast
      • 自分が作ってるツール
memcachedの監視
  • 何を監視するか?上の方が稼働監視、下の方がリソース監視
    • 動いているか
    • コネクション数は足りているか
    • メモリ使用率
    • Cache Hit率
    • memcahcedの動いているサーバの負荷(CPU、トラフィック
    • Get/Setなどの発行回数
    • サーバ間の偏り
      • あるサーバだけ重いなどのボトルネックが起こらないように
Nagiosによる稼働監視
  • インストールやCGIの設定など細かい話は
  • define commandで死活監視
    • -s 'stats\r\nquit\r\n'で繋がるかどうかだけでなく正常に動作しているかも確認
      • 改行を有効にするために-Eも指定が必要
      • -e 'uptime'を指定して、レスポンスにuptimeという文字列があるか確認
Nagios Pluginの作成
  • perlNagiosフレームワークとかあるけど、使わなくてもいいと思う
    • 重くなるだけなので
  • 単純なCUIコマンド
  • 標準プラグイン(例えばcheck_tcp)が置いてあるようなディレクトリ(/usr/local/nagios/libexec/)に置く
cloudforecastによるリソース監視
  • mixiのリソース監視項目を元に作成
    • execしまくるようなものだったので作り直した
  • 高速動作
  • 簡単なデプロイと設置
  • 小規模から大規模まで1つの設定で対応
    • 2台とか、tokuhiromは1台で使ってる
    • 1200台とかでもいける
      • 30秒くらいで全台舐められる
  • 詳しくはYAPC::Asia 2010
インストール
  • yumでnet-snmp、net-snmp-perlrrdtoolrrdtool-perlをインストール
    • yumじゃないと結構時間かかるかも
  • cloudforecastはgithubから
    • cpanmの--installdepsで依存モジュールもインストール
      • cpanm -l extlib --installdeps .
設定
  • サンプルをコピーすればとりあえず動くようになっている
    • cp cloudforecast_sample.yaml cloudforecast.yaml
  • 設定はyaml
    • ただし、正確なyamlではないのでyamlのパーサに食わせたらエラーになっちゃうけど
  • サーバが増えてもserver_list.yamlのhostsの項目にサーバを並べていくだけ
  • 監視項目の設定はhost_config/memcached.yaml
起動
  • Webサーバが付属されているのでcgiとかphpを用意する必要はない
  • デーモンでも起動できる
    • cloudforecast_radarで5分毎にリソースデータの取得を行う
グラフ
  • メモリ使用量グラフ
    • Maxは起動時に指定した値
    • どれくらいの時間でMaxに達するかを見た方がいい
      • 一瞬で達した場合はメモリ足りてないだろうなぁとか、数日経って達した場合にはまぁ問題ないとか
  • リクエスト数グラフ
    • SetとGetのそれぞれのリクエスト数
    • サーバ間のばらつきを調べるのに使う
  • Hit率グラフ
    • getを発行した際のHit率
    • アプリによりHit率は様々
      • 低いから問題とは限らない。セッションでmemcachedを使ってる場合は低かったりする
    • 定常状態を確認しておくのが重要
      • 上がったり下がったりしたら何か問題がある
  • 接続数グラフ(最近追加した機能)
    • 赤いラインが起動時に指定する最大接続数
    • 普段どのくらいかを確認
      • サーバを増やしたときに想定以上に増えてるか、足りているかを見る
その他statsでどんな情報が取れるか
  • stats slabs
    • chunk_size
    • incr、decr
  • stats items
    • evicted:expireする前にLRUで消された回数
  • 個人的にはstats調べて深く考えるよりはメモリを多く取っちゃえという感じ
まとめ
  • 稼働監視、リソースモニタリングにより最適な起動オプションの選択をする
  • 基本的にmemcachedは落ちたことがない
    • バグとか踏まない限りはあんまり経験ない

トークセッション

  • コネクション数3万件ってあり得るの?
  • chunk sizeのこだわりは何かある?
    • livedoorではセッションと他のデータを同居させるときにセッションが消えないようchunk sizeをいじっている
  • セッション管理用にmemcachedを使うときってどうやってる?
    • 個人的にはDBに格納して、前段にmemcachedがいいと思う
      • 気軽にmemcachedを再起動したいので、再起動でセッション消えちゃうとまずいな
  • なんでmixiからlivedoorへ転職?
    • mixiに4年間いて、その間にアクセスが10倍くらいに成長したが、やってることがmixiだけだった
      • 運用のやり方などが決まってしまっていたので、エンジニアとしての成長のためにもっと色々なサービスの運用をやってみたいと思った
  • cloudforecastは商用でも可?
    • はい。全然問題ないです
  • memcachedを利用していてキャッシュアクセスに対するトラフィックの偏りが原因でトラブルになったことはなかった?
    • すべてのページに同じお知らせを出す場合、memcachedの決まったサーバに保存されるので、すべてのページが1台のmemcachedにアクセスしてしまう
    • keyに数字を負荷してデータを分散させた方がいい。詳しくは技評のページ
  • statsのリセットは?
    • できるけどしたことない
  • statsにはどんなのがあるか?
    • ソースのdoc/protocol.txtに書いてあったりソースコード読むとわかる
  • ナジオス?ナギオス?
    • ナジオスって読んでます
  • 分散アルゴリズム
    • 剰余
    • Consistent-Hashing
  • サーバってそんなに増やすの?
    • 増やすときより壊れたりで外すことがある
  • UDP使うの?
  • memcached以外のkvsは?
  • スケールアウトが難しいけどどうしたらいい?
    • スケールアウトよりもスケールアップで性能を稼ぐ方がいい
      • tokyo tyrantはgetだけなら数万qpsいくのでそれで済まないのはなかなかないかなぁと