昨今の新型コロナの影響により新しい生活様式を取り入れるなど、目には見えないウィルスによって人々の暮らしはアフターコロナではなく with コロナの真っただ中。時短営業に在宅テレワーク・外出自粛と世の中が変わり、消費傾向も変わり、人々が求めているものも変化しつつあります。
私自身、在宅勤務を増やすと出てくるのが筋肉の衰えです（電車通勤が減ることによる脚力の衰えは久々に出社した翌日のスネあたりに…）。最近ではヘルスケアツールを利用しており、体温・体重・心拍数・血圧・筋肉量・歩数等々の自己監視をして「平常時」がどのような状態かをモニタリングしております。また健康診断のデータもインプットしたり、昨年対比も見たりして自分の身体の状態をチェックしています（ただしチェックしただけでは筋肉は戻ってきませんが）。

さて、今回のコラムは「性能監視」と題しましたが、過去のコラムにも何度か似た題材で登場しています。

要約すると、
・システムを安定的に運用する（異常把握・運用見直し・サービス停止による業務影響）
・適切なリソースとコスト管理（キャパプラ・サイジングによるコスト最適化・適切な設備投資）
・品質や効率向上（その為のデータ収集・改善）
などがあげられますが、「目的をもって性能監視をしましょう、死活監視だけでは足りないですよ」とお話ししております。

性能監視の神髄は、収集したデータから予測する見えないデータや紐づきにくいデータを相関して視る事です。性能監視もデータを取得しておけば安心ということではありません。常日頃からデータの動きを読み取って、その変動値の影響は何からくるものなのかを読む（推測する・仮説を立てる）必要があります。
その為には、取得できるデータは多く、取得項目が多い方が、分析時に役立ちます。無論、性能監視運用に無意味なパラメーターもありますので取捨選択は必要です。

例えば、監視でよくある CPU、メモリー、トラフィックに焦点を当てると、CPU が 80％ の使用率を超えた場合に何故、超えたのか…（瞬間的なスパイクを発生させただけかもしれません）。その瞬間に何がおこなわれて 80％ になったかは CPU の監視だけでは理解することはできません。機器によっては、最初から CUP 負荷が 60％ の製品もあると思います。
メモリーも同様に、何もしてないはずなのに初期の段階で使用率が高い場合があります。そして CPU 負荷とトラフィック負荷が連動する時もあればそうでない時もあります。

また、突然の短時間の通信断が発生した時、特定機器からアラートが出ていたが、その発生要因は別の冗長化された機器の 1 台がハードウェア不調を起こしていた原因に影響されたというケースもあります。この例えは実際にあった話です。

見えているデータだけで解決出来ないケースもあるかと思いますが、性能監視は「見えているもの以外の原因を見抜く最初のきっかけ」でもあります。

こんな経験はないでしょうか ？ CPU 負荷は高くないけど処理が重たい、という症状。ネットワークが遅いのか何なのか、その時は突然やってきます。その場合に何の情報を参照すると良いでしょうか。
または、既にずっと重たい症状に悩まされており、根本原因が掴めず、性能監視を入れてみようと思うケースもあるかと思います。

突然の不安定が発生した時は、恐らく何かしらのリソースバランスを崩し雪崩のように影響し始めたか、想定外のリソース消費があったか、蓄積されたものが破綻し始めたかというあたりでしょうか。
人であれば、調子を崩した状況に応じてかかりつけ医に行って見てもらうか、状態によっては救急車を呼ぶかという事だと思います。
ただ、性能監視をおこなう皆様は少しでも早く障害や不調から回復したい一心かと思います。私がインフラ運用者だった時、性能監視の導入目的は障害原因把握の速度向上でした。色々な機器からの値を数字で見て判断するためには、あまりに数字変動が多く、記憶に留めておけないからです。そして障害時には、機器の状況確認のためのアラートの内容をみて、ログを確認して追いかけますが、複合障害時に確認しなければならない情報量はとても多すぎます。そして思うのです、「平常時の値は？」と。少し前が本当の正常値かどうかも疑ってくるようになります。少し前までどういった状態だったのかを客観的に素早く把握したいわけです。ただ単に「エラー」となっているのであれば、それは性能の話ではありませんが、何かのバランスを崩した結果のエラーかもしれません。

もっとも難しいのは、潜在的にバグやメモリーリークを抱えている機器やアプリケーションです。初期の段階でひたすら緩やかに異変となる値が増加する要素は、中々平常時の値と考えるには難しいです。しかし、大抵はアプリケーション開発時やシステム構築時、性能監視は後回しになっている事が多いのではないでしょうか。

また、快適な環境になった時こそ、そこに魔物が潜んでいます。快適になると利用率が向上し、更に追加された機能が増え、データ量増加などを起こします。そしてシステムは拡張し複雑化が進んでいきます。その時に想定外の悲鳴をあげるシステム…。ですが死活監視だけでは、どの様に悲鳴をあげたのか追跡が出来なくなります。サイレント障害等は死活監視ではアラートも発生しませんので、性能値などで判断していくことになると思います。
その為、性能監視をおこなうことにより、常に何かしら構築した初期の頃から収集した「平常時」のデータを詳細に収集 / 保存し、平常時のデータ精度の向上や異常値の把握が早期発見に役立てることが出来ます。CPU やメモリの使用率が低い事が良いわけではなく、「平常時」のパフォーマンス値を知ることが重要です。使用率が低いだけならリソースの見直しを求められます。

このように、「性能監視」によって「平常時」を知ることは、迅速な障害の原因特定に役立つのです。

次回のコラムでも、引き続き「性能監視」ついて解説していきます。次回は、人が見て分かりやすいように「可視化」することの重要性と、具体的な監視項目についてお話しします。

by DX 営業推進部　次長　夏堀 貴仁