1. WebOTXシステムの構築

1.1. システム構築の課題

今日のミッションクリティカルな業務システム、特にインターネットに対応したシステムについては、従来のメインフレームを中心としたミッションクリティカルシステムと比べて可用性、拡張性、安全性の要件に着目する必要があります。いかにして可用性、拡張性、安全性を高めていくかがシステム構築の課題となります。

1.1.1. 可用性

インターネットに対応した業務システムでは、24時間365日運用を止めずに安定してサービスを提供し続けることが必要となります。また、急激な負荷変動に対しても重要度の高い業務やユーザに対してサービスを継続できるサービスレベル保証の考え方も必要となります。イントラネットに制限され24時間運転をしていない業務システムでも業務がグローバルに拡大している今日、いつ24時間365日対応が必要になるかわかりません。

アプリケーションサーバでは、無停止でサービスを提供し続けられるように各種カウンタやログファイルなどが慎重に設計されていること、サービスを提供するアプリケーションを動的に追加・置換できること、など無停止運用技術が重要になります。

1.1.2. 拡張性

業務システムのトラフィックの増加に対しては、最終的にハードウェアの増設が必要となります。システム全体で提供するサービスを停止することなく、サーバ、CPU、メモリなどのハードウェア資源を増設できる拡張性が重要です。単純にハードウェアを増設するのでなく最適な機能分散により、性能ネックが発生している部分を切り出し、そこに集中してハードウェアを増設することがシステム全体のハードウェア投資を削減し、ハードウェアを有効に活用することになります。システム内のアプリケーションの配置を自由に変更でき、ビジネスロジックがネックになっていればアプリケーションサーバを増設、プレゼンテーションロジックがネックとなっていればWebサーバを増設するなどシステムを柔軟に変更できることができる高い拡張性が求められます。

1.1.3. 安全性

インターネット業務システムに限らず、セキュリティアタックは多数発生しています。今日ではインターネットのEnd-to-Endの透過性はファイアウォールにより遮断されるようになりました。機密データの露呈や、不正なアクセスへのガード、改竄、成りすましなどアタック技術も日々進歩しています。現時点で十分なセキュリティ対策をしても、将来のアタックには無効かも知れません。

アプリケーションは上記のようにスピーディに強化されることが必要ですが、一度作ったアプリケーションがセキュリティ攻撃に対応するために改造を必要としたのでは大変です。アプリケーションサーバやファイアウォールなどのアプライアンスサーバを活用して、セキュリティ強化の影響をアプリケーションから独立させることができる実行基盤が重要になります。

1.2. システム設計の考え方

ミッションクリティカルな業務システムを設計する上での考え方について説明します。

1.2.1. システムの可用性について

今日、ミッションクリティカルな業務システムでは、24時間365日のサービス提供が求められます。 すなわち、計画的、非計画的を問わず、システム全体の停止が許されません。 このような厳しい可用性に対する要求をクリアするには、次に示すことを考慮する設計が必要となります。

1.2.2. システムの拡張について

拡張可能(スケーラブル)なシステムの要件としては以下が挙げられます。設計時にこれらを満たしているどうか検証を行う必要があります。

システムの拡張の方法としては大きく「スケールアウト」、「スケールアップ」の2つがあります。 システムの特性に応じ、適切な拡張方法を選択する必要があります。

一般的にスケールアウトによる拡張を行えるのは、全く同様なアプリケーションが複数のサーバで同時に動作し負荷分散が可能な場合です。 さらにサーバ間の連携が必要ない場合は、理想的にはサーバ台数に比例した性能を実現することが可能となります。 しかし、複数サーバ構成とした際に、クライアントが特定のサーバを意識してアクセスする設計だと最大の性能を実現することができません。 よって、入り口となるWebサーバやロードバランサのような装置が全クライアントからのリクエストを受け、 複数のサーバに適切に処理を振り分ける、という仕組みが必要となります。

同じアプリケーションが複数のサーバで実行できない時はスケールアップで拡張を行います。 たとえば、それぞれのアプリケーションサーバが特定のリソースに紐付いている状況などが考えられます。

1.2.3. 負荷分散機構

