新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

WAS虎の巻 第2回「WebSphere Application Server(WAS)の複数台構成」

1

複数台構成の必要性と課題

前回は、Webシステムを構成する主なコンポーネントとしてのWebサーバー、アプリケーション・サーバーと、Websphere Application Server(WAS)の概要をご紹介しました。 第2回では、WASを構成する基本的なコンポーネントと、WASを利用したWebシステムの複数台構成についてご説明します。

1.1. 単一アプリケーション・サーバー構成

ユーザーがWebブラウザーを用いてインターネットやイントラネットを経由してアプリケーションへアクセスし、何らかのデータ処理をした結果Webブラウザーに応答画面が表示されるWebシステムを構築するとします。この場合、Webサーバー、アプリケーション・サーバーを一台の物理ノードに配置するのが必要最小限の構成です。この構成は、単一アプリケーション・サーバー構成と呼ばれます。

alt

1.2. 複数台構成の必要性

単一アプリケーション・サーバー構成は構成・管理が容易です。しかし、信頼できるWebシステムを提供し維持するためには、連載第1回1.3「Webシステムへの要求」の章で説明したように、パフォーマンス(性能)、スケーラビリティー(拡張性)、アベイラビリティー(可用性)、セキュリティー(安全性)を考慮しなければなりません。これらのシステム要件に対して、それぞれ対応する必要があります。様々な対応策がありますが、基本は各コンポーネントを複数台で構成することです。

  • パフォーマンス
    様々な対応策がありますが、ボトルネックがWebシステムの処理能力にある場合は、処理能力を増加させるしかありません。そのためには、CPU、メモリ、ディスク等のサーバー・リソースを増強するか、サーバーを複数台に増設する必要があります。
  • スケーラビリティー
    環境の変化に応じて、柔軟に性能向上や機能変更が求められます。アクセス数が増加した場合には、上記パフォーマンスと同様に、サーバー増設がひとつの解となります。サーバーの筐体や区画を増やす方法以外にも、同じ筐体や区画内にアプリケーション・サーバー・プロセスを追加する方法もあります。
  • アベイラビリティー
    不意のハードウェア障害やソフトウェア障害が発生してもサービスを提供し続けるためには、Webサーバー、アプリケーション・サーバーなどの各コンポーネントを冗長化する必要があります。システムの停止は、障害発生時だけでなく計画停止等の保守でも発生します。
  • セキュリティー
    様々な対応策がありますが、そのひとつに、プロキシーやファイアウォールと組み合わせてゾーニングし、WebサーバーをDMZに配置する構成があります。この場合、Webサーバーとアプリケーション・サーバーを別マシンに分割します。このように、拡張性や冗長化の目的以外にも、複数台構成をとる場合があります。

1.3. 複数台構成のための負荷分散機能

Webサーバー、アプリケーション・サーバーを複数台で構成したWebシステムの例を下図に示します。複数台のサーバーを配置した場合、各コンポーネントは処理要求(下図の場合はHTTPリクエスト)を適切なサーバーへ転送する必要があります。これを負荷分散機能といいます。この例では、アプリケーション・サーバーに対する負荷分散はWebサーバーで行われます。さらに、Webサーバーに対する負荷分散のために負荷分散サーバーを配置しています。

alt

適切な負荷分散をするためには以下のような仕組みが必要となります。

  • 障害検知機能
    割り振り先となるバックエンドのサーバーの稼動状況を確認し、障害発生中や計画停止中のサーバーにはリクエストを転送しない仕組みが必要です。
  • セッション・アフィニティー機能
    連載第1回2.6「セッション」の章でご紹介したセッションを保持するため、同じユーザーからのリクエスト(同じセッションへの処理要求)は同じサーバーへ転送する必要があります。この機能は一般的にセッション・アフィニティーと呼ばれます。

1.4. 複数台構成の課題

