エンジニアコラム

渡邊 聡 渡邉 聡

0 0

答えはだいたい「反対側」にある

2018.09.03

答えはだいたい「反対側」にある

プログラムを改善するヒントの見つけ方

ソフトウェアプログラムの処理性能において速さは絶対善です。速さは最重要指標と言ってもいいでしょう。簡単で小さなデータを扱うプログラムであれば、昨今のCPUや潤沢なRAMを搭載したマシンなら、処理速度に辟易することは少ないかもしれません。しかし巨大なデータを扱うプログラムの場合、そのアーキテクチャ(基本設計や設計思想)によって歴然とした処理時間の差が出ます。

経験の浅いソフトウェアエンジニアの場合、仕様要件を満たすことで頭がいっぱいになってしまい、処理速度の考慮が二の次になってしまうことがあります。今回は、私が入社半年後に、初めて一人で任されたサブシステムの開発での経験です。そこで私が突き当たった壁(処理時間の改善)をどうやって乗り切ったのか。拙い経験ではありますが、参考になればと思いお話します。

開発テーマはデータ移行ツール

私が任されたサブシステムは、ある旧システムからシステム刷新のため、新システムへのデータ移行を行うものでした。今ではあまりやらないことですが、SQLを組み合わせたプロシージャ(複数の処理位を一つにまとめたプログラム)を作成し、順番にバッチファイルで起動し、データベース間で、データ変換、移行処理を行うものです。

当初、自分的には簡単なプログラムだと考えていましたが(新人にありがちなやつですね・・・)、ただ単にデータを移行するということではなく、運用保守の面、ユーザビリティを考慮すると、処理時間が大きなネックになることに気づきました。

着手時は、本当に単純なルールで変換することで実現できるだろうと安易に考えていました。しかし、作業を進めるほど、そう間単にはいかないということが分かり、プログラム処理時間の長さという壁にぶつかりました。処理時間が長いということは、ユーザビリティが悪い(ユーザーストレス)のはもちろん、デバッグ中にも言えることですが、何か問題があったときにやり直しが簡単にできないという問題があります。

処理時間が長くなる原因

処理時間が長くなる理由には、大きく下記の2点がありました。

(1)旧システムのデータ仕様が不規則な上にパターンが複数ある

旧システムでは、ユーザが自在にフォーマット編集やルール決めができるようになっており、任意なデータを作成することが可能。したがってそこから全てのユーザのデータを新システムに移行可能にできるように、全てのデータベーステーブルに様々な変換処理プログラムを埋め込みました。
そのため実際走らせてみると、条件分岐が多重に発生し、その処理時間が予想以上にかかっていたのです。また変換処理時間だけでなくその前の、旧システムのデータ仕様のインポートにも時間はかかっていました。

(2)移行対象データが膨大

レコード数が数百万になるテーブルで、かつテーブル数も100以上ありました。旧システムでの運用レコード数が大きいため、単純に条件を組んで処理を行おうとすると、処理時間がレコード数に比例して長くなります。デバッグ時には、サンプルレコードで数を絞って行っていたので、さほど気に留めていませんでしたが、初めての結合テストでは、実に半日以上かかり唖然としてしまいました。

このことにより、新システム側のデータベース設計の見直しで挽回できないかと考えたのですが、データ変換仕様という面では既にコミットしていたため、テーブルインデックスなどの見直しに留まり速度改善には至らず、1年目のエンジニアとしては、決定的な次の手を思いつくことがすぐにはできませんでした。

本サイトの閲覧には会員登録(無料)が必要です。

会員登録はこちら

×