障害検知の仕組みと対応の考え方

障害検知の仕組みと対応の考え方

障害を好んでいる人はいないと思いますが、システムは必ず障害を起こします。

障害の種類としては、サーバー障害、システム障害、人的障害、攻撃・・・多種多様です。
メンテナンスを行わずに、放っておくことでも、ハードウェアやデータボリュームにより、障害につながります。

上記のように障害には様々ありますが、全ての障害は

「想定していれば、ある程度防げる」

という考えで間違いないです。是非、リスクリストを作成してみましょう。

リスクリストの考え方

前提として、弊社のWEBサービスで考えてみます。

「フォームアシスト」のリスクリストについて・・・

  1. ユーザーアクセスは、どの位耐えられるか?
  2. ユーザー数は、どの位の数が登録できるか?
  3. 1ユーザーあたりのログデータ容量は、どの位まで許容できるか?
  4. 稼働サーバーにHWトラブルが発生した場合にどうなるか?

もっとたくさん出るとは思いますが、ざっくりこんな感じを殴り書きしてみてください。

リスクリストの詳細を考えてみる

1.ユーザーアクセスは、どの位耐えられるか?

■概要

サービスが正常稼働できなくなる数値を上限値とする。

■考え方
フォームアシストの様な、タグ貼り型のサービスの場合は、タグを貼ったサイトのPV数に依存して、アクセス数が発生します。

「サイトの数 x ユーザー数」で計算できるかと思いますが、この場合の数値は、瞬間同時アクセス数が、ここの値にふさわしいので、月間のPV数ではなく、1秒間での最大コネクション数を弾き出したほうが現実的です。

 【計算方法】

  • 1サーバーあたりの最大アクセス(コネクション)数=1,000コネクション
  • サーバーを4台でバランシングさせるとすると、1秒間に4,000コネクション可能です。
  • ピーク時を18:00〜24:00と仮定して、それ以外を10分の1程度のコネクションと考えて
  • ピーク時:4,000 x 60秒 x 60分 x 6時間 = 8,640,000コネクション
  • それ以外:400 x 60秒 x 60分 x 18時間 = 25,920,000コネクション
  • 8,640,000 + 25,920,000 = 34,560,000コネクション/日

1日3456万が可能なコネクション数だということがわかります。
1ヶ月にすると、34,560,000 x 30日 = 1,036,800,000コネクション/月

この結果から、月間1000万PVの会社が10社ぐらいまでは対応可能という結果が分かります。

2.ユーザー数のキャパシティ

 ■概要
  ユーザーの設定データ容量、ファイル・フォルダ数、設定の同時アクセス数など。
  ※サーバーをバランシングさせる前に、1サーバーでのキャパを考えておきましょう。

 ■考え方
  使用しているサーバーのinode上限値がファイル・フォルダ数の上限値で有ることを考慮して。
  基本設定に関して、1ユーザーでいくつのファイルを使用するか?

  仮に10ファイルだとすると、「ユーザー数 x 10ファイル」が、基本ファイルの総数になります。

  その他にもinodeには、OSが使用するシステムファイルや、ログ・ファイルなども考慮しなければいけないのですが、むしろ、ログファイルが一番inodeを消費する事が間違いないので、こちらの設定を考慮した方がいいですね。

3.1ユーザーあたりのログデータ容量は、どの位まで許容できるか?

 ■概要
 集計システムなどでのプログラムメモリのキャパをオーバーするのは、ログデータ容量の上限容量はどの位か?

 ■考え方
  ログデータは、取得方法や、内容により、サイズもファイル数も全く違う値になるので、この計算は重要になると思われます。
ちなみに、弊社の扱うサービスのログデータで最も容量を占めているものは、「ユーザーエージェント」の文字列になります。

