スタートアップ企業等の少人数チームの場合、専任のシステム運用担当がいることは稀だと思います。本記事では、そうした少人数チームの開発兼運用担当者を主な対象として、システム運用の重要な要素である「システム稼働状況の確認、障害対応」を省力化するための方法の一つとして「システムの監視」の方法について説明します。

少人数チームでのシステム運用

Retty開発担当の鹿島です。第1回で少し紹介しましたが、RettyはWebサイト、iPhoneアプリ、Androidアプリの計3プラットフォームを、3人＋αの開発者で開発を進めています。私は主にWebサイトの開発とインフラ全般を担当しているのですが、Webサイトの開発がメインのため、インフラ構築・運用に割ける時間はそれほど多くありません。

おそらく世間の小規模チームの大半では、我々と同様に専任の担当者がいないと思われます。今回の記事はそうしたスタートアップ企業など、小規模チームの開発者兼インフラ担当者を主な対象として、極力手間をかけずにインフラ周りの運用を行うためのノウハウを紹介していきます。

まずは最初にインフラ構築・運用に関する基本的な方針を説明し、次にインフラ運用の重要な要素である監視に関して説明します。その後、実例を交えつつ監視項目について説明します。

本記事の内容はIaaSの使用を前提としていますが、PaaSや自前でサーバーを持っている場合にもある程度は当てはまるかと思います。

また、本記事は過去の記事と同様、Webサービスを構築している・しようと考えている方を対象としています。従って、業務系システムとは事情が異なる場合が多いですし、マネージメントやITILの話などは出て来ません。

なお、筆者自身の経歴は、開発が半分、残りは運用、技術コンサル等なので、いわゆるインフラ屋さんではありません。インフラ専門の方からのご意見なども頂ければ幸いです。

基本方針：手間をかけず、ほどほどに

冒頭にも書いた通り、Rettyのような小規模スタートアップ企業では、インフラ関連に割ける時間はそれほど多くありません。手間をかけず、インフラ構築・運用を回すために心がけたい事として、まずは以下の2点を挙げたいと思います。

自動化できる事は自動化する
やりすぎない

両方ともインフラ構築・運用に限った話ではありませんし、言葉通りではあるのですが、簡単に補足します。

1番の意図は明確だと思いますが、そもそも「自動化できる事」はどんな事かを把握する必要があります。具体的には以下のようなものがありますが、今回の記事では1番目の「稼働状況の確認・障害対応」を中心に扱います。

システム稼働状況の確認、障害対応
バックアップ、稼働状況レポート作成、その他の定常作業
自動テスト

また、これらの作業を自動化するために、普段から何らかの作業をした場合には、それにかかった時間を記録しておく事をお勧めします。その上で時間を多く使っている作業を自動化できないかを考えます。

2番は費用対効果・過剰品質などに関連する話です。これもチーム規模の大小を問わず必要な事ですが、「最小限の手間で最大の効果を得る」という事を常に念頭に置いて作業内容を考える必要があります。

以上の基本方針を元に、システム監視について説明していきましょう。

システムを監視して楽をしよう

「システム運用」には様々な作業が含まれますが、その中でも比較的大きな割合を占めるのが「システム稼働状況の確認」だと思います。今回はその作業を省力化するためのシステム監視について説明します。

システム稼働状況の監視というのは、基本的には以下のような流れの中のひとつとして位置付けられます。

リスクの洗い出し

リスクの分析

方針の策定、対策の実施

予防的対策

監視設定

障害発生時の対応方針策定

以下、各項目について説明します。

リスクの洗い出し

基本的にはあらゆる障害が起こりうるものと想定するのですが、サービスの内容、システム構成によってリスクの種類はかなり異なると思います。具体的な例としては以下のようなものが挙げられます。

アクセス集中によるサイトの高負荷・無応答

IaaS側の障害によるシステム停止

データ増加によるディスク容量不足

システムの脆弱性・バグに対する攻撃による、データ消失・改竄

不正アクセスによるシステム高負荷

なお、洗い出し作業を行う際には、事象のレイヤー・因果関係に注意して分類を行って下さい。上の1番目の例を用いると、例えば以下の様に細分化が出来ます（あくまで一例です）。

システム外部の視点からの事象：サイト無反応

システム外部の視点からの原因：アクセス過多

システム内部の視点からの事象：DBサーバーのCPU高負荷

システム内部の視点からの原因：適切なインデックスが張られていない、DBのバッファサイズが小さい等々

リスクの分析

次に、上記のようなリスク事象の発生頻度、発生した場合の影響度（定量的・定性的）などを調査し、優先順位を決定します。

なお、これはリスク分析の基本なのですが、あまり時間をかけすぎて、リスク事象発生時の損害を上回るコスト（＝作業時間）をかけても仕方ありません。基本は「ほどほどに」です。どの程度が「ほどほど」か分からなければ、「ないよりマシ」というレベルでいいと思います。

