【実体験あり】システムの性能問題は最悪な話

皆さん、システム開発を行う上で重要な要素の一つに「性能」があるのをご存じでしょうか。画面の表示や検索が遅い・できない、データの送受信が遅い、タイムアウトが頻繁に発生するなどの影響が出た際は性能問題が発生している可能性が高いです。
私はシステムの保守作業の経験があるのですが、この性能問題が一番嫌いでした。
今回は実体験をもとに、性能問題の大変さについて話していきたいと思います。
また、今回の話は性能問題の具体的な解決策を話しているわけではありませんのでご注意ください。愚痴に近いです。

システムの性能問題とは
実際に起きた性能問題
まとめ

システムの性能問題とは

システムの性能問題とは、システムが期待される動作の速度、容量、応答、効率などのパフォーマンスを維持できなくなる状態のことです。
性能問題が発生する原因としては、設計ミス、リソースの不適切な割り当て、ネットワークの問題、非効率なアルゴリズム、ユーザー増加など、さまざまな要因が考えられます。
定期的にモニタリングを行い、システムの最適化を行うことで防止することはできますが、性能問題を完全に避けることは難しいです。

実際に起きた性能問題

私は某保険会社のシステム保守を行っていた経験があります。今回はそこで発生した性能問題を2つ紹介します。

①画面で検索を行うとタイムアウトする

事象詳細
保険の案件を検索する一覧画面があり、検索条件を指定して検索を行うと、数十秒間通信中となった後でタイムアウト(エラー)となる。

原因
エラーとなった一覧画面は元々検索に時間がかかる画面でしたが、新たにビュー定義を修正したことで性能が悪化したと予想。

対策
ビューにヒント句を追加して、修正前後の実行計画を取得し、性能改善を試みる。
→ただし、ヒント句を追加するとOracleのオプティマイザが最適な実行計画を選択できなくなるリスクがあります。

結果
多少の改善が見られたため、今後も注視していくとしてクローズ。

嫌なこと、面倒なこと
・ユーザーの温度感が高い
これは仕方ないことですが、性能問題はユーザーの日々の業務に支障が出るため、温度感が非常に高くなります。現場はピリピリです。

・ユーザーが使っていない時間でリリース、試験を行う
ユーザーの業務時間にリリースを行うことはできませんので、残業確定です。また、リリース後は簡単にテストを行うことになります。性能問題は確実に障害が解消されるとは限りませんので、みんな早く帰りたい中、解消されなかった時の空気は地獄です。

・元々複雑なビューのため内部構造自体を修正できない(したくない)
ヒント句の追加は正直、その場しのぎの策となります。今後のことを考えてもビュー自体を修正するのが良いかもしれませんが、修正する立場としては修正やテスト、影響調査にかかる時間を考えればヒント句で解決するならそれで勘弁してほしいところです。

・リリース後もしばらく不安
性能問題は多くのユーザーがいて発生する場合もあります。実際に多くのユーザーがシステムを使う日中に再度問題が発生しないかは不安です。

②バッチ処理の時間が急増してリソースを大量に使う

事象詳細
普段5分以内で終了するバッチ処理が30分以上かかり、リソースも大量に使っていた。

原因
大規模なリリースの前後で統計情報が書き換わり、原因となりそうなテーブルの実行計画を比較したところ、明らかに処理が遅くなっていた（フルスキャンが発生していた）。そのため、このテーブルの統計情報が原因と判断。

対策
修正を行っていないテーブルのため、とりあえず統計情報を更新してみたい。ダメだったときは正直よくわからない。

結果
手動で統計情報の更新を行う前に、データ変動により自動で更新が行われており、実行計画で確認したら解決していた。

嫌なこと、面倒なこと
・ちゃんとした原因はわからなかった
この件は統計情報の更新でダメになって、次の更新で元に戻ったのでよくわからなかった。

・ユーザーは真の原因を求めたがる
性能問題の原因は不明確な場合も多いが、ユーザーは基本的に納得しません。「Oracleに聞いてくれ」とは言えないので、こちらも困ります。