パフォーマンスの決め手はアーキテクチャー

アプリケーションのパフォーマンスの決め手になるのは、アプリケーションのアーキテクチャーです。そんなのは当たり前だと思われるかもしれませんが、現実の世界ではそうでもないのです。たとえば、ミドルウエアの製品を変えるだけで、パフォーマンスの問題が解決すると思っているソフトウェア・アーキテクトは山ほどいます。たぶん、ベンダーが宣伝する「ベンチマークテストの結果は、ライバルと比べて25%も上回っています」という言葉に踊らされているんでしょう。しかし、アーキテクチャーの効率がとてつもなく悪く、それがパフォーマンスの悪さの根本的な原因になっている場合、ライバル製品なら4ミリ秒かかるところを、わずか3ミリ秒で処理できると言っても、その1ミリ秒、25%の差は、焼け石に水です。

これはITマネージャーやベンダーのベンチマーク・チームの言い分ですが、ベンダーのサポート部門やパフォーマンス管理について書くライターには別の言い分があります。メモリー割り当て量、コネクションプール数、スレッドプール数といったものを調整してソフトウェアを「チューニング」すればパフォーマンスが上がるというのです。しかし、予想される負荷と比べてアプリケーションの配備環境が貧弱だったり、そもそものアーキテクチャーがリソースを効率的に使えていなければ、いかにアーキテクトがチューニングしでも、パフォーマンスやスケーラビリティは、要求水準にとうてい及ばないでしょう。

ベンダー製品もアプリケーション・アーキテクチャーも結局のところ、分散コンピューティングの基本原則と物理資源の制約を受けます。アプリケーションにしても、ベンダー製品にしても、ある性能のコンピューターの上でプロセスとして実行され、ネットワークやメモリを介して連携するときにはかならず遅れが生じます。ですから、アプリケーションのパフォーマンスとスケーラビリティを左右する最大の要因は、アプリケーションのアーキテクチャーだということを肝に銘じなければなりません。パフォーマンスやスケーラビリテイは、プランドとか「チューニング」だけでスイッチを押すように改善されるような代物ではないのです。これらを改善したければ、根本的なロジックか配備環境そのもの、あるいはその両方の(再)設計が必要なのです。