性能管理

読み：せいのうかんり　／　英語表記：Performance Management

• 性能・監視・運用

性能管理とは、通信量や遅延、資源の利用状況などを継続的に測定・分析し、必要なサービス品質を維持するために改善や容量の計画を行う管理活動である。現在の状態を評価するだけでなく、需要の増加や構成の変化による性能不足も予測する。

イマシルちゃんの解説

機器が壊れていなくても、通信が遅くて仕事が進まないことはあるよね。
性能管理は通信の待ち時間や実際に送れる量を調べて、必要な使い心地を保つための活動なんだ。
例えば昼休みだけ画面が遅いなら、その時間の通信量や機器の負荷を比べて原因を探すよ。
回線の速さだけでなく、途中の機器やサーバの処理が影響していることもあるんだ。
平均の値では短い混雑を見落とすこともあるから、目的に合った測り方を選ぶことが大切だよ。
利用者が増えた場合や予備の回線に切り替えた場合も考えて、将来まで無理なく使えるようにするんだね。

より深い解説

業務で必要な性能から測定を決める

性能管理では、機器が応答するかだけでなく必要な処理を十分な速さで行えるかを評価する。ITU-T X.700は、資源の振る舞いや通信活動の有効性を評価するための統計収集などを性能管理に含めている。障害管理が異常からの正常化を扱うのに対し、性能管理は状態の測定と傾向の分析から必要な能力を維持する。

必要な指標は用途によって変わる。大きなファイルを転送する業務では完了までの時間と転送できる量が重要になる。音声通話では届くまでの時間や到着間隔の乱れが品質に影響する。画面操作の多い業務では、利用者の操作から応答までの時間を確かめる必要がある。

Ciscoの性能管理資料も、利用者やアプリケーションに必要な性能を定めて測定することを重視している。「CPU使用率が低い」という機器の状態だけでは、利用者が快適に操作できるかを判断できない。対象のサービスと測定する位置、時間帯、通信の条件を先に決める。

主な指標を読み分ける

回線に表示される1 Gbit/sなどの速度は、アプリケーションのデータがその速度で届くことを保証しない。通信の制御に使う情報や再送、経路上の制約、送受信側の処理などが実際の転送量に影響する。測定結果を比較するときは、どの区間の何を数えているかをそろえる必要がある。

時間の変動の定義は一つではない。RFC 3393のIP Packet Delay Variationは、選んだパケット間の片道の所要時間の差を基に定義する。製品が同じ名称で表示していても、集計方法が同じとは限らない。

また片道の所要時間を送信側と受信側の時刻から求める場合は、両端の時計のずれが測定誤差になる。RFC 7679はこの影響も扱っている。往路と復路で経路や混雑状況が違う可能性があるため、往復の値を単純に半分にして片道の値と断定することもできない。

累積値から単位時間の通信量を求める

機器から取得する値には、CPU使用率のようにその時点や指定された期間の状態を表す値と、受信した総バイト数のように積み上がるカウンタがある。累積値をそのままグラフにしても現在の通信量は分からない。前回との差を実際の経過時間で割って、単位時間の値へ変換する。

例えば同じインタフェースの受信バイト数が30秒で450,000,000増えたとする。この区間の平均受信速度は、450,000,000 × 8 ÷ 30から120 Mbit/sとなる。回線容量を1,000 Mbit/sとすれば、この計算での平均受信利用率は12 %である。バイト数をビット数へ換算することと、収集が遅れた場合には実際の経過時間を使うことが重要になる。

この計算は取得したバイト数を対象にした平均である。物理層を含めた回線上の全ての時間や、アプリケーションの有効データ量と一致するとは限らない。全二重の回線では送信と受信が同時に行われるため、通常は方向ごとに利用率を評価する。

RFC 2863のifHCInOctetsやifHCOutOctetsは64ビットの累積値を持つ。高速な回線で小さい桁数の値を使うと、収集の間に上限を越えて先頭に戻り、増分を正しく求めにくくなる。また再起動や初期化による値の不連続も区別する必要がある。同仕様のifCounterDiscontinuityTimeなどを確認し、不連続をまたいだ値の差を通常の通信量として扱わない。

