第6回 最適な設計はホスト時代の流儀に同じ？
 |
eビジネスアプリケーションは基幹連携の方法に違いがある |
前回の以下の4つの項目を思い出してください。これはクライアントサーバ技術者がeビジネスシステムを見て、クライアント・サーバシステムとの違いを感じる時ということで上げた、4つのポイントです。
| ● eビジネス・アプリケーションが分散から集中へ変化したこと |
| ● eビジネス・アプリケーションの基幹連携の方法に違いがあること |
| ● eビジネス・アプリケーションには第3者の行動が強く影響すること |
| ● eビジネス・アプリケーションを作るにはコツがあること |
今回は、この2つ目の項目の「eビジネスアプリケーションの基幹連携の方法に違いがあること」についてお話ししてみたいと思います。
最初に、クライアント／サーバの技術で作成されたシステムの構築事例を見てもらおうと思います。この処理の中でデータベース（以下DB）の中であるデータが必要になったとき、どのような処理になるでしょうか。以下の図を見てください。
 |
|
図1 クライアントからサーバを直接アクセスする（クライアント・サーバの世界では業務プログラムと基幹システムのアクセスが1対1に対応する）
|
クライアント・サーバシステムでは、クライアント側で起動しているプログラムが直接DBへのアクセスを行います。ここではクライアントの要求は、DBサーバに送られ何らかのDB処理が行われる事例です。例えばクライアントから要求された処理がデータの検索処理でしたら、クライアントからselectなどのSQLステートメントがDBサーバ側に送られて実行され、その結果がクライアントに戻されるわけですね。
|
プログラムが他の機能の恩恵を受ける。 それは相手の資源を使うこと |
多くのプログラムは処理の中でほかのコンピュータ・システムの補助を受けながら処理を行います。そのよい例がDBアクセスです。データ検索を行うのでしたら、プログラムからDBサーバに対して、データを検索してほしい旨の依頼をすることになります。
プログラムの中で行わなければならないデータ検索という処理を、DBサーバというほかのコンピュータ・システムの持つ機能を借りて実行し、そしてその答えをもらって処理を継続するわけですね。
こういう方法をコンピュータの世界では、「システム連携処理」などといいます。システム連携を行う相手先という点では、DBサーバだけがシステム連携の対象かといえば、決してそうではありません。例えばメールの送受信をしたい場合では、専用のメールサーバが存在します。
また、複数のプログラム処理を行って、万が一失敗したら、それまでやった処理をすべてなかったことにしたい場合があります。こういう処理を「トランザクション処理」といいますが、こういう場合はOLTPサーバを利用して、どこまで処理が進んでいたのかを記録してもらったり、また処理を元に戻してもらったりします。
同じように考えれば、ERPやコラボレーションなどのように、ほかのサーバ・システムと連動してプログラムを完結させるような相手先は山ほどあるといってもいいでしょう。
このようにシステム連携処理というのは、自分のプログラムですべての処理をやると複雑になってしまったり、もっと効率的にプログラムを完成させたい場合に、必ず出てくるコンピュータ構築技術になります。
|
システム連携処理には、 ミドルソフトの存在が欠かせない |
実はシステム連携という世界では、自分のプログラムに必要な機能をほかのコンピュータの力を借りて実現するという観点でいえば、もっと強力な考え方があります。例えば、システム連携先が○○サーバとか、××ミドルソフトではなく、すでに稼働している基幹系や情報系の業務システムでもいいわけです。例えば、すでに完成されているこのような基幹システムには、値を入出力するための端末（Webアプリケーションの世界ではブラウザですね）や、プリンタなどがあります。本来ならば端末へのアクセスは人間が行っていたわけです。しかし少し見方を変えて、もしこれら基幹系の処理を人間ではなくてプログラムから処理させることができればどうなるでしょうか？
そうです。本来そのシステムだけで完結していた処理の結果を、これから新しく作るプログラムで受け取ることができるので、基幹システムの処理した結果を、またさらに新しいデータに加工したり、ほかのシステムで活用できたりするわけです。
いうなればプログラムからサブルーチンを呼び出すように、プログラムが他システムのプログラムと連携する。これがまさしくコンピュータの世界でいうところの基幹システム連携処理になります。
このように、プログラムの中で足りない機能を他システムに求めるという考え方をすれば、サーバと連携するだけでなく、既存システムもその対象に入ります。
 |
|
図2 プログラムから他のシステムを使う
|
|
クライアント・サーバの基幹連携を サーブレットに置き換えてみると |
クライアント・サーバの世界では、クライアント側のプログラムから直接、ほかのシステムへの連携処理を行うことになります。しかしeビジネスシステムの世界では、業務プログラムがブラウザに存在することはありませんから、Webアプリケーションサーバなどで稼働しているサーバ上のプログラムからシステム連携処理を行います。例えばeビジネスシステムが、データベースへのアクセスを行うとすると、データベースへのアクセスは、すべてホスト側で集中的に行われることになります。この様子を分かりやすく示したのが図3になります。
 |
|
図3 eビジネスアプリの基幹システムへのアクセス（ブラウザからのアクセスが少ないときは問題は少ない） |
でも、ここでちょっと考えておかないといけない点があります。例えば、Webアプリケーションサーバにアクセスするユーザーが、この図のように数人しかいない場合は問題ありません。しかしインターネットは、アクセスするユーザーを特定したり、その頻度や時間帯など特定するのが難しい世界です。場合によっては、一挙に数千から数万のアクセスがWebアプリケーションサーバに発生することもあるのがインターネットを利用したeビジネスアプリケーションの難しいところです。
ここでもし、多数のブラウザから同時にサーブレットにアクセスが起これば、サーブレットに記述された業務処理はマルチで処理されて、そのすべての処理から他システムへのアクセスが行われることになります。これは連携する相手が基幹システムであろうと、DBサーバであろうと、状況は全く同じです。
 |
|
図4 基幹システムアクセスが一極集中する（ブラウザからのアクセスが集中すると一気にWebサーバと基幹システムへの負荷がUPする）
|
サーブレットの中でマルチ処理されている何千、何万ものアクセス処理が基幹システムやサーバに対して行われます。アクセスされる基幹システムやサーバにとっては、一挙に同時に襲ってくるアクセスの嵐に耐えられるようにに運用するのは、至難の業です。またサーブレットを起動するWebアプリケーションサーバにも大きな負荷がかかるでしょう。例えば相手のシステムに対するアクセスは、ミドルのクライアントソフト経由で接続されることが普通です。この接続処理は、通常の業務処理に比べて非常に大きなコンピュータの力を必要とします。この接続処理が同時に大量に発生すると相手の基幹システムだけでなく、Webアプリケーションサーバの能力を持ちこたえるのも多大な負荷になってくるわけです。
もちろん、こうなったらWebアプリケーションサーバを止めてしまえば、何の処理も行われませんから問題は発生しません。しかしそれではインターネットという膨大なeビジネスアプリケーションを使ったビジネス・ポテンシャルを奪ってしまうことにもなります。クライアント／サーバの世界では、あまり問題にならなかったシステム連携もクラサバのように個別に要求された場合よりも、大量にホストで集中的に行われると、非常に大きな影響を引き起こす可能性があるのがサーバ・サイドJavaの世界です。このようにeビジネスシステムというのは、明らかにホスト集中処理の特徴を考慮して構築されなければいけないシステムといえます。
 |
2/6 |  |
 |
連載記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （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に関する基礎知識を解説する。
 |
|
|
|
|
