RTCPやデータパステストに注目

クラウドでアプリケーションパフォーマンスを監視する方法（1/2 ページ）

リアルタイムアプリケーションをクラウドに移行すると、ネットワークの制御を一部手放すことになる。ただし、幾つかのメカニズムを利用すれば、アプリケーションのパフォーマンスを監視できる。

公開 2018年09月27日 05時01分

著者

Terry Slattery

[TechTarget]

印刷する Googleで優先するソースとして追加

クラウド環境でもアプリケーションパフォーマンス監視を

　一般に「リアルタイムアプリケーション」と呼ばれるアプリケーションは、利用者がアプリケーションの実行結果を待つ。音声、動画、画面共有のように分かりやすいものもあるが、ビジネスプロセスや監視システムも含まれることがある。動画のストリーミング配信もある程度リアルタイムアプリケーションといえるが、配信を滑らかにするためにバッファーリング技術が使われることもあるため、真の意味でのリアルタイムアプリケーションではないかもしれない。

　リアルタイムアプリケーションに関するネットワークの問題は、そのアプリケーションと使用するデータ転送の仕組みに左右される。双方向（インタラクティブ）な音声や動画は比較的許容度が高く、最大1％のパケットロス（パケットの損失）が発生しても許容できる。こうしたアプリケーションは、ユーザーデータグラムプロトコル（UDP）のパケットストリームを使用し、端末側（エンドポイント）では補間機能を使用して、失われたパケット内のデータを推定する。

　一方、大半のインタラクティブビジネスアプリケーションや音声、動画ストリーミングのような伝送制御プロトコル（TCP）を利用するアプリケーションは、パケットロスの影響を非常に受けやすい。TCPを使うアプリケーションでは、0.0001％を上回るパケットロスはスループット（一定時間当たりの処理性能）に大きな影響を与える。

併せて読みたいお薦め記事

アプリケーションパフォーマンス監視で注意すべき点とは

注目を集めるクラウド監視ツール

　パケットロスが起きると、動画ストリーミングアプリケーションであれば一時停止することになる。その間、送信側のシステムから喪失されたデータが再転送される。その結果、アプリケーションは一時停止しながらデータのバッファーリングをすることになる。

　パケットロスは、主に接続経路（リンク）のエラーや混雑に起因する。

　リンクエラーでは、調査や訂正などの動作が必要になる。リンク速度の違いやリンクを集約するポイントに混雑が発生する。例えば10Gbpsのデータセンターからのリンクを1GbpsのオフィスやWANのリンクに転送するときなど、高速リンクから低速リンクにデータが移動すると、リンクの速度差が生じる。

アプリケーションパフォーマンスの監視とパケットの問題点の指摘

　アップリンク（上位の転送速度を持つポート）を備えるルーターやスイッチに、多くの低速リンクを接続すると、混雑の原因となり得る。複数のエンドポイントから大量のトラフィックがほぼ同時に着信すると、インタフェースとなるバッファーの限界を超えてしまい、大量のパケットロスが起きる恐れがある。

　ジッタ（デジタル信号の品質を示す指標で、信号の揺らぎのこと）が高くなれば、インタラクティブの音声や動画に大きな影響を与える。ジッタは、複数の大きなパケットの後にリアルタイムパケットがキュー登録（キューイング）されることで発生する。リアルタイムトラフィックは処理の順番を待たなければならず、大きなパケット処理の順番を待つため、結果的に遅延時間に大きなずれが生まれる。

　ジッタが高くなり過ぎると、音声や動画のパケットの受け取りが遅くなり正しいタイミングで再生されなくなる。音声のエンドポイントは、ジッタの影響を抑えるためにバッファーリングをある程度組み込んでいるが、高いジッタへの対処には限界がある。その結果、高いジッタはパケットロスと同じ影響があるといえる。

　高いジッタは、パケットを受け取っていないようにも見える。混雑が激しいと、他のアプリケーションやデータフローの遅延が生まれ、パケットロスにもつながる。こうした問題は、喪失の多いインタフェースを調べることで追跡可能だ。問題が大きいインタフェースを特定するには「95パーセンタイル」（上位5％を特定するためのデータ分析手法）を使用する。喪失が非常に高いインタフェースが見つかる場合は、リンクが過剰に使用されており、トラフィックを減らすか帯域幅を増やす必要があることを示している。

　高いレベルのエラーは、インタフェースの統計を確認すれば容易に追跡できる。場合によっては物理層の問題を示すこともあり得る。

　リアルタイムトラフィックを分析することで、監視システムが探すべき障害の原因を提示できる。探すべき原因には、リンク速度の違いや集約ポイントのリンクエラー、高いジッタ、混雑に伴うパケットロスなどがある。

　クラウドでは物理インタフェースにアクセスできないため、インタフェースのエラーやインタフェースでの喪失を監視できない。そのため、アプリケーションの障害を探すには別の仕組みを使用しなければならない。

次ページへアプリケーションパフォーマンスの受動的監視

印刷する

この記事の著者

Terry Slattery

クラウドでアプリケーションパフォーマンスを監視する方法（1/2 ページ）

併せて読みたいお薦め記事

アプリケーションパフォーマンス監視で注意すべき点とは

注目を集めるクラウド監視ツール

アプリケーションパフォーマンスの監視とパケットの問題点の指摘

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

クラウドでアプリケーションパフォーマンスを監視する方法（1/2 ページ）

併せて読みたいお薦め記事

アプリケーションパフォーマンス監視で注意すべき点とは

注目を集めるクラウド監視ツール

アプリケーションパフォーマンスの監視とパケットの問題点の指摘

この記事の著者

関連記事

アプリケーションパフォーマンス監視（APM）の比較で着目すべき3つの機能

今、話題の監視ツール「Sensu」とは？――基本的な構成、監視の仕組みを理解する

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