以上のように、信頼できるWebシステムの実現のために複数台構成は必要不可欠ですが、複数台構成による課題を考慮する必要があります。

  • 管理対象の増加
    マシン台数が増加すると管理対象も増加し、構成の管理、プロセスの管理、アプリケーションの管理などの手間が増加します。
  • 処理の継続(フェイルオーバー)
    障害検知機能によりリクエストが別のサーバーへ転送されても、今までの処理を引き継ぐ必要があります。

次節からは、これらのシステム要件と課題に対して、WASが提供している機能をご紹介します。

2

複数台構成のパターン

WAS BaseはJava EE エンタープライズ・アプリケーションを稼動させるための機能を備えたエディションです。WAS Network Deployment(以下、ND) はアプリケーションを複数のマシン上で実行する環境を提供することを目的としたエディションです。

複数のアプリケーション・サーバーを統合的に管理する機能を提供するデプロイメント・マネージャー(DM)や、負荷分散機能を提供するEdge Componentsなど、このエディションにはWASを複数マシン環境で実行する際に欠かすことのできない機能が含まれています。

2.1. WASを構成するコンポーネント

複数台構成の話の前に、WASの基本コンポーネントをご紹介します。WASは、各マシンをノードという論理的な概念で表します。また、ノードのグループをセルと呼び、各ノードはセル単位で管理されています。各ノードにはアプリケーション・サーバー、ノード・エージェントやDMと呼ばれるJavaプロセスが含まれます。

これらの論理的なセル、ノードの概念と、各プロセスについて下記にまとめます。セル、ノード、アプリケーション・サーバー、WebサーバーはWAS BaseおよびWAS NDの共通の概念ですが、DM、ノード・エージェントは、WAS NDでのみ提供されます。

alt

  • セル
    セルは、WAS の1つ以上のノードを論理的なグループにまとめたものです。
    WAS ND構成で使用されるものであり、WAS Baseでは通常は意識しません。
  • ノード
    ノードは、WASが管轄する論理的なマシンです。多くの場合、ネットワーク上で識別可能な IP ホスト・アドレスを持つ物理的なマシンに一致します。
    NDの複数台構成では、あるノードをあるセル配下に構成することを、「統合する」といいます。各ノードで実行するアプリケーション・サーバーの管理は、DMがノード・エージェントと通信することにより行います。
  • アプリケーション・サーバー
    アプリケーション・サーバーは、Java EEに準拠したエンタープライズ・アプリケーションが稼動するJavaプロセスです。 Webコンテナー、EJBコンテナー、トランザクション管理等の機能が含まれます。
  • Webサーバー
    Webサーバーは、HTTPリクエストを受け付けるhttpdプロセスです。 WASにはApacheをベースにしたIBM HTTP Server(IHS)が同梱されています。IHS以外のWebサーバーの使用も可能です。
    Webサーバーをセルに統合しWASから集中管理をすることが可能です(上図のWebServerA)。反対に、セルに統合しない構成も可能です(上図のWebServerB)。
  • デプロイメント・マネージャー(DM)
    DMは、セル内のすべての構成要素の集中管理を行います。DMは、それ自体が専用のアプリケーション・サーバー上で実行されていて、Webベースの管理インターフェース(管理コンソール)などの管理機能を提供しています。
  • ノード・エージェント
    ノード・エージェントはDMからの管理要求をアプリケーション・サーバーに伝達するJavaプロセスで、セルに統合されているすべてのノードで実行されます。また、ファイル転送サービス、構成の同期、およびパフォーマンス・モニターなどの管理機能を提供します。ノード・エージェントは単なる管理エージェントで、エンタープライズ・アプリケーションが提供する機能には関与しません。ノード・エージェントは、ノードをセルに追加すると、自動的に作成されます。逆に、セルに追加するまではノード・エージェントは作成されません。

2.2. WAS Baseの複数台構成

