安定したWebサービスを提供するためには欠かすことができないのが監視です。監視を行うことで障害をいち早く検知し、対応を行うことでダウンタイムを最小限にできます。また負荷の掛かり具合やサーバリソースの消費度合いを明らかにすることでいつ、どのタイミングでサーバやインフラを増強するか、またアプリケーションの改善を行うのかを判断できます。Webサービスの稼働やリソースの「見える化」を実現することで、個人の経験や勘、また根性だけに頼らない運用が可能となり、より的確なタイミングでのシステムの改善、増強を行えます。
稼働監視とリソースモニタリング
Webサービスのシステムの監視には大きく分けて2種類の監視があります。1つ目は稼働監視、2つ目はリソースのモニタリングです。稼働監視では監視を行ったタイミングで対象システムに例外があれば、メールを送信するなどのアラートを発生させます。稼働監視に於ける例外とは、対象サーバからのping応答が得られなかったり、指定したポートに対して接続ができない、また一定の時間以内でのレスポンスが帰ってこない場合などが挙げられます。加えてサーバのリソース(CPU使用率やDISK使用量)が設定した閾値を超えている場合も含まれます。
稼働監視は監視を行った瞬間の「見える化」を行いますが、リソースモニタリングは継続的にシステムのリソースに関するデータを取得し、グラフなどの形で変化を可視化します。リソースモニタリングの対象としては、CPU使用率やメモリ使用量、Webサーバのリクエスト処理回数、データベースのトランザクション数などがあげれます。
memcachedの監視も稼働監視とリソースモニタリングの両面から行う必要があります。
memcachedの稼働監視
memcachedの稼働監視としてNagiosを利用した監視を紹介します。Nagiosはオープンソースの稼働監視ソフトウェアとして最も有名なソフトウェアで、国内でもミクシィをはじめ豊富な利用実績があります。Nagiosのインストールや基本的な設定については、筆者が以前に執筆させて頂いた『WEB+DB PRESS Vol.55』の連載「大規模Webサービスの裏側」や書籍『サーバ/インフラを支える技術』を参考にしてください。
- 『WEB+DB PRESS Vol.55』
- http://gihyo.jp/magazine/wdpress/archive/2010/vol55
- 『サーバ/インフラを支える技術』
- http://gihyo.jp/book/2008/978-4-7741-3566-3
接続と動作の監視
memcachedの稼働監視として真っ先にあげられるのが、memcachedが起動しているかどうかの死活監視ではないでしょうか。最も簡単な死活監視の方法はmemcachedがListenしているポートに接続ができるかどうかを確認することです。
上記の監視コマンド設定を利用すると、Nagiosは5秒以内に監視対象サーバの11211ポートに接続できなかった場合に障害が発生したと認識します。この設定を使用するには、ホスト設定、サービス設定を次のように行います。
IPアドレス「192.168.67.30」のサーバに対して、memcachedのサービスを定義し、(1)でコマンドを指定しています。
この設定のみで死活監視を行うことができますが、接続ができたということだけでmemcachedが正常に動作しているとは断定できません、そこで動作確認のためにstatsコマンドを送って、レスポンスが得られるかを死活監視に追加します。
(1)でサーバに対して送るコマンドを指定します。ここではstatsコマンドと接続を切るためのquitコマンドを指定しています。コマンドにて改行コードを利用するためには、(2)の「-E」オプションも追加する必要があります。(3)はレスポンスに含まれる文字列で、ここではmemcachedの統計にuptime(起動してからの経過時間)が含まれている事で、statsコマンドが正常に動作したかを確認します。statsコマンドの結果のサンプルのこの記事の2ページ目にあります。
さらにNagiosの監視プラグインを作成することで、memcachedに対してgetやsetといったキャッシュオブジェクトを操作するコマンドを実行して、実際にアプリケーションから利用する場合に即した稼働監視を行うこともできます。前述した「WEB+DB PRESS Vol.55」の連載「大規模Webサービスの裏側」にて、サーバに対してget、set、addを行う監視プラグインを紹介しています。また、ひろせまさあき氏作成の監視プラグイン「check_memcached_paranoid」でも同様の監視が可能です。
- check_memcached_paranoid
- http://d.hatena.ne.jp/hirose31/20100118/1263810212
コネクション数の監視
memcachedがListenするポートに対して接続をする死活監視、またコマンドに対して正常なレスポンスを返せるかを検証する監視の他にmemcachedにはもうひとつ重要だと思われる監視があります。
先日(2010年8月)のmixiの大規模障害は、memcachedの異常終了が引き金となったと発表されています。その後の解析により起動時に指定した最大接続数を超えた際に起きるmemcachedの不具合であることが確認されています。不具合の修正についてはmemcachedの開発コミュニティで議論がされています。
障害の有無に関わらず最大接続数に達することでクライアントがmemcachedに接続できなくなり、データベースの負荷が上昇したり、キャッシュオブジェクトの不整合が起きることはサービス上問題となります。障害を回避しつつmemcachedを安定稼働させるためは、同時接続数の設定を多めに変更したり、memcachedに対する接続数の監視を行い適切な接続数を維持することが必要となります。
以下は現在のコネクション数が最大同時コネクション数に対して、指定した割合よりも大きい場合に例外とするNagiosプラグインと設定例です。
上記の設定では、最大同時コネクション数に対しての現在の接続数の割合が85%を超えるとWARNINGとなり、90%を超えるとCRTICALステータスとなり、Nagiosは障害が発生していると認識します。
CloudForecastによるリソースモニタリング
ここまでmemcachedの稼働監視として、接続やコマンドに対するレスポンスの監視、接続数の監視について紹介しました。次は拙作のリソースモニタリングツールであるCloudForecastを利用したmemcachedのリソース監視について説明します。
CloudForecastとは
CloudForecastとは、筆者が開発しているリソースモニタリングのためのツールです。ミクシィで利用していた監視ツールの項目などを参考にして作られ、SNMPやHTTP等を経由して取得したリソースデータをRRDToolを通してグラフ化する機能を持っています。Perlを用いて開発されており、高速かつ拡張が容易でサーバ数台の小規模な環境から1000台以上の大規模な環境でも1つの設定で監視ができるよう設計されています。同じ目的のソフトウェアとしては、MRTGやCacti、Muninなどがあります。
- RRDTool
- http://oss.oetiker.ch/rrdtool/
CloudForecastのインストール
CloudForecastはSNMPとRRDToolを使用しています。RRDToolはCentOSの場合、EPELを利用すると導入が簡単に行えます。
- EPEL
- http://fedoraproject.org/wiki/EPEL
RRDToolやSNMPのPerlのモジュールも必要となるため同時にインストールします。CloudForecastのソースコードはgithubから取得できます。また、CloudForecastはいくつかのCPANモジュールに依存していますが、それらの依存モジュールはcpanmを利用すると簡単にインストールできます。
- cpanm
- http://search.cpan.org/dist/App-cpanminus/
memcachedサーバの登録
memcachedサーバをモニタリングするための設定を紹介します。まず、設定ファイルをsampleからコピーして作成します。
次にサーバ一覧ファイルをserver_list.yamlというファイル名で作成します。server_list.yamlの内容は以下のようにします。
(1)はCloudForecastのWeb画面でサーバ一覧を区切るラベルとなります。ここではMemcachedとしました。(2)でこれから作成する監視項目の設定ファイル名を指定します。(3)では監視対象となるサーバを追加します。サーバの指定は半角スペース区切りで、IPアドレス、ホスト名、コメントの順に書いていきます。コメント欄はサーバの利用方法などのメモとして利用できます。
(2)で指定した監視項目の設定ファイルは、host_configディレクトリ内に作成します。
resourcesにモニタリングするリソースを追加します。ここではeth1インターフェースの通信量(traffic)、CPU使用率メモリ使用量などを1つにまとめたリソース(basic)、そしてmemcachedを対象に含めています。
ここまで設定が完了したら、CloudForecastを起動します。Webインターフェースのデーモンとリソースデータを巡回取得するデーモンの2つを起動します。
起動後ブラウザで「http://cloudforcastを起動したサーバ:5000/」にリクエストすると次のようなページが表示されます。より詳しいCloudForecastの使用方法については順次筆者のblogなどで公開していくことを考えています。
グラフ解説
CloudForecastによるmemcachedのリソースモニタリングは、CloudForecastの巡回デーモンから直接memcachedに接続を行い、「stats」コマンドや「stats settings」コマンドを発行して行っています。以下はstatsコマンドの出力例(一部)です。ここで得られたデータを利用しています。
statsコマンドによるデータ収集の結果、表示されるグラフは4つあります。
上から、キャッシュの使用量、getとsetが発行された数、getのhit率、最後がコネクション数のグラフになります。この中でキャッシュの使用量のグラフには注意が必要です。memcachedのキャッシュオブジェクトを保存するスラブの仕様上、100%まで使用することはできません。上のグラフでは3GB中2.8GBを使用していますが、おそらくこれ以上の使用率にはなりません。
最後のグラフは、稼働監視でも紹介したコネクション数のグラフです。赤いラインが起動時に設定をした最大同時接続数を表します。約16万が設定されています。緑色のグラフが実際の接続数になりますが、一日の中で最大でも5,700コネクションとなっているのでまだ接続数の余裕があることがわかります。
まとめ
memcachedのNagiosを利用した稼働監視とCloudForecastでのリソースモニタリングについて紹介しました。Webサービスのスケーラビリティにおいてmemcachedが重要なコンポーネントの1つとなって今、監視の重要性も高くなっています。筆者の経験上memcachedは非常に安定したソフトウェアだと考えていますが、障害に対して即座に対応ができるよう、また効率的な運用ために監視は欠かすことはできません。
次回はこれまでに説明した起動オプションやセキュリティ以外のmemcachedを利用する上でのTIPSを紹介します。