スケールアウトによりシステム拡張ができる場合、負荷分散を行うための装置やソフトウェアを利用する構成が一般的になっています。

負荷分散機構

負荷分散機構を用いた代表的な構成は図のようになっています。処理を割り振るルールにはいくつかの方式がありますが、ここではもっとも単純なラウンドロビン方式の例をあげます。クライアントは負荷分散機構に処理をリクエストします。負荷分散機構は、最初のリクエストはサーバA にその次はサーバB に、その次はサーバC にというように、順番にリクエストを割り振ります。これによりクライアントから個別のサーバを隠蔽し、仮想的な巨大なサーバを実現することが可能となります。ただし、負荷分散機構の割り振り先のサーバは同一の処理を行う必要があります。またサーバ間で排他が必要な処理はオーバーヘッドにより負荷分散を用いた処理の処理能力に制限を設けますので、できるだけ避ける必要があります。

次に負荷分散の実現方式について以下に挙げます。

また、負荷分散機構を検討する上で重要なポイントとしては障害時の縮退機能と負荷分散のポリシーです。次に負荷分散のポリシーについて説明します。

負荷分散機構を提供する装置やソフトウェアによって選択できる負荷分散方式やポリシーが異なりますので各製品でどのような負荷分散ができるのか考慮する必要があります。WebOTXのアプリケーションサーバはラウンドロビン、重み付けラウンドロビンの負荷分散を提供しています。

1.2.4. クラスタ構成

サーバが障害発生時においてもシステムを継続して運用させるためには、サーバを複数台にて構成(クラスタ構成)し、障害のあったサーバの業務を他のサーバで引き継がせる必要があります。クラスタ構成においては次の仕組みが必要となっています。障害を検出する仕組みと、障害発生後、どのようにして業務運用を続行させるかを考慮する必要があります。

1.2.4.1. フェイルオーバ型クラスタ

フェイルオーバを利用したクラスタ構成で、クラスタソフトウェアと連携させることにより実現できます。フェイルオーバ型クラスタでは、ハートビートを利用したサーバ間の相互監視によるサーバマシン自体の障害検出、強制サーバ停止によるシステムの切り替え、グループ管理による、アプリケーションごとのフェイルオーバの3 つの機能により高可用を実現しており、従来から高度な可用性が要求されるシステムで一般的に採用される構成です。

クラスタソフトウェアについて

クラスタソフトウェアと連携したフェイルオーバ型クラスタ構成の一般的な特徴について説明します。詳しくは個々のクラスタソフトウェアの機能を確認してください。

1.2.4.2. 負荷分散型クラスタ

同一処理を行う複数台のマシンの前に負荷分散機構を置く構成です。拡張性を確保するには、できるだけ複数サーバ間の連携をなくす必要があります。負荷分散型クラスタ構成では、高可用で拡張性の高い業務システムが効率的に実現できます。処理要求はフロントの負荷分散機構に対して行われ、負荷分散機構は管理するノードにその処理を割り振ります。障害時には、障害が発生したノードを負荷分散機構が検知し、処理の割り振り先から外します。つまりノードの縮退により可用性を確保しています。この時の障害検知方法は負荷分散機構の機能に依存します。

1.2.5. アプリケーショングルーピング

WebOTX Application Server Standard/Enterpriseでは、 サーバアプリケーションは「アプリケーショングループ」および 「プロセスグループ」という単位でグルーピングを行ないます。 それぞれのグループの特性を踏まえて、グルーピングの構成を決める観点について説明します。

1.2.5.1. アプリケーショングループ

アプリケーショングループとは、開始・終了などの運用を共にするアプリケーション群をグルーピングしたものです。例えば、「受発注業務」「在庫数管理業務」といったような業務毎にツリーを分けて管理するといった方法を用います。

こうすることで、「受発注業務」は10時から17時まで動作させ、その後は停止させる、「在庫数管理業務」は24時間動作させる、などのアプリケーショングループ単位での独立した運用が行えるようになります。

よって、アプリケーショングループは業務運用の単位でグルーピングを行ないます。ただしアプリケーション設定の変更時にアプリケーショングループの再起動が必要となることがあるため、運用上再起動が行なえるアプリケーションの組み合わせで構成する必要があります。

