アーキテクチャ徹底解説 Microsoft SQL Server 2000 : 15.4 ストアド プロシージャとキャッシング メカニズムの使用
15.4 ストアド プロシージャとキャッシング メカニズムの使用
トピック
15.4.1 アドホックキャッシング
15.4.2 自動パラメータ化
15.4.3 sp_executesql プロシージャ
15.4.4 PREPARE と EXECUTE メソッド
15.4.5 キャッシュされたプランの共有
15.4.6 プランキャッシュの調査
15.4.7 キャッシュ内の複数のプラン
15.4.8 ストアドプロシージャとほかのキャッシングメカニズムの選択基準
15.4.9 ストアドプロシージャの再コンパイル
15.4.10 ストアドプロシージャのほかの利点
アプリケーションからSQLコマンドを実行するうえで、最もコスト効率のよいメカニズムはストアドプロシージャだ。アプリケーションからアドホックのSQLステートメントを渡すよりも、可能な限りストアドプロシージャを利用することをお勧めする。「第3章 構成要素と機能」と「第11章 バッチ、ストアドプロシージャ、関数」では、実行時にプランのコンパイルが必要になるかどうかという観点からストアドプロシージャの効率のよさを説明した。ストアドプロシージャでは、プランはキャッシュにとどまり、後で再利用できる。格納されたプランの再利用は、パフォーマンスのうえで大きな利点になる。クエリオプティマイザは何千ものプランの可能性を評価するため、コンパイルと最適化のための時間は実行時間全体のかなりの割合になる。どのような場合に再コンパイルが行われるかを理解し、できる限り再コンパイルを回避することが重要になる。
SQL Server 2000では、広範な状況で使用できるように、プランをキャッシュするための4つの新しいメカニズムが採用されている。これにより再コンパイルを減らせる。
アドホックキャッシング
自動パラメータ化
sp_executesqlプロシージャ
PREPAREメソッドとEXECUTEメソッド
メモ
クエリプランのキャッシュに関する情報は、Peter Scharlock氏が書いた暫定版のドキュメントから引用した。
15.4.1 アドホックキャッシング
SQL Serverはアドホッククエリが生成したプランをキャッシュに入れる。そして、その後実行するバッチがそのプランと完全に一致した場合は、キャッシュしたプランが使用される。この機能を使用するための特別な操作は必要ないが、文字が完全に一致した場合に限られる。たとえば、次の3つのクエリをNorthwindデータベースで実行すると、1番目と3番目のクエリでは同じプランを使用できるが、2番目のクエリには新しいプランを作成する必要がある。
SELECT * FROM orders WHERE customerID = 'HANAR' SELECT * FROM orders WHERE customerID = 'CHOPS' SELECT * FROM orders WHERE customerID = 'HANAR'
15.4.2 自動パラメータ化
簡単なクエリでは、SQL Serverはどの定数がパラメータであるかを推測し、定数をパラメータ化する。パラメータ化が成功した場合、同じ基本テンプレートを使用するクエリを後で実行するとき、同一のプランが使用される。自動パラメータ化では、4つのテンプレートを使用できる。key-expressionとは、列名、定数、AND演算子、および比較演算子（<、>、=、<=、>=、<>）のみからなる式を指す。
INSERT table VALUES({constant | NULL | DEFAULT}, ...)
DELETE table WHERE key-expression
UPDATE table SET colname = constant WHERE key-expression
SELECT {* | column-list} FROM table WHERE key-expression ORDER BY column-list
たとえば、次の2つのクエリは同じプランを使用する。
SELECT firstname, lastname, title FROM employees WHERE employeeID = 6 SELECT firstname, lastname, title FROM employees WHERE employeeID = 2
SQL Serverは、これらのクエリを内部的に次のようにパラメータ化する。
SELECT firstname, lastname, title FROM employees WHERE employeeID = @p
SQL Serverは、テンプレートが安全な場合にのみ、ほかのクエリに同じプランの使用を許可する。テンプレートが安全であるとは、実パラメータが変更されても、選択したプランが変わらない場合を指す。安全なパラメータを使用すると、自動パラメータ化を実行してもクエリのパフォーマンスが低下する心配はない。
SQL Serverのクエリプロセッサがテンプレートの安全性を判断するが、その判断はアプリケーションが行うよりもはるかに慎重に行われる。SQL Serverはどの値がパラメータであるかを推測するのに対して、アプリケーションはどれがパラメータであるかが既にわかっている。パラメータがわかっているのであれば、自動パラメータ化を使用せずに、次の2つのメカニズムのいずれかを使用して、パラメータマーカーを付けた方がよい。
15.4.3 sp_executesql プロシージャ
sp_executesqlストアドプロシージャは、アドホックキャッシングとストアドプロシージャの中間的な働きをする。sp_executesqlプロシージャを使用するには、パラメータを指定する必要があるが、ストアドプロシージャのような永続的なオブジェクト管理がすべて必要となるわけではない。
sp_executesqlプロシージャの一般的な構文を次に示す。
sp_executesql @batch_text, @batch_parameter_definitions, param1,...paramN
同じbatch_textを使用するステートメントが繰り返し呼び出されると、キャッシュに格納されているプランが使用され、新しいパラメータ値が指定される。次のケースではすべて、キャッシュにある同一のプランが使用される。
EXEC sp_executesql N'SELECT firstname, lastname, title FROM employees WHERE employeeID = @p', N'@p tinyint', 6 EXEC sp_executesql N'SELECT firstname, lastname, title FROM employees WHERE employeeID = @p', N'@p tinyint', 2 EXEC sp_executesql N'SELECT firstname, lastname, title FROM employees WHERE employeeID = @p', N'@p tinyint', 6
ODBCとOLE DBは、SQLExecDirectとICommandWithParametersを介してこの機能を提供している（詳細については、ODBCおよびOLE DBのマニュアルを参照）。
15.4.4 PREPARE と EXECUTE メソッド
4つ目のメカニズムは、バッチのパラメータをアプリケーション側で指定する点がsp_executesqlに似ているが、重要な違いがいくつかある。PREPAREとEXECUTEメソッドでは、実行のたびにバッチの全文を送る必要はない。ただし、PREPARE時に一度だけバッチの全文を送信する。このとき、ハンドルが返され、このハンドルを使用してEXECUTE時にバッチを起動する。ODBCとOLE DBでは、SQLPrepare/SQLExecuteとICommandPrepareを介して、この機能を提供している。カーソルを使用する場合も、ODBCとOLE DBでこのメカニズムを利用できる。上記の機能により、SQL Serverは、バッチを再利用可能であると認識する。
15.4.5 キャッシュされたプランの共有
ユーザーがプランを共有して、キャッシングメカニズムを最大限活用できるようにするには、すべてのユーザーがプランを同一の環境で実行する必要がある。アプリケーションの実行時または接続時に、SETオプションやデータベースの設定を変更してはならない。
すべてのキャッシングメカニズムでは、キャッシュに格納されたプランを再利用すればコンパイルと最適化を繰り返さなくて済む。これによりコンパイル時間を短縮できるが、同時に、どのようなパラメータ値が渡される場合でも同じプランが使用されることを意味する。キャッシュに格納されているプランがパラメータ値にとって最適なプランでなければ、実行時間は短縮されない。このため、SQL Serverは、自動パラメータ化の使用をできるだけ避けようとする。アプリケーションでsp_executesql、PREPAREとEXECUTE、またはストアドプロシージャを使用する場合は、開発時に何をパラメータ化するかを決定する必要がある。値の範囲により最適化の方法が大きく変わるような定数は、パラメータ化すべきではない。
パフォーマンスモニタには、SQL Server:SQL Statisticsというカウンタがあり、その中には自動パラメータ化用のカウンタがいくつか含まれている。これらのカウンタを監視すれば、安全でない、あるいは失敗した自動パラメータ化の発生件数を調べられる。失敗した自動パラメータ化の数が多いときは、アプリケーション側で明示的にパラメータマーカーを付けることを考慮した方がよい。
15.4.6 プランキャッシュの調査
システムテーブルsyscacheobjectsには、キャッシュ内のコンパイル済みオブジェクトが常に記録されている。これは実際には疑似テーブルであり、masterデータベースの中にのみ存在する。このテーブルはディスク上に書き込まれているわけではなく、具体的になるのは、テーブルにアクセスするためのクエリが実行されたときだけである。表15－2は、syscacheobjectsテーブルに用意されている有益な列をいくつか紹介している。
列名 |
説明 |
|---|---|
Bucketed |
内部ハッシュテーブルに入っている該当プランのバケットID。SQL ServerはバケットIDを使ってプランをすばやく見つける。同一のバケットIDを持つ2つの行は同じオブジェクト（たとえば同じプロシージャまたはトリガ）と見なされる。 |
cacheobjtype |
キャッシュ内のオブジェクトの種類。 |
objtype |
オブジェクトの種類。 |
objid |
キャッシュ内のオブジェクトを見つけるのに使われる主要なキーの1つ。sysobjectsに格納されているオブジェクト（プロシージャ、ビュー、トリガなど）のID。アドホックSQLや準備されたSQLなどのキャッシュオブジェクトでは、objidの値は内部的に生成される。 |
dbid |
キャッシュオブジェクトがコンパイルされたデータベースのID。 |
uid |
プランの作成者（アドホックのクエリプランと準備されたプランの場合）。 |
refcounts |
該当のキャッシュオブジェクトを参照するほかのキャッシュオブジェクトの数。 |
usecounts |
該当のキャッシュオブジェクトが使用された回数。 |
pagesused |
キャッシュオブジェクトが消費したメモリページの数。 |
setopts |
コンパイルされたプランに影響するSETオプションの設定。この列の値の変更は、ユーザーがSETオプションを変更したことを意味する。 |
langid |
キャッシュオブジェクトを作成した接続の言語ID。 |
dateformat |
キャッシュオブジェクトを作成した接続の日付形式。 |
sql |
実行されたバッチのプロシージャ名または最初の128文字。 |
Cacheobjtypeはプランの種類を示す。Cacheobjtypeの値は次のいずれかになる。
Compiled Plan（コンパイル済みプラン）
コンパイルと最適化によって実際に生成されたプラン。コンパイル済みプランは、同じプロシージャまたはクエリを実行しているセッションによって共有できる。Executable Plan（実行可能プラン）
コンパイル済みプランを実行する環境。同一のコンパイル済みプランを同時に呼び出している場合、そのそれぞれが実行可能プランを備えている。この環境情報をキャッシュに入れておけば、セットアップのコストが節約される。頻繁に実行するクエリの場合、この節約はかなりのものになる。実行可能プランには必ず、bucketidを同じくするコンパイル済みプランが関連付けられている。しかし、すべてのコンパイル済みプランに格納済みの実行可能プランが関連付けられているとは限らない。Parse Tree（解析ツリー）
コンパイルと最適化が行われる前のクエリの内部形式。Cursor Parse Tree（カーソル解析ツリー）
カーソルのクエリ用の解析ツリー。
Objtypeは、プランがキャッシュされているオブジェクトの種類を指す。Objtypeの値は次のいずれかになる。
Proc（プロシージャ）
ストアドプロシージャとインライン関数の両方。Prepared（準備）
sp_executesqlを使って実行依頼され、prepareとexecuteのメソッドを使っているクエリ用。およびSQL Serverが自動パラメータ化すると決定したクエリ用。Ad hoc query（アドホッククエリ）
上記のどのカテゴリにも当てはまらないクエリ用。ReplProc
レプリケーションエージェント用。Trigger（トリガ）
プランがプロシージャまたはインライン関数のプランによく似ている種類。View（ビュー）
プランではなく解析ツリーだけが表示されている種類。ビューにアクセスしたときだけでなく、非インライン関数に遭遇したときにもこの種類を見ることになる。非インライン関数は独自のプランを備えていないが、クエリの一部として展開される。Table（テーブル）
この種類では、ユーザーまたはシステムのシステムに計算済み列がある場合は、解析ツリーが生成される。Default, Check, Rule（デフォルト、チェック、ルール）
解析ツリーに展開され、クエリの一部としてコンパイルされる種類。
このほか、プランの使用状況を示す2つの列（refcountとusecount）がある。refcountの値は、プランが何回参照されたかを示す。キャッシュ内の実行可能プランのrefcountは常に1になる。プランの実行中には、実行可能プランのrefcountは実際には1よりも大きくなることがあるが、これはsyscacheobjectsテーブルには反映されない。コンパイル済みプランのrefcountは、キャッシュまたは使用中の実行プランの数に1を加えた値となる。usecountの値は、キャッシュされたオブジェクトの使用回数を示す。プランが検索され、て見つかるたびにusecountは増える。プロシージャまたはクエリを初めて実行した後で、usecountの値が2になっていることがある。プランが作成され、キャッシュに格納されるときに一度アクセスがあり、キャッシュから取り出されて実行されるときにもう一度アクセスがあるためである。
15.4.7 キャッシュ内の複数のプラン
SQL Serverは、クエリまたはストアドプロシージャのプランの数を制限しようとする。プランは再入可能なので、制限は簡単に実現できる。ある種の状況では、同一プロシージャ用の複数のプランがキャッシュに保存されることがある。よくあるのは、SETオプション、データベースオプション、または設定オプションに相違がある場合である。たとえば、文字列を連結するストアドプロシージャでは、CONCAT_NULL_YIELDS_NULLオプションがONかOFFか、または対応するデータベースオプションがTRUEかFALSEかによって、連結処理のコンパイル方法が異なる場合がある。オプションをONにしてプロシージャを実行する場合と、OFFにして実行する場合とでは、使用するプランが異なる。syscacheobjectsテーブルのsetopts列はビットマップであり、プランがキャッシュに入っているときに有効となっているSETオプションを示す。別のSETオプションを有効にして別のセッションを開始すると、SQL Serverは新しいプランを生成する。setoptsフィールドには、次のオプションが入る。
<list class="unordered"> </list>
言語やdateformat値が異なる2つのセッションも、それぞれ別のプランを生成する。SQL Serverはsyscacheobjectsテーブルのlangid値とdateformat値を記憶して、後で同じプランを実行しようとする試みがあったときに、これらの値を比較する。
プランを再利用できるかどうかには、もう1つの接続の問題もからんでくる。所有者名を暗黙のうちに解決しなければならない場合、プランは再利用できない。たとえば、ユーザーsueが次のようなSELECTステートメントを出した場合を想定しよう。
<list class="unordered"> </list>
SQL Serverはまず、sueが所有するmytableというオブジェクトを探して、オブジェクトを解決しようとする。このオブジェクトが見つからなければ、DBOが所有するmytableというオブジェクトを探す。ここでユーザーdanが同じクエリを実行すると、オブジェクトはまったく別の方法で解決される（danが所有するテーブルに解決される）。したがって、sueとdanは、このクエリのために生成されるプランを共有できない。しかし、sueが次のようなコマンドを出すと、状況は一変する。
<list class="unordered"> </list>
ここにはあいまいさはない。これと同じクエリを実行するユーザーは常に同じオブジェクトを参照する。syscacheobjectsテーブルのuid列は、プランが生成された接続でのユーザーIDを示す。同じプランは同じユーザーIDによる別の接続でのみ使用できる。唯一の例外は、syscacheobjectsでユーザーIDが-2となっている場合だ。このユーザーIDは、実行依頼されたクエリが暗黙の名前解決には依存せず、複数のユーザーで共有できることを示す。これは好んで使われる方法でもある。
ヒント
SQL Serverが開始してから一定期間経過すると、syscacheobjectsテーブルが非常に大きくなり、扱いにくくなる。キャッシュに何が入り、いつ再利用されるかを知るために、独自のテストを実行したい場合は、キャッシュをときおり整理して、扱いやすいサイズに保っておくとよい。このためには、DBCC FREEPROCCACHEコマンドを使う。このコマンドは、キャッシュされたプランをすべてメモリから除去する。DBCC FLUSHPROCINDB(<dbid>)を実行すれば、特定のデータベースからプランをすべて削除できる。ただし、これらのコマンドはアプリケーションのパフォーマンスに影響するため、実働サーバーでは使わないようにする。
15.4.8 ストアドプロシージャとほかのキャッシングメカニズムの選択基準
ストアドプロシージャあるいはそのほかのメカニズムを使用するかは、次の点に注意して決定するとよい。
ストアドプロシージャ
複数のアプリケーションから、パラメータがわかっているバッチを実行しているときに使用。アドホックキャッシング
特定の状況でのみ有効。アプリケーションがこの機能を使用するように設計しないこと。自動パラメータ化
簡単に変更できないアプリケーションで使用。アプリケーションが自動パラメータ化の機能を使用するように設計しないこと。sp_executesqlプロシージャ
1人のユーザーが同じバッチを複数回使用する可能性があり、パラメータがわかっている場合に使用。PREPAREとEXECUTEメソッド
複数のユーザーが同じバッチを使用し、パラメータがわかっている場合、または1人のユーザーが同じバッチを複数回使うと確実にわかっている場合に使用。
15.4.9 ストアドプロシージャの再コンパイル
前述のメカニズムはどれも有用だが、それでもできるだけストアドプロシージャを使用した方がよい。ストアドプロシージャは、コンパイル済みであるという利点以外にも、アプリケーションからSQL Serverに送るテキスト量が減るのでネットワークトラフィックの改善に役立つ。また、ストアドプロシージャのセキュリティメカニズムにより、データにアクセスできるユーザーと条件を制御できる。ストアドプロシージャは、さまざまな条件下で、自動でも手動でも再コンパイルできる（「第11章 バッチ、ストアドプロシージャ、関数」でこの点についてある程度説明した）。
SQLプロファイラを使用すれば、実際に自動再コンパイルが行われるようすを確認できる。確認するには、［ストアドプロシージャ］の下にある［SP:Recompile］というイベントのトレースを選択する。［SP:StmtStarting］というイベントもトレースすると、どの時点でプロシージャの再コンパイルが行われるかもわかる。トレースを見ると特に、ストアドプロシージャが実行時に複数回再コンパイルされていることがわかるだろう。たとえば、一時テーブルを作成し、後でそのテーブルにインデックスを設定し、さらにデータを追加する場合、ストアドプロシージャは何度も再コンパイルされる。これを避けるには、一時テーブルのすべてのデータ定義ステートメント、および一時テーブルへの行の挿入を行うステートメントを、プロシージャの最初に記述する。そうすれば、プロシージャを再コンパイルする必要が発生しても、一度だけで済む。ほかにも、KEEPPLANクエリヒントを一時テーブルにアクセスするステートメントに追加し、再コンパイルを防ぐ方法がある。クエリヒントについては、「第16章 クエリのチューニング」でさらに詳しく解説する。
再コンパイルはなるべく避けるべきものという前提で説明してきたが、例外もある。統計を更新するとクエリプランが改善されることがわかっている場合、またはパラメータに非常に広い範囲の値が指定される可能性がある場合には、再コンパイルが適している。
既に見たように、システムテーブルsyscacheobjectsは、キャッシュに入っているコンパイル済みオブジェクトを記録する。このテーブルにアクセスできるのはシステム管理者だけだが、チューニングとテストのために自分でストアドプロシージャを書くことも可能だ。付属CD-ROMに収録されているsp_procs_in_cacheというプロシージャは、キャッシュに入っているすべてのプロシージャプランのリストと各プランの発生回数を戻す。リストはデータベースごとに編成されている。パラメータを渡さずにこのプロシージャを実行すれば、現行データベースのプロシージャだけが表示される。データベース名を指定すれば、そのデータベースのプロシージャが表示される。allというパラメータを指定すれば、すべてのデータベースのキャッシュに入っているプロシージャプランが表示される。このプロシージャをカスタマイズすることにより、syscacheobjectsテーブルからさまざまな情報を引き出すことができる。前述したように、masterデータベースにプロシージャを作成しておけば、どこからでも呼び出すことができる。システム管理者以外のものがこのプロシージャを実行する場合は、適切な許可を与える必要がある。sp_procs_in_cacheプロシージャは、コンパイル済みプランと実行可能プランの両方を示す。
15.4.10 ストアドプロシージャのほかの利点
ストアドプロシージャは、パフォーマンスとセキュリティの面で大きな利点を持つ以外にも、アプリケーションとデータベース設計の間の重要な中間層の役割を果たす。アプリケーションがget_customer_balanceなどのプロシージャを呼び出し、結果セットを待っているとする。その間に、基になるデータベースが変更されても、アプリケーションにはまったく影響なく、期待される結果セットを返すようにプロシージャが変更されていれば、データベースの変更を意識しなくてもよい。たとえば、クエリパフォーマンスを改善するために、データベース設計の正規化を解除する場合は、クエリを指定し直すようストアドプロシージャを変更すればよい。複数のアプリケーションからストアドプロシージャが呼び出される場合でも、ストアドプロシージャを一度変更するだけでよく、アプリケーションに手を加える必要はない。実行中のアプリケーションを再起動する必要もない。
ストアドプロシージャを使用した方がよいもう1つの理由に、ネットワーク上の往復（バッチの実行および結果セットの取得ごとに、クライアントアプリケーションとSQL Serverとの間で発生する対話型TDSトラフィック）を削減できることがある。データ値に基づいて別の動作を行う場合は、なるべくその動作をプロシージャ内で直接実行する（厳密にいえば、バッチにもこの機能があるので、ストアドプロシージャを使用する必要はない）。バッチには、できるだけ多くのコマンドを入れるようにする。最初に、1つのバッチで100行を挿入し、次に、1バッチで1行ずつ挿入する（つまり100バッチを実行する）という簡単なテストがある。すると、両者はLAN上でもパフォーマンスが1桁違うことがわかる。ましてもっと遅いネットワークでは、驚嘆するほどのパフォーマンスの違いが見られる。10MbpsのLANは十分高速であり、一般にネットワークが重大なボトルネックになることはない。しかし、低速なネットワークでは、違いが非常に大きくなる。28.8Kbpsのモデムの速度は、LANの速度の約300分の1である。WANの速度もばらつきが大きいが、一般的にはLANの100分の1から200分の1である。高速なLANでは、ネットワーク利用の効率の悪さが目立たないことがある。しかし、ネットワーク利用の効率の悪さは、カーソル使用時に顕著に現れる。LANでは行ごとに問題なく取得できるが、ダイヤルアップ回線を使用して行ごとの処理を行うと、耐えられないほど反応が遅くなる。
ストアドプロシージャに複数のステートメントがある場合、SQL Serverは、既定で各ステートメントの完了時にクライアントアプリケーションにメッセージを送り、ステートメントで処理された行数を知らせる。これは、TDSの用語ではDONE_IN_PROCメッセージと呼ばれている。しかし、DONE_IN_PROCメッセージを必要とするアプリケーションはあまりない。そこで、アプリケーションが処理済みの行数を知らせるメッセージを必要ないと判断した場合、DONE_IN_PROCメッセージを送信する機能を無効にできる。こうすると、ネットワークトラフィックの障害となる要因がほかになければ、低速ネットワークのパフォーマンスが大幅に改善する。WANに展開したあるアプリケーションでは、DONE_IN_PROCメッセージを無効にしたらパフォーマンスが桁違いに改善した。大失敗だった運用で成功を収めることができた。
接続に特化したオプションであるSET NOCOUNT ONを使用すれば、DONE_IN_PROCメッセージをアプリケーションで無効にできる。DONE_IN_PROCメッセージが無効になっていると、ODBCのSQLRowCount関数やOLE DBの同様の関数も使用できない。しかし、必要に応じてNOCOUNTのONとOFFを切り替えることができる。また、NOCOUNTをONにしても、SELECT @@ROWCOUNTを使用できる。また、トレースフラグ3640を指定してサーバーを起動して、DONE_IN_PROCメッセージの送信を無効にできる。トレースフラグ3640は、アプリケーションに手を加えなくても、不要なオーバーヘッドを軽減する。しかし、ODBCアプリケーションの中には、DONE_IN_PROCメッセージが必要なものもあるので、実際の運用でトレースフラグ3640を使用する前に、アプリケーションをテストするとよい。DONE_IN_PROCメッセージのトークンを待つよう暗黙的に書かれているアプリケーションが、正常に動作しなくなる可能性があるからである。
クライアントアプリケーションとサーバー間のトラフィックを監視する必要がある。低速ネットワーク用に設計、調整されているアプリケーションは、高速ネットワークでもすばらしいパフォーマンスを発揮するが、逆は成り立たない。SQLステートメントの生成やコマンドの発行を行ってくれる高度な開発ツールを使用する場合は、ネットワーク上でどのようなトラフィックが発生するか注意を払うことが特に重要である。SQLプロファイラを使用すれば、サーバーで発生するトラフィックを監視できる。ネットワークトラフィックを監視するだけなら、出力させる必要はない。ネットワークモニタ（Windows NT ServerおよびWindows 2000 Serverで利用可能）などのネットワーク監視ツールを使用する方が効果的だろう。ネットワークモニタの使い方は簡単で、ネットワーク初心者でもすぐにセットアップできる。マウスをクリックするだけで、コンピュータ間のネットワークトラフィックを監視できる。