プロセス親和性とステート認識モード (保持モード 1)

Web のアーキテクチャはステートレスです。Web アーキテクチャから最高のパフォーマンス、保守性、およびスケーラビリティを引き出すには、Web アプリケーションはステートレス・パラダイムを採用する必要があります。

既定では、Web アプリケーションはホストする InterSystems IRIS® サーバに対してステートレスな環境で動作します。Web ゲートウェイは InterSystems IRIS への接続プールを維持して、それらに負荷を分散し、構成された制限以内で接続プールのサイズを増加または減少させます。 各接続は ($Job 変数によって指定される) 1 つの InterSystems IRIS プロセスに関連付けられます。

ステートレス・モードで動作する通常の Web アプリケーションの場合は、クライアント・セッションに対する各要求を処理するために使用されるバックエンド InterSystems IRIS プロセスの選択をランダムにすることを検討してください。 Web ゲートウェイは、そのときに利用可能な任意の接続/プロセスを選択します。

ただし、効率性を高めるために、Web ゲートウェイは一種の InterSystems IRIS プロセス親和性を実装します。 つまり、可能であれば、セッションに対する前回の要求を処理するために使用されたものと同じ InterSystems IRIS プロセスにセッションへの要求を転送しようと試みます。

Web ゲートウェイはセッション ID に基づいたプロセス親和性に加え、ネームスペースに基づいたプロセス親和性の実装も試みます。 Web ゲートウェイは各接続がポイントするネームスペースを追跡し、可能な場合は、要求の処理に必要なネームスペースを既にポイントしている接続へ要求を配信します。 これにより、各 Web 要求の受信時に異なるネームスペース間でリソースを移動する際に発生するオーバーヘッドを回避できます。

優先順位という点では、接続を選択する際は、セッション親和性が常に他のすべての考慮事項より優先されます。受け取った要求をそのクライアント・セッションの処理に前回使用された接続に割り当てることができない場合は、代わりにネームスペース親和性を使用して最終的な選択が行われます。

CSP には、セッションに対するすべての要求を予約済みの (またはプライベート) InterSystems IRIS 接続/プロセスに Web ゲートウェイが転送するモードが含まれています。 この処理モードは、Web セッションとそれらに対応する InterSystems IRIS プロセスの関係に関してステート認識の環境を提供します。

ステート認識モード (保持モード 1) による処理は、固定クライアント・サーバ環境 (ターミナル・アプリケーション) から Web への従来のアプリケーション・コードの移行を比較的簡単にすることを当初の目的として提供されました。 また、複数の HTTP 要求に広がるトランザクションのサポートも考慮されました。 ただし、ステート認識アプリケーションを作成する際は、以下の段落で概説する制限事項に注意することが必要です。

ステート認識アプリケーションは、ステートレス・アプリケーションほどスケーラビリティが高くないため、新しいアプリケーション (および既存のアプリケーションの変更) は実質的にできる限りステートレスに設計することが推奨されます。 ステート認識モードを使用する場合は、大部分はステートレスなアプリケーションで、控えめに適用することをお勧めします。

アプリケーション全体をステート認識モードで動作するように作成することはお勧めできません。 ステート認識アプリケーションでは、全セッションそれぞれに InterSystems IRIS プロセスを予約する必要があるためにスケーラビリティの問題が発生するほか、転送要求に対する非常に固有の要件により、最新の負荷分散およびフェイルオーバー・ソリューションをフルに利用することができません。 また、ステート認識アプリケーションは、ステートレス・アプリケーションほど優れた耐障害性を備えていません。 例えば、Web サーバ・ワーカ・プロセスのリサイクルはステートレス・アプリケーションの下で透過的に発生しますが、その結果、関連付けられたすべてのステート認識セッションが閉じてしまいます。 もちろん、Web ゲートウェイの NSD コンポーネントを使用して、Web ゲートウェイ・プロセス・プールの管理をホスト Web サーバから分離することで、この後者の制限事項は回避できます。

適切なステート認識アプリケーション (または大部分がステートレス・アプリケーション内のステート認識セクション) を作成するには、ある程度のコントロールが必要です。

セッションに対するすべての要求は同じ InterSystems IRIS プロセスによって処理する必要があるため、クライアントが複数の要求を同時に送信する場合にプライベート InterSystems IRIS プロセスへのアクセスをシリアル化するためのキューを維持する必要があります。 元の HTTP v1.1 標準は、クライアントは各サーバに対して同時に 3 つ以上の接続を開いてはいけないと定めています (RFC2616)。 ただし、この制限は構成可能で、実際には、最新世代の Web ブラウザは、既定で、各サーバに対して最大 8 つの接続をサポートしています。 もちろん、各サーバへの最大接続数が増加すると、ステート認識 Web アプリケーションは深く影響されます。つまり、アプリケーションは、最大 8 つの要求が同時に送信され、1 つのプライベート InterSystems IRIS プロセスへのアクセスを制御するキューに保持されることを期待するようになります。

ステート認識モードで考えられるもう 1 つの落とし穴は、Web ゲートウェイと InterSystems IRIS の間で動作するサーバ応答タイムアウトの影響です。 応答タイムアウトによる所定の制限時間内に Web ゲートウェイが応答を受信しなかった場合は、接続を閉じる以外の措置をとることはできず、結果的にステート認識セッションは失われてしまいます。

最後に、クライアントが中断すると、ステート認識モードで動作しているアプリケーションで問題が発生する可能性があります。 InterSystems IRIS が応答を生成する時点以降にクライアントが要求を中断すると、Web ゲートウェイは接続を保持するために (不要になった) 応答ペイロードを吸収しようとします。 この場合も、これをタイムリーに行えない場合は、InterSystems IRIS プロセスを中断する以外の措置をとることはできなくなり、接続が閉じられてセッションが失われることになります。 中断された要求のペイロードを Web ゲートウェイが吸収しようとしている間に、同じセッションに対するさらなる要求が到着してキューに置かれる可能性があることに注意してください。