WAS NDを使用せずに、各ノードに同じ構成のWAS Baseを導入し、同じアプリケーションをインストールすることができます。この場合は、管理コンソールを使用してノードごとに管理を行う必要があります。また、Webサーバー(IHS)を複数台構成する場合は、前段になんらかの負荷分散装置を用意する必要があります。管理コンソールは、通常、各アプリケーション・サーバー内で稼動します。

alt

2.3. WAS NDの複数台構成

WAS NDでは、複数台構成の機能としてクラスター、およびEdge Componentsを提供しています。これらのクラスター、Edge Componentsにより、障害検知機能、セッション・アフィニティー機能が提供されます。

alt

  • クラスター
    クラスターは、同一構成のアプリケーション・サーバーを複数配置して、まとめて管理する仕組みです。クラスターに対する処理要求は、利用可能なクラスター・メンバーへ割り振られます。また、クラスター・メンバーを容易に追加、削除できるため、柔軟な拡張性も提供されます。
  • クラスター・メンバー
    クラスター・メンバーは、クラスター内の各アプリケーション・サーバーを表します。各クラスター・メンバー(アプリケーション・サーバー)上では同一のアプリケーションが稼動し、同じ構成情報を保持します。各クラスター・メンバーの構成は、コピー元のアプリケーション・サーバーに基づいています。クラスター・メンバーは、同一ノード上、または異なるノード上に作成できます。
  • Edge Components
    Edge Componentsは、様々なサービスやシステムに対するネットワーク・トラフィックの負荷分散機能(Load Balancerコンポーネント)を提供します。
    上記構成の場合、インターネット/イントラネットとWebサーバーの間に配置して、HTTPリクエストの負荷分散を行います。Edge Componentsの代わりに他社製の負荷分散装置も使用できます。

また、1.4節でご紹介した管理対象の増加とフェイルオーバーの課題に対して、WAS NDでは以下のような機能が提供されています。

  • DMでの構成一元管理と同期処理
    WASの構成リポジトリー(構成情報)は、すべてXMLファイル形式で保管されます。アプリケーション・サーバーの作成、アプリケーションのインストール、各種定義の変更などを行うことによって構成を変更し、これらの変更を保管するとXMLファイルが更新されます。
    WAS Baseでは、各ノードで構成リポジトリーを管理します。
    WAS NDでは、DMがセル全体の構成リポジトリーのマスターを管理し、各ノードにはマスターのコピーが作成されます。セルのマスター構成リポジトリーが更新されると、ファイル同期サービスによって各ノード・レベルの構成リポジトリーと同期がとられます。各ノードはローカルにコピーされた構成リポジトリーを参照して動作します。 alt
  • フェイルオーバー
    Webシステムに部分停止が発生しても、処理を継続する機能が提供されています。
    セッションの維持は、基本的にセッション・アフィニティーを前提としてリクエストを転送することで担保するとご紹介しましたが、仮に障害が発生してもセッション・オブジェクトをフェイルオーバーする機能が提供されます。これをセッション・パーシスタンス機能といいます。
    また、セッションだけでなく、処理中トランザクションのログがフェイルオーバーされるなど、SPOF(Single Point of Failure:単一障害点)を排除する機能が複数提供されています。

アプリケーション・サーバーを複数台構成にする場合の大きなポイントのひとつは、セッションをどのように維持するか、という点です。WASはセッション・アフィニティーとセッション・パーシスタンスという機能でこれを実現します。この点を次節でさらに見ていきましょう。

3

複数台構成のための機能

複数台構成が必要となる背景、WASで提供する機能概要と、セッション維持の重要性を説明してきました。ここでは、WAS のクラスター機能とセッションのフェイルオーバーをもう少し詳細に説明します。

3.1. クラスター構成による負荷分散