1.2.5.2. プロセスグループ

プロセスグループとは、ある特定のサービスを提供するプロセス群です。同一のプロセスグループに登録されているコンポーネントは同一のプロセス上でロードされます。 WebOTXはビジネスロジックを記述した1つまたは複数のコンポーネントをプロセスグループに登録し、プロセスとして実行します。

プロセスグループでは、以下の項目が共有されます。

1.2.5.3. 処理の流れ

Standard/EnterpriseのサーバAPでの処理の流れについて説明します。

前節で説明したように、受信用のキューはプロセスグループ単位で生成され、クライアント(thinクライアントの構成ではWebサーバ)からの要求はIIOPリスナを経由して、該当プロセスグループのキューにキューイングされます。キューイングされた要求はアイドル中のスレッドに割り振られて実行されますが、アイドル中のスレッドが無い場合はキューで実行待ちとなります。

キューはプロセスグループで共有するため、例えば実行時間が非常に長い呼び出しが実行された場合、そのリクエストを処理するためにプロセスグループ内のスレッドが1つ占有されて、プロセスグループ内の実行可能なスレッドが一時的に減少してしまいます。この状況が頻発して全てのスレッドが長い呼び出しに占有されてしまうと、そのプロセスグループに対する要求は全てキューイングされ、実行待ちによる遅延が発生することになります。

1.2.5.4. マルチプロセス・マルチスレッド

プロセスグループを多重化させる場合、プロセスを多重化させる方法とスレッドを多重化させる方法があります。

各プロセスはシングルスレッドでもマルチスレッドでも動作させることができます。マルチスレッド構成では、プロセスグループ内のスレッド群は単一のキューに対してデータの到着を待ち合わせるので、空きスレッドに効率良くトランザクション要求を割り当てることができます。また、マルチプロセス実行させることにより、アプリケーションの一時的な障害に対してサービスの継続が可能になります。この場合、データや環境、タイミングなどの要因でアプリケーション障害が発生しても、そのプロセスだけが異常終了し、他のプロセスは影響を受けません。よって、システム全体でサービスを継続することができます。

しかしマルチプロセス構成はマルチスレッド構成に比べてより多くのリソースを必要とします。そのため、HWの性能に合わない過度なマルチプロセス構成はマシンのリソース不足を招き、サーバ自体が不安定になる恐れがあります。よって、マルチプロセスは予期せぬアプリケーション障害に備えての多重化とし、クライアントからの同時実行に備えての多重化はできるだけマルチスレッドで行う構成が望ましいといえます。ただし、アプリケーションの構成上(スレッド間同期、排他制御)の問題でマルチスレッドの動作ができないなどの制限がある場合は、マルチプロセス構成で多重度を確保します。

また、システム運用中に発生した想定外の大量のトランザクション要求に対して、動的にアプリケーション多重度(スレッド、プロセス)を増加させることが可能です(注:スレッド数は最初に確保した数以上は増やせません)。これにより、大量のトランザクション要求をサーバ側が処理しきれずにキューに滞留してレスポンスの悪化となる状況が避けられます。また、負荷が下がったときに安全に実行多重度を元に戻すこともできます。

運用アシスタント機能により、システムの稼働状況に応じて多重度の増減を推奨(または自動変更)することができます。高負荷によりあらかじめ設定された応答時間を満たさないと予想される場合は、多重度を増やすよう通知(または自動変更)します。また、負荷が下がった状態が続くと多重度を減らすように通知(または自動変更)します。 詳しくは[ ドメイン構築・基本設定ガイド > 7.1. TPシステム > 7.1.13.2. 多重度の最適化支援 ]を参照してください。

1.2.5.5. グルーピングのポイント

WebOTXのプロセスグループの特性を踏まえて、グルーピングを決定する際に考慮が必要な事項について説明します。

消費メモリの違いについて

処理の多重度を確保するにはマルチプロセスによる多重化とマルチスレッドによる多重化がありますが、この二つの構成の違いの一つとして使用メモリ量があります。

以下はWebOTX Java APの1プロセスあたりのメモリ消費量の目安の計算式です。