発生頻度

発生頻度は過去のデータがあれば一番いいのですが、例えばサービスを立ち上げた直後にはデータがありませんので、大ざっぱに推測します。その際、あまり正確な値にしようとは考えず、間違えていてもいいのでとりあえず値を出します。

項目	発生頻度
DoS攻撃	1回／月
EC2のリージョン単位の障害	1回／年
クラウドサービスに保管したデータの消失	0.00001%
ディスク容量不足	今のペースだと10G／1ヶ月増加

影響度

事象が発生した場合の影響度を、定量的・定性的に見積もります。

定量的に影響度を出せるケースはあまり多くはないと思いますが、例えば、サービス停止の場合は以下のようなものを算出します。

日中にサービスが30分間停止すると、その間発生するはずだった以下の機会を逃す。

項目	影響
新規登録者	50人
投稿数	100
SNSへの投稿	20

定性的な影響度の例として、システム外部からの視点では以下のようなものが挙げられます。

投稿されたデータの消失により、ネット上で悪評が広まる
APIが無応答となるとiPhoneアプリが使用できず、AppStoreで悪いレビューを書かれる

システム的な視点からは、主に事象間の因果関係や、事象がシステム外部にどう影響を及ぼすかを調べる事になると思います。例えば以下のようなものです。

優先順位の策定

発生頻度と影響度が分かったら、優先順位を付けていきます。両方とも「高」のものは当然すぐに対策を考える必要があります。

また、前項で「リスクをレイヤー・因果関係に注意して分類する」と説明しましたが、基本的にはシステム外部からの（ユーザー）視点で異常が発生した場合の方が、システム内部での異常よりも優先して扱われるべきでしょう。

発生頻度が極端に低い事象、あるいは発生頻度が低く影響度も低い事象の場合、「考慮・対応しない」という選択肢もあります。例えば、「天災によって日本が沈没する」といったリスクです。

方針の策定、対策の実施

リスクの洗い出し・分析が完了したら、それらに対する対応方針を作成し、対策を実施します。ざっくりとしたレベルで構わないので、以下のような対応方針を決めておくと具体的な対策が打ちやすいです。

「○○という事象が発生した時には、ｘｘ程度の時間/コスト/損失でサービス復旧させる」

対策は、主に以下のパターンに分けられます。

事前に対策を実施して、リスクを軽減する
リスク事象発生時の影響を軽減する
- リスク事象発生時に素早く検知し、影響を軽減する（★）
- リスク事象発生時の対応を手順化・自動化し、影響を軽減する

この「★」で示した項目が、今回の主題であるシステム監視にあたります。

ここまでは概念的な話がほとんどでしたが、ここからは具体例を用いながら、リスク事象・監視項目について説明します。

リスク及びそれに対する監視：Rettyでの実例

ここではRettyで想定しているリスク、実際に起きた障害、そしてそれらに対応した監視項目について説明します。

サービス無応答

あるURLに対してアクセスして反応を確認する

どんなサービスでも、最低これは監視しておく必要があります。Webサービスの場合、システムにHTTPで定期的にアクセスし、反応が無かった場合にアラートが上がるようにします。

具体的に何を以って正常とするかはシステムによって異なりますが、基本的には、特定のURLにアクセスして、一定時間以内にステータスコード200が返ってくればOK、と言った方法になります。

なお、ここでアクセスするURLとしては、以下のようなものが考えられます。

静的なHTML（インデックスページ等）
ヘルスチェック用のプログラム（DBサーバーへの接続等、一通りチェックして問題なければ200を返す、など）

システム外部から監視する

当たり前のように聞こえるかもしれませんが、この監視項目の場合、システムが稼働している環境とは物理的、ネットワーク的に異なる環境から監視する事が望ましいです。

RettyはAmazon EC2上で稼働していますので、Amazon EC2以外から監視するのが望ましいです。具体的には以下の方法が考えられますが、Rettyでは後者を利用しています。

別途VPSを契約して、そこで監視システムを構築する
外部の監視サービスを利用する

また、外部からの監視が難しい・監視項目に制限がある、と言った場合には、IaaSベンダー等が提供している（内部からの）監視サービス（例えばAmazon CloundWatch）と組み合わせる事も検討してみて下さい。

モジュール単位で監視する

ここまで、「サービス無応答」と一括りにしてきましたが、システムの規模が大きい場合にはモジュール単位で監視する必要があります。ここでの「モジュール」というのはシステム外部から見たモジュールを指します。例えばECサイトであれば以下のように分けられるかもしれません。

一般ユーザー向け、商品検索・閲覧機能
一般ユーザー向け、購入・決済系機能
店舗ユーザー向け、管理機能
外部ベンダー向け、API機能