クラスターでは以下の2つの構成が可能です。

  • 垂直クラスター
    同一ノード上に複数のクラスター・メンバーが存在します。複数のアプリケーション・サーバー・プロセスを同時に実行することによって、プロセス障害に対応し可用性を向上させることができます。しかしながら、プロセスを複数作成することによってより多くのリソースを使用するため、パフォーマンスが劣化しないように十分なリソースを確保することが必要になります。
  • 水平クラスター
    複数ノード上に複数のクラスター・メンバーが存在します。この構成では各ノードに均等な数のクライアント要求を振り分けられることになり、より効率的な負荷分散が可能です。この構成では、アプリケーション・サーバーの稼動するマシン自体の障害にも対応することが可能です。
    下図は、複数のクラスター・メンバーに対する負荷分散処理を、Webサーバーで実施するケースとEdge Componentsで実施するケースのふたつの構成例を示しています。
    alt
    クラスター・メンバーへの負荷分散は、WASが提供するWebサーバー・プラグインによって実行されます。
    クラスター構成では、同じクラスター内のサーブレットやJSPファイルは同一のURLを持ち、クラスターに対して行われるリクエストは、あらかじめ設定されたポリシーにしたがって、Webサーバー・プラグインによりクラスター・メンバーのいずれかひとつに転送されます。
    Webサーバー・プラグインのディスパッチ・ポリシーには以下の3つがあります。重み付きラウンドロビンとランダムはどちらかを選択する必要がありますが、セッション・アフィニティーは他2つとの併用が可能です。
  • セッション・アフィニティー
    セッションを使用している場合、同一セッションIDを持つクライアントからの要求を毎回同じクラスター・メンバーに渡します。
  • 重み付きラウンドロビン
    あらかじめ設定された静的な重み付けにしたがってラウンドロビンでディスパッチします。
  • ランダム
    クライアントからの要求を、各メンバーにランダムに渡します。

アプリケーション・サーバーの障害時にはWebサーバー・プラグインがそれを検知し、リクエストのフェイルオーバーを行います。

3.2. セッション・アフィニティー

セッション・アフィニティーとは、セッションを使用したアプリケーションに対して、同一セッションIDを持つクライアントからの要求を毎回同じクラスター・メンバーに渡す方式です。クラスターではデフォルトで有効となっており、重み付きラウンドロビンやランダムよりも優先されます。

alt

クラスター・メンバーとなったアプリケーション・サーバーはクローンIDと呼ばれるユニークなIDを保持します。このクローンIDはHTTPセッションIDの後ろに付加されセッションIDの一部として設定されます。Webサーバー・プラグインはセッションID中のクローンIDを参照することによって、クローンIDを持つクラスター・メンバーにリクエストを割り振り、アフィニティを実現しています。

セッションID : CacheID + HTTPセッションID + クローンID

例: JSESSIONID=0000A2MB4IJozU_VM8IffsMNfdR:v544d0o0

上記の例では、セッションID名がJSESSIONIDになっています。この名前はサーブレットの仕様で定義されていますがWASでは柔軟性の観点から変更も可能です。セッションIDをクライアントとアプリケーション・サーバー間でやり取りするためには、CookieやURL再書き込みという機能を使用します。Cookieを使用する場合は、通常Cookieを使用する場合と同じように、CookieドメインやCookieパス、Cookie最大経過時間の考慮が必要ですが、これらもWASで設定することができます。

3.3. 障害検知とHTTPリクエストのフェイルオーバー

Webサーバー・プラグインは、クラスター・メンバーの障害・再起動を自動的に検知して、現在処理可能なアプリケーション・サーバーにクライアントからの要求を割り当てます。 クラスター・メンバーに障害が発生した場合、Webサーバー・プラグインはそのHTTPリクエストを別のクラスター・メンバーに送信することにより、フェイルオーバーを実現しています。Webサーバー・プラグインは一定時間間隔でそのクラスター・メンバーを再度転送先として有効化するため、障害が復旧した場合には再びリクエストが転送されるようになります。この動作は、クラスター・メンバーの障害時だけでなく、ネットワーク障害時、クラスター・メンバーの意図的な停止時も同様です。

alt

