ハウテレビジョンブログ

『外資就活ドットコム』『Liiga』『Mond』を開発している株式会社ハウテレビジョンのブログです。

サーバの監視システムを設計したときに考えたこと

弊社では少し前にサーバをAWSに移行しました。 それまでは継ぎ足し継ぎ足しで作っていたものを再構成しての移行だったので、この機会にサーバの監視体制についても一新しました。

この記事ではそのときどういったことを考えて設計したかをお伝えできればと思います。

はじめに決めておくとよいこと

サーバの監視体制を設計するにあたり、先に決めておくとよいことがいくつかあります。

目標稼働率

サービス提供時間中はいつでも使えることが理想です。 しかし、サーバを運用していくうえで予期せぬ障害というものはつきものなので、100%いつでも完全に使える状態にしておくのは大変な労力を伴います。 大規模なサービスならともかく、小規模のサービスでは100%動作するように作るのはコストに合わないことが多いと思います。

そこで、どのくらいの頻度で、どのくらいの時間止まることを許容するかといったポリシーを決めておくと設計の際に役立ちます。 これは目標とする稼働率を維持するのにかかるコストや、障害が発生してサービスが使えない状態になったときの損失などから決めることになります。 ただし、必ずしも厳密な計算や定義が必要というわけではなく、プロジェクトの関係者内で同意が取れていれば十分だと思います。実際、弊社では目標稼働率を数値として決めていません。

目標稼働率は次のように具体的に考えると決めやすいと思います。

  • 障害の頻度
    • ○ヶ月に○回程度
  • 復旧までにかかる時間
    • 8割復旧まで○○分、完全復旧まで○○分
    • 例)冗長化されていないサーバが1台壊れたとき、8割復旧まで30分、完全復旧まで120分

こういった目標があると、今何が足りていないか、そのために何をすべきかが明確になってきます。 例えば…

  • 障害の頻度が多すぎる → 冗長化する
  • 復旧までに時間がかかりすぎる → システム全体のバックアップを取っておきリストアする

などといった感じです。

目標がないと、どこまでやっても終わりが見えなかったり、オーバースペックなものができあがってしまう恐れもあります。 費用対効果を考えた対策を行っていくことが重要です。

何を監視するか

自分たちのサーバがどういう状態にあるべきかといったことを検討し、必要な項目を挙げていきます。

サーバの監視では一般的には、

  • サーバの死活監視
  • CPU使用率
  • ロードアベレージ
  • メモリ使用量(率)
  • ディスク使用量(率)
  • プロセスの数

などを監視します。 そこに、必要なプロセスの起動状況、Listenしているポートの状態などを加えていきます。

また、実際に運用していくと自分たちに必要な情報は何かということがわかってきます。 そういったタイミングで随時追加していくといったやり方でも良いと思います。

通知方法

障害が発生した時にどういった手段でそれを通知するかを決めます。 勤務時間中であれば、通常の業務で使用しているメールやSlackなどのチャットツールへの通知で十分だと思います。 勤務時間外であれば、担当者個人のメールや、場合によっては電話をかけて知らせる必要があるかもしれません。 また、複数の担当者でシフトを組んで月曜日はAさんに通知、火曜日はBさんに通知…といった設計もあり得ます。

要件にもよりますが、PagerDutyなどの外部サービスがフィットするかもしれませんので、そういったサービスも一度検討してみると良いと思います。

対応できる人とその責任範囲

障害が発生した時、誰がどの範囲を担当するかを整理しておきます。

  • 誰がどういう作業ができるか(権限があるか)
  • このプログラムに詳しい人は誰か

などといったことをまとめておくと、障害発生時の通知、その後の連絡体制の設計に役立ちます。

復旧までの流れ