(ヒープサイズ)+(スレッドスタックサイズ)×スレッド数+15(MB)

※OSの種類によりメモリ消費量には差があります。

上記の式より、マルチスレッド構成ではスレッド数を増やしても(スレッドスタックサイズ:既定値1M)分だけ増加するのに対し、マルチプロセス構成ではプロセス数を増やすと上記の計算式全体の値だけ増加します。そのため、マルチプロセスよりマルチスレッドによる多重化の方が少ないメモリ量で構成できることになります。

多重化構成を選択する際には、使用可能なメモリ量を考慮する必要があります。

コネクションライセンスによる制約について

コネクション単位のライセンス方式を採用しているモジュールの使用によって、グルーピングの構成が制限される事があります。

例えばコネクション単位のライセンス方式を採用しているVISコネクタで、以下のライセンスを購入したとします。
WebOTX VISコネクタ実行環境 (4)
WebOTX VISコネクタ実行環境 (+8)
この場合、ライセンス数は4+8(=12)ですので、1プロセスグループ1プロセス1スレッド構成ではプロセスグループ数は12個までに制限されます。
同様に、1プロセスグループ2プロセス2スレッド構成の場合は、プロセスグループ数は3個(12÷4)までとなります。

そのため、多重化構成を選択する際には、構築するシステムが使用するモジュールのライセンス方式と制限を考慮する必要があります。

コネクション数の違いについて

バックエンドサーバへのコネクション数についても注意が必要となります。
マルチプロセス構成の場合は、プロセス数だけバックエンドサーバとコネクションを生成することとなりますが、マルチスレッド構成の場合はコネクションを共有します。
そのため、マルチプロセス構成よりもマルチスレッド構成の方が少ないコネクション数で構成できることになります。
多重化構成を選択する際には、バックエンドサーバとのコネクション数の制限を考慮する必要があります。

障害時の影響について

障害時の影響についても考慮する必要があります。

マルチプロセス構成ではプロセス空間がプロセスごとに独立するため、あるコンポーネントで問題が発生し、ストールやレスポンス悪化、アボートが発生した場合でも、他のプロセスはほとんど影響を受けません。

しかしマルチスレッド構成では、ストール、レスポンス悪化、アボートに対して注意が必要になります。
例えば、スレッド上のあるコンポーネントでストールやレスポンスの悪化が発生した場合、 徐々に同じプロセス上のスレッドがストールして処理が止まり、最終的にプロセス全体がストールしたり、実行プロセスがアボートしてなくなる状況が考えられます。
このような状況の対策として、マルチスレッドで多重度を十分に確保すること、およびマルチプロセスでアボートしてもプロセス数が0とならない構成をとっておくことがあげられます。

1.3. システム構成について

アプリケーションサーバを用いた基本的なシステム構成について説明します。
なお、本章で説明しているいくつかの機能(高速スタンバイ, CNS, WatchServer, フェイルオーバ通知コマンド)についてはWebOTX Application Server Enterpriseの機能です。

1.3.1. システムの3層構成

3層構成はクライアントとサーバアプリケーションの間にWebサーバとアプリケーションサーバを配置したシステムです。クライアントはWebブラウザによりWebサーバに処理要求を行い、Webサーバ上で動作するWebアプリケーションがアプリケーションサーバに処理要求を行います。アプリケーションサーバ上でその処理要求に対するビジネスロジックが実行され、必要に応じてバックエンドサーバ(データベースサーバ、メインフレームなどの既存システム)を呼び出します。各層それぞれ要件に応じてシステム構成を検討することになります。

システムの3層構成

各階層の役割

1.3.2. Webサーバの構成

Webサーバはクライアントからの入り口となっておりクライアントからのリクエストを直接受け付けます。クライアント数の増大などによる負荷の影響を一番受けるため、高い拡張性が重要になってきます。負荷分散機構による負荷分散クラスタ運用を採用するのが一般的です。

Webサーバはスケールアウトの考え方で処理能力の向上を行うことが可能です。アプリケーションサーバやバックエンドサーバにボトルネックがない限り、n台の負荷分散構成は1台構成に比べてn倍の処理能力を持つことが可能です。