ステート認識アプリケーションを作成する際に従うべき設計目標を以下にまとめます。

• 多数の同時要求を生成するクライアント構造 (例 ： HTML フレームセット・ドキュメント) は、できるだけ避けます (または控えめに使用します)。

• 応答が迅速に生成されるようにします。 これにより、タイムアウトやクライアント中断イベントに関連する問題の範囲が縮小します。 また、セッション・キューの圧力が軽減されます。 InterSystems IRIS のタスクを完了するのに長い時間がかかると予測される場合は、プライマリ・プライベート・プロセスが Web ゲートウェイ (とクライアント) にすばやく応答を返すことができるように、別のプロセスでそのタスクを実行することを検討してください。

ステート認識モードの起動

以下のように保持モードを設定することで、セッションをステート認識にします。

Set %session.Preserve = 1

フォームの OnPreHTTP メソッドでセッションをステート認識としてマークすることを推奨します。

<script language=objectscript method=OnPreHTTP arguments="" returntype=%Boolean>
Set %session.Preserve = 1
Quit 1
</script>

ここで指示を出すことで、CSP エンジンは HTTP 応答ヘッダを作成して Web ゲートウェイに送信する前に、セッションの cookie (またはトークン) をステート認識としてマークできます。

OnPreHTTP メソッドが起動した後でセッションをステート認識としてマークすることもできますが、この場合、セッションの cookie/トークンは既に作成されています。 CSP エンジンは、preserve=1 という指示を応答フッタで Web ゲートウェイに渡し (応答ペイロードの後で送信)、Web ゲートウェイは接続を private とマークして、そのセッション ID に対する指示をキャッシュします。これによって Web ゲートウェイは、以降の要求が到着した際、unmodified セッション・トークンをステート認識として識別することが可能になります。

OnPreHTTP メソッドでセッションがステート認識としてマークされた場合、その情報は事実上クライアントに常駐するセッションの cookie/トークンで運ばれるため、Web ゲートウェイはそのセッションの移行をキャッシュする必要はありません。

ステート認識モードの維持とエラーへの応答

セッションがステート認識としてマークされ、Web ゲートウェイがステートの移行を認識して接続をプライベートとマークすると、以下のイベントのいずれかが発生するまでセッションは透過的にステート認識モードで動作します。

• アプリケーションがステートレス処理モードに戻った場合。

• アプリケーションがプログラムによってセッションを終了するか、セッションがタイムアウトした場合。

• エラー状態の結果としてプライベート接続が不完全に閉じた場合。

(おそらくエラー状態の結果として) ステート認識アプリケーションをホストするプライベート接続が不完全に閉じた場合、Web ゲートウェイはプールで利用可能なステートレス接続に要求を転送し、InterSystems IRIS エラー番号 5974 が返されます。

CSP error occurred
Error: The persistent session is no longer available because the server process does not exist
ErrorNo: 5974
CSP Page: /csp/samples/loop.csp
Namespace: %SYS
Class: <Unknown>

この時点では、要求はステートレス・モードで処理され、このエラーにはアプリケーションが例えばユーザにアプリケーションのログイン・フォームを再度表示するなどして応答します。

ステート認識モードで動作している際は、全ページの %session.NewSession の値をチェックする必要があります。 または、アプリケーションへのアクセスをユーザが最初に許可されたときに、アプリケーションが %session.Data に格納されているユーザ固有の認証データの有効性をチェックする必要があります。これらのチェックはセキュリティのためにも、ユーザ・セッションが依然としてステート認識処理モードにしっかり固定されていることを確認するためにも重要です。 これらの状況では、エラー状態は自動的に発生しません。なぜなら、セッションは既に (適切な手順を踏んで正常に) ステート認識モードから移行している可能性があるからです。 例えば、受信セッションのトークンは依然としてステート認識とマークされているもののアプリケーションは既にステートレス・モードに移行している状況を考えてみましょう。この状況は、移行が行われる前に処理されたフォームに (CSPCHD として) セッションのトークンが埋め込まれているために起こります。

最後に、(例えば、タイムアウトの後で) セッションが終了する際、CSP エンジンはそのセッションに関連付けられたすべての処理データを削除することに注意してください。その後は、そのセッションに対する受信要求は、すべて新しいセッションに対する要求のように処理されます。

InterSystems IRIS が Web アプリケーションに提供する埋め込みのセキュリティ・メカニズムは、前述の不測の事態から保護します。 (InterSystems IRIS プロセスに関して) ステート認識アプリケーション内の継続性が失われた場合は必ず、ユーザには自動的にログイン・フォームが表示されます。

ステート認識モードの終了

以下のように保持モードを設定することで、アプリケーションをステートレス処理モードに戻すことができます。

Set %session.Preserve = 0

このコードは、フォームの OnPreHTTP メソッドで実行することを推奨します。

<script language=objectscript method=OnPreHTTP arguments="" returntype=%Boolean>
    Set %session.Preserve = 0
    Quit 1
</script>

ここで指示を出すことで、CSP エンジンは HTTP 応答ヘッダを作成して Web ゲートウェイに送信する前に、セッションの cookie (またはトークン) をステートレスとしてマークできます。

セッションは以下のように即座に終了できます。

Set %session.EndSession = 1

このプロパティを設定すると、セッションは現在の要求を処理した後で直ちに終了します。

以下のようにセッションのタイムアウトを設定できます。

Set %session.AppTimeout = 900

アクティビティがない時間が所定の秒数に達すると、セッションはタイムアウトして終了します。 既定値は 900 秒 (15 分) です。