皆様こんにちは。
ソーシャルアプリ事業部でシステム周りの仕事をしております、ムックです。
早速ですが、タイトルにもあるサーバ監視についてです。
サーバ監視と言えば下記のように分類出来ます。
- nagios、monitなどのプロセス監視
- cacti、munin、zabbixなどのリソース監視
弊社でもいくつかサーバ監視ソフトウェアを利用していますが、今回はリソース監視にスポットを当ててお話したいと思います。
リソース監視の導入メリット
- インシデントを未然に気づけることがある
- トラブルシューティング時の解決糸口
- 負荷の少ないプログラムを意識するようになる
今日は、弊社で運用しているとあるソーシャルゲームサービスのmunin監視グラフ(と一言コメント)をお見せ致します。
環境
- 1アプリサーバあたりの日PV数は約70万
- 構成は、LB、WebApp(Apache)、DB(MySQL)、cacheとよくあるサーバ構成
- サーバスペックは用途によってまちまち
それでは、muninで出力されるグラフになります！
[web]Apache accesses
縦軸：アクセス/秒
一発目はWebサーバのApacheの一秒あたりのアクセス数になります。
静的ファイルを返すサーバなので、これだけのアクセスがあってもLoadAverageはほぼ0です。
ピーク時は400アクセス/秒くらい行くこともあります。
[app]Apache processes
縦軸：プロセス(数)
緑が処理中のプロセス数
青が処理待ち(アイドル中)のプロセス数
緑の横ラインが閾値
黒の横ラインがmaxClients
お次はphpを処理するアプリサーバになります。
ちょっとmaxClientsが多めでしょうか。
[web]eth0 traffic
縦軸：bits/秒(一秒あたりのbit通信量) 上がout、下がinになります。
コンテンツを返すサーバなので基本的にoutの方が多いです。
特に気にすることはなさそうです。
[app]APC cache size
縦軸：キャッシュバイト数(MB) 
アプリサーバのAPCキャッシュサイズになります。
正常にキャッシュが使われているか見る程度です。
以前キャッシュが上手く利用されず負荷が急激に高まるということもありました。
[db]mysql queries
縦軸：クエリ/秒(一秒あたりのクエリ数)
緑がselect、藍色がcache_hit、橙がupdateクエリになります。 
この程度であれば、CPU負荷もなくまだまださばけます。
update文が随分多いですね(汗)
イベント次第では、倍くらいのクエリ数になったりします。
[app]CPU usage
縦軸：使用率(%)
各CPU使用率の合算になります。
上限が400%というところから4コアCPUということがわかります。
また、ピークでも100％なので平均各CPU25％くらいしか使っていません。
かなりのバッファがありますが特定イベント時には負荷がグッと上がります。
まとめ
また今回は紹介出来ませんでしたが、 memcacheのcommand数やcontext switch、diskIOなどをサーバ監視しています。
かなりバッファを持った値に見えますが、特定のイベントやイベント初日などは急激に負荷があがります。
こういった複雑なシステムや流動的なユーザがソーシャルアプリ運用の特徴と言えると思います。
あまり時間をかけるものではありませんが、頻繁にグラフを眺めているとDAUの増減、機能リリースによる負荷などに気づきます。
そういったサービスの状態を把握、成長を眺めることが出来るところは、運用のひとつの楽しみであると思います。
最後に
上記以外のリソースも蓄積していますが、自分自身まだまだ活用しきれていない情報がたくさんありまだまだ勉強不足です。
グラフの意味を理解し、サービスの安定化、新規機能開発に活かしていきたいと思います。