1.3.2.1. 可用性について

負荷分散機構の機能に依存することにはなりますが、負荷が増大した場合のサーバの追加や障害発生時のサーバの切り替えについてはシステムを停止することなく、もしくは非常に短時間に行うことが可能です。障害の検出方法は負荷分散機構に依存しますが、単純なping による確認や、レスポンスの有無、HTTP コマンド(GET)による監視などがあり、障害検出時にはサーバ単位で縮退します。この時、縮退したサーバ分システムの処理能力が低下します。障害サーバ復旧までの応答性能の劣化が許容されない場合は、障害が発生したサーバの負荷を他サーバへ分散させた場合でも応答性能が劣化しないだけの冗長性を、あらかじめシステムに持たせておく必要があります。また、負荷分散機構自体の障害がシステムに影響を与えないように負荷分散機構を多重化する必要があります。

1.3.2.2. コンテンツの管理について

負荷分散環境下でのWebサーバで扱うコンテンツの管理については共有する方式と分散する方式があります。

コンテンツを共有させるためには、ファイルサーバ上でコンテンツを一元管理する方法です。コンテンツを共有することにより、ファイルサーバ上のコンテンツを更新するだけで全てのWebサーバのコンテンツが更新されます。しかし、複数のWebサーバでネットワークを通してファイル参照を行うためネットワークやファイルサーバの負荷を考慮する必要があります。またファイルサーバの障害に対応するため、ファイルサーバの多重化することも考慮しなければなりません。

コンテンツを分散する方式はそれぞれのWebサーバのローカルディスクにコンテンツを配置します。この方式ではコンテンツの更新は全てのWebサーバについて行う必要があります。Webサーバの運用を止めずにコンテンツの更新を行う場合、新旧のコンテンツが混在することがあり、思わぬ結果になる危険性があります。またアプリケーションサーバとのインタフェースが変更になるようなコンテンツの変更である場合、アプリケーションサーバのアプリケーションと同期して変更を行う必要があります。安全に変更を行うためには適切な単位でコンテンツを一時的に閉塞し、相手システムからのアクセスを完全にシャットアウトしてから、Webサーバとアプリケーションサーバの更新を行う方法があります。この方法なら、どのようなシステム構成や条件でも安全にコンテンツを更新することができますが、一部のサービスは短時間中断せざるを得ません。

1.3.3. アプリケーションサーバの構成

アプリケーションサーバはWebサーバからの要求を受け、業務アプリケーションを実行します。必要であればデータベースやメインフレーム等のバックエンドサーバに対してデータの変更や更新要求を行います。WebOTXではJ2EEやCORBAなどの分散オブジェクト業務基盤を利用して、業務アプリケーションを実行することができます。

1.3.3.1. 可用性について

アプリケーションサーバの可用性を高めるためにアプリケーションサーバについてもクラスタ構成とすることが可能です。どのようなクラスタ構成(負荷分散、フェイルオーバ)とするかはシステムの要件を考慮して決定する必要があります。次にクラスタソフトウェアの特徴とクラスタ構成について説明します。

負荷分散構成

同一業務を行うアプリケーションサーバを複数台用意することによりアプリケーションサーバの処理能力を高めることが可能です。ただし、参照するバックエンドサーバでの排他制御があるため単純にアプリケーションサーバの処理能力は台数に比例はしません。Webサーバ同様サーバ障害発生時には該当サーバをシステムより切り離し、縮退運転となります。なお負荷分散構成を行った場合、Webサーバからの要求は要求毎に実行するアプリケーションサーバが異なる場合があるため、アプリケーション内での情報の保持についてはプロセス内のみで行うことができなくなることを注意しなければなりません。

WebOTXでは名前サーバがクライアントからのオブジェクト取得要求に対して返却するオブジェクトリファレンスをラウンドロビンに振り分ける仕組みを提供しています。これによりクライアントからの要求を複数台のサーバに振り分けます。WebOTXの状態を定期的に監視するWatchサーバを組み込むことによりアプリケーションサーバ異常終了時に該当サーバをシステムから切り離し縮退運転を行うことができます。

負荷分散構成

フェイルオーバ構成

