第2回　急増するパフォーマンス・トラブルを直視する －求められるパフォーマンスへの意識と知識

最近、システムのパフォーマンスに関するトラブルが増えています。日中の利用時間帯に急にレスポンスが下がり、クライアント上のアプリケーションがどんどん遅くなっていった。苦渋の選択でサーバーを落としたが、二度と立ち上がらなかった…。顧客向けサイトで突如利用が急増し、反応が不安定に。そこに定時のデータ連動と更新が走ったために、一気に停止状態に陥った…。パフォーマンスの低下からその後の対処を誤り、思いがけず大きなトラブルになるといったケースは少なくありません。サーバーが止まるような障害の中でも、パフォーマンスに起因するものの比率は、日増しに高くなっているというのが実感です。

そうでなくても、パフォーマンスの低下は利用者の不満を一気に駆り立てます。システムが落ちたというのは、被害が大きく深刻だけれど、業務の側から見ればまだ分かりやすい。しかし、遅いシステムというのは、動いているだけに業務続行の判断が難しく、利用者の時間を犠牲にしつつもそのまま使い続けるということになりやすい。しかし、業務効率は著しく下がり、業務プロセスに滞留が出始める。結局は、顧客に迷惑をかけ、それへのリカバリーでまた仕事が増える…。パフォーマンスへの不満が大きいのは、それによる影響とリカバリーの負担が、そのまま利用者に覆い被さることが多いからかもしれません。しかも今日では、そこから大きなシステム障害へと広がることが少なくない。今や、パフォーマンスのトラブルは運用における最大リスクのひとつとなっています。

一方で、システムに目を転じれば、パフォーマンスのトラブルが起こるべくして起きていると痛感するような実態があります。まず第一に、アプリケーションの形態が変わり、システム環境に対する負荷の度合いが違ってきています。入力担当者によるパンチ型の入力が業務担当者自身による発生時点入力に変わり、それと共に、単純な伝票入力画面が業務支援を伴う画面へと変わっています。多様な入力支援の機能、マスターや候補値の表示。最近では、入力値に対して即座に基準値をぶつけて、業務上のアラートやワーニングを出すといった例も増えています。そして、入力したデータは即座に更新され、関連するシステムにそのまま連動されていきます。しかも、業務支援型のシステムは、業務のスケジュールに合わせて使われます。時々の状況によって利用のリズムが違い、ある一瞬に処理が集中したり、予期せぬ大量のデータが発生したりします。

このようなアプリケーションや利用形態の特性が、そのままシステム環境の動作や負荷の特性につながります。もちろんこれは、入力系のシステムだけの問題ではありません。また、オンラインの画面のことだけでもないはずです。バッチ処理にしても、従来はバッチと言えば夜間の更新処理を指していたのが、最近では、日中のオンライン利用時間中に大量のＥＤＩデータが入ってくる。その一方でシステム間の連動は、1日１回のバッチからもっと細かいサイクルに変わり、リアルタイムにトランザクションを行き来することも増えている、といった具合です。

もちろん、こうした変化はシステム開発時のキャパシティ・プランニングで十二分に想定しておくべきことですし、運用設計の焦点にもなるべきことです。また、パフォーマンスの状況を常にモニタリングすると共に、リソースを監視し、最適配分をする運用基盤も不可欠であるはずです。パフォーマンスのトラブルが多いということは、それだけ、今日のシステムではパフォーマンスの安定化が難しく、トラブルのインパクトも大きいということを指しています。しかし必ずしも、具体策がとられているわけではない。概念的には分かっていても、設計や実装上に具現化しているわけではない、といった実態が少なくありません。本来検討すべき場面で「意識」が十分でなく、意識を具現化するだけの「知識」もないと言っても過言ではない状況が一般的です。

パフォーマンスは今日のシステムにとって最重要課題であり、中でも、システム環境と運用の担当者に強くスキルを求めるものです。パフォーマンスのプロフェッショナルが不可欠であり、開発プロジェクトの初期からパフォーマンスを意識した検討と工程がとられるべきであるはずです。続出するパフォーマンスのトラブルは、システムの信頼性を揺さぶりかねない問題になっています。セキュリティ、コンプライアンスなどと同様に、「システム・リスク」のひとつとして、具体的なアクションが急がれています。

とはいえこれには、開発プロジェクトに運用組織がどう参加するのか、あるいは、開発プロジェクトはいかにしてシステム環境や運用と一体化していくのかといった本質的な課題が関わっています。そうした課題を認識しながらも、目の前のシステム化からパフォーマンスへの対策を講じていく。例えば、パフォーマンス・トラブルの原因のひとつに、アプリケーション、ミドルウエア、ハードウェア環境の３層にまたがるシステムの動作や負荷の特性と、用意したシステム環境が合っていないということがあります。この対策には、開発の初期に一部機能を使った「サンプル開発」をおこない、システムの動作やパフォーマンス特性を把握しておくことが非常に役に立ちます。特に、最近のシステムはミドルウエアへの依存度が高く、その選択によってパフォーマンス特性が大きく変わってくるということがあります。それだけに早い段階で、実際のシステムを通して特性を知ることは重要な意味を持ちます。

パフォーマンスの問題に対して十分な意識を持ち、設計や実装に具現化するだけの知識を育む。同時に、パフォーマンスが難関であることを前提とした開発工程とプロジェクト・プランを立案する。こうした一見当たり前に思えることを具体策にしていくには、強い問題意識が必要です。その機運をつくるのは、パフォーマンス・トラブルと常に背中合わせにある運用組織の切迫感ではないかと思います。次回は、このパフォーマンスにも大きな影響を与えているミドルウエアと運用の関係についてお話をしたいと思います。