ソフトウェア技術者のためのバグ百科事典（12）デスマーチを呼ぶ処理時間のバグ：山浦恒央の“くみこみ”な話（133）（2/3 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

4．バグの例題

　処理時間のバグとはどのようなものなのでしょうか。下記に例題を示します。

4.1 組み込みソフトの場合

　組み込み系のソフトウェアでは、数十ms間隔の割り込みハンドラに、動作させたい処理を記載することが多くあります。その際、例えば、10ms間隔で動作するルーティンに、30msの処理を入れると、不可解な動作をします。

4.2 データベース系のソフトウェア

　データベースにアクセスするソフトウェアでも、処理時間は重要な要素となります。例えば、ECサイトでは、顧客データ、商品データ、注文データなどの大量のデータを処理します。データ件数が増えるほど、処理時間が遅くなり、最悪の場合、顧客が閲覧・選択した商品の購入手続きに時間がかかり、購入しないままWebブラウザを閉じる可能性があります。

　これは、ECサイトでの致命的なバグであり、絶対に避けねばなりません。

4.3 数値解析系ソフト

　数値解析系ソフトウェアの場合、大量の計算処理を実行するため、ハイスペックなPCを選定しても計算がすぐに終了しないことがあります。計算結果を返す応答時間が許容範囲を超えると、役に立たない解析ソフトとなります。

5．やってしまったバグ

　筆者がデータベース系のソフトウェアを作成したときに経験した処理性能系のバグを紹介します。

　当時、試験用の環境と本番環境は別々にありました。そのため、開発中は試験用環境を使い、正常に動作することを確認してから本番環境に移行し、最終確認しました。

　筆者は、試験用の開発環境上でテストして処理時間系のバグはないと考え、安心していました。その後、本番環境に移行すると、試験環境では想定時間内に終了していた処理が想定値を超え、場合によっては次画面へ遷移しない現象が発生しました。

　原因を調べると、大きな問題は以下の2つでした。

• 試験環境と本番環境では、データ量に大きな差があった
• 不必要なデータにアクセスしており、処理時間をロスしていた

　試験環境では、本番を想定した十分なデータ数を用いてテストしておらず、その結果、本番環境で苦しみました。また、不必要なデータへのアクセスも分かり、2つを対処したところ、大幅に応答性能を改善できました。

　早い段階で、試験環境と本番環境の違いを明確にすべきだったと反省しました。とはいえ、試験環境と本番環境を分けていたため、試験環境で十分なデバッグができ、基本機能が正常に動作することを確認していた効果は非常に大きく、不必要なデータをアクセスするバグを検出、修正するだけで、応答性能を改善できました。

　もし、データの不必要なアクセスのバグがなく、広範囲で少しずつ応答性能を上げねばならない状況であれば、このソフトウェア開発はデスマーチ化していたかもしれません。

6．バグの兆候

　処理時間に関するバグは、動作するソフトウェアがない要求仕様の定義段階では簡単には想定できませんが、プログラムがある程度動作するフェーズであれば、比較的簡単に検知できます。例えば、以下のような兆候が出ます。

• 操作をしていて動作が遅いと感じる（画面遷移がギクシャクする、結果が返ってこないなど）
• ログや計測ツールなどで応答性能が規定値に達していない
• 負荷が掛かり過ぎてプログラムが止まる

　上記の通り、現象自体は追うことができますが、デバッガを使用すると、デバッガの処理時間の陰に隠れて、上記の兆候が発生しない可能性がありますので、注意してください。また、CPU使用率なども並行して確認しましょう。