また特にミッションクリティカル性が求められるシステムについては、フェイルオーバクラスタソフトと連携したクラスタ構成とすることによりアプリケーションサーバの可用性を持たせることができます。以下にクラスタソフトと連携したフェイルオーバクラスタの構成について説明します。

シングルスタンバイ型

稼動系と待機系で運用を行い、通常は稼動系のサーバでアプリケーションサーバは動作しています。Webサーバからのアプリケーションサーバへのアクセスはクラスタソフトが提供する仮想ホスト名もしくは仮想IPアドレスを利用して行います。稼動系ノードで障害が発生した場合、フェイルオーバが発生し待機系ノードで運用が引き継がれます。このとき仮想ホスト名、仮想IPアドレスについても待機系に引き継がれるため、ステートレスなトランザクション処理については、Webサーバはアプリケーションサーバがフェイルオーバしたことを特に意識する必要はありません。ただし稼動系アプリケーションとの間で生成されたセッションについては稼動系サーバ異常終了により切断されるためセッションの再生成が必要になります。ステートフルなトランザクション処理についてはフェイルオーバ発生によりアプリケーション側で保持しているオブジェクトが失われ、セッションも切断されるため、待機系でその情報を引き継ぐ手段やセッション管理を厳密に行わない限り、フェイルオーバ発生時はトランザクションを無効とし、クライアント側でもう一度はじめからやり直すことになります。

通常のシングルスタンバイ構成においてはフェイルオーバが発生した時点で待機系のサービスが開始されるので障害が発生してから、待機系ノードで運用を引き継ぐまでの切り替に時間を要する場合があります。

シングルスタンバイ型

高速スタンバイ型

稼動系と待機系で運用を行うことについてはシングルスタンバイ型と同様ですが、切り替に要する時間を短縮するためにあらかじめ待機系でもサービスを起動し、バックエンドサーバへのセッションについてもあらかじめ生成しておきます。これにより稼動系が障害発生となった場合においても、仮想ホスト名、仮想IPアドレスの切り替えのみでフェイルオーバが完了し、短時間での系切り替えを実現します。

高速スタンバイ型

相互スタンバイ型

複数の異なる業務システムをマルチサーバでそれぞれ動作させ、あるサーバで障害が発生した場合、その業務システムは別のサーバにフェイルオーバします。よってフェイルオーバ先のサーバは複数の業務システムが動作することになります。相互スタンバイ型の場合、どのサーバも常に稼動系システムを割り当てることができますが、フェイルオーバ発生時は、1つのサーバに複数の業務システムが動作することになるため、そのサーバの処理能力低下は避けられません。

相互スタンバイ型

情報の引き継ぎについて

フェイルオーバ構成において、稼動系から待機系にどのように情報を引き継ぐかを考慮する場合があります。次にフェイルオーバ構成における情報の引き継ぎについて説明します。

基本的に引き継ぎ情報については共有ディスクやデータベースなどクラスタ環境で共有可能で永続性のある外部リソースに保持しなければなりません。サーバが異常終了しフェイルオーバが発生しても確実に情報を取得できなければならないためです。

情報を取得するタイミングですが、シングルスタンバイ型や相互スタンバイ型の場合、フェイルオーバ発生時には、待機系にてサービス起動から行われるためアプリケーション起動時に情報を取得することができます。しかし高速スタンバイ型の場合、フェイルオーバが発生しても、待機系ではサービスが既に開始されているため情報を取得するタイミングがありません。そこでWebOTXではフェイルオーバが発生したことを各アプリケーションにコールバックするためのコマンドとAPIを提供しています。フェイルオーバの開始スクリプトでフェイルオーバ発生を通知するためのコマンドを実行することにより、各アプリケーションにその通知がコールバックされます。このタイミングで引き継ぎ情報の取得を行うことが可能となります。

名前サーバの多重化について

CORBAのアプリケーションサーバを負荷分散構成とした場合には、名前サーバの可用性をどのようにして向上するかを考慮しなければなりません。名前サーバを多重化する方法について説明します。

CNSによる多重化

JNDIサーバの多重化について