障害が発生してから復旧させるまでの一連の流れを検討します。 いろいろな状況が考えられるので、できるだけ網羅的に洗い出します。 例えば、次のようなことが考えられます。

  • 一次担当者が寝ていて気づかなかった。
  • 一次担当者が気づいたが、修正方法がわからない。
  • 一次担当者が気づいたが、泥酔しており作業できる状態ではない。

これらの事態に対してどういう対応を取るかを検討し、一連のフローにまとめます。 細かく洗い出していると、複雑なフローになってしまいがちですが、なるべく単純になるように設計した方が良いです。 あまり複雑にしすぎるといざというときに何をすれば良いかわからなくなってしまいます…。

クラウドサービスか自前か

最近ではDataDogやMackerelなど、サーバにエージェントをインストールするだけで簡単に監視できるサービスがあります。 これのサービスを使うと専用サーバを立てなくても良いので、気軽に監視を始められて便利です。 料金はおよそ2000円/月/台程度のものが多いようです。

一方、自前のサーバにZabbixなどの監視システムをインストールする場合、手軽さでは負けますが自由度の高いシステムが手に入ります。 また、クラウドサービスではデータの保存期間などが決まっている場合が多く、それが制限となってしまうこともあります。

ハウテレビジョンでのサーバ監視体制

例として、弊社の監視体制をご紹介します。

構成

弊社では以下のような形で監視システムを組んでいます。(多少簡略化してあります。)

f:id:xyz_i:20151120174231p:plain

Zabbix

Zabbixをメインで利用しています。Zabbixの選択理由は、以下のものが挙げられます。

  • データの保存期間
    弊社では新卒就活のサービスを提供しています。就活は季節性のあるイベントですが、最近就活の時期が頻繁に変更されており、負荷のピークが必ずしも1年前とは限りません。そのためデータの保存期間を1年以上確保したいという要望があります。
  • 将来的な拡張の余地
    クラウドサービスでも大抵のことは実現できるとは思いますが、自前のサーバで動かしていると最悪自分たちでカスタマイズしてなんとかするという選択ができます。
  • これまでの実績
    Zabbixは他社でも多く採用されており実績があり安心感があります。

監視項目は…

  • サーバインスタンスの死活監視
  • プロセスの死活監視
  • TCP/UDPポートの状態監視
  • 各種リソースの使用状況監視
  • サイトの主要なページにHTTPアクセスして、レスポンスのステータスコードやHTMLの内容のチェック

また、ZabbixでのAWSリソースの監視については、クラスメソッドさんが後悔している「【セッションレポート】ZabbixによるAWS監視のコツ」がとても参考になりました。

AWS CloudWatch

AWS CloudWatchはZabbix自体を監視するために使用しています。これはあくまで補助的な役割のため、ZabbixサーバインスタンスとZabbixサーバプロセスの死活監視のみに留めています。

PagerDuty

障害を検知したときの通知にはPagerDutyを利用しています。 PagerDutyを使っているのは、通知に関する一通りのサービスがそろっていることが理由です。 スマホアプリが用意されていたり、電話で障害を知らせてくれたり…必要なものがほとんど全て用意されています。 これら(特に電話!)を自前で用意しようとするとかなり大変な作業になってしまうと思われるので、こういったサービスをありがたく使わせていただいています!

ポリシー

弊社では今のところ目標稼働率は数字としては特に決めていません。 これまで障害の頻度がそれほど高くなかったこともあり、障害が発生した時に随時対応していこうという考えです。 (もちろんやるべきことはやったうえでの話です!)

障害が発生すると担当者数名に通知が届き一次対応を行います。 ほとんどのものはここで対応が可能だと考えられますが、対応しきれない場合、他のエンジニアと電話やSlackなどで連携して解決にあたります。 少人数で対応しているため、ベストエフォートで対応するという体制です。

まとめ

この記事では障害対策について書いてきました。 障害はないに越したことはありませんが、サーバを運用している限り避けて通ることはできません。 そして障害は忘れた頃にやってきます。 その時に迅速に対処できるように、事前にきちんと対策しておきましょう!