C/S型システムのデプロイ作業で発生したトラブルの話

先日、とある受託開発で開発したC/S型のシステムを、エンドユーザの運用環境にデプロイした時に発生したトラブルと、その解決に至った経緯の話です。

この記事に出てくる技術要素：SQLServer (データ移行/パフォーマンスチューニング)、仮想環境のメモリ割り当て

システム構成

そのシステムは以下の図のような構成となっていました。

ローカルネットワーク内にサーバとクライアントが配置される、典型的なC/S型のシステム構成です。 (※実際はもう少し複雑で、アプリケーションをClickOnceで配布したり、サーバ上でいくつかのサービスが実行されていたりしますが、今回の内容には関係ないので省略しています。)

サーバは複数のシステムが動いているようで、それぞれに仮想サーバが割り当てられています。今回のシステムもサーバ上に新しく仮想サーバを用意してもらい、そこにデプロイしました。

トラブル発生：システムの応答速度が異常に遅い

事前に社内で同一構成の検証環境を用意して、デプロイのリハーサルと動作確認を行いました。その時には何事もなく、システムも正常に稼働していたのですが…

デプロイ作業当日、運用環境へのサーバセットアップは順調に進んでいました。ほぼ見積通りの時間でデータの配置を終え、いざ導通確認。ということでクライアントからアプリケーションを起動してみたところ…

アプリケーションの動作が全体的に重い。

使い物にならないレベルで待たされます。何故..と思いながら調査を進めた結果、どうやらクライアントからサーバ上のデータベースに接続し、SQLコマンドを実行するタイミングで待たされることが分かってきました。

原因1. SQL Server インデックスの断片化？

システム上で実行されるSQLコマンドの大半はSELECT文なので、テーブルにインデックスが張られていないことも一瞬疑いましたが、確認したところインデックス自体は張ってありました。いよいよ当てがなくなってきたな…と悩んでいたら、トラブルについて相談していた上長から以下のSQLコマンドを実行してみるようにと指示が。

ALTER INDEX ALL ON {table_name} REBUILD;

インデックスの再構築コマンドです。これを実行してみたところ、コマンドの実行時間が1/5になり、目に見えて速度が改善されました。ということは、インデックスの断片化が進んでいたのでしょうか。

今回、運用環境へのデータ配置において、SQLServerデータベースは、別の環境で構築したデータベースをデタッチ&アタッチで移行することで配置したのですが、この作業で断片化が進むという情報がMicrosoftのフォーラムでも確認されました。なので、データ移行でSQLServerのパフォーマンスが落ちた時にはインデックスの再構築を行う意味はありそうです。