J2EEのアプリケーションサーバを負荷分散構成とした場合には、JNDIサーバの可用性をどのようにして向上するかを考慮しなければなりません。JNDIサーバを多重化する方法について説明します。

1.3.3.2. クライアントの情報管理について

アプリケーションサーバでクライアント(Webブラウザ)を識別して情報管理を行う場合の方法について説明します。

マルチサーバ構成の場合、負荷分散構成、フェイルオーバ構成ともにサーバをまたがって同一ブラウザからの要求を処理する場合があります。このときにアプリケーションサーバ側でブラウザを意識して処理を行う場合、マルチサーバ間でどのようにクライアントを識別するかが問題となります。ブラウザから最初に要求を受けたときアプリケーションサーバではそのブラウザを一意に識別するための識別子を生成しWebサーバ上のWebアプリケーションにその識別子を渡します。またアプリケーションサーバはそのWebブラウザに関する情報をその識別子をキーとしてデータベースなどマルチサーバ間で共有可能で永続性のある外部リソースに保持します。Webアプリケーションではアプリケーションサーバよりもらった識別子をブラウザに渡します。例えばcookieを利用する場合、Webサーバとアプリケーションサーバの呼び出しにおいてcookieを引数として渡すことによりアプリケーションサーバでcookieに識別子を設定できます。hiddenタグを利用する場合はWebサーバとアプリケーションサーバの呼び出しにおいて識別子を引数として渡し、Webアプリケーション上で識別子をhiddenタグに設定します。次にブラウザから要求を行った場合、アプリケーションサーバで設定された識別子を元に外部リソースを参照し情報を取得することができます。ここで問題となるのが情報の削除タイミングですが、正常に処理が行われた場合、対象ブラウザの最終要求が行われた時点で削除します。仮にクライアントが異常終了してしまった場合最終要求が行われず、ブラウザの生存確認も困難なため削除するタイミングがありません。そのような場合、アプリケーションサーバ上のアプリケーションは外部リソースの使用状況を監視し、クライアントごとに払い出した識別子が長時間使用されていない場合には、識別子を無効化する必要があります。

1.3.4. バックエンドサーバの構成

データを管理するバックエンドサーバ特にデータベースサーバの構成について説明します。

データベースサーバの処理能力を上げるには、インデックスの活用のほか、テーブルの非正規化、メモリにデータをバッファリングする方法などが一般的な方法として行われます。こうした処理能力の向上手段を使った上で、さらに強化するためには、分散処理(スケールアウト)やサーバの増強(スケールアップ)を行うなどの方法がとられます。データベースサーバの強化にはスケールアップによる拡張を行うのが一般的です。スケールアウト型の拡張(サーバ増設)を行うには、関連性のないデータベースサーバのテーブルを複数のデータベースサーバに分け、処理を分散させる方法があります。ただし、データベースは分散すると構成が複雑になるので、いったんデータベースを構築してしまうとスケールアウトを行うことは難しく、最初のシステム設計時にはいっそうの考慮が必要です。

1.3.4.1. 可用性について

データベースサーバの可用性を向上させるためには、フェイルオーバクラスタソフトウェアと連携した多重構成を行うこととなります。一般に複数のデータベースサーバで更新データの共有は行えないため稼動待機のスタンバイ構成を撮ることになります。

1.3.4.2. データベースサーバフェイルオーバ時の影響

データベースサーバをクラスタソフトウェアと連携した多重構成とした場合のアプリケーションサーバへの影響について説明します。データベースサーバがフェイルオーバした場合、どのような対応をアプリケーションサーバ側で行うかの考慮が必要になります。

アプリケーションサーバはデータベースとアクセスを行うためにデータベースサーバとセッションを生成しています。データベースサーバフェイルオーバにより保持しているセッションが消滅することとなります。フェイルオーバ完了後、再びデータベースサーバにアクセスするためにはもう一度セッションを生成する必要があります。セッションを再生成するための方法について以下に説明します。

データベースサーバがフェイルオーバした場合のアプリケーションサーバの対応については、フェイルオーバ通知コマンドを利用およびデータベースサーバへのアクセス失敗時にセッションの再生成を行うことによりシステム全体への影響を最小限にすることができます。

