WEBサービス監視を設計する際に決めること

はじめに

これはドリコム Advent Calendar 2020 の18日目です。 17日目は 橘田隼一さんによる「CI、CD、そしてPDにて」です。
こんにちは。SRE部のひらしーです。 今回はWEBサービスの監視システムを設計する際にどのようなことを決めておいたほうが良いかを紹介します。

我々は何を監視すべきか

 サービスが健全な状態とはどういう状態か 

全てはこちらを決めるのがスタートとなります。
人間が把握するためには数値の指標を決めなければなりません。メジャーな指標としてSLO/SLI/SLAがあります。

• サービスレベル目標 (Service Level Objective = SLO)
  • サービスの信頼性として目指す目標
• サービスレベル指標 (Service Level Indicator = SLI)
  • SLOを満たすために収集する指標
• サービスレベル合意 (Service Level Agreement = SLA)
  • ビジネス上ユーザに対して約束する合意

特にSLOはサービス利用者に具体的に何を提供すれば価値があるのかを決めることになるので、とりあえずこれだけを決めることだけでもメリットはあると思います。

サービスが健全であるために何に気付きたいのか

SLI/SLO/SLAは主にサービスやシステムの状態を数字として把握するためのものですが、これのサブセットとして気付きたい変化も多岐に渡ると思います。以下に一部例を挙げます。

• 現在は正常な指標で稼働しているが長期的に見て不健康な状態に変化をしているか
• 直ちにサービス・システムの指標には関連しないがチームの成長やサービス向上を阻害しているか
• サービスに携わるエンジニアのトイルとなっているか

不健全の定義

サービスが健全な状態を定義するには、サービスが不健全であったり異常である状態を定義することが近道です。以下に具体例を挙げます。

• ユーザがサーバにアクセスした全ての試行回数の内成功した割合xx%以下を異常とする
• ユーザがサーバに正常にアクセスした際に正常な結果が画面に表示されるまでの時間を計測し、全体でxx分間の平均がxx秒以上を異常とする
• １ヶ月の外部PaaS/SaaS/IaaSにかかる費用がxx円を超えることを不健全とする
• 手動でメール返信する作業が1週間でxx件以下又はxx件を超えることを不健全とする
• 1日あたりのアクティブユーザ数(daily active users,DAU)がxx以下を不健全とする
• CPU使用率がxx%～xx%以外の状態の稼働中仮想マシンの全体の割合がxx%以上を不健全とする

不健全の際に何をするのかを決める

不健全の定義はその際に何を行動するのかをセットで決めて下さい。
また、この２つは定期的に見直し、積極的に廃止・更新しましょう。

監視システム

何を監視すべきか決まったら手段について検討しましょう。
監視システムとしては大きく分けて外部のSaaS採用、OSSでの構築、SaaS/PaaS上に自分のコードを置くパターンがあります。

• SaaS
  • Mackerel
  • Datadog
• OSS
  • Zabbix
  • Prometheus
• SaaS/PaaS上に自分のコードを置く
  • AWS/Lambda
  • Google Apps Scripts

選択するポイントは以下があります

• 費用
  • 特にSaaSを採用する場合は大規模になるほど高額なので見積もりに注意しましょう
• 習熟・完成に要する時間
  • OSS利用や自前で環境を構築する場合は必要となる技術も増えます
• 日々の運用の手間
  • 設定をコードで管理できるソフトウェア/SaaSであれば監視業務に参加するエンジニアも増えるでしょう。また、作業者のアカウント管理の手間も事前に検討しましょう
• 将来のサポート
  • 古いOSSやマイナーすぎるSaaSを利用する際は将来的に存続しなくなるケースも想定しましょう

通知方法

不健全な状態に迅速に対応するために以下のような通知方法を検討しましょう。
後述するエスカレーションと組み合わせることがお薦めです。

• メール/SMS
  • いわゆるアラートメールです。迷惑メールで気付かなかったり受信が多すぎて埋もれることが多いので新規に採用することは控えたほうが良いかもしれません
