なぜベテラン運用者は「しきい値超えのアラート」を静観できるのか ブロードリーフが考える“アラートへの向き合い方”：「Cloud Operator Days Tokyo 2022」セミナーレポート＃5

Cloud Operator Days Tokyo 2022のセッション「効果的なアラートを再考する『メモリ使用率が80%になりました。』んで、どうすればいいん？」にてブロードリーフの左近充 裕樹氏は、監視の基礎である「アラート」に対する向き合い方や対処方法を解説した。

[齋藤公二，＠IT]

印刷

隕九ｋPost

Shareシェア

はてなブックマーク

SharePocket Button

　運用担当者の悩みの一つに「何のためか分からないアラート」がある。大量に発生しているが「しきい値を超えたこと」を知らせるだけで、緊急度や原因を知らせてくれるわけではない。放置できないので一つ一つ調べようとするが、ベテランの運用担当者は「それは放っておいてよい」と安心し切っている（そして実際、問題にはならない……）。「このアラートは本当に必要なのか？」、そんなもやもやを感じたことのある運用担当者は多いだろう。

　ブロードリーフの左近充 裕樹氏（プロダクトインフラ課　インフラエンジニア）は、Cloud Operator Days Tokyo 2022のセッション「効果的なアラートを再考する『メモリ使用率が80％になりました。』んで、どうすればいいん？」にて運用管理者がアラートにどう向きあうべきかを紹介した。

アラートとは「システムを正常に動作させる対応を行うためのトリガー」である

ブロードリーフの左近充 裕樹氏

　ブロードリーフはモビリティ産業向けにSaaS「.Cシリーズ」（ドットシーシリーズ）を中心としたITソリューションを提供している。左近充氏はそこでインフラの運用を担当している。

　左近充氏が常々疑問に思っているのが「メモリ使用率が80%になりました」とだけ伝えるアラートの存在だ。

　「ベテランの運用担当者であれば『これはすぐに復旧する』と判断し、静観する。すると大体は狙い通り復旧し、復旧（正常範囲に戻った）を知らせる通知が届く。問題がないことはよいが、果たしてこのアラートに意味はあるのか」

無意味なアラート

　アラートとは、システムが正常に動いているかどうか、ユーザーが満足して使えているかどうかをチェックために必要なものだ。だが、「メモリ使用率がしきい値を超えた」とだけ伝えられても運用担当者は何をすればいいのか分からない。もちろん、アラートが発生した原因も分からず、ユーザーやシステムに影響が出ているのかどうかも分からない。

　「アラートはシステムの状態を監視し、正常な状態を維持するために必要な手段だ。言い換えればシステムが正常に動作しなくなることが明らかな場合に『システムを正常に動作させるためのトリガー』にしなければならない」

4大シグナルを監視せよ

　アラートを、システムを正常に動作させるトリガーとするためには“何を監視させるか”が重要になる。左近充氏は監視対象について書籍『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』（オライリージャパン）を参照し、次のように解説している。

　「同書では、監視対象として『レイテンシ』『トラフィック』『エラー』『サチュレーション』の4つを挙げている。レイテンシは、リクエストを処理してレスポンスを返すまでにかかる時間。トラフィックは、システムに対するリクエストの量。エラーは処理に失敗したリクエストのレートで、サチュレーションは、サービスがどれだけ“手いっぱいになっているか”を示すものだ」

　この「4大シグナル」を計測し、「問題が生じたときに対応することでサービスが維持できる」と左近充氏は説明している。例えば「外部から疎通ができない」「エラーレートがいつもの2倍になっている」「ストレージの使用率が90％を超過している」「メモリの使用量が80％を超過している」などの場合、システムが正常に動作できない（できなくなる可能性が高い）状態だといえる。

　左近充氏は「アラートを出す条件の工夫も必要だ」と指摘している。

アラートを出すタイミングが重要

　「特定のしきい値だけでなく、変化量も測定するようにする。たった数分でメモリ使用量が30％から70％に上がるようなことがあればシステムに何か異変が起きている可能性が高いが、しきい値を設定しているだけではそういった変化に気付けない。他にも、ユーザーの満足度を意識してレイテンシは平均値ではなく『パーセンタイル』を使うといった方法が有効だ。平均値でレイテンシを測定すると、遅延が全体に紛れてしまい監視側では気付きにくい。ユーザーは特定のリクエストが遅いことより、平均的に少し遅い方が不満を感じにくいのでパーセンタイルの数値でユーザーへの影響を捉えた方が実態に近くなる」

肝心なのはアラートの“伝え方”と“対応手順書”

