「SRE Meetup Tokyo」レポート
Googleがおススメするシステム運用管理手法「SRE」「SLO」のメリット(2/2 ページ)
モニタリング結果が管理者をだましているかもしれない
SREに限らないが、システム管理においてモニタリングは欠かせない。SLOを満たしているかどうか、システムに不具合はないかどうか、適切なパフォーマンスを維持できているかどうか、さまざまなモニタリングデータから判断し、必要な対処をする。しかし、その根拠となるモニタリング結果自体が、本当に信じられるものなのか。Google日本法人でSRE(サイトリライアビリティエンジニア)を務める関根達夫氏はイベントで、そんな疑問を投げ掛けた。
「モニタリングとは何かを知るための手段。いわば地図のようなものです。地図から想像した状況と現地の状況に差があるように、モニタリング結果から読み取れる情報とシステムの本当の状態との間に、違いが生じることがあります」(関根氏)
関根氏はこの状況を「モニタリング結果にだまされる」と表現した。よくある例として、同じ方法で複数のサーバのパフォーマンスをモニタリングした場合を取り上げた。4つのサーバからリクエストを処理した数を収集し、パフォーマンスをグラフ化するという簡単な例だ。健全な状態であれば、それまでのリクエスト数を時間で割ると一定時間に処理したリクエスト数が得られる。
しかし、一部のサーバでデータ取得に失敗した場合、その時間にはリクエストがなかったことにされる。その次のデータ取得のタイミングで正常にリクエスト総数が得られたとしても、実際の挙動とは違うグラフになってしまう。
このような「ウソ」を減らすためには、データ取得のメソッドを変えたり、取得したリクエスト数の集計方法を変えたりする必要がある。しかしデータ取得失敗のような異常な状況が発生しなければ、集計方法の不備に気付くこともできない。そのままシステム管理を続け、いつかモニタリング結果にだまされるというわけだ。
他にもモニタリングの粒度、モニタリングする場所、複数のデータソースをモニタリングする際のデータ集計方法の違いなど、モニタリング結果にだまされる例は幾つもあると関根氏は指摘する。「例えばネットワークにエラーがあってサービス不全に陥った場合、サーバ側だけでモニタリングしていても気付くことはできません」(同氏)
モニタリング結果を左右する要素として関根氏は、データ集計時のバケットサイズを挙げる。ここでいうバケットとは、集計を容易にするために、対象となるデータをひとまとめにする単位と考えてほしい。例えばレイテンシ(通信の遅延時間)のモニタリングにおいては、平均値を見るのではなく、どのような部分でレイテンシが高まっているのかを知る必要がある。しかし、そのために全てのモニタリング結果を地道に計算していては、モニタリングに高い負荷がかかる。そこでレイテンシ1ミリ秒以内、2ミリ秒以内などとモニタリング結果をバケットに入れて集計するのだが、この場合も粒度が問題になる。バケットサイズを一定にするとデータ処理に負荷があまり軽減できないからだ。
レイテンシモニタリングの場合は「1.2倍ずつ等比級数(等比数列の和)的にバケットサイズ(1回のモニタリングで取得する単位データ)を大きくしていくと、だいたい正しい値が出ます」と関根氏は語る。最初のバケットには1ミリ秒以内でレスポンスを返した数、次のバケットでは1ミリ秒から2.2ミリ秒以内(バケットサイズは1.2ミリ秒=1ミリ秒の1.2倍)、その次は2.2ミリ秒から3.66ミリ秒以内(バケットサイズは1.44ミリ秒=1.2ミリ秒の1.2倍)といった具合だ。Googleではレイテンシのモニタリング時に、レイテンシの95パーセンタイル値(データを昇順に並べて、全体を100として小さい方から95番目に位置する値)を見ることが多いという。同じデータを基にバケットサイズを一定にした場合と1.2倍ずつ大きくした場合とを比較してみると、レイテンシの95パーセンタイル値は双方ともほとんど同じ値になっていると同氏は説明する。
バケットサイズを大きくしていけばモニタリング負荷は軽減できる。しかし同じデータを1.4倍ずつ大きくなるバケットサイズで集計すると、95パーセンタイル値は150ミリ秒となり、誤差が生じる。同じようにバケットサイズを2倍ずつにした場合とは180ミリ秒、4倍ずつにすると250ミリ秒となり、もはや元の値とは懸け離れてしまう。バケットサイズやデータ分析粒度の重要性がよく分かる例だ。
「重要なことは、自分の見ているモニタリング結果が、どのようなモニタリングシステムで得られたものかを考えることです。異常値が見つかった場合にはモニタリング手法が正しいのかどうかも疑い、最終的には生データを確認することで正確な状況把握をしてください」(関根氏)
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Excel至上主義」の終わらせ方 丸2日の手作業地獄から情シスと現場を救うには
-
2
「Microsoft 365のセキュリティ運用」に関するアンケート
-
3
取手市がVDIと決別した理由 更改費用「4倍超」を約1.7倍に圧縮
-
4
急増する「AIはこう言ってる」マン 判断を狂わせる「AI忖度」を防ぐには?
-
5
221人調査で分かった「情シス最大のストレス」は?
-
6
「Salesforceのテスト自動化ツール」に関するアンケート
-
7
IT製品の導入に関するアンケート「サーバ&ストレージ」編
-
8
「データストレージの活用方法」に関するアンケート
-
9
「AI時代の統合基盤・エンタープライズAI管理」に関するアンケート
-
10
自宅のWi-Fiが「遅い」「途切れる」本当の原因は? Dellが推奨する鉄則
ホワイトペーパーランキング PR
-
1
年収2000万「クラウドセキュリティのプロ」になれる資格とは
-
2
セキュリティソフトをすり抜ける標的型攻撃メール、不審メールの見破り方とは?
-
3
Windows Updateの通信集中で回線が逼迫、ネットワーク刷新事例に学ぶ解決策
-
4
財務を戦略的組織へ進化させるAI活用術、4つの主要な障壁と解消方法
-
5
「NAS」「SAN」「DAS」は何が違う? いまさら聞けないストレージの基礎
-
6
“あのファイル転送”で暗躍するノーウェアランサム
-
7
標的型攻撃メールを見破るには? サンプル文面を例に傾向を解説
-
8
商用利用の安全性を確保し大量のコンテンツを高速で生成する、AI活用の秘訣
-
9
マンガで解説、1日で生成AI環境を構築できるワークショップの中身とは?
-
10
Dark AIが台頭する時代の新発想、「より高度なAIで対抗する」具体的方法とは?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー