DECOLOGのZABBIXを使ったシステム監視

こんにちは、hiroshiです。今は土曜の昼下がり、週１連載なんて言わなきゃよかったなーと思いながら男が一度言ったことは１ヶ月はやらねばだめだよね！ということで記事を書いてます。

今日はDECOLOGのシステムの監視についてです。
「便りがないのは良い知らせ」と言いますが、その便りが「システム落ちました」だとシビれますよね。

そうならないためには、システムを常時監視し、なるべく事前に異常に気づける仕組みづくりが欠かせません。

DECOLOGではシステムの監視にオープンソースツール「ZABBIX」を使っています。

ZABBIXはServerとAgentからなるクラサバ形式のツールで、CPU・メモリ・HDDの使用率などのおなじみなものはもちろん、標準出力に出せるものならなんでも取れてしまう優れものです。と書きましたが、他のツールのことは知らないのでこれはZABBIXに限ったことじゃないかもしれないです。

ちなみに例えばmemcachedのコネクション数を取りたい時なんかは、zabbix_agentd.confに↓のような感じにかけばよいわけです。

UserParameter=memcached.curr_conn,/usr/local/bin/memcached-tool localhost stats | grep curr_conn | awk '{print $2}'

grep curr_connのところはawkでNR==8とかでもいいかもですね。まあ、取れればなんでもいいワケです。

そして取得したデータをお好みのグラフにまとめたり、そのグラフをスクリーンという画面単位に整理できたりするのです！まあ、これも他のツールでもできることかもしれないですけど。

しかもしかもですよ、それぞれの監視項目に閾値を設定してそれを超えたらメール送信したりもできちゃうのです。・・・きっとこれも他のツールでもできるんだろうなー。

なぜZABBIXかというと「これ」っているのはなくて、DECOLOGの場合はstoneが導入当時、やりたいことができるツールを探していくつか試した結果、導入もすんなりいってしっくりきた最初のツールがZABBIXで、今も特に困ったことがないのでZABBIXを使い続けています。

困ってなきゃ、なんでもいいんです。今Cacti使ってて困ってることがなければCactiでいいと思います。ツールの変更とかは困ってきたら、もしくは困ることが見え始めてきたら考えるというノリでやってます。これは利用するプログラム言語もIDEもなんでもそうなんですが、あまり先のことまで考えすぎてはいけないと思ってます。

さて、そのZABBIXを使って何を監視しているか？ですが、基本的な死活監視およびCPU,メモリ，HDDの使用率、トラフィックなどは全サーバ視てます。というかZABBIXのAgentセットアップしてServerと疎通とると同時に勝手にみてくれてます。あとは用途ごとに定番のものがあります。だいたい以下です。

