gumiStudy#2の実践memcached見て来た
gumiという会社を今まで知らなかったのですが、memcached勉強会ということで見に行ってきました。
内容的には、memcachedの活用と運用 実践編:特集|gihyo.jp … 技術評論社と、この前のYokohama.pmでの内容という感じ。
懇親会ではgumiの方と話をして、面白そうな会社だなぁという印象でした。
社長に魅力がありそうだとそれだけで惹かれますね。
以下、発表内容とメモ。
資料と動画も公開されてます。
- kazeburoさんの資料
- 動画
- Ustream.tv: ユーザー gumilab: gumilab 09/14/10 03:31AM, gumilab 09/14/10 03:31AM. コンピュータ
- Ustream.tv: ユーザー gumilab: gumilab 09/14/10 04:33AM, gumilab 09/14/10 04:33AM. コンピュータ
- Ustream.tv: ユーザー gumilab: gumilab 09/14/10 04:43AM, gumilab 09/14/10 04:43AM. コンピュータ
- Ustream.tv: ユーザー gumilab: gumilab 09/14/10 04:52AM, gumilab 09/14/10 04:52AM. コンピュータ
- Ustream.tv: ユーザー gumilab: gumilab 09/14/10 04:56AM, gumilab 09/14/10 04:56AM. コンピュータ
- Ustream.tv: ユーザー gumilab: gumistudy #2 後半, Recorded on 10/09/14. コンピュータ
実践memcached - 株式会社ライブドア 開発部 システム管理グループ 長野雅広
今日話すmemcached
- 起動オプション
- 監視
今memcachedが熱い
- 技術評論社Web連載
- Shibuya.pmでも話す
熱いわけ
- 8/10-12のmixi大規模障害
- memcachedの異常終了
mixi大規模障害
- 日本のCTO達による解析
- togetterにまとめられてる
- 原因究明・判明
- 複数のI/FをListenしていて、接続数が指定した最大数に達し、接続切断を繰り返す際にスレッド間の排他制御に失敗する
- コネクション数の計算が合わなくなって正常終了の形で落ちる。coreも吐かない
- MLにもフィードバックされているが、あまり起きない現象だし直るのに時間がかかるかも
- 複数のI/FをListenしていて、接続数が指定した最大数に達し、接続切断を繰り返す際にスレッド間の排他制御に失敗する
今できる対処方法
- 大きく2つ
- 最大接続数を増やす
- ListenするI/Fを1つにする
- これらの設定をするためには?
memcachedとは
- 1回目のアクセスはDBへアクセス、それをmemcachedに入れておき、2回目のアクセスはmemcachedから取得することで高速にレスポンスを返す
- DBだけじゃなくてWebAPIとかでも利用する
- kumofsの古橋さんが作ったmemstrikeでのベンチマーク
- そんなに大したマシンじゃなくても73,000qps出る
- DBで出そうとすると大変
- そんなに大したマシンじゃなくても73,000qps出る
分散
- アプリ側で分散アルゴリズムを使って分散する
- memcachedサーバ側には分散の仕組みはない
- 6GBメモリのサーバ2台と2GBメモリのサーバ6台の分散なら後者の方がいい
- 1台落ちたとき、再起動をしたいときに影響が少ない
- サーバが用意できないときはアプリケーションサーバに同居させてしまう
- アプリケーションサーバと同居させた場合はアプリケーションのメモリ使用量の見極めが必要
- (Min|Max)SpareServersは使わない
- リクエストがあるときにメモリ使用量が変化したりしないように、全部値を同じに設定しておく
- メモリの使用量を一目でわかるようにした方がいい
- (Min|Max)SpareServersは使わない
デメリット
- アプリケーションサーバのTCP接続数が増える
- memcachedサーバ数 + アプリケーションプロセス数
チューニング
- 基本的にやる必要はないと思うけど、
- アプリケーションサーバのip_local_port_rangeの拡張
- memcachedサーバのtcp_max_tw_packetsの調整
最大接続数を変更する:-c
I/Fの制限:-l
安定稼働に必須オプション
sudo ./memcached -c 262144 -u nobody
- 最大コネクション数が十分に足りていればとりあえず障害は発生しない
- コネクション数が不足して接続できないこと自体が問題
冗長モード:-v, -vv, -vvv
- -vvvは1.4系から
ポート番号とUDP:-p, -U
メモリサイズ:-m
- slabの仕様上、指定したメモリサイズを100%使用するのは難しい
- プロセスのサイズは指定したサイズよりも大きくなる
- 専用サーバでも80%くらいに抑えるのがよい
CASを無効にする:-C
- CASを使ってる人いないですよね?
- CASのための予約領域を作らない
- 1アイテムに対して8Byteずつの節約
- mixiの前坂さんのやった機能
設定の確認
- memcachedに繋いでstats settingsを発行すると見れる
- (ただし、maxbytesが間違った値で出てくる)
監視の基本
- 稼働監視(死活監視)
- リソース監視
稼働監視(死活監視)
- 一定間隔での監視で「例外」を発見し通知する
- 「例外」の例
- ping応答、TCPポートの接続不可
- HTTPステータスが200じゃないとか
- CPU使用率が90%以上のサーバリソースの使用状況
リソース監視
memcachedの監視
- 何を監視するか?上の方が稼働監視、下の方がリソース監視
- 動いているか
- コネクション数は足りているか
- メモリ使用率
- Cache Hit率
- memcahcedの動いているサーバの負荷(CPU、トラフィック)
- Get/Setなどの発行回数
- サーバ間の偏り
- あるサーバだけ重いなどのボトルネックが起こらないように
Nagiosによる稼働監視
- インストールやCGIの設定など細かい話は
- WEB+DB PRESS vol.55に書いた
- 大規模サービス技術入門とかにも
- define commandで死活監視
Nagios Pluginの作成
cloudforecastによるリソース監視
インストール
設定
起動
- 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万件ってあり得るの?
- アプリケーションサーバのプロセス数が60で、それが500台あればあり得るかなぁと
- chunk sizeのこだわりは何かある?
- livedoorではセッションと他のデータを同居させるときにセッションが消えないようchunk sizeをいじっている
- セッション管理用にmemcachedを使うときってどうやってる?
- 個人的にはDBに格納して、前段にmemcachedがいいと思う
- 気軽にmemcachedを再起動したいので、再起動でセッション消えちゃうとまずいな
- 個人的にはDBに格納して、前段にmemcachedがいいと思う
- なんでmixiからlivedoorへ転職?
- cloudforecastは商用でも可?
- はい。全然問題ないです
- memcachedを利用していてキャッシュアクセスに対するトラフィックの偏りが原因でトラブルになったことはなかった?
- すべてのページに同じお知らせを出す場合、memcachedの決まったサーバに保存されるので、すべてのページが1台のmemcachedにアクセスしてしまう
- keyに数字を負荷してデータを分散させた方がいい。詳しくは技評のページへ
- statsのリセットは?
- できるけどしたことない
- statsにはどんなのがあるか?
- ソースのdoc/protocol.txtに書いてあったりソースコード読むとわかる
- ナジオス?ナギオス?
- ナジオスって読んでます
- 分散アルゴリズム
- 剰余
- Consistent-Hashing
- サーバってそんなに増やすの?
- 増やすときより壊れたりで外すことがある
- UDP使うの?
- memcached以外のkvsは?
- mixiではtokyo tyrant
- livedoorでも使ってるサービスはある
- mixiではtokyo tyrant
- スケールアウトが難しいけどどうしたらいい?
- スケールアウトよりもスケールアップで性能を稼ぐ方がいい
- tokyo tyrantはgetだけなら数万qpsいくのでそれで済まないのはなかなかないかなぁと
- スケールアウトよりもスケールアップで性能を稼ぐ方がいい