 |
||||||||||
|
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
||||||||||
| テスト環境と本番環境の違い | ||||||||||
|
「本番開始判定会議の2週間前にも関わらず、本番環境において端末オンラインのレスポンスがない」 某社におけるプロジェクトで本番判定会議を間近に控えた中、端末オンラインのレスポンスがないが、本番環境での仮稼動が本番開始の第一条件に指定されているので、何とか解決して欲しいとの依頼を受けました。 早々にこのプロジェクトの担当者に照会すると、テスト環境では問題なく稼働していたとのこと。本番環境で稼働させる際に端末のレスポンスがなくなるようです。従って「本番環境の設定の問題であって、アプリケーションに起因する問題ではないと思われる」とのことでした。 そこでテスト環境の構成を確認してみると、テスト環境は16MBitのLAN環境、本番環境は128KbitのWAN環境で、かなりの差異があることがわかりました。 この環境の差異についていえることは、本番環境の通信容量が小さいため、オンライン処理を行う上で端末とセンター側の間で複数回のやり取りが生じると、レスポンスの低下が生じるのが当然であろうということです。 次にプログラマを呼んで、オンラインを実現するプログラムの実装について聴取しましたが、課題が明らかにはなりませんでした。そこでもしやと思い、端末画面に表示される項目を毎回個別にセンター側へ読みに行く構造になってはいないかを確認したところ、その通りになっていました。 つまりテスト環境では16Mbit/sと通信容量が大きいため、端末とセンター間で通信が複数回発生しても問題となりませんが、本番環境では128Kbit/sと通信容量が小さいため、通信の頻度によりレスポンスが低下してしまいます。 解決の方法は1つです。端末の画面項目ごとにセンターヘ通信する方式を止めて、画面単位にまとめた後に通信する方式へと抜本的に変更することです。 この大手術を本番までに行い、何とかレスポンスの画期的な改善を実現しました。しかしかなりの人手を要し、多くのプログラマの支援が必要でした。しかしそれでも、このプロジェクトでは本番稼働に際してもう2つの壁がありました。 1つは取引先の開発端末のスペックに比べてユーザが保有する端末のスペックが古く、アプリケーション納入時点ではレスポンスが不充分だったことです。もう1つはやや専門的になってしまいますが、アプリケーションサーバとデータベースサーバのコネクション負荷に問題があり、端末数が35台を過ぎた辺りからレスポンスが急激に低下する現象が生じたことです。 前者については、使用頻度が高い用途に対しては最新スペックの端末を設置して頂くようにユーザを説得し、後者についてはデータベース・コネクションの張り方のタイミングを変更し対処しました。これらの問題の解決後、本プロジェクトのシステムはまったく何の障害もなく順調に稼働しました。  図2：回線速度の差による問題 （画像をクリックすると別ウィンドウに拡大図を表示します） 本プロジェクトの最大の問題はテスト環境と本番環境の根本的な違いを開発者自身が理解できていなかったことです。テスト環境は本番と同様のシステム・アーキテクチャを用意することが重要です。 本番環境とシステム・アーキテクチャが異なるテスト環境ではテストになりません。端末側でアプリケーションを稼働させる場合、本番で使用する端末スペック（CPUとメモリ）にあわせたテストをしておかないと、本番納入後にレスポンスが悪いなどのクレームが顕在化する恐れがあります。 そのため、必ず端末のスペックや基本的な環境は本番に合せた想定でテストを行うべきです。そして、プロジェクトの早い段階で基本的な動作検証を行っておくことが重要です。 今回は筆者が考える「技術力」について紹介しました。次回以降でも引き続き経験談を交え「技術力とは何か」を一緒に考えていきたいと思います。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
人気記事ランキング
-
-
連載
