実例で学ぶWebシステムのチューニング手法 IDGジャパン JavaWorld誌2002年2月号特集 「実例で学ぶWebシステムのチューニング手法」の原稿を元に再構成 (埋金 進一・藤野 契)

PDFはこちら

WEBシステムのパフォーマンスチューニング理論編

理論編では、筆者がWEBシステムのパフォーマンスをチューニングする際に行っている方法をベースにチューニングの方法を解説する。実際のチューニングの方法はシステムによりまちまちであり、システムのアーキテクチャによりチューニングの方法も大きく変わるのであるが、ここではアプリケーションサーバを使用してWEBシステムであれば、多くのシステムに適用できるであろうことを中心に解説する。

パフォーマンスが向上に結びつきそうなことを、いろいろ実施してみたのだが思うように性能が向上しないという話をよく聞く。そのようなケースでは、ボトルネックが何処にあるのかを見誤り、あるいはボトルネックが何処にあるのかを見極めずにチューニングを行い思うような性能が得られていないことが多いのではないかと想像する。ボトルネックに対してチューニングを施して、はじめてチューニングは高い効果を得られるるのであり、やみくもにチューニングのテクニックを適合しても、大抵は思うような性能の向上など得られない。

筆者は、ボトルネックを見つけることこそがチューニングの中心であり、ボトルネックが特定されればチューニング作業は半分は終了したようなものと考える。以下、どのようにしてボトルネックを見つけるのか、そしてそのボトルネックに対してどのように対処するのかと行った観点で解説をしていく。

本特集の執筆に当たっては、WEBサーバにApache, アプリケーションサーバにBEAのWebLogic, DBサーバにはOracleを使用することを想定している。しかし、これから解説することは、基本的にプロダクトに依存しないので、Apache, WebLogic, Oracle以外のプロダクトを使用している読者にも十分役立つはずである。

チューニングのサイクル

チューニングは、ボトルネックを見つけだし、何故そこがボトルネックになっているかを推定し、ボトルネックを解消するための対処を施し、その効果を確認するというサイクルを繰り返すことによって行わなければいけない。

図4は筆者が考えるチューニングのプロセスを図式化したものである。

チューニング作業の中心となるのは、ボトルネックがどこにあるかを推測することである。この推測の為のベースとなるのが、測定データとシステム構成の分析となる。測定データには負荷テストを実施したときの結果であったり、実際にシステムを運用したときに取得したデータであったりする。システム構成の分析は、アプリケーションプログラムのアーキテクチャや、ネットワークの構成を考えてボトルネックになりそうな箇所を予想することである。

測定結果から、ボトルネックが明確に分かることも多いが、ボトルネックの原因の候補が幾つか上がる場合や、ボトルネックの候補は見つかったが本当にボトルネックであるかを確信が持てないということも多いだろう。

ボトルネックが明確に分からない場合は、どうすればボトルネックを見つけだせるかと視点から考える。アプリケーションのアーキテクチャを詳細に検討することによって、ボトルネックを特定することもあるし、本当にそこがボトルネックになっているかを確認するためのテストを実施することもある。

システムのどこにボトルネックがあるかが見つかれば、それに応じた対策を行う。
ボトルネックとなる箇所によって、取るべき対策のパターンがある。次項でボトルネックになりやすい箇所とその対策のパターンを示すので参考にしてほしい。

どこがボトルネックになるか

図１は、筆者が想定するWEBシステムの例である。システムは複数のWEBサーバ、アプリケーションサーバとDBサーバから構成され、ルータ、ファイヤーウォール、SSLアクセラレータ、ロードバランサー等のネットワーク機器を解してインターネット／イントラネットに接続している。ユーザは、PC上のブラウザから、インターネット／イントラネットを介してシステムにアクセスする。これらの機器のすべてがボトルネックになりうる。これから、それぞれの機器について、どこがボトルネックになりやすいのかを見ていく。

図1はかなり大規模な例であるが、例えば図2のような小規模な構成でも基本的な考え方はほとんど変わらない。

インターネットとの接続回線

サーバ側の能力がいくら高くても、対インターネットとの接続回線の容量以上の性能はだすことはできない。専用線のコストが高いため、回線速度がボトルネックになっているシステムも多いだろう。

WEBサーバ

アプリケーションサーバを使用する場合は、WEBサーバ側には、htmlファイルや画像ファイルなどの静的なコンテンツのみを置き、動的なコンテンツの作成はアプリケーションサーバに任せるのがセオリーである。静的なコンテンツのみをおくのであれば、現在のWEBサーバは10MbpsのLANの帯域を簡単に使い切ってしまうくらいの能力がある。

