お疲れ様です。技術ブログを久しぶりに投稿します。SREチームのキム・ドンヒョンです。
SREチームは、信頼性の高いシステムを提供するため、様々な活動を通じてシステムをサポートしています。その中でもシステムの監視と通知活動は、SREチームの重要な業務の一つです。今回は、サービスの安定性を確保するための重要な活動の一つである閾値設定について詳しく説明します。
目次
基本的な監視と閾値設定
基本的なシステムの監視は、システムのパフォーマンスが特定の閾値を超えたり下回ったりしたときに警告を発することです。こうした監視により、システムは自己フィードバックを受けて安定した正常状態を保つことができます。例えば、エアコンのように室内温度を一定に保つ必要があるシステムでは、温度が一定の範囲を外れるとイベントを発生させたり、必要な動作を行ったりしてシステムの安定性を維持します。このような閾値設定は、システムの特性に応じて異なり、システムの特性を理解して適切な閾値を設定することが非常に重要です。
また、閾値の許容範囲を狭く設定しすぎると通知が頻繁に発生し、その確認に高いコストがかかります。反対に、閾値を広く設定しすぎると、システムの状態が不安定になっても通知が発生せず、インシデントに繋がる可能性があります。この重要な閾値をどう設定すれば良いのでしょうか?経験にだけ頼るべきでしょうか?
さらに、システムを利用する顧客の要求は、時間帯、曜日、ゴールデンウィークや年末年始などの特定のイベントに応じて変化します。この場合、システムのパフォーマンスは常に一定の値に収束するのではなく、これらの変数に応じて通常の値が変動するため、固定された閾値ではシステムを効果的に監視するのが難しい場合があります。次の例を見てみましょう。
システム監視値の例
以下は、あるシステムのユーザー要求に対するパフォーマンスの記録を示したデータです。測定された表のp50の意味は平均的な値であり、p99は上位1%の値を示します。しかし、表を見ると前半と後半で異なるパフォーマンスの様相を示しています。このような場合、適切な閾値を設定するにはどうすれば良いのでしょうか?
測定表を見てみると、p50の値は1番から14番までは単位時間1未満のパフォーマンスを示しています。この状況だけを見ると、1を閾値に設定しても問題ないように見えます。しかし、25番から35番までは1の値を超えているため、1を閾値に設定すると、25番から38番までのイベントは継続的に警告が発生することになります。
また、後半の場合を考慮して10程度を閾値に設定すると、前半の値では警告は発生しませんが、閾値の許容範囲が広すぎると、意味のあるイベントが発生しても無視されてしまうことになります。このような場合には、閾値を動的に設定する方法があります。
動的閾値の設定
動的に閾値を設定する方法にはいくつかあります。例えば、業務時間と深夜のように絶対的な時間を基準にしてそれぞれ異なる閾値を使用したり、曜日を基準にして異なる基準を使用することなどが考えられます。ここでは、いくつかの世代のサンプルを利用し、標準偏差を活用して現在の値が意味のあるイベントであるかどうかを計算して閾値を動的に決定する方法についてご紹介します。数式としては68–95–99.7則を利用してみたいと思います。
68–95–99.7則
ウィキペディアでは68–95–99.7則を次のように定義しています。
「統計学における68–95–99.7則(英: 68–95–99.7 rule)とは、正規分布において、平均値を中心とした標準偏差の1倍、2倍、3倍の幅に入るデータの割合の簡略表現である。より正確には、68.27%、95.45%、 99.73%である。」
数学的には、平均 μ で標準偏差 σ の正規分布に従う確率変数 X は以下の式に従います。
この式は平均と標準偏差を活用して、現在のサンプル値がどの程度通常の範囲内であるかを計算することができます。この時に通常の値を外れる意味のあるイベント、スパイクの定義も重要です。通常の範囲を68%にするか、95%にするか、99.7%にするか、どの程度まで設定するかが重要です。
この時に3シグマの範囲を選択すると、ほぼ確実な場合にのみイベントが発生しますが、2シグマの範囲を選択すると、95%の通常の範囲外のイベントも捉えることができます。予防的に警告を発することが重要な場合には2シグマの範囲を選択するのが適切です。通常の範囲内のサンプルである確率95%を超えるイベントをスパイクと定義し、これをデータマイニングすると結果は次のようになります。
適用
結果として示される次の表は、2シグマを利用して閾値を設定した結果です。平均は10世代の平均値を使用し、標準偏差は10世代のサンプル値を使用しました。警告は現在のサンプル値(p50)が平均から2シグマを超える場合に発生するように設定しました。実際の監視スクリプトではプログラムを通じて計算しますが、エクセルを利用して簡単に計算することもできます。平均値はAVERAGE
関数を使用し、標準偏差はSTDEV.S
関数を使用すれば良いです。
この表を見ると、徐々に高い数値のサンプル値が続くに連れて、通常の95%確率範囲の数値が徐々に大きくなっていくことがわかります。この数値を超える不自然なイベント(警告)が発生した場合はシステムを確認するのが良いでしょう。この範囲を外れるイベントが発生する時に警告を発するのが適切だと判断されます。ある絶対値の閾値設定と並行して使用し、システムの安定性を確保することができます。
応用
統計を使用した動的閾値設定は標準偏差を利用する方法以外にも、CDF(累積分布関数)を利用する方法や、ポアソン分布を利用する方法など様々な方法があります。こうした統計を利用した監視は実際にも様々な分野で使われている方式です。例えば、
- GoogleのAdSenseの不正行為検出(不自然な広告クリックの増加がある場合に警告を発する)
- 健康の異常を検知する医療機器(普段と異なる心拍数や血圧が測定された場合に警告を発する)
- 市場や株価などの突然の経済的変動を検知する
などが挙げられます。こうした方法は統計と確率を活用してシステムの安定性を確保するのに非常に有用な方法です。
まとめ
今回の投稿では確率と統計を活用してデータマイニングを通じて、意味のあるイベント発生の可否を動的に決定する方法についてご紹介しました。動的閾値の設定に関する洞察は単にシステムだけでなく、生活にも適用できるものです。つまり、
- 小さな事故を頻繁に経験するシステムは大きな事故に遭遇することも不自然ではなく、
- 小さな成功を頻繁に成し遂げる人は大きな成功を成し遂げることも不自然ではないということです。
そして今回の技術ブログをGMOイズムにもあるこの言葉で締めくくりたいと思います。
「人間の行動の9割は習慣である。良い習慣を身につけよう。」
ブログの著者欄
採用情報
関連記事
KEYWORD
CATEGORY
-
技術情報(433)
-
イベント(159)
-
カルチャー(36)
-
デザイン(17)
TAG
- 5G
- Adam byGMO
- AI
- AWX
- BIT VALLEY
- blockchain
- ChatGPT
- cloudnative
- CloudStack
- CM
- CNDO
- CNDT
- CODEGYM Academy
- ConoHa
- CS
- CSS
- CTF
- DC
- Designship
- Desiner
- DevSecOpsThon
- Docker
- DTF
- GitLab
- GMO Developers Day
- GMO Developers Night
- GMO GPUクラウド
- GMO Hacking Night
- GMO kitaQ
- GMO SONIC
- GMOアドパートナーズ
- GMOアドマーケティング
- GMOイエラエ
- GMOグローバルサイン
- GMOソリューションパートナー
- GMOデジキッズ
- GMOブランドセキュリティ
- GMOペイメントゲートウェイ
- GMOペパボ
- GMOリサーチ
- Go
- GTB
- Hardning
- Harvester
- HCI
- iOS
- IoT
- ISUCON
- JapanDrone
- Java
- JJUG
- K8s
- Kids VALLEY
- LLM
- MetaMask
- MySQL
- NFT
- NVIDIA
- OpenStack
- Perl
- PHP
- PHPcon
- PHPerKaigi
- QUIC
- Rancher
- RPA
- Ruby
- Selenium
- Spectrum Tokyo Meetup
- splunk
- SRE
- SSL
- Terraform
- TLS
- TypeScript
- UI/UX
- VLAN
- VS Code
- アドベントカレンダー
- インターンシップ
- オブジェクト指向
- オンボーディング
- お名前.com
- カルチャー
- コンテナ
- スクラム
- スペシャリスト
- セキュリティ
- ソフトウェアテスト
- チームビルディング
- ドローン
- ネットワーク
- プログラミング教育
- ブロックチェーン
- ミドルウェア
- モバイル
- ゆめみらいワーク
- リモートワーク
- 京大ミートアップ
- 基礎
- 多拠点開発
- 大学授業
- 宮崎オフィス
- 応用
- 技育プロジェクト
- 新卒
- 暗号
- 機械学習
- 決済
PICKUP