また、WebOTXのJDBCデータソースでは、データベースとのコネクションを一括して破棄するためのAPIやコマンド、監視機能を提供しています。JDBCデータソースを利用してデータベースアクセスを行っている場合は、データベースサーバへのアクセスがエラーとなった場合に、コネクション一括破棄用のAPIを呼び出して、使用できなくなったコネクションを破棄してからコネクションの再取得を行うことで、セッションを再生成することができます。あるいは、コマンドや監視機能によってコネクションが一括破棄された後で、コネクションの再取得を行うことで、セッションを再生成することができます。

1.4. セキュリティについて

インターネット業務システムでは、外部からの不正侵入に対するセキュリティが重要です。また、イントラネットの業務システムでも、社員IDの一元管理などのSingle Sign On技術が要求されています。次にシステムのセキュリティ対策について説明します。

1.4.1. 認証と暗号化

不特定多数からのアクセスが想定されるインターネット業務システムにおいて、サービスを提供する側では、サービスを利用している相手が誰であるか、信用できる相手であるかを確認することは非常に重要です。また、サービスを利用する側にとっても、アクセスした先が信用できるサイトであるか確認する手段が必要です。このような問題を解決するための認証と暗号化の技術が必要になります。3層のシステムモデルではWebブラウザとWeb サーバ間の認証と暗号化が必要となり、一般的にSecure Socket Layer(SSL)を使います。

SSL は共通鍵暗号化方式と公開鍵暗号化方式、デジタル証明書を併用した認証および暗号化のプロトコルです。SSL を使用するには、それに対応したWeb サーバ、Webブラウザとデジタル証明書を発行する認証局(CA)が必要となります。

1.4.2. アクセス制御

Web サーバにおいて、アクセス者に応じたアクセス制御を行う場合、アクセスするユーザを管理し、その認証を確実に行うことが必要です。デジタル証明書は、認証する必要のある側に向けて発行する必要があります。例えば、エンドユーザがWeb サーバを認証する(ニセのWeb サーバでないことを確認する)ためには、Web サーバ用の証明書が必要です。逆にWeb サーバ側でエンドユーザを認証するためには、個々のエンドユーザに証明書を配付する必要があります。そこで、Web サーバでアクセス制御を実現するためには、アクセスするエンドユーザの管理と、それと連繋した証明書を発行する運用管理の仕組みが必要となります。さらに、アクセス対象のページ情報の管理や、どのユーザがどのページをアクセス可能なのかを表現するアクセス制御リスト(ACL)の管理も必要になりますし、以上の管理情報に基づいて実際にWeb サーバの動作を制御する仕組みも必要になります。

これらの管理や仕組みはシステム構築における作り込みで実現することも可能ですが、SECUREMASTER のような、情報管理機能とWeb サーバ連繋の制御モジュールを提供する汎用パッケージ製品も利用可能です。

1.4.3. 不正進入対策

インターネット業務システムにおいて、その入り口であるWeb サーバには不特定多数からのアクセスを想定しなければなりません。しかし、すべてのサービスへアクセスができる環境では、Web サーバにセキュリティホールがあれば、それを足がかりに不正に侵入されてしまうことが考えられます。そこで、Web サーバへアクセスするサービスを限定したり、クライアントを限定したりするために、システムの入り口にファイアウォール(防火壁)を導入する必要があります。また、Web サーバとアプリケーションサーバの間にもWeb サーバからの特定のサービスのみがアプリケーションサーバにアクセスできるようにファイアウォールを導入することでアプリケーションサーバが外部から直接アクセスされることを禁止でき、さらに強固なセキュリティレベルを確保することができます。このとき、Web サーバは外部のインターネットからも内部のネットワークからも限定的にアクセスができます。この2つのファイアウォールの間に挟まれたネットワークをDMZ(非武装地帯)と呼び、高い機密性が求められるアプリケーションサーバやデータベースサーバに対する強固なセキュリティを確保するために用いられます。

さらにファイアウォールには、ローカルIP アドレスをグローバルIP アドレスに付け替えることで、内部のサーバを隠蔽しセキュリティを確保することや、アクセスをログに記録するといった役割もあります。

セキュリティ