出そうで出ないシステム性能：攻めの性能マネジメント

ハードウェアの性能は年々向上するが、ITシステムの性能問題が解決したという話は聞かない。システムの機能要件を満たすことと、構築したシステムが予想したとおりの性能を出すということは別次元の問題なのである。システムの性能は、開発工程の最初から管理しなければならない。そのための考え方と実践的な解決策を提示する。

ハードウェアの性能は上がったが、システムの性能問題はいまだに解決しない

　プロセッサのクロック数は電子的な限界に近づくほど速くなり、メモリは数十GBを搭載するサーバが当たり前。有り余ったハード資産は、仮想化技術でようやく有効活用できるといわれるほど、近年のハードウェア性能は目覚ましい進歩を遂げています。ハードウェア性能の例として、サーバ性能の指標値とされるベンチマーク値に注目してみましょう。SPECjbb2005という受注処理のベンチマークを例にすると、最新エントリレベルサーバで、40,000?50,000BOPSという結果が公開されています。これは、1秒間に数万回のオンライン処理が可能であることを示しており、1台でもかなりの業務処理ができると期待したくなります（実際の業務処理はベンチマーク値ほどの性能は出ないのが普通です）。

　ハードウェアの性能は確かに向上していますが、ITシステムの開発現場ではシステムの性能問題が話題になることも多いです。皆さんも一度くらい、以下のような話題に遭遇したことはありませんか？

• ネットで買い物をしようとして、ログインボタンを押したが、反応がない
• 毎日使う社内システムは、月末になると遅くなる
• 指定日までに決済処理が終わらない
• リリース当日にWebサイトが突然遅くなった

　「Webサイトが1日スローダウンして、5000万円の販売機会損失」「処理が5時間遅延して2億円の損害賠償請求」。そんな話も珍しくはありません。システムの性能問題は、実際に発生するとビジネスへのインパクトが大きく、それを放置すれば、企業の経営問題に発展する危険性があります。

　性能問題には（緊急に改善する必要がありながらも）、根本原因が分かりにくいという怖い特徴があります。原因解析をするには、高いスキルを持つ専門家や、高価な解析ツールの導入が有効なのですが、どちらもコストが掛かるうえに、すぐに手に入るとは限らないのが悩ましいところです。

性能問題の本質は、非機能要件を重視しないことにある

　ハード性能は向上したのに性能問題が多発する。なぜこのような矛盾が起きているのでしょうか？ 昨今の性能問題には、以下のような原因があるといわれています。

• ハード性能が向上した代わりに、システムの複雑度も上がった
• 構成要素のブラックボックス化が進んだ
• IT化が進み、データ量や処理量が大きく増えた

　確かにどれも性能に与えるインパクトは大きなものです。しかし、これらは、事前に実施できる対応策が確立されているため、どれも本質的な原因とはいえません。

　性能問題の本質に触れる前に、システムに対する機能要件と非機能要件について整理したいと思います。機能要件とは、ユーザー企業のシステム化対象業務そのものであり、システムの動作や処理内容のことです。それに対して非機能要件とは、信頼性や性能など、業務機能でない要件のことです。

　さて、どんなシステムでも最も重要なのは「仕様どおりに動くこと」であるためか、開発の現場では機能要件と比較して、非機能要件は軽視される風潮にあります。その影響で、業務機能の仕様やバグは管理されますが、システムの性能は管理されていないことが多いのです。実はそれが性能問題の本質なのです。

システムの性能に注目するのは、開発工程の中で2回だけ

　システム企画から開始される開発工程の中で、（システムの）性能が注目されるのは、以下の2回という開発を多く見掛けます。

　1回目はシステム構成を決定する段階です。導入するハードウェア／ソフトウェアが決定し、投資額に大きな影響があるタイミングなので、システム部門だけでなく経営層も注目しています。2回目は、出来上がったシステムに性能問題がないことが確認される段階、すなわち、リリース直前の性能評価が完了した段階です。運よくシステムの性能に問題が出なければ、めでたくリリースされます。

システムの性能が注目される時は2回くらい

　このようなやり方は、大きな問題を抱えています。何かあったら最後のチューニングでなんとかするという「出たとこ勝負」なので、もし問題が発生した場合は、リリース直前にバタバタとその場しのぎの対策をするか、それすらできずにハードウェアの増強やパフォーマンス・チューニングに巨額の追加コストを支払う可能性もあります。最悪の場合は、手遅れで何もできずにタイムアップとなります。

「システム性能には、それなりの手間と時間を費やしている」というプロジェクトもあると思います。そのようなプロジェクトには、ユーザー企業かプロジェクトマネージャあたりに、かつて性能問題でとても苦労した経験のある方がいらっしゃるのでしょう。その場合、性能問題が発生する確率はぐっと低くなるのですが、なかなか稀（まれ）なケースだといわざるを得ません。

　性能問題は一度起きてしまうと、プロジェクト全体に与える影響が大きいだけではなく、問題の解決には膨大な追加コストが掛かります。また、性能問題の解決には、時間的な制約が課されます。開発工程の後半以降で発生した場合、リリースに間に合うようにと早急な改善が求められ、運用中に発生すればサービスを復旧するために1分1秒を争うという具合です。つまり、性能問題への対処とは、問題を発生させないための予防と、発生した際の迅速な対応という2つの行動で構成されているのです。

性能問題解決の方向性：性能は「見える化」して、リスクを減らすようにする

　私は性能問題について緊急で呼び出されることがあるのですが、開発中／運用中を問わず、性能問題が発生するほとんどの現場に共通しているのは以下の2点です。

• 動かしてみたら遅かった。または、昨日までは問題がなかった
• どこが悪いのか分からない

　「どこが悪いのかよく分からない」というのが、性能リスクと呼ばれる理由でもあるのですが、たとえ性能が悪くても、機能試験は問題なくパスしてしまうため、性能問題は顕在化するまで認知されないことが多いのです。性能を「見える化」することで、リスクを減らすのが賢い対処方法といえます。つまり、重要なのは性能の積極的な「見える化」と管理、それをここでは「攻めの性能マネジメント」と呼ぶことにします。

　「見える化」の対象は、以下のように整理すればよいでしょう。

　上記の「見える化」を、開発工程の適切な時期に実施するのが重要です。例えば、ハードウェアのサイジングのミス（＝ハードウェア性能問題）が、ハードウェア発注前に明らかであれば何の問題もありませんが、運用開始後に発覚すると、最悪の場合はマシンリプレースに巨額のコストを支払うことになります。処理速度の遅さがコーディング作業前に分かればコーディング作業の手戻りは発生しませんが、運用中に問題となった場合、再設計からリリースまでに、多くのコストと時間が必要となります。

　以上を踏まえ、次回以降は事例を交えながら、「攻めの情報マネジメント」として実施すべき具体的な作業と考え方を説明します。