第5回 クライアント・サーバとの根本的な違いを理解する
 |
eビジネスアプリケーションの処理は、 1対1の処理ではない |
上記のような、2台目の処理が、先に始まった1台目の処理を追い越して先に終了してしまうという事例は、別に特殊なことではありません。
コンピュータに対して指示した処理が重ければ重いほど処理時間がかかるのは当然ですし、インターネットのどの場所にブラウザがあるかも分かりません。ネットワーク性能の違いによって、素早くサーバに処理を指示できるものもあれば、そうでないものも出てくるでしょう。
実はこのサーブレットがこのような奇妙な動きをするのには、次のような原因があります。まずクライアント・サーバのアーキテクチャでは、クライアント側には必ず1本のプログラムがあって、それがサーバ側の、例えばデータベースに接続して処理を行っています。
 |
| 図7 クライアント・サーバの処理の流れ |
クライアント・サーバのこの考え方をeビジネス・システムでも応用して、Webアプリケーションを作成しようと考える方もたくさんいます。
例えば図7のようにそれぞれのパソコンに1つずつプログラムがあり、このイメージでプログラムがサーバ側で動けば、それで問題ない場合もあります。
このようなクライアント・サーバのアーキテクチャをそのままeビジネス・システムに応用すれば、クライアント側のプログラムがすべてサーバ側のWebアプリケーション・サーバというミドルソフトで稼働していると考えてもよいわけです。
これはこれでまずいというわけではありません。
しかしeビジネス・システムではプログラムが稼働する環境がクライアント・サーバとはまったく異なるという点で、このようなプログラムの配置や連携の方法だけを考えていくと、問題が出てくる場合もあります。
Webアプリケーション・サーバで稼働するeビジネスアプリケーションの実際の動きは、ちょっとクライアント・サーバとは違った、実に面白い動きをします。
 |
| 図8 eビジネスアプリケーションの処理の流れ？ |
|
サーバ・サイド側のプログラムは常に1本 |
eビジネスアプリケーションのサーバ・サイド側で稼働するJavaプログラムの動き方は、eビジネス・システム全体の仕組みに大きく依存しています。
eビジネスアプリケーションでは多くのブラウザがWebアプリケーション・サーバにアクセスして、サーブレットというプログラムを動かしています。
しかし起動するサーブレットは、要求してくるブラウザの数だけ存在しているわけではなく、常に必要な処理に対して1つしか起動していません。
このイメージを図示したのが、図9です。ブラウザは複数あるのですが、Webアプリケーション・サーバ上では、その処理を行うサーブレットは1本だけです。
ではなぜ数多くのブラウザからの要求を1本のサーブレットでこなせるかというと、そこにサーバ・サイドJavaがWebアプリケーション・サーバの下で稼働する方法の特徴が出てきます。
 |
| 図9 Webアプリケーション・サーバ上ではプログラムは1つ |
この連載「スマートなサーバ・サイドJava」を読んでいただいている皆さんには、おさらいになるかもしれませんが、ちょっと確認しておきましょう。
Webアプリケーション・サーバは、要求のあったサーブレットのプログラムをロードして稼働させます。
一度サーブレットを稼働させたらこのプログラムを常時メモリ上に保持しておきます。ブラウザから要求されるのは実はこのプログラムの中にある業務処理の部分です。ですから同一のプログラムの中にある業務ロジック部分をブラウザの要求に応じて同時に稼働させます。これがWebアプリケーション・サーバが提供してくれる、Javaのマルチスレッドという仕組みです。
さてここからより詳しい解説に入りますが、実はこういう仕組みを知っていたとしても、うまく稼働するeビジネス・システムを構築する方法にはつながりません。
皆さんが知っている知識や技術をどのように使っていくか、どの個所にこのようなリスクが潜んでいるか事前に察知できる技術が本当に重要になります。
|
Webアプリケーション・サーバの動きが、 |
この業務プログラムをマルチスレッドで動かすという仕組みは、だれがやっているのかといえば、それは実は業務プログラムの中をマルチスレッドで動くように作るのではなくて、Webアプリケーション・サーバが自動的に業務プログラムをマルチスレッドで動かしています。いわばこういう仕組みは、業務プログラムを作成する私たちが意識してやっているわけではありません。
こういう意識していないいろいろな仕組みの影響を受けてeビジネスアプリケーションが動くことを考えると、クライアント・サーバとeビジネスアプリケーションで同じ業務ロジックを動かしていたとしても、それ以外に多少考えないといけないことが出てきます。
その例が先ほどの1台目と2台目のブラウザで起動されるサーブレットの特徴的な動きに表れます。
この動きは、実はプログラムの中で使っている変数の定義の仕方に関係します。以下のように1本のサーブレットの中身を拡大してみると、マルチスレッドで同時にいくつかの業務処理が動いているとしましょう。
 |
| 図10 グローバル領域に置いた変数 |
この同時に動いているいくつかの業務ロジックで参照したり更新したりする変数が、すべての業務ロジックから別け隔てられることなく共通に見える領域（こういう変数の場所をグローバル変数とか、Java固有の用語ではインスタンス変数とかいいます）にあるとちょっと問題が出てきます。
1つのブラウザが処理を行って、変数の中に値を格納している間に、ほかのブラウザから起動された業務処理がまったく同じ変数の中身を書き換えてしまって、先に処理を終了してしまいました。
当然のことながら処理を続行している業務処理は、変数の中に正しい値が入っているものとして、処理を進めているので、場合によっては違った結果が出てきてしまうということになるわけですね。
こういう場合のサーバ・サイドJavaのプログラムで、変数を確保する位置は、全部から共有されて見える位置に置いてはいけません。すべての変数は、図11のように、必ず業務処理の中で完結するようなローカルな位置に確保しておかないといけないわけです。
 |
| 図11 ローカル領域に置いた変数 |
 |
3/5 |  |
 |
連載記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
