設計上の問題

パフォーマンス劣化において、一見どこに問題があるかわからないようなケースがあります。

例えば徐々にパフォーマンスが遅くなっていったような気がするものの、特にアプリケーションレベルの変更やデータベース側の設定変更等何も行っていないといったケース。

こういった場合、実はもともとの設計そのものに問題があったりすることがあるわけです。

ここでいう設計というのはデータベースやアプリケーションを含む設計になるため、本当に多岐に渡り、一概にこの部分とはいえないわけですが、ここではデータベース側を中心に見ていく事にしましょう。

まずよくあるのが、マスタ表とトランザクション表のデータからデータを洗い替えして、データを公開するといったよくあるアプリケーション。こういった場合、データの洗い替え部分に一番時間がかかったりします。

複数のデータベース間を連携させる必要がある場合は、例えばスナップショットといった技術を使ったり、昔ながらにファイルを出力してFTPで転送してから、またロードして、といった流れで進めるものもあります。

こうした処理の場合、大抵問題になってくるのがデータ量の増大に伴うパフォーマンス劣化、です。データ量が増加すれば転送するデータ量や洗い替えで処理するデータ量も増大するため、必然的に時間がかかるようになってしまいます。

しかもこれは徐々に遅くなっていく類のものであるため、なかなか気付きにくいといった問題もあります。

これらはデータ量的な限界値を予め予測できていない、つまり設計上の問題によりパフォーマンス劣化が発生しているといえます。

この場合、例えばデータベース側の表設計を見直すか、処理経路を変更するか、サードベンダー製のツール等を使って素早く処理させるかといった対応をする事で対処したりします。

が、最初からこういった事態は予測できたはずで、最初から予測しておけばもう少し違った対応が出来たのではないでしょうか。

単純にCPU数を1枚多くしておくとか、DISK領域を分けておいてI/Oを分散させておくだけで済むとか、意外と単純な方法や設計で対処が出来たかもしれません。

設計上の問題とは、逆にいえば如何に未来を予測できたか。

これにかかっているといっても過言ではないのです。

アプリケーションレベルの変更

パフォーマンス劣化問題で意外と多いのが、コレ。

アプリケーションレベルの変更、とざっくり書いてみましたが、簡単にいうと

　・アプリケーションの追加

　・アプリケーションの変更

　　(ソース変更、改訂等)

　・アプリケーションの削除

といったようなことです。

特にソースレベルでの改訂で問題が発生することが多いようです。

例えばパフォーマンス向上を意図に索引をはったとします。

ある処理は索引経由でデータを取得できるようになったため、意図した通りパフォーマンスが向上したとします。しかし、他の処理もこの新しくはった索引を使うようになったとします。

もし本当は全表走査のほうが速いのがわかっているのに、索引をはったがためにこの索引を走査してしまう処理が出てきたとしましょう。

そうするとパフォーマンスが遅くなる処理も出てきてしまうわけです。

恐らく最も多いのが、索引設計を変更したタイミングで処理経路が大幅に変わってしまうことによって発生するパフォーマンス劣化なのではないでしょうか。

前回も書いた通り、こういった問題は開発環境や運用テスト環境におけるテストが何より重要になってきます。

そこでどの程度テストを本番環境に近い形で実施できたか。

これが全てです。

アプリケーションレベルでの変更を施す場合も、変更対象のアプリケーションだけでなく、全アプリケーションについて事前に検証し、問題が発生しないこと、またアプリケーションが予期した通りの動作をしていることを確認しておきましょう。

パラメータ変更

パフォーマンス劣化の問題発生時によくあるパターンの一つが、これ。

ここでいうパラメータは大きく、OSのパラメータとアプリケーション(RDBMSソフトウェアやWebApplication系ソフトウェア)のパラメータを指します。

一般的にパラメータ変更をする場合は、開発環境やテスト環境、或いは運用環境といった本番環境ではない環境を用いて十分なテストをした上で本番環境のパラメータを変更すべきです。

こんな「べき論」は誰しもがわかっているわけですが、しかし実際の業務に落とした際に必ずしもこういった本来すべきことが出来ないケースが多々あります。

例えば開発環境がない、開発環境はあるがスペックが本番環境と全然異なる、運用環境があるがデータ量が本番環境と全く異なる、といったようなことです。

こういった現実と踏まえ、結局は本番環境でいきなりパラメータ変更を行うケースがよくあるわけです。

パラメータといっても本当に多岐にわたります。

セッション数を増加させるもの、メモリのキャッシュサイズを変更するもの、ファイルキャッシュサイズの変更、非同期I/Oの変更、不具合に対処するためのもの、トレースするためのもの・・・・

大抵は良かれと思って、或いは現状よりも前向きによくするためにパラメータの変更をするわけですが、これが思いもよらぬ形で問題を引き起こすことがあるわけです。

例えばセッション数を多く受け入れれるような設定をしたことで、予想以上にメモリ領域が利用され、結局スワップが多発してシステム全体がスローダウンしてしまったり、トレースするためのパラメータを設定したら想像以上にトレースファイルが出力されてDISKを圧迫してしまったり・・・。

こういった事象は結局のところ、事前に十分なテストをしていないがために発生するものです。

現状、IT業界でもコストダウンが叫ばれており、少しでも安くシステムを作ってくれるところが重宝されたりするわけですが、往々にしてこういうところで作ったシステムや運用である場合に限って、こういう問題は発生したりします。

コストを下げれば、こういうリスクは必ず増大するわけです。

この点は多くの予算権を持つ皆様には是非ご認識頂きたい点ですね。

やはり開発環境と、運用テスト環境。これはあった方が良いに決まってるわけです。