3.4. セッション・パーシスタンスとセッションのフェイルオーバー

セッションはアプリケーション・サーバー上のメモリ内に格納されて管理が行われます。通常はセッション・アフィニティー機能によりセッションを使用し続けることができます。しかし、障害発生等により、HTTPリクエストがフェイルオーバーされた場合、メモリ上にセッション・オブジェクトが存在せず、ユーザーは処理をやり直さなくてはなりません。この問題を解決するために、セッション・フェイルオーバーを可能にするのがセッション・パーシスタンス機能です。

alt

セッション・パーシスタンス機能は、セッション情報を外部のデータストア(DBまたは他のアプリケーション・サーバー)に格納することによって、複数のアプリケーション・サーバーでセッション情報を共有(セッションのクラスター化)します。セッションのクラスター化には以下の利点があります。

  • セッションを使用するアプリケーションを、異なるノードにある複数のアプリケーション・サーバー上で実行することができ、効果的な負荷分散が実現できます。
  • セッション途中で、このセッションの処理を行っていたアプリケーション・サーバー・プロセスがダウンした場合でも、セッションのフェイルオーバーが可能になります。

一方、WASの管理者やアプリケーション開発者が考慮しなければいけない点もあります。例えば、セッションを外部のデータストアに書き出すタイミングや、書き出すデータ量に応じてパフォーマンスに影響を与えるため、WASの管理者はこれらの設定について考慮する必要があります。

また、アプリケーション開発者にとっても、セッション・データを外部のデータストアに書き出すため、セッション・オブジェクトはシリアライズ可能でなければならない、という制約があります。さらに、フェイルオーバーが発生した場合はセッションの状態が不整合になる可能性があることを考慮したアプリケーション・ロジックとする必要があります。

3.5. 複数台構成のセッション維持

では最後に、セッション・アフィニティーとセッション・パースシスタンスによるセッション・フェイルオーバーの動作について、もう一度確認しましょう。アプリケーション・サーバーに障害が起きた場合のWebサーバー・プラグインとWASの挙動は以下のようになります。セッション・パーシスタンスはDB(パーシスタンスに使用されるDBはセッションDBと呼ばれます)を使用するとします。

  1. ユーザーからのリクエストはクラスター・メンバーAに割り振られ、セッション・アフィニティーによりリクエストはセッション終了までクラスター・メンバーAに振られ続けます。セッション・パーシスタンスによって、クラスター・メンバーAが保持するセッション・オブジェクトの情報はセッションDBへと書き込まれます。
    alt
  2. ユーザーの一連の処理が終了する前にクラスター・メンバーAが障害によってダウンすると、Webサーバー・プラグインはその障害を検知し、別のクラスター・メンバーBにリクエストを割り振りなおします。クラスター・メンバーBはユーザーのセッション情報を保持していないので、セッションDBよりユーザーのセッション情報を取得しセッションの回復を行います。セッションが回復し、ユーザーはセッションを持続しながらリクエストを続けます。この時、セッション・アフィニティーの対象となるのはクラスター・メンバーBです。セッション情報はセッションDBに書き込まれます。
    alt
  3. クラスター・メンバーAが復旧すると、Webサーバー・プラグインによって、ユーザーからのリクエストはクラスター・メンバーAに割り振られます。クラスター・メンバーAは障害によってダウンしている間のセッション情報を保持していないので、セッションDBよりセッション情報を取得しセッションの回復を行います。セッションが回復し、ユーザーからのリクエストは再びクラスター・メンバーAに割り振られ、セッション・アフィニティーが維持されます。
    alt

WAS虎の巻第2回では、WASの複数台構成についてご紹介しました。今回は、主にWebサーバーとアプリケーション・サーバーの複数台構成をご紹介しましたが、Webシステムの構成要素には、データベースやメッセージングなどのリソースアクセスも欠かせません。次回以降では、DBやMQなどのリソースアクセスについてご紹介します。