ツールを生かした開発の実際

データベースの設計で“はまる”ケースが多い

さて、こうした移行作業の中で、しばしばトラブルになるのが、移行後のアプリケーションのパフォーマンスに関する問題です。多くのアプリケーションでは、データベースを利用していますが、このデータベースの利用が、思わぬパフォーマンス問題を引き起こしています。

古いシステムでは、フラットなファイル構造のデータベースを利用している場合があります。また、現在よりもファイル・サイズの制約も厳しかったため、いくつものファイルに分割した構造を採用していたものもあります。これらを右から左にSQLベースのデータベースに移行すると、うまくいかないことがあります。

また、時間の経過とともに、データ構造が複雑化し、つぎはぎ化しているケースもあります。仕様変更や機能追加、ほかのシステムと連携するための修正などが蓄積して、最初の設計とはずいぶん変わってきてしまっているのです。

既存のシステムやデータが存在する場合には、現状の認識が重要です。現在あるものの姿を可視化して、どこに問題があるのかを理解しておくことで、「移行してみたらうまく動きませんでした」という事態を防ぎます。

筆者が所属するエンバカデロテクノロジーズが提供しているツールを例に挙げると、「ER/Studio」というデータ・モデリング・ツールがあります。ER/Studioに既存のデータベースからスキーマ情報を取り込むと、スキーマ情報から物理設計と論理設計を生成します。論理設計に戻ることができるため、移行先のデータベースが現状と異なるケースにおいても有効です。最適な設計に変更したら、新しい設計を実際のデータベースに反映できます。

開発段階で必要なパフォーマンス・チェック

データベース設計ではパフォーマンスの調査も重要です。データベースの処理速度は、扱うデータ量次第でn倍にも膨れ上がるためです。テスト稼働の段階で、本番に近いデータを投入してみたら、開発現場では起こっていなかったパフォーマンス問題が発生したという例をよく耳にします。これは、問題が起こっていなかったわけではなく、顕在化していなかっただけなのです。

開発段階では、限られた量のデータを用いて、機能テストを中心にチェックを行います。実際のパフォーマンス・チェックは、ある程度システムが組み上がってからでないと意味がないと考えるからです。しかし、そもそも発行しているSQLに問題があった場合や、余計なデータを非効率にクライアントへ転送していた場合などは、SQLの発行回数やデータの量によってパフォーマンスの問題が火を噴くことは明らかです。

こちらについても、解決の糸口となるツールを1つ紹介します。SQLのパフォーマンス問題を解決してくれる「DB Optimizer」です。DB Optimizerは、SQLをプロファイリングして、具体的にどの個所で時間を消費しているのかを分かりやすいグラフで表示します。CPU時間やデータ転送時間、SQLの解釈に要する時間など、具体的な成分ごとにグラフ化するので、ユーザーは何を改善すればよいかといった指針を立てることができます。

また、利用しているデータベースの種類などを考慮して、最適化されたSQLの修正案を提示してくれます。さらに、個々の修正案を実際に試行して、試行結果をベースにシステム環境ごとに最適な案を選択することができます。手動での試行錯誤や勘に頼ってきたこれまでのチューニング作業を、ツールのパワーで効率化できます。

移行プロジェクトの場合、既存システムの資産は、どうしてもブラック・ボックスに見えてしまいます。「箱を開けないでおいた方が、トラブルに遭遇しないのではないか」と安直に考えてしまいがちです。しかし、箱の中身がどうなっているかを確認せずに閉めたままというのは、決して良い解決策とは言えません。こういう時には、ツールを使って中身を掌握していきたいものです。

次回は、「速く作る＝Rapid開発」と「しっかり作る＝開発標準化」のバランスについて解説します。