勉強メモ２ - 負けてゐる日誌

.NETエンタープライズWEBアプリケーション開発技術大全VOL.3 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ)

作者: 赤間信幸
出版社/メーカー: 日経BP社
発売日: 2004/06/05
メディア: 単行本
購入: 5人クリック: 89回
この商品を含むブログ (24件) を見る

Vol.3に対するメモです。

Vol.3

p35 NLB(Network Load Balancing)方式による負荷分散

NLBはWindowsOSの組み込み機能です。（ドライバ）
Webサーバ群に対して1つの仮想IPアドレスを振ります。その上で、

・仮想IPアドレス宛に投げられたパケットはすべてのサーバがいったん受け取る
・NLBドライバによるフィルタリングによりいずれか1つのサーバ上のアプリだけが実際にリクエストを受け取る

レイヤ3スイッチみたいな機構ですね。
ただし注意点もあります。

p40 NLBでは実現できない負荷分散

プロトコルの中身に基づいた振り分けや、アプリケーションデータに基づいた振り分けを行うことはできない。
サーバのCPU負荷や応答時間に基づいた動的な不可分さんも行うことができない。

p59 物理2階層（ティア）型のシステム構成のメリット

物理3階層型システムの方が拡張性に富む（スケールアウトしやすい）という主張は、ほとんどの場合誤りである。

Webサーバの増設台数数上限に達するよりも前に、DBサーバ側にボトルネックが現れる。

そのほか著者は、
・PDF出力などの重い帳票作成処理は分離したいという反論に対しては「すべてのビジネスロジックをWebサーバからAPサーバに分ける理由にはならない」
・クラスタの設計や拡張の見積もりが困難である
と主張しています。
Javaの場合だとApacheHTTPServer - Java EE Server - DB Serverの構成が多いと思いますが物理も3構成にしているのが多いような気がします。Java EE ServerにApacheHTTPServerが組み込まれている場合は違うかも？

p90 Sessionデータの保存場所と耐障害性（ステートサービスとステートデータベース）

Sessionデータ(あくまでSessionオブジェクトに格納されているデータのこと)は4つの方式があります（表2-4）
・InProc：そのままメモリ上に保管する。
・StateServer1：Webサーバがデータをシリアライズして管理する。
・StateServer2：ステートサービスを立ち上げて、そのサービスがデータをシリアライズして管理する。
・SqlServer：DBサーバに値をシリアライズして管理する。

デフォルトではInProcモードとなっているが、開発中はこれをStateServer1に変更しておくことが望ましい。(略)
・InProcモードを利用した場合、シリアル化できないデータをSessionオブジェクトに格納してもえらーが発生しない。このため、運用系に配置するまで問題に気づけない危険性がある。
・InProcモードでは、シリアル化やデータ転送処理が一切行われない。このため、巨大なデータを格納していても性能劣化がなく、開発者が設計・実装のミスに気づきにくくなってしまう。

ありがち過ぎる…

p135 データキャッシュ

自動的なデータ破棄を行いたい場合には、データキャッシュを利用することが望ましい(略)。
具体的には以下のようなノントランザクショナルな読み取り専用データに対して、データキャッシュを活用することが望ましい。
・読み取りや準備・作成に時間がかかるが、頻繁には更新されない読み取り専用データ
・変更されることがめったにない、アプリケーション全体で利用される設定データ
　XMLファイルから読み込まれた設定データ

XMLファイルから読み込まれた設定データとかも自動的にキャッシュできるのがすばらしい。
定数クラスにリテラルを定義するより、業務の頻度が低いものはメモリに乗っからなくてもいいので便利。
ただ、キャッシュサイズが小さすぎた場合スラッシングみたいな状態になってしまい、レスポンスタイムが安定しないかも。

p155 Webアプリケーションの状態管理のまとめ

ユーザ状態管理

クライアントサイド

ViewStateオジェクト

Cookie

クエリ文字列

サーバサイド

Sessionオブジェクト

HttpContextオブジェクト

SQLServer

アプリケーション状態管理

サーバサイド

Applicationオブジェクト

static変数

SQLServerカスタムDB

Cacheオブジェクト

HttpContextオブジェクトはJava EEでいうリクエストスコープ。

p160 IIS(Internet Information Serices)概要

IISは5.x系と6.0系で大きく異なる。
6.0系はWindows Server 2003以降に搭載されている。

p169 ISAPI拡張によるアプリケーションランタイムへのルーティング処理

IISの基本動作はファイルをHTTP経由で返すことだが、ISAPI(アイサピ）Extensionによって「クライアントから要求されたファイルの拡張子に応じて適切なアプリケーションランタイムへの振り分け処理を行う」ことが可能

Windowsの基本的な概念がそのままWebアプリケーションに応用されているのが納得感ある（思想として統一されている）。
Javaの場合だと、APサーバにWebアプリのコンポーネントをdeployして、URLをマッピングする作業になる。結果的にできるものは同じだが、Javaの方はWebアプリの世界観を習得しないといけないので大変。

p173 ISAPI拡張に対する注意点

IIS 6では、クライアントから要求された拡張子がISAPI拡張に登録されていない場合、MIMEマップと呼ばれるマッピング情報を確認する（略）。MIMEマップに登録されていない場合には、静的コンテンツだとは言い切れない。このためIIS 6はクライアントに対して404 File Not Foundエラーを返す。

むしろIIS 5の場合は.csや.aspxが拡張子として登録されていないとソースをそのまま返すという仕様になっていたことのほうがありえない。
IIS 6は未定義の場合はなにも404を返すのでフェイルセキュア。

p200 アプリケーションリスタートとその条件

Webアプリケーションに大幅な変更が加えられた場合にはアプリケーションをリスタートさせるようになっている。
・大量のファイルが更新された場合
（略）

ハマりそう…
なお、「大量」の正確な定義はweb.configファイルのcompilation要素のなｋのnumRecompilesBeforeAppRestart属性で定義される。

あとはそんなにJavaと変わらないと思いました。