はじめに

株式会社ミクシィの小池知裕です。運用部でアプリ運用を担当しています。前回は年末年始や突発的な負荷に耐えられるシステムの改善について紹介しました。連載2回目となる今回は、mixi.jpを支える運用業務でどのようにシステムの監視と測定が行われているのか、紹介します。

監視／測定って？

まず、前号からのおさらいになってしまいますが、筆者の所属する部署の「アプリ運用グループ」は mixi.jpのミドルウェア層以上の運用／維持管理／改善をおもに担当しています。

そこでは、「⁠システムが正常に稼働しているか」「⁠サーバの（CPUやメモリ、トラフィックなど）どういうリソースがどのくらい使われているのか」などを把握しておくことが非常に重要になってきます。

mixiでの監視／測定には大きく分けると2つあります。

• 死活監視／サービス監視
• リソース監視

これらはそれぞれにシステムを運用し、改善するためにも欠かせないものです。では、それぞれについて具体的なしくみや工夫している点などを紹介します。

死活監視／サービス監視

一般的にWebサービスの運用を行う場合に「監視」と言えば、「⁠死活監視／サービス監視」を指します。簡単に言うと「サーバが生きている」ことと「⁠（⁠Apacheなどの）サービスが生きている」ことの確認です。そこで、mixiでは監視ツール（システム）として「Nagios」を採用／導入しています。なぜNagiosを採用しているかというと、次のような特徴があるためです。

• OSS（オープンソースソフトウェア）である
• プラグインで監視項目／しきい値などをカスタマイズできる
• 各所での導入実績が豊富

何かあった場合にも、自分たちで何とかできるということを重視して選択しています。

工夫している点とは

Nagiosで監視を行っていくうち、いくつかの問題に直面しました。

［mixiでの監視システムの問題点］

• 管理や設定が煩雑
• 1台のサーバで監視した場合に監視サーバが過負荷になる

一口に「サーバが生きているかどうかを監視」すると言っても、mixi.jpを支えるサーバ群は2,000台以上もあります。つまり、「⁠どのサーバにどのような（何に対する）監視を行うのか？」ということの管理自体が煩雑になってしまいます。

また、Nagios の監視用の設定（cfg）ファイルはリスト1、リスト2のようなものです。

define service {
use                    generic-service
host_name              web1
service_description    webserver
check_command          check_http_live
}

use                      generic-host
host_name                web1
address                  192.168.10.1
check_command            check-host-alive
max_check_attempts       3
notification_interval    20
notification_period      24x7
notification_options     d,u,r
contact_groups           admins
}

パッと見た感じ、何がどういった設定項目かというのはなんとなくはわかるとは思いますが、大量のサーバやサービス（Apache、MySQLなど）に対して、これらの設定ファイルをそれぞれ編集しなければならず、面倒でミスも起こしやすいです。

そこで、作業の省力化として「サービスとそれらを構成するサーバの関係を記述したYAMLファイル」からリスト1やリスト2のcfgファイルを生成するPerlスクリプトを利用しています（図1⁠）⁠。

このように比較的視認性がよいYAMLファイルを使うことで編集ミスを防いでいます。

リソース監視

リソース監視は死活監視／サービス監視とは違って、「⁠各サーバのリソース（CPU使用率、トラフィック量、メモリの使用量など）がどのくらい使われてるか」を監視／測定することです。

これらの監視／測定データ（とそれらを可視化したグラフ）は運用エンジニアにとって、一、二を争うくらいの重要かつ必須なツールだと考えています。

では、どうやっているか？ 各種データの取得についてはSNMP（Simple Network Management Protocol）を利用して各サーバからデータを取得し、それらを「RRDtool」を用いてデータの蓄積＆グラフ化しています（図2⁠）⁠。また、RRDtoolは複数の値のグラフの重ね合わせも可能なので図3のようなグラフも可能です。

リスト3はSNMPでサーバからデータを取得するスクリプト例です（この例ではロードアベレージを取得しています⁠）⁠。実行例は図4のとおりです。

#!/usr/bin/perl

$snmpget = "/usr/bin/snmpget";
$community = shift(@ARGV);
$server = shift(@ARGV);

$load = `$snmpget -v1 -c $community $server UCD-SNMP-MIB::laLoad.1`;
$load = (split(/\s+/, $load))[3];

print $load;

$ perl ./get_snmp.pl（コミュニティ名）（サーバのIPアドレス）

なぜ監視をするのか？

では、なぜmixiではこのような監視をしているのでしょうか？ それは当然ながら障害を素早く検知することもその理由のひとつです。2,300万人という大勢のユーザの皆様に、常に快適に使っていただけるサービスにするため、障害検知をいち早くすることは重要です。

そしてそれだけではなく、こういった「監視／測定をすることでシステムの問題点を把握し、改善に生かす」という側面もあります。そのためには、この監視データを取得／蓄積して、そこで終わりでなく、日常的にこれらグラフを確認することで、先月号の「あけおめアクセスの負荷とその対策」で紹介したようなさまざまな改善を行う場合、改善の足がかりとなることも多いです。

日々のこれらのリソース監視グラフの具体的な運用については次回でも触れたいと思います。

まとめ

今回はmixi.jpで行っている監視／測定のシステムと考え方について紹介しました。

ここまで読まれて「なんだ、普通のサービス／リソース監視だな」とお感じの方も多いと思います。そのとおりです。mixiだから、大規模なサービスだからという特別なことは何もやっていません。それは、このようなごく普通の死活監視／サービス監視やリソース監視でも、またmixiのような大規模なサービスであっても、日々の運用の中で改善の材料が十分に見つかるということが伝えられれば筆者としては嬉しく思います。