もちろん、上記機能が内部で同じDBサーバー・APサーバーを使っている場合などは、まとめて監視しても良いと思います。

CPU高負荷

ここからはシステム内部の監視項目になります。

CPU高負荷は、以下の理由から必ずしも悪いものとは言い切れません。

CPU高負荷が必ずしもシステム応答速度の低下などを招くわけではない
CPU負荷が低いのは、逆に過剰なスペックのインスタンスを使用しているとも言え、その場合はスケールダウンを検討すべき

ただ、通常より負荷が高い状態が続く場合には警告を上げるように設定し、調査を行うと良いと思います。主な監視項目としては「CPU使用率」と「CPUキュー長」の2つでしょう。

具体的な実現方法としては、以下のようなものがあります。

IaaSベンダーの用意する監視サービス
システム監視ソフトウェア

Rettyの場合は前者のAmazon CloudWatchを使用して、閾値を超えた状態が一定時間以上続いた場合に警告を上げるようにしています。

Amazon CloudWatch: http://aws.amazon.com/cloudwatch/

具体的な閾値等の設定値は、OS・システムの特性によって異なってくるかと思いますので、運用しながら随時調節していくと良いと思います。

ディスク容量不足

ディスク使用量が100%に達すると、大抵のサーバーソフトウェアは期待通りに動作しませんので、この監視項目は必須だと言えるでしょう。

具体的な監視方法としては、他の指標と同様にスクリプトや監視ソフトウェアで監視することになります。EC2固有の話になりますが、Rettyでは以下の選択肢を検討しました。

EC2インスタンス上の監視スクリプトからAmazon CloudWatchにアラートを投げる
システム監視ソフトウェア

当時（半年くらい前）は手軽に使えるスクリプトが見つからなかったので、システム監視ソフトウェアとしてmonitを採用しました。

monit: http://mmonit.com/monit/

なお、現在では以下のようなスクリプトもあるので（筆者自身では試していません）、EC2を使用している方は選択肢になり得ると思います。

Amazon CloudWatch Monitoring Scripts for Linux: http://aws.amazon.com/code/8720044071969977

サーバーソフトウェアの障害

Rettyは基本的にはLAMP構成なのですが、例えばApache、MySQLなどで障害が発生する可能性もあります。

Rettyで過去に起きたトラブルとしては（Apache、MySQLに直接起因する障害ではありませんが）、以下のようなものがありました。

Apacheプロセス数の増加によるメモリ不足
ディスク使用量が100%になり、INSERT等に失敗

前者の発生後は、Apacheのプロセス数の設定を見直すと共に、ログ監視を導入して事前に検知出来るようにしました。Rettyではログ監視にはNagiosを使用しています。

Nagios: http://www.nagios.org/

後者に関しても、Nagiosによるログ監視と上で説明したディスク使用量監視により事前に検知出来るような仕組みになっています。

プログラムのバグ、予期せぬエラー

「リリース前にテストをしっかり書いて、テストが全て通ってからデプロイする」というのが望ましいですが、Rettyの場合は残念ながらカバレッジはそれほど高くありません。また、仮にカバレッジが高かったとしても、予想外のバグ・障害は常に起こるものと仮定して、事前に対策をするというのは「リスクの洗い出し」の項で説明したとおりです。

このリスクに対しては、以下の方針ですぐに検知出来るようにしています

異常が発生した場合にログに書き込む
ログ監視によりアラートを発生させる

まとめ

今回は「システム運用」に関わる作業の一つとして「システムの稼働状況の確認、障害対応」を取り上げ、それを効率良く行うために「システムの監視」の方法を説明しました。

システムを監視することで、以下のようなメリットがあります。

障害を未然に防げる
障害の検知にかかる作業時間を減らす事が出来る
障害発生から検知までの時間、ひいてはダウンタイムを減らす事ができる

また、障害が発生した際の対応策を事前に考慮しておく事により、以下のようなメリットがあります。

障害発生後の対応時間が短くなり、結果としてダウンタイムを減らす事ができる

今回触れなかった項目として、以下のようなものがありますので、次回以降で説明しようと思います。

監視による警告が発生した際の対応方針の策定、そのための施策
監視項目、設定の継続的な見直し
予防的対策

執筆者紹介
鹿島和郎
ソーシャルグルメサイト「Retty」の開発・インフラ全般を担当。過去には米企業でのオフショア開発拠点の立ち上げから国内SIerでの運用保守業務まで、広く浅く経験している何でも屋。
Rettyは、「行った」お店の投稿・共有、友達・趣味嗜好の合う人のオススメから「行きたい」お店をリスト化、スマートフォンで現在地周辺のお店をリストから検索などできるサービスで、Facebook、Twitterアカウントがあれば無料で使用可能。PC、iPhone、Androidに対応。

O'Reilly Japan Blog

スタートアップ企業向けインフラ運用入門（1）：監視