障害対応とチューニングの危うい関係：システム開発プロジェクトの現場から（12）（1/2 ページ）

開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

パフォーマンス・チューニング・チームのリーダーに

　前回「オフショアなんて、怖くない」では、オフショアでの開発を含む大規模基幹システム構築プロジェクトの経験を基に、私がオフショア開発に思うことをお話ししました。今回はその続きで、同じプロジェクトでのパフォーマンス・チューニングについてです。

　オフショアでの開発・結合テストも終了し、システムテストが開始されました。移行のリハーサルも無事完了し、数百万件のトランザクションが投入されました……。と、ここまでは順調に見えましたが、移行データでのテストを開始してすぐに、性能に関する問題が表面化しました。

　数百件、数千件のテストデータでは問題なく動いていたアプリケーションが、ボタンを押しても数分間応答しなくなったり、最悪タイムアウトになったりし始めたのです。

　私はそのとき、移行チームのリーダーでした。システムテストの後工程には、当然ですがユーザーテストが控えています。何とかこの状態から脱しないと、ユーザーテストが開始できません。……と思っていた矢先、私はパフォーマンス・チューニング・チームのリーダーに任命されました（立候補したような記憶も多少あるのですが……）。メンバーは私を入れて5人ほど。そのうちの1人はスキルレベルが非常に高く、後から思うと本当にいい仕事をしてくれました。

　実はそれまで、大規模なシステムでのパフォーマンス・チューニングはしたことがありませんでした。しかし私は、何となくやれそうな気がしていました。データ移行を担当していたのでテーブル構造はほとんど理解していましたし、アプリケーションの仕様もほぼ押さえていましたので。

チューニング開始：インデックス再設計と計測第1弾

　とはいえ、テーブル数は1000以上、全機能数も数百に及ぶ大規模システムです。検索画面は、検索条件のバリエーションによってさらに倍増します。うーん、どこからどうやって始めよう……。やみくもに始めても終わりなき旅になってしまうし、時間的な余裕もそれほどない……。

　考えに考え抜いた揚げ句、私は以下の手順でチューニングを始めることにしました。

1. インデックスの再設計
2. 処理速度の計測およびチューニング対象の抽出（第1弾）
3. アプリケーション（SQL）チューニング（第1弾）
4. 処理速度の計測およびチューニング対象の抽出（第2弾）
5. アプリケーション（SQL）チューニング（第2弾）

　まずはインデックスの再設計を実施しました。インデックスの見直しは、設計書からもある程度実施することができます。それに、インデックスが最適であるという確証がないままチューニングを始めても、効率が良くないと考えたのです。

　自分が納得できるインデックスの状態を確認してから、処理速度の計測（第1弾）を実施しました。

　第1弾の計測では、検索画面ごとに使用頻度の高い検索条件2〜3個のみを計測することにしました。前述したとおり、全機能数および検索条件のバリエーションは相当な数になってしまいます。計測だけでかなりの時間が必要となりますし、いきなりすべてを計測しても、根本的なSQLのチューニングが必要な機能についてはあまり意味がありません。根本的なSQLがダメな場合、どんな検索条件で検索したとしても遅いのですから。

　対象を絞り込んで計測を行うことには、もう1つ重大な理由がありました。出だしから計測に多くの時間を費やしてしまうと、チューニング自体の実績はまったく挙がらないまま時間が過ぎることになります。そうなればメンバーのモチベーションにも大きく影響するでしょうし、プロジェクト全体への不安をあおることにもなってしまうでしょう。

チューニング第1弾と障害の発見

　こうして第1弾の計測を行って性能に問題のある機能を洗い出し、優先度を決めて、第1弾のチューニングを開始しました。

　私自身もチューニングを行いました。特にSQLのチューニングをして、例えば3分ぐらいかかっていた処理が1秒以内で終わるようになったりするのは、本当に気持ちが良いものです。このシステムではデータベースはOracleを使用していたのですが、チューニングを重ねるうちにOracleのオプティマイザがどう考えているのか分かるような気がしてきました。このSQLだとオプティマイザはこっちのテーブルから検索しに行ってしまうので、こうした方がいいな……といった具合に。多分、気のせいなのでしょうが……。

　SQLのチューニングをする際、注意しなければならないことがありました。当たり前なのですが、チューニングによって障害が発生することは絶対にあってはなりません。パフォーマンス・チューニングでコードが壊れてしまっては本末転倒です。

　そこで、SQLのチューニングを実施した際には必ず、チューニング前とチューニング後で検索結果がまったく同じであることを保証させるようにしました。万が一検索結果が異なる場合には、徹底的にその原因を究明しました。こうした作業を続けるうち、何と、非常に奥深い障害の発見、解消という副産物まで生み出すことができました。