WEBサーバには、静的なコンテンツのみを置くようにし、後に述べるSSLの問題がないのであれば、よほど大規模なシステムでない限り、WEBサーバがボトルネックにはならない。

SSLを使わないHTTPによるリクエストであれば、WEBサーバはローエンドのPCサーバを使用したときでさえ、少なくとも毎秒100程度のリクエストを処理できる能力がある。

相当に大きなシステムでなければ毎秒100もアクセスはないであろうし、インターネットとの接続回線が毎秒100ものアクセスに耐えられるほどの容量を持たないのが普通（注1）なので、通常は、WEBサーバがボトルネックにはならない。

SSL

SSLを使ったHTTPSによる通信は、SSLを使わないHTTPによる通信と比べて非常に大きな負荷をWEBサーバに与える。場合によっては、WEBサーバは1CPUあたり数件のSSLのリクエストしか処理できない。SSLによるアクセスが毎秒1以上あるのであれば、WEBサーバがどの程度SSLのアクセスを処理できるのかを測定の上、必要な処置をとる必要がある。

SSLの性能は、サーバのCPUや、WEBサーバの実装によってかなり異なる。どの程度SSLの性能が出るのかは、実際にシステムの運用時に使用するプラットホームと同じ環境で測定してみて欲しい。測定の結果、SSLを使用しても十分な性能があることが分かるかもしれないし、対策が必要になることもある。

SSL通信がボトルネックになる場合、対策は２通り考えられる。WEBサーバの台数を増やす方向と、SSLアクセラレータを導入することである。SSLアクセラレータを使用すると、SSLに関する処理は、すべてSSLアクセラレータが受け持つことになる。ブラウザ側から見ると、SSLを使って通信を行っているのだが、WEBサーバがわから見ると、SSLを使わずに、HTTPで通信をしていることになる(図3)。SSLアクセラレータを導入すれば、SSLアクセラレータのキャパシティが問題になるような非常に大規模なサイトを除いて、SSLが性能のボトルネックとなることはないと考えて良い。

ルータ、ファイヤーウォール

ルータやファイヤーウォールの能力は意外と見落としがちである。ルータや、ファイヤーウォールに100MbpsのLANが接続できるからといって、100Mbpsのデータを転送できると考えてはいけない。数Mbps程度の性能しかでないことも多い。

数Mbps程度の能力があれば、たいていのシステムでは問題ないだろうが、データの転送量が数Mbpsを超えるような大規模なシステムでは、ルータ、ファイヤーウォールの能力がボトルネックとなる可能性がある。

ルーティングや、フィルタリングの設定が増えれば、それに応じてルータ、ファイアウールの性能は低下する。また、WEBシステムは多くのクライアントが比較的小さなデータのやり取りを頻繁に行い、ソケットのセッションの生成を頻繁に行うという性質があるため、FTPを使って大きなファイルを転送するような場合と比べて、転送速度が低下するという性質がある。

ルータ、ファイヤーウォールがどの程度の能力があるかは、負荷テストをして実測して欲しい。なお、スィッチングハブや、Layer 3 SwitchはLANの帯域に比べて十分な性能を持つのが普通なので、基本的にボトルネックになることはないと考えてよい。

アプリケーションサーバ

多くのシステムでは、アプリケーションサーバと次に述べるDBサーバがボトルネックになる。動的にコンテンツを作成する役割をアプリケーションサーバが引き受けるため、多くのロジックがアプリケーションサーバに集中する。この結果、アプリケーションサーバのCPUがボトルネックとなることが多い。

また、アプリケーションサーバのCPU使用率は余裕があり、ディスクI/Oもそれほどないにも関わらず、アプリケーションサーバがボトルネックになってしまうことも多い。このような状況では、アプリケーションサーバのコンフィグレーションパラメータを適当に変更することで大きく性能が向上するこが期待できる。理論編の後半ではアプリケーションサーバの性質とチューニングの方法について詳しくみていく。

DBサーバ

DBサーバはアプリケーションサーバと並んでボトルネックになることが多い。検索をメインにデータベースを使用し、検索の内容がそれほど複雑ではない場合は、DBサーバがボトルネックになることは少ない。

逆に、複雑な検索を行う場合や、大量の更新処理が必要な場合は、データベースがボトルネックになる。この様な場合は、SQL文の見直しや本格的なデータベースのチューニングが必要になる。

DBサーバにはそれほど負荷がかかる処理をしていないにも関わらず、DBサーバがボトルネックになる場合も多い。これは、コネクションプール(コネクションプールについては後で詳しく説明する)を使用していないなど、DBサーバの使い方が適切でないことが原因であることが多い。

（注1）アクセスあたり10Kbyteのデータが流れるとして、毎秒100のアクセスに対応するには、8MBPSの回線が必要。