Managed Service Column ＜システム運用コラム＞第11回：可用性を高めるための監視仕様

システムのクラウド移行が加速する中、「クラウドサービスを活用しているが、クラウド毎に個別に監視・運用をしているため、運用が煩雑化している。どうすればよいか？」「オンプレミスとクラウドを併用することになり、運用管理体制を見直したい」といったお声をいただくことも多くなりました。

システムは構築して終わりではなく、安定稼働するための運用が重要です。そして、システム運用の品質を担保しながら効率を上げていくためには、運用設計が必要となります。

この連載では、運用設計の考え方やの取り組みについて、事例も交えて紹介します（全12回）。

はじめに

運用設計における可用性管理で重要な内容の一つに監視仕様、障害対応手順があげられます。
サービス停止の時間をなるべく少なくするために監視を行い、万が一障害が発生した場合はすぐに対応できるように障害対応手順を用意しておくといった事は広く行われています。特にインターネットを使って24時間多数のユーザーにサービスを提供し続けているシステムであれば、正常に稼働しているかの監視を行っていないシステムはほとんど無いと思います。

監視仕様を決めるために理解しておきたい “監視” のこと

一般的に監視はよく行われていますが、では、監視の仕様はどのように決めていくべきものなのでしょうか。システムを運用する人にとって “監視” 自体は身近な言葉であるものの、監視の実装では、サーバーの疎通をチェックする、監視サービス(ツール)の標準設定をあてはめるといった対応にとどまっている例も多く見受けられます。実は、”監視仕様はどう決めるべきか” ということをしっかり説明できる運用担当者は多くはないかもしれません。

そこで、まずは “監視” とは何かから整理してみたいと思います。

ただ単に「監視」というと、何を思い浮かべるでしょうか。サーバーのping監視や、httpdプロセスが存在するかどうかの監視、CPU負荷の監視といった内容を思い浮かべる方も多いと思います。しかし、システムを運用していくうえでは、「監視」はもっと幅広く考える必要があります。
監視には、大きく分けて次の2つがあります。

• サービスの監視
  サービスを利用するエンドユーザー視点で、そのサービスを利用できるかどうかを監視します。
• インフラの監視
  サービスを提供するサーバーやネットワーク機器など、サービスを提供するために必要な要素を監視します。

例えば、https://example.com というECサイトがあるとすると、サイトにアクセスできて商品を購入できることを監視するのがサービス監視、そのサイトを構成しているサーバーのhttpdプロセスの状態などを監視するのがインフラの監視です。

また、「インフラの監視」は、さらに次の2つの目的に分かれます。

• 予防のための監視
  冗長化がされており、1台のサーバーダウンではサービスとしては停止しないように設計されているシステムでは、1台のサーバーに対するインフラの監視はサービス停止が発生する前の予防措置のための監視と言えます。
• 原因特定のための監視
  サービス停止が発生した際に、原因がWebサーバーなのか、DBサーバーなのか、ネットワークなのか等、インフラのどの部分に問題があるのかを特定するための監視です。

監視仕様の決め方とポイント

前述の通り、「監視」と一言で言っても複数の視点があります。「第１回：運用設計を行うべき理由と運用設計のアプローチ」で書いたように、運用設計ではじめに行うことは、「対象システムの用途」を知ることです。監視仕様を決めるにあたってもこの基本的考え方に沿って、システムがユーザーに対して提供するサービスは何かを考えるところから落とし込んでいきます。次のようなイメージです。

STEP１で、 ユーザーがそのシステムを使ってできることを洗い出します。
STEP２で、 ネットワーク、WebサーバーやDBサーバーといったサービス提供のために用意しているシステムインフラを洗い出します。
STEP３で、 Webサーバー機能を提供するhttpdのサーバーや、データを格納しているDBサーバプロセスなどを洗い出します。

では、https://example.com というECサイトを例に監視仕様を決めるためのそれぞれのステップを見ていきます。このサイトは次のような構成のシステムでできているとします。

「システムがユーザーに対して提供するサービスが何であるか」という視点で監視する

このサイトでは、ユーザーは次のようなことができます。

• アカウント作成、変更、削除
• 作成したアカウントでのログイン
• 商品の検索
• 商品をカートに入れる
• 商品を購入する

ユーザーから見た場合、これらを正常に操作できることがサービスを正常に使える状態であるといえます。

監視仕様に落とし込むと、次の2つの一連の操作が正常に完了できれば良いということになります。

• Webブラウザでサイトにアクセス → アカウント作成 → ログイン → アカウント変更 → アカウント削除
• Webブラウザでサイトにアクセス → ログイン → 商品検索 → 商品をカートに入れる →商品を購入する → ログアウト