• 電話(システム自動による)
  • 担当者に直接自動音声の着信をかけるので、サイトがダウンした際などの緊急事態の通知方法のみ使用するのが良いでしょう。一般的にはSaaSを利用することになるでしょう
• Chatアプリ
  • Slack/Chatwork/LINE等通常業務で利用しているアプリに通知することで、シームレスに対応チームの会話に流れることができるのでお薦めです
• 専用スマートフォンアプリ
  • PagerDutyやServiceNowのようなインシデント管理SaaSサービスを採用しているのであれば専用のアプリにて通知を受けることも良いでしょう

エスカレーション

アラートの重要度(severity)とアクションのパターンを事前に決めておくことで休暇中の人への連絡や重要なアラートに気付かなかったケースを減らすことができます。
監視システムによっては明示的にエスカレーション機能がないケースがあるので、その際は通知先グループにて代替えして下さい。
以下に、エスカレーションする際のパターンのサンプルをいくつか挙げます。

• 深刻度レベル別エスカレーション
  • information: 情報
    • アクション: 特に対応する必要はない
  • warning: 軽度の障害
    • アクション: 期限はないが対応する必要がある
  • critical: 重度の障害
    • アクション: 次の営業時間内に対応する必要がある
  • fatal: 致命的な障害
    • すぐに対応する必要がある
• シンプルなエスカレーション
  • warning
    • アクション: 勤務時間外であれば対応しなくても良い
  • critical
    • アクション: 勤務時間外でも対応すべき
• 送信メディア別エスカレーション
  • alert
    • すぐに対応する必要がある
  • ticket
    • チケット管理システム(JIRA等)に登録されているのでいつか対応する必要がある
  • logging
    • ロギングシステム(Cloudwatch Logs等)に記録される。特に対応する必要はない

オンコール担当

オンコールとはエスカレーションが発生した際に担当者を呼び出すことです。オンコール担当とは一般的には時間外に問題を解決するための担当です。特定の人がいつもオンコール担当になってしまうと、その人の疲弊や問題解決自体の品質劣化を招くので以下の観点で決める様にしましょう。

• まずはオンコールすべき問題の有無と頻度を把握する
  • エスカレーション、自動解決の仕組みでオンコールすべき問題が減ればオンコール担当の作業量、担当日数を減らすことができます
• オンコールローテーションを組む
  • 日替わりで別の人がオンコール担当になるようにスケジュールを組みます。深夜や休日担当が必要な場合は同じ人が週2回以上に担当にならないようにしましょう
• グループチャットを有効に活用する
  • エスカレーションに即時に対応できるオンコール担当が大勢いる環境がなければ、チャットアプリのグループ機能による通知を利用しましょう。ただしグループ内特定メンバーに対応が集中することを避けて下さい

インシデントの管理

サービスが不健全な状態を解決するまで複雑なエスカレーションを経由したり、時間が掛かるケースもあります。一般的には PagerDutyのようなインシデント管理ツールを採用するのがお薦めです。以下前回私が書いた記事も参考にして下さい。 PagerDutyでアラート管理を改善した話

ポストモーテム

ポストモーテムは事後検証と訳されます。特に重大な障害が発生した際には同じことを繰り返さないためと根本原因の分析から多くの学びを得るために積極的に実施するようにしましょう。
一般的にはチームで決めたドキュメントのフォーマットを定義し、発生したサービス障害単位で作成します。弊社SREチームでは以下の項目に沿って作成しているので参考になればと思います。

• 障害の概要
• 障害の影響
• 根本原因
• 発生原因
• 対応
• 検出
• 今後のアクション・改善点
• 教訓
• うまくいった事
• うまくいかなかった事
• 幸運だった事
• 再発防止の為にできる事
• タイムライン

まとめ

WEBサービスの監視システムを設計する際に決めておきたいことを早足で紹介させて頂きました。 昨今では監視システムもSaaS、OSS含めて充実していますが、だからこそサービスやチームを軸足にした最適な運用を設計しましょう。
明日の記事は Egliss さんの「WPFでノードエディタを作ってみる」です。 
ドリコムでは一緒に働くメンバーを募集しています！
募集一覧はコチラを御覧ください！