平常時と比べて異常の条件を決める

通常の稼働状態を測定して比較の基準を作ったものをベースラインという。昼間と夜間、平日と休日、月末の処理などでは通信量が変わるため、同じ条件の過去の値と比較する。ここでの基準は性能の傾向を表し、構成管理でいう承認済みの構成とは目的が異なる。

通知する境界となる値をしきい値という。例えば利用率がある値を上回った状態が一定時間続いたときに通知する。ただし一律に何%なら危険と決まるわけではない。必要な応答時間や機器の特性、平常時の変動と実際の影響を踏まえて定める。

境界付近で値が上下すると、異常と正常の通知を繰り返すことがある。Ciscoの監視例にもあるように、発生と解除の条件を分けるヒステリシスを設けると、この繰り返しを抑えられる。例えば発生を80%以上、解除を70%未満とする方法が考えられる。この数値は説明のための例であり、どの回線にも適用できる推奨値ではない。短い変動を無視する時間条件を加える場合にも、業務上見逃せない異常まで隠さないようにする。

平均値で隠れる混雑を調べる

5分間の平均利用率が低くても、短い時間に大量のデータが集中して待ち行列があふれることはある。収集間隔を短くすれば時間の変化を細かく把握できるが、それより短い集中を全て捉えられるわけではない。機器の廃棄数や待ち行列の状態も合わせて確認し、情報の収集と保存に掛かる負荷も考える。

応答時間を評価するときは、平均値に加えて分布やパーセンタイルを使う。例えば95番目の百分位の値は、測定値を小さい順に見ておおむね95%がその値以下となる境界を表す。大半の操作は速くても一部だけ非常に遅い状況は、平均だけでは見えにくい。GoogleのSRE資料も、遅い側の応答や測定の粒度を考慮する必要を説明している。

集計では成功した応答と失敗した応答も区別する。処理をすぐに拒否してエラーを返す状態になると、応答時間だけは短く見える場合がある。成功率が悪化していないかも確認し、単にグラフの値が下がったことを改善と判断しない。

測った結果から制約のある場所を探す

システム全体の性能を制限する箇所をボトルネックという。回線が混雑しているのか、装置の処理が追い付かないのか、サーバの処理が遅いのかによって対策は変わる。利用者の応答が悪化した時刻に、経路上の通信量やエラー、装置の負荷などがどう変化したかを照合する。

例えば画面の表示が遅いとき、ネットワークへの単純な往復測定が正常でもアプリケーションの処理が長い可能性がある。逆にサーバ内部の処理時間は短いのに端末からの操作に時間が掛かるなら、名前解決や接続確立、途中の通信状態も調べる。一つの値だけで場所を断定せず、条件の異なる観測を組み合わせる。

主な遅さがサーバの処理にある場合、回線容量を増やしても十分な改善は得られない。対策前後を比べるときも、通信量やパケットの大きさ、経路、測定時間などの条件をそろえる。利用者が少ない時間にだけ試して改善したと判断すると、混雑する時間帯に問題が残るおそれがある。

将来の需要と縮退時の能力を見積もる

需要の増加に合わせて必要な資源や増強時期を見積もることをキャパシティプランニングという。直近の最大値だけでなく利用者数や新しいサービス、定期処理の増加を考慮する。増強には準備や調達の時間が掛かるため、不足してから対応するのでは間に合わない場合がある。

冗長構成では片方が使えないときの能力も確認する。例えば同じ方向へ合計120 Mbit/sを転送する需要を、各100 Mbit/sの2回線へ60 Mbit/sずつ分けられているとする。1回線が停止して全ての需要を残る回線へ寄せると、その容量を超える。通常時に余裕があるという事実だけでは、切替え後の性能を保証できない。

対策には容量の増強や処理の分散、通信の時間帯の調整がある。QoSによる優先制御は重要な通信へ資源を配分する手段だが、物理的な容量そのものを増やすものではない。待ち行列を大きくする方法にも、廃棄を減らす一方で待ち時間が伸びる場合がある。必要な業務の条件に照らして対策を選び、実施後も測定を続ける。

この用語が出てくる記事

• 構成管理
• 障害管理