ブラウザでアクセスした際に単に画面遷移が意図通りにできるということだけでなく、ユーザーの満足度を満たす品質という意味では、各ページの表示や画面遷移の時間にも一定の指標を決め、監視項目の一つとして定義します。

「サービスを提供するために必要なインフラが何であるか」という視点で監視する

前述の図を確認すると、サービスを提供するシステムインフラとしての要素は次の通りです。

• インターネット接続回線
• インターネット接続ルータ、ファイアーウォール
• スイッチ
• ロードバランサー
• Webサーバー
• DBサーバー

すべてがサービスを提供するために必要なインフラですが、冗長化されている部分については一方の障害ではサービス停止には至らないため、サービス停止を予防する措置を行うための監視という位置づけになります。
それに対して、冗長化されていない部分や冗長化されていても両系の障害を検知するための監視は、サービス停止にいち早く気づき、即座に復旧対応に移るための監視という位置づけになります。

例えば、Webサーバーであれば、

• 2台中1台の障害であれば警告としての通報
• 2台とも障害であれば障害通報

というように、同じ監視内容であっても条件によって通知方法を変更するといった考え方が必要になります。

「サービス提供するために動作しているOSやプロセス(プログラム)の状態」という視点での監視

サービス、システムインフラと見てきましたが、最後はOSおよびプロセスです。監視仕様を決めるにあたっては、プロセスが一番細かい単位になります。

サービスを提供するために重要なプロセスとしては、Webサーバーのhttpdプロセスや、DBサーバーのmysqldなどがあります。プロセスに関してもインフラと同様に目的によって次の2つの監視があります。

サービス障害に直結する障害を検知し、即座に復旧できるようにするための監視

• プロセス存在監視
• プロセス(サービス)応答監視 (http 応答や、DB の接続応答など)

将来のサービス障害を予測もしくはサービス障害時の原因調査をしやすくするための監視

• OSが管理するリソースの監視 (CPU使用率、メモリ使用率、ディスク使用率など)
• プロセス(サービス)の応答速度

監視設計のポイント

監視設計においては、特にOSやプロセスの監視において何のための監視であるかの目的を間違えないようにすることが重要です。これがしっかりできていないと、例えばすべての監視とそれに伴う障害通知が同じレベルで実施され、本当の問題点を見失います。

実際、当社でお客様システムの運用を請け負う際に確認すると、CPU使用率を監視し、ある一定の閾値を超えたら担当者へ緊急通報するような設計がされている監視を見かけることがあります。つまり、サービス障害に直結する障害検知の目的でCPU使用率を使っている例です。

しかし、CPU使用率が高いからといって、それに対して何らかの対処ができることは通常ありません。サービス障害かどうかの判定は別の手法であるべきで、CPU使用率はサービス障害に至る前段の情報収集として使うべきものといえます(当社ではこういった間違った監視設計は見直し対応をさせていただいています)。

監視仕様のまとめ

“システムがユーザーに提供するサービスは何かという視点での監視”、”サービスを提供するために必要なインフラが何であるかという視点での監視”、”サービス提供するために動作しているOSやプロセス(プログラム)の状態という視点での監視” という 3つの視点で、どう監視仕様を決めるかを説明してきました。
全体を通して、ここまでお話した監視仕様をまとめてみます。

https://example.com システム監視仕様:

(※) 冗長化されていない部分では可用性確保の目的という意味を持ちますが、冗長化されている部分では可用性確保目的としては不要です。

以上で、どのような項目をどのような目的で監視するかがまとまりました。これは、https://example.com という例に対するものですので代表的な内容のみとなっていますが、実際のシステムではこれよりも項目が多い大きな表になるでしょう。
また、実際にはそれぞれの監視項目において障害と判断するための閾値をどうするかという点も監視設計では考慮する必要があります。

このように、監視設計は、システムでWebやDBのプロセスが動いているから単にそれの監視をするというのではなく、そのシステムがいったいユーザーに何を提供していくかという視点で行っていく必要があります。このような監視設計を行うことにより、本当に可用性を維持するための監視がどうあるべきかの定義ができるのと同時に、万が一障害が発生した際の復旧時間を短くしたり、事前の障害予防にもつなげることができることができます。

当社では、多くのお客様の新規構築したシステムだけでなく、すでに運用を行っているシステムに対しても、サービスから落とし込むという考え方で将来につながる監視設計を実施させていただいています。

Tag： 監視設計 システム監視 運用設計

• 

  第10回：構成管理とは―目的と取り組み事例

• 

  第12回：可用性を高めるための障害対応手順