　「通知の伝え方を工夫することも重要だ」と左近充氏は指摘している。ユーザーに影響が出ているような重要度が高いアラート（High）なら、電話とSMS（Short Message Service）、「Slack」などのメッセージツールを併用し、「人間が気付きやすい形で知らせる必要がある」と左近充氏は言う。

重要度に合わせて連絡方法を工夫する

　「すぐに影響はないにしても今後問題が発生しそうなもの（Mid）なら、連絡にはメッセージングツールを使い、後で対応しやすいように『JIRA』などでチケットを起票するのも効果的だ。一方、特に対処は不要だが、今後問題が発生した際に見直せるようにするもの（Low）は、『ログに記録するだけ』にすることで余計な情報に惑わされなくなる」

　左近充氏は見落とされがちなポイントとして「アラートに対応した手順書を用意すること」を挙げる。

　「アラートが発生するとどうしても焦ってしまい、それが新たなミスを誘発する。手順と異なることをしてしまう“うっかりミス”は当然として、例えば『以前使った復旧用のコマンドを実行したらもう使えなくなっていた』というミスもあり得る。コマンドなど一連の作業内容を手順書の形で整備しておけばそうした事態を防ぐことができる」

　手順書のメリットは他にもある。手順書の形になっていれば、ベテランの運用担当者でなくとも適切な対応ができるため、オンコール対応のローテーションも組みやすくなる。また、手順書には「どのような問題がこのシステムに発生したことがあるのか、どのような問題を抱えているのか」という情報が含まれているため、「新しく入ったメンバーのオンボーディングに利用することもできる」と左近充氏は指摘している。

Runbookは「レシピ」、Playbookは「ガイドブック」

　手順書には「Playbook」「Runbook」といったように幾つかの種類がある。左近充氏はインシデント管理プラットフォームを提供するPagerDutyのブログを参考に、Runbookを「レシピ」、Playbookを「（冠婚葬祭などの）イベントを進行するためのガイドブック」に例えている。

　「食事を作るためにレシピは必要だが、イベント全体から見れば一部にすぎない。大まかな流れはPlaybookに記載し、細かい手順はRunbookに記載するなど、使い分けることが重要だ」

　例えば「データベースクラスタのヘルスチェックで問題が発生した」というアラートには、データベースクラスタのヘルスチェックに関連するPlaybookを用意し、その配下に「VMへのログイン方法」「データベースのヘルスの確認方法」「データベースの再起動方法」など具体的な対処方法が記載されたRunbookを作る、といった感じだ。

アラートとPlaybookとRunbookの関係性の例

　「PlaybookとRunbookを分けておくと、『パブリッククラウドのログイン方法が変わる』『画面イメージが更新される』といった変化があっても、該当するRunbookだけ修正すればよいというメリットがある。修正漏れが多いと手順書への信頼性も落ちてしまうので、できるだけ“ドライな形”で最新状態を維持することが大切だ」

　細かな手順はRunbookに記載するとして、Playbookには何を書くべきなのか。左近充氏はPlaybookに記述すべきものとして以下、9つのポイントを挙げる。

• ユーザーへの影響
• 他システムへの影響
• 推奨される実施者（担当チーム）
• 制約事項（必要な権限、必要なルール）
• アラートの目的
• 何が発生しているか
• 調査方法や対応方法（Runbookへのリンク）
• エスカレーション先
• 正常時の状態（復旧したかどうかを判断するため）

「アラート疲れ」にも注意

　ここまで「無意味なアラートにならないようにするには、どのような点に注意して監視すべきか」「適切に対処するためにはどのような準備、対策が必要か」といった内容について触れてきた。左近充氏は「そもそもアラートを出させない工夫も必要だ」と指摘している。

　「アラートが多過ぎると確認する手間が増え、担当者が疲弊してしまう。そうした状況が続けば、せっかくのアラートが無視されてしまう。それでは意味がない。『偽陽性のアラート』をなくすことも重要だ」

　ここで言う“偽陽性のアラート”とはユーザーへの影響のない、形だけになってしまったアラートのことだ。静観していればいい「メモリ使用量80％超えのアラート」がそれに当たる。もちろん、ユーザーへの影響がないかどうかを確認するには、本稿で触れたポイントを抑えた監視が必要だ。

　また、「ユーザーへの影響はあるが、復旧作業を自動化できるアラート」を増やすことも“アラート疲れ”の防止に役立つと左近充氏は言う。

　「手順書を作れるということは、その作業は自動化が可能だ。自動化を進めることでアラート対応をする担当者の負担を減らすことができる。さらに、運用チーム内でリソースの傾向を定期的に確認しておけば、アラートが出る前に不具合や障害の予兆を知ることも可能だ。こうした活動もアラート疲れの防止には有効だ」