夜ぐっすり眠るための監視分類

本記事は AWSアワード受賞者祭り 6日目の記事です。
✨🏆 5日目 ▶▶ 本記事 ▶▶ 7日目 🏆✨

こんにちは、玉邑です。

年齢を重ねるにつれて、睡眠時間が翌日のパフォーマンスに大きく影響することを実感するようになりました。よく眠ることの大切さを、改めてしみじみと感じています。今回は、そんな貴重な睡眠時間をしっかり確保するための工夫についてお話しします。

ITシステムの運用に携わっている方であれば、夜間や休日のオンコール*1対応を経験されたことがあるのではないでしょうか。私自身も、15年以上前にシステム運用を担当していた頃は、連日鳴り止まないオペレーターからの電話に疲弊していました。当時はシングル構成のサーバーが多く、可用性を高める仕組みの成熟度もまだ低かったように思います。

現在のIT技術では、可用性を高めるための仕組みが非常に洗練されています。たとえば、AWSのマルチAZ構成やマネージドサービスを活用することで、インフラを複数のデータセンターにまたがって構成することが容易になりました。さらに、書籍やAWS Blackbelt*2などで提供されているリファレンスアーキテクチャ*3を参考にすることで、高い信頼性を備えたシステムを効率的に構築することが可能です。

このように、システム全体の可用性は以前と比べて格段に向上していると感じます。それでもなお、ITインフラの運用においてオンコール対応を完全に無くすことは難しいのが現実です。アラートの発生頻度が減った現在でも、サービスのSLO*4を維持するためには、緊急対応が求められる場面が残っています。

まずは「監視を分類する」からはじめてみる
監視分類の例
監視分類の考え方
継続的な監視分類の見直しの重要性
最後に

まずは「監視を分類する」からはじめてみる

書籍『システム運用アンチパターン』（Jeffery D. Smith 著、田中裕一訳）では、アラートの基準について「陥りがちなのが、異常だと思われる可能性のあるシナリオ全てに対してアラートを送信するという罠です」と指摘しています。この中では、アラート単体でオンコール対応の必要性を判断するのではなく、それがシステムにどのような影響を与えているのかという“文脈”を踏まえて評価することの重要性が解説されています。

「文脈で評価する」という考え方は、概念としては理解できても、実際の運用にどう落とし込むかが難しいと感じていました。そこでまずは、監視対象をシステムの重要度やユーザーへの影響度に応じて適切に分類し、オンコール対応が本当に必要なアラートを絞り込むことから始めるのが有効だと思います。

たとえば、監視の分類において「'WARNING'と'CRITICAL'を通知対象とし、'CRITICAL'は一律でオンコール対応する」といった方法は、先ほど触れた“罠”に陥っている典型的な例です。もちろん、すべてのシステムに当てはまるわけではありませんが、夜間や休日に即時対応しなくても、翌営業日に速やかに対応することで、システムが求める信頼性に大きな影響を与えないアラートは少なくないはずです。

監視分類の例

例にはなりますが、下記のようなシステム監視分類を考えてみました。

例：システム監視分類

監視内容	オンコール対象	想定される状態
外形監視 (Synthetics監視)	対象	障害発生中
5xxエラー監視	対象外	障害発生中の可能性あり性能劣化が発生している可能性あり
死活監視 (ノード監視、ICMP監視等)
レイテンシー監視
アプリエラー監視
AWS障害連絡
リソース監視	対象外	障害の予兆検知性能限界の兆候検知メンテナンス調整が必要
データベース監視
スループット監視
イベント監視

ここでは思い切って、外形監視のみをオンコール対応の対象としています。もちろん、システムの特性によってはそれだけでは不十分なケースも多く存在するでしょう。ただし、ユーザーの実際の体験に近い監視項目をオンコール対応の対象とすることで、他の監視でオンコールで対処すべき問題を代替できる可能性を検討することができないかという視点が、オンコール対象を適切に分類する際の観点として大切だと考えています。

監視分類の考え方

監視項目の分類は、オンコール対応の合理化において非常に重要なステップです。ここでは、代表的な監視項目を分類した表をもとに、特に検討が必要なポイントについて抜粋し、それぞれの監視がオンコール対象として適切かどうかを考えるための視点を紹介します。

外形監視 (Synthetics監視)について
- 外形監視はオンコール対象として分類されることが多い
  - これは、ユーザーの体験に近い視点からシステムの状態を把握できるためです。そのため、単なるPingによる死活確認だけでなく、基本的なHTTP応答を確認できるような、より高度な外形監視を実装することが望ましいでしょう。
- 停止時間の判断基準も重要
  - 何分以上の停止を「障害」とみなすかは、システムの性質によって異なります。数分以内の短時間の停止であれば、翌営業日に対応するだけで十分なケースもあるかもしれません。
- 誤報のリスクと信頼性向上の工夫
  - 外形監視は、監視元（From）の信頼性やネットワーク経路上の問題によって誤報が発生する可能性があります。そのため、監視の信頼性を高める工夫も重要です。たとえば、複数のリージョンから監視を行ったり、監視システム自体に障害が発生した場合でも通知が行えるような設計が求められます。
