TAKAが試したこと考えたこと

Webシステムが一般的になるにつれて、B2Cのサービス（EC、各種Webサービス）はWebシステムで利用されるようになった。
システムが企業のものだったのが、一般のものに変化したことによって、トランザクション量を想定することができなくなりました。

そこで、スケールアウトという考え方が浸透し、Webサーバ、アプリケーションサーバを横に並べて負荷が高まるにつれて一台あたりのトランザクション量を一定にすることでトランザクション量を増加しても対応できるようになりました。

負荷分散の基本的な考え方は、
　アクセスの入り口を1カ所に
　アクセスの出口を複数箇所にする
です。
この負荷分散をさせる１：Nの装置として、ソフトウェアが利用される場合、ハードウェアが利用される場合があります。

１） アクセスの入り口を1カ所にする
　アクセスの入り口を1カ所にするために、VIP（Virtual IP）を用いて、複数のサーバに対する入り口を一つにします。
　URLで振り分けをする場合でもVIPによって入り口を一つにします。

２） 出口を複数箇所にする
　負荷分散装置によって、どのサーバを選択するかを決定します。（負荷分散装置のアルゴリズムとして、ラウンドロビンや係数によって振り分けなどを選択できます）

この2つによって、負荷を分散し性能を維持していきます。

単純なクライアントサーバ型からアプリケーションサーバ型に変化すると単一なDBMSによってデータが格納されており、データの整合性を保っていたものが複数のサーバの連携によって実現されるようになるとデータの整合性を保つことが難しくなります。

あるサーバのデータが更新されたのに、それにひも付いている他のサーバのデータがサーバ障害によって更新されないといったことがあり得ます。データ不整合を防ぐために一連の更新処理がAll-Nothingで実施されなければなりません。
そのために、トランザクション制御（管理）することが重要になります。そのために分散オブジェクトにトランザクション管理機能を追加された構成が考えられます。それがCORBAでいえばOTSであり、一般的なアプリケーションサーバで言えばTPモニタです。

前回書いた構成にOTSサーバ、TPモニタを追加した構成が今日のアーキテクチャになります。

クライアントサーバ型から発展して、クライアントとDBのストアードプロシジャに分散する処理ロジックをビジネスロジック処理専用サーバで処理させる3階層のアーキテクチャがあります。

Webはこの発展系ですが、Web以外でもアプリケーションサーバとしてのミドルウェアを使う場合もありました。
Webシステムでたとえると一つのサーバとしてのイメージが強くなりますが、スケールアウトする構成ではなく、機能を束ねる単位でサーバを
分けて、構成しています。

分散オブジェクトをカテゴリで束ねてサーバ化した（CORBAなど）構成がこのような形状となります。

クライアントサーバ型のアプリケーションは、保守（派生開発）をしていく上で大きなポイントが一つあります。
それがタイトルに書いたクライアントの配布です。

1対1であればサーバの変更・リリースもクライアントの変更・リリースも同じ事ですが、
一般的にはクライアントの台数は多く、時には数万台に及ぶ場合もあります。

クライアントの変更（バグ修正・新機能追加など）を反映させるために、クライアントを
再インストールしなければなりません。それには膨大なコストがかかる場合もあるため、クライアントの配布の
仕組みはセットで考えます。

運用管理ソフトの機能の一つか、Java Web Start、ClickOnceなどの技術を用います。

ファイル共有による方式では、同時更新を苦手とする特性がありました。
同時更新を中心とする定型的なデータ（情報）の共有をするために、ファイルの中のデータを
同時更新可能な形で管理をするサーバを介して、複数のアプリケーションでデータを共有できるようにしたのが
DBMSを用いたクライアントサーバ方式のアプリケーションです。

アーキテクチャとして考えると、この方式にもバリエーションがあり、データ格納のみをDBMSで実施する方式とデータとデータ処理の一部をDBMSで実施する方式に分かれます。（これは3階層のWebシステムでも同等のバリエーションがあります）

スタンドアローンの拡張を考えた場合に、アプリケーションを複数人数で利用したいというニーズが発生すると思われます。

このような場合は、データ（情報）を共有し、アプリケーションを複数人で利用する方法を考えます。
つまり、スタンドアローンアプリケーションを各自のマシンに入れて、データだけを共有する方法です。

データを共有する方法はいくつかありますが、今回紹介する方法は、スタンドアローンで利用する
ファイルをファイルサーバで共有する方法です。

CIFSのようなプロトコルを利用してファイルを共有するサーバを介して、複数のアプリケーションが
連携します。

この方式は、同時に更新するブロックがファイルという全体に及ぶため同時更新に弱くなります。
同時更新を維持するためには片方を読み取り（参照専用）とするか、ファイルにロックをかけて誰かが使っている間は使えないようにするかなどの仕組みを追加する必要があります。

Excelを代表とするマルチビューアプリケーションは、MVCの本領を発揮するアプリケーションです。
マルチビューアプリケーションとは、同じデータ（情報）を違う見せ方で表示できるアプリケーションです。
Excelが代表的なのは、セルの値を表形式、グラフなどの複数の見せ方をするためです。

シングルビューのアプリケーションでは、ビューとモデルは対でしたが、マルチビューでは
モデルに対して複数のビューが関連します。

モデルにビューをプラガブルで関連できるようにして、表示させたいビューをモデルに
登録しておくことでモデルが変化した時に複数のビューを更新することができます。

単純な話ですが、仕掛けを考えないとスムーズにいきません。
また、モデルに登録するビューのインタフェースを明確にして、依存関係をできうる限り排除するというのもポイントとなります。

一昨日読んだ書籍。

アーキテクチャという言葉がいろいろな意味を持っているなと思いました。
ユーザ企業の情報システム関係者（もしかしたらエンドユーザとしても）が持つべき視点を
網羅的に描かれた面白い一冊。
図も多くて直観的に理解できるのは何よりもうまい本作りだと思う。