三層クライアント・サーバ型 データベース・システム
ユーザが地理的に遠く離れた拠点に分散して帯域の狭い回線を使わざるを得なかったり、クライアント数が多すぎたりして、通信負荷に回線が耐えられない場合や、データベースサーバの負荷が大きくなりすぎた場合に、中間層にあたるアプリケーション・サーバを用いて、通信量の圧縮および、データベースサーバ負荷の軽減・分散を行うものです。
メリット
- データベースが比較的安全に保たれる(二層C/Sと同じ)
- クライアント・アプリケーションと、データベース・サーバ間の通信量を、二層C/S型のシステムに比較してさらに激減できるため、インターネットを含めたWANを介して遠隔地からのアクセスが実用的に可能になる
- アプリケーションサーバ上に一部のアプリケーション機能を登録することで、通信量をさらに減らせる。(サーバサイド・アプリケーション、サーバサード・スクリプティング、サーバサイド・ロジックなどと呼ぶ)
- データベースサーバのリソース負荷を軽減でき、ユーザ数の増加に耐え得るシステムを作りやすい。
- データベースのセキュリティを保ちやすい。
デメリット
- 三層クライアント・サーバを実現するミドルウェア製品は、もともとハイエンドユーザ向けに開発された製品が多く、一般にオーバースペックで、とにかくライセンス価格が高い
- また、ローエンドユーザ向けのミドルウェアが普及する前に、簡易三層C/SアーキテクチャとしてWebアプリケーションが一般的になったため、現存するミドルウェアのほとんどは、高度なプログラミングスキルを要し開発生産性が低いままに放置されている。
コメント
三層クライアント・サーバの実現は、一般に、二層クライアント・サーバに比較してかなり難しく、高価なミドルウェアを購入し、高度なトレーニングを受けなければ設計・構築ができないと、一般に考えられて来ました。Webアプリケーションは、一種の三層クライアント・サーバシステムですが、アプリケーションサーバとクライアントの通信にHTTPという一般的なプロトコルを使うことで、実装技術の導入コストと技術習得のハードルを同時に引き下げた点で歓迎されています。しかし、三層クライアントはまだ死んではいないのです。
なぜ三層C/S型システムは大規模分散システムに強いのか
WAN回線に最適化された通信
在来のクライアント・サーバ型RDBMSのネットワークプロトコルは、LANでの使用を前提に作られています。これは、ネットワークの歴史上、LANでの使用の方が先に一般的になった結果です。このようなプロトコルは、クライアントとサーバの間での通信を頻繁に行うため、細くて伝送遅延のある回線を経由するアクセスの場合に、使い物になりません。
三層C/S向けミドルウェアは、いろいろな方法によって通信量・通信回数を減らします
- たとえば、検索結果のデータを一件づつクライアントから要求するのがLAN環境では普通ですが、WAN環境の場合は、検索結果を全件一度にアプリケーションサーバが取得し、データをまとめて圧縮してからクライアントに一括転送して、クライアントで展開するという「一括取得」「圧縮通信」などの方法によって、通信回数と通信量を共に削減するということが考えられます。
- また、クライアント上でのデータ更新を、一件づつサーバに反映するのがLAN環境では普通ですが、WAN環境の場合は、更新内容をクライアントアプリケーションがローカルにキャッシュし、差分データを圧縮通信によってサーバにまとめて送り、一括して更新するという方法によっても、通信回数・通信量が削減されます
DBサーバー資源の有効利用
二層C/S型RDBMSは一般に、接続したクライアントごとに一定のメモリ資源を割り当てるため、同時に接続するユーザ数が極端に増えた場合に、サーバ上のメモリを大量に消費してしまうという欠点を持っています。
実際のところ、典型的なオンラインアプリケーションの場合、ある一時点で考えた場合ほとんどのユーザは、クライアント画面をただ「眺めて」いるだけであり、1000台の端末が接続されていても、「登録」ボタンを押すユーザは同時に5人もいるかいないかというのが実情です。たった5人のために、1000人分のセッションを維持するのはサーバのハードウェア資源の無駄といえるでしょう。
そこで、三層C/S型システムのアプリケーションサーバは、常時データベースサーバとの間に維持する小数(たとえば10)のセッションを、多数(たとえば1000台)のクライアントの内で本当にその時点でDBアクセスが必要な小数(たとえば7台)のクライアントに対して割り当てるという方法で、データアクセスを取り次ぎます。(コネクション・プーリングと呼びます)
これによって、同じハードウェア仕様のDBサーバで、数十倍以上の端末数に対応できるようになります。
負荷分散
さらに端末数や同時実行トランザクション数が増えた場合にも対応するため、三層クライアント・サーバのミドルウェアには負荷を複数のサーバに分散させる機能を備える場合も比較的多くあります。クライアントからのリクエストを、複数のアプリケーションサーバが分担して引き受けるアプリケーションサーバの負荷分散もありますし、アプリケーションサーバからのデータベースアクセス要求を複数のデータベースサーバで分担するという、データベースサーバの負荷分散もあります。
代表的な製品は？
いわゆる「アプリケーション・サーバ」「TPモニタ」などと銘打った製品の中で、Webアプリケーションをターゲットとしていないものが、三層クライアント・サーバ型システムに必要なミドルウェアに相当するものだといえます。ハイエンドの製品ということで、歴史的理由からWindows環境よりもUNIX環境向けに様々な製品があります。提供される機能のレベルも様々で、網羅することは困難です。
それぞれの製品には特有の機能があり、千差万別であるため、一つ一つを挙げた機能比較は行いません。実際のところ、使い方を習得するのは一苦労なので、乗り換えのコストも高く、一度導入した製品を使いつづけるユーザが多いでしょう。歴史的政治的な理由によって製品が選定される割合が高いのではないでしょうか。
残念なことにDelphi開発者の皆さんには、あまり選択肢がありません。
| Borland DataSnap (MIDAS) | |
|
Borland純正のソリューションがこれです。 |
|
| 価格 |
Delphi6 Enterprise版(定価36万円)で開発 |
| ASTA | |
|
サードパーティ製の安価なソリューションです。対応しているDBMSの種類も豊富。 |
|
| 価格 |
Delphi Professional で開発 |
弊社ではASTAを使用しています。Delphi Enterpriseを購入するお金がなかったので。
私はたまたま、ASTAのトレーニングセッションに参加する機会を持てましたが、MIDASにしてもASTAにしても、何のトレーニングも受けずにこの手のミドルウェアを独学で使いこなすのはほとんど困難との印象を受けました。これは何とかしなければと思っています。