50Xエラー*5監視について
- オンコール対象とするかどうか悩ましい監視項目
  - 50Xエラーは、ユーザーに対してサーバーエラーが返されている状態であり、一見すると即時対応が必要に思えます。しかし、件数が少ない場合には、すでにシステムが自動復旧しており、オンコール対応時には特に対処が不要となっているケースもあります。
- ユーザー影響の継続性と規模を重視する
  - そのため、こうしたエラーは外形監視によってユーザー影響の継続性や規模を判断し、オンコール対象とするかどうかを慎重に検討する必要があります。50Xエラー自体は重要なエラーとして分類しつつも、必ずしも即時対応が必要とは限らないという視点を持つことが大切です。
死活監視 (ノード監視、ICMP監視等)について
- 重要度は高いが、必ずしもオンコール対象ではない
  - 最近では、死活監視を重要なアラートとして分類していても、オンコール対応が必須とは限らないケースが増えています。多くのシステムが冗長化や自動復旧の仕組みを備えているため、夜間や休日に即時対応する必要がない場合もあります。
- 例外的なケースへの注意
  - とはいえ、現在でも一部の仕組みにおいては、死活監視の異常がシステム全体の停止に直結する可能性があります。そうしたケースでは、対象範囲を明確に限定したうえで、オンコール対応の対象とすることが適切です。
その他の監視について
- 重要度の高いケースもあるが、外形監視との連携が鍵
  - これまでの監視項目と同様に、その他の監視にも重要度が高いケースは存在します。ただし、外形監視で問題が検出されていない場合は、原則としてユーザー体験に大きな影響は出ていないと判断できることもあります。
- 割り切りと関係者との合意形成が重要
  - すべての未知の障害に対して即時対応が必要かどうかは、冷静に見極める必要があります。監視分類の資料などをベースに、お客様や上司などのシステムオーナーと十分に話し合い、対応の優先度やオンコールの範囲を明確にしておくことが重要です。

継続的な監視分類の見直しの重要性

これらの取り組みは、設計フェーズで検討される内容ではありますが、実際のシステム稼働を通じて得られる経験をもとに、継続的にブラッシュアップしていくことが重要です。 すべてを一度に変更するのではなく、段階的に監視分類を見直していくアプローチが現実的かつ効果的です。

具体的には、以下のような改善を積み重ねていくことになります。

閾値の見直し
ノイズの多いアラートの抑制
問題の根本原因の解決

これらの改善を進める際には、各アラートがシステムの重要度やユーザーのアクセスパターンに応じて、どのタイミングで対応が必要かという“文脈”を考慮し、オンコール対象とすべきかを慎重に見定める必要があります。

また、こうした判断は、プロダクトオーナーであるお客様や上司などのシステムオーナーとしっかりと会話し、認識を合わせておくことも非常に重要です。

最後に

監視分類が適切に行われていないと、チームメンバーが不要な対応に疲弊し、結果として運用コストの高いシステムになってしまいます。特定のシステムの監視設計をそのまま流用するのではなく、それぞれのシステムの重要度や、投入可能なコストに見合った形で監視を設計・分類することが重要です。

今回の内容が、監視改善の第一歩となり、皆さんが少しでも安心してぐっすり眠れる環境づくりに役立てば幸いです。

*1:オンコール（On-call）：システム運用などで、夜間や休日に障害が発生した際に対応するため、待機状態にある担当者のこと。アラート通知を受けて、必要に応じてリモートや現地で対応を行う。

*2:AWS Blackbelt：AWSが公式に提供している技術解説シリーズで、各サービスの概要から設計・運用のベストプラクティスまでを網羅的に学べる資料群。日本語での解説が充実しており、エンジニアだけでなく企画・運用担当者にも理解しやすい内容となっている。詳細は AWS サービス別資料を参照。

*3:リファレンスアーキテクチャ：特定のユースケースやベストプラクティスに基づいて設計された、システム構成の標準的なモデル。AWSでは公式ドキュメントやセミナー資料などで、信頼性・可用性・セキュリティなどの観点から最適化された構成例が多数公開されており、設計や実装の指針として広く活用されている。詳細は AWS Architecture Center を参照。

*4:SLO（Service Level Objective）：サービスレベル目標。システムやサービスがどの程度の可用性や応答性を維持すべきかを定量的に定めた目標値のこと。たとえば「月間稼働率99.9%」や「95パーセンタイルで応答時間500ms以下」などが該当する。

*5:50Xエラー：Webサーバーがリクエストを処理できなかった際に返すHTTPステータスコードの一群。代表的なものに「500 Internal Server Error（サーバー内部エラー）」「502 Bad Gateway（ゲートウェイ不正応答）」「503 Service Unavailable（サービス利用不可）」などがある。これらはサーバー側の問題を示しており、ユーザーにとってはサービスが正常に利用できない状態となる。