プロキシサーバー(バランサー）
DECOLOGのトラフィックはすべて数台のリバースプロキシサーバーを通って複数台のWEBサーバなりsquidサーバなりに振られるんですが、まずここのトラフィックが最重要監視項目です。何か問題がある場合は、ここに高確率で表れます。プログラムの更新とかネットワーク関係の設定変更とかをやる際は、タスクごとにいろいろ監視しながらやりますが、ここの監視は絶対に含まれます。

図１．とある日のとある時間のトラフィック
ここに変な動きがあったら何かがおかしい可能性が高い！

WWW/AP
CPUのロードアベレージとapacheのBusyWorkerを見てます。

DB
masterはロードアベレージとコネクション数で、slaveはさらにreplication delayを見てます。

memcached
コネクション数とキャッシュHit率を見てます。

squid
キャッシュHit率とファイルディスクリプタ数を見てます。

メールサーバ
キューの数とか送信状態を見てます。


と、こんな感じの定番項目以外は、必要に応じてグラフを起こして監視します。

グラフは、同じ役割のものを全部束ねて作ります。こんなイメージです。
こうすると、サーバに異常があったり、設定におかしなところがあったりすると、1本だけおかしな動きになるのでわかりやすいです。
たとえば
こんな感じです。これはとあるDBのロードアベレージのグラフですが、バックアップ用のDBを使って負荷のかかるSQLを流しているのでバックアップ用のDBの線（赤いの）だけロードアベレージが跳ね上がってます。

異常監視だけじゃなくて、上記のような例だと、「この線が下降してきたら、SQL処理が終わったんだな」みたいな用途にも使えます。

あとは、とにかく気になったものはグラフを起こしてスクリーンにまとめます。スクリーンには名前が付けられるので分かりやすい名前をつけます。たとえば「Squid Overview」とかです。しばらく、そのまま運用してみて、「やっぱこれいらねえな」ということになれば、なくなりますし、「これいいね！」ということになると、「04 Squid Overview」というように名前の手前に数字が付くというAKIRAのナンバーズのような制度を設けています。

今回はここまでにします。

各監視項目には必要に応じて閾値が設けられており、その閾値を超えるとアラートメールを飛ばすように設定していますが、次回はそのアラートメールについて書く予定です。違ったらごめんなさい。

次回が1ヶ月目のはずなので後1回はかならず週刊を守るべくがんばります。

では、また次回に会いましょう。

画像配信システムその２

こんにちは、hiroshiです。
自分のことをhiroshiとかアルファベットで表現すると軽く有名人っぽくて気分がいいです。みなさんも是非やってみてください。

さて、前回の記事の最後に紹介させていただいたはITメディアさんの記事では、記事画像配信の仕組みについて触れられています。
あの仕組みは「デコメで投稿される記事に使われている画像」の特性から現状のあの構成になりました。

一方でDECOLOGで扱われる画像はもちろん記事画像だけではありません。
代表的なものに、ブログTOP画像というのがあります。

ブログTOP画像は、その名の通りブロガーのみなさんの顔ともいえるブログのTOPページを飾る画像です。

図１．ブログトップページサンプル

上図の通りページ上部に配置される画像であるため、携帯画面でのファーストビューはこのブログTOP画像で占めらる割合が大きいです。
つまり、「ブログTOP画像＝ブロガーのみなさんの顔」といっても過言ではなく、少しでも早く表示させたい画像なわけです。

さて、ITメディアさんの記事で、記事画像配信の仕組み変遷の歴史画像が掲載されていますが、あれの３代目まではこのブログTOP画像も同じパケットのフローにのっていました。違っていたは一番下のDBだけです。

しかしながらブログTOP画像と、記事画像では大きな違いが２点あります。

1. アクセスの頻度が違う。記事画像は時間が経てばが落ちるが、ブログTOP画像は一定。
2. データ量が違う。記事画像は際限なく増加するが、ブログTOP画像は仕様上、ブログ開設数×２が上限

１から、アクセス頻度がロングテール化する記事画像のようなアーカイブ方式はそぐわないことがわかります。
この大きな違いを持つ２種類の画像が共存していたため、squidのキャッシュ効率も悪く(たぶん）、ブログTOP画像の表示がもっさりする、登録しても反映が遅い(=replication delayの発生)ことがしばしばありました。


なので、「まずブログTOP画像をなんとかしよう！」ということで対策会議を開きました。といっても技術責任者のstoneと2人でベランダでタバコすいながら「なんかいい方法ないっすかねー」みたいなノリでしたけど。
で、いろいろ議論を重ねた末に、「とりあえずこれでやってみっか！」となったのが下図の構成です。

図２．ブログトップ画像構成

Before、Afterでの大きな違いは、画像の保持方法を動的(DB管理)から静的(FS管理)に変えたことです。
２の「データ量が違う」ということから、ITメディアさんの記事で触れられているinodeの枯渇の心配もないことがわかり、だったらDBにぶち込まないでそのまま置いといたほうが早くね？ということでそうしてみました。

画像サーバは読み取りと書き込み用にポートを分けておき、書き込み用には画像を受け取る用のPHPスクリプトを置いておきます。

書き込み処理の流れを追ってみます。ブログトップ画像の登録はメール送信で行われます。

1. qmailで受け取ったメールはパイプ処理でphpプログラムに渡す
2. phpでメールの中身を解析し、画像ファイルの取り出し・加工処理などを行った後、
3. DBにぶち込み、
4. HTTPでブログIDをキーに決められた格納先画像サーバとバックアップ用画像サーバにPUTする。

PUTと言っても、単純にrequestに画像データをぶち込んで画像サーバの81に向けて特定のURLを呼び出すだけです。

METHODとしてのPUTを使ってみる方法(WEBDAVとかを使うんだったけかなあ？）も試行錯誤してみたんですが、作業を担当したのが2流の僕なのですぐ音を上げました。「stoneさん、これムリっす！」「じゃあ、あと1時間だけ挑戦してダメだったらやめよっか」やっぱりだめでした。。

言い訳っぽいのですが、あのまま試し続けていればカッコいい方法が実現できたかもしれません。ただ、慣れてない方法でやるよりもシンプルかつ自分が完全に理解できている方法でやったほうが、トラブル時などの対策案も多々浮かんできます。それになにより、人がいないので方針を決めたら作業完了までの工数が読めない方式は取りたくない、というのもありました。

一方で、どこかで新しいことやモノに挑戦していかないと手元のカードは増えません。状況に余裕があるときであれば、新しい手法・試したことのない手法はどんどん突っ込んでいくべきだと思います。

ということでまあ当時は余裕がなかったんです。

さて、話を元に戻します。
ユーザーから送られてきた画像は、3箇所に書き込まれます。もちろん理由があります。
内訳はDB1箇所に画像サーバ2箇所。

画像サーバ2箇所に書き込んである理由はすぐわかります。画像サーバがぶっ壊れたらすぐ代替と交換できるようにそうしてます。なので、バックアップ用サーバは全ての画像を保持しています。

DBに書き込んでいる理由もやっぱり画像サーバがぶっ壊れたときのためです。
どこかの画像サーバがぶっ壊れても、バックアップサーバを突っ込めばサービスとしては問題ない状態になりますが、その間に復旧作業をしなければなりません。

バックアップ用サーバからrsyncで、とかもちょっと考えましたが、普及中もユーザーによる追加／更新が行われ続けるため、完全に同期がとれるのかがすごく疑問でした。また、その検証方法も思いつきませんでした。

一方、DBで持っておけば、その辺の取り回しはいくらでも融通が効くので、復旧用のスクリプトさえ用意しておけば数時間で普及できる計算が成り立ちました。ということでDBにも書き込んでいるわけです。


読み込み処理の流れはシンプルです。URLにその画像がどの画像サーバにあるかがわかるようになってるのでmod_proxyで振り分けるだけです。

この仕組は想定通りの結果が得られ、今でも非常に安定して稼働しています。

本当は、既存の仕組みから新しい仕組みに切り替えるときに発生する「移行」についてもいろいろ工夫してきた話があるのですが、これはまた後日にさせてください。

では、また次回に会いましょう。

DECOLOG TECH BLOG始めました。

はじめまして。hiroshiです。

Twitterでは、前からやるやるといってやってなかった「DECOLOGの中の人ブログ」、ようやく始めました。

気がつけば「DECOLOG」もそれなりの規模のサービスになってきて、技術的にもそれなりのことをできるようになりました。それは、同じ業界の方々が生み出した様々なプロダクトや、公開していただいた経験・ノウハウに助けられて成り立っていると思っています。そこでセンエツではあるものの、ぼくたちの経験・ノウハウを公開することによって、ぼくたちが助けられたように、誰かを助けられたらいいな！ということで始めました。

「DECOLOG」って何？という方も多いと思いますので、初回は「DECOLOG」の紹介を簡単にしたいと思います。

まず、どんなサイトなの？というところは、この記事で弊社の光山がお話させてもらってるのでどうぞ。

次に数字で見るDECOLOGです。

• ブログ開設数：190万
• PV数：2億/日
• HIT数：14億/日
• メール送信数：1,000万/日
• apacheのログ：220GB/日
• サーバ台数：約330台

※数字はすべて「約」で、2010年9月中旬のものです。

などなど。

これをハードウェアを除くすべての運用・開発を5人の技術チーム（最近、当社比で倍近くの人数になりました！）で回してます。

ヒストリーも含めて、このシステムがどのように支えられているか？支えてられてきたか？をぽつぽつ紹介していきたいと思ってます。

最後に、9月1日にITメディアさんに掲載していただいた「月間57億PV、300台のサーバを運用するミツバチワークスが編み出したインフラ技術」を紹介して終わります。

ではまた次回に会いましょう。