mac端末でchromeブラウザを使った時のユーザーエージェント文字列は以下のような感じですが、これで、121文字になります。

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

 10pvで1KBになるということは、10000PVで1MBになってしまう計算ですよね。

 ちなみに、ログデータだけで1日に数GBもあるユーザーさんもいて、それに対応できるシステム構築には、とても苦労しましたが、DBMSであれば、運用も大変だし、ハード障害も避けられないでしょうが、ここの仕組みについては、別の機会に説明したいと思います。

4.稼働サーバーにハードウェア障害が発生した場合にどうなるか?

 ■概要
ハードウェア障害は、機器自体が故障する事を想定しますが、この場合は、サーバーの中のHDD1台が故障しても、RAIDシステムで、サービス継続が可能なので、個別の詳細を考えておく必要があります。

 ■考え方
サーバーハードウェア

  1. HDDが故障した場合
  2. ボードが損傷が故障した場合(通信装置や、内部チップは全て含みます)

ネットワーク関連

  1. FW故障
  2. LB故障
  3. SW故障

  
特定セグメントの障害

  1. 一部のサーバーでの通信障害
  2. 一部のサービスでの通信障害

上記のようなトラブルの場合にどのように「検知、確認、修復」を行うかを事前に考えておくことで、実障害を軽減できます。

冗長構成と負荷分散

トラブルが発生する事が想定できた次に行う作業は、サーバーの実機を冗長構成にして、トラブルの際は、ホットスタンバイに切り替わり、サービスは止めないという事が必要になります。

また、ロードバランサーを用いて、自動的に障害サーバーを切り離す仕組みがあるだけで、受けサーバーを無限に増やすことができる構成にしておけば、サービスの仕組みにもよりますが、可動しているサービスを止めることなく運用することは可能です。

1サーバーに対する負荷値のセットがちゃんとできていれば、必然的に、安定運用するサーバーが何台必要かは計算できると思います。
※予算が許すのであれば、キャパの2倍ぐらいにセットしておくと安心ではないでしょうか。

監視の重要性

サービスを止めないインフラの仕組みを作っても、実際に障害は発生すると思います。
その時に重要なのが、「監視システム」です。

サーバーに負荷が発生する以外に、単なる内部機器の故障などもあり、全く予測できない時に壊れるケースも少なくありません。

そんな時、できるだけ細かく詳細データを監視できていれば、原因究明も、復旧対応も、非常に迅速に行えます。

多くの会社では、「Nagios」や「Zabbix」などのソフトを使って、データ収集とアラートまでを行っていると思いますが、こういったOSS系のソフトは、誤検知があまりにも多く、メールが飛んできた時に、調査をする工数頻度を考えると、設定をかなり詳細にサービス別に行う必要があります。

また、WEBサービスで検知アラートサービスを行っているようなケースもありますが、多くがPING監視や、特定ファイル監視レベルが殆どで、逆に詳細データが取得できない分、実際の障害時に原因究明に時間がかかるケースが多いです。

こういったストレスを無くすために、監視ソフトも自社開発して使っています。

しかも、外部環境に設置して、実際のエンドユーザーの人と同じ目線で監視することで、細かな問題を検知するようにしています。

作ったソフトは、お見せできませんが、ポイントは以下の点ということで、この項目を5分に一度ログ取得して、閾値判定を行うことで簡単に可能です。

  • httpアクセス
  • httpsアクセス
  • メモリ値
  • CPU値
  • HDD容量(%)
  • LB値
  • Proc数

Nagiosなどは、これ以外にも色々な情報を取得できますが、上記のみで十分と割り切って設定するのもいいかもしれません。

障害訓練の実施

最後に、上記のように、環境構築と監視が構築できた際に、是非実際にサーバーがダウンした事を想定した実地訓練を行うことをオススメします。

対応フローが、いかに頭に入っていても、実際に障害が発生した時は、色々な慌ただしい状況になることは間違いありません。
会社であれば、そんな時に誰が何の役割をするのかを、担当者全員が把握し、対応するという手順が一番重要です。

火事場の連携プレーと同じですね。

まさに火消し!

そんな訳で、弊社も3ヶ月に一度、こういった訓練を実施して、障害と向き合っています。

コメント