見出し画像

WebLogic Serverのクラスタ機能について理解したい！

nishi

※　この記事は書籍「OracleWebLogicServer構築運用ガイド11ｇ」の内容を自分なりに解釈して記述したものです。


クラスタとは・・・

システムを止めずに安定して動かし続けたい場合、クラスタ機能がとても大切である。クラスタとは、複数のサーバーをつなげて一つの大きなシステムとして働かせる仕組みのことだ。

クラスタを使うと、以下のような利点がある:

  1. 一台のサーバーが壊れても大丈夫である。

  2. システム全体が止まらない。

  3. 他の正常なサーバーが仕事を引き継ぐ。

簡単に言えば、クラスタは「保険」のようなものだ。一台のサーバーに問題が起きても、全体のシステムは問題なく動き続けられるのである。

クラスタのメリット

WebLogic Serverのクラスタとは、複数のWebLogic Serverインスタンス（管理対象サーバー）が協調して動作するサーバーのグループの事。
このグループは、クライアントからは、単一のWebLogic Serverのインスタンスのように見え、どのインスタンスにおいても、同じサービスを提供できる。

WebLogic Serverのクラスタ化によるメリットは主に3つ。

◯拡張性の向上

クラスターに新しいサーバーを追加することで、クラスター能力を増強できる
ハードウェアがさらに必要な場合、新しいマシンに新しいサーバーを追加できる
1つのサーバーで、既存マシンの能力を十分に活用しきれない場合、そのマシン上にサーバーを追加することもできる

◯可用性の向上

複数サーバーを用いることにより、シングルポイント障害による影響がクライアントに及ばないようにする。
クラス内の複数のサーバーが同じサービスを提供できるので、ある。サーバーに障害が発生しても、別のサーバーで処理を引き継ぐ（フェイルオーバー）ことができる。

◯管理性の向上

複数サーバーは、クラスタ化されることによって1つの塊として管理される
これによりアプリケーションのデプロイの一括化、サーバーに対するパッチ適用の際のローリング・アップグレード等が可能になる。

クラスタ内の通信

WebLogic Serverのクラスターを理解する上で最も重要なのは、クラスター内の通信である。この通信には2種類あり、それぞれ異なる目的で使用される。

  1. IP ユニキャストによる通信

  2. IP ソケットによる通信

これらの通信方法によって、複数のサーバーが一つのグループ（クラスター）として機能することができる。クラスター内の通信は、サーバー同士が情報を交換し、協調して動作するために不可欠である。

以下に、それぞれの通信方法についてより詳しく説明する。

IP ユニキャスト

IP ユニキャストは、クラスター内のメンバー間で2つの重要な目的で使用される。

１．JNDIツリーの更新

WebLogic Serverのクラスター内では、JNDIツリーの更新が重要な役割を果たす。JNDIツリーとは、サーバー上のリソースや設定情報を名前で管理する電話帳のようなものだ。

JNDIツリーとは：

  • JNDI（Java Naming and Directory Interface）は、名前とオブジェクトを関連付けて管理するための仕組みである。

  • JNDIツリーは、これらの名前とオブジェクトの関係を木構造で管理している。

  • 例えば、データベース接続やメッセージキューなどのリソースを名前で簡単に見つけられるようにする。

JNDIツリーの更新イメージ


JNDIツリーの更新プロセス：

  • クラスター内の各サーバーは、自身のJNDIツリーを持っている。

  • あるサーバーでJNDIツリーの内容が変更されると、その情報を他のサーバーに伝える必要がある。

  • この更新情報の伝達にIP ユニキャストが使用される。

スタブ情報とは：

  • スタブは、リモートオブジェクト（別のサーバー上にあるオブジェクト）へのアクセスを代理で行う小さなプログラムである。

  • スタブ情報には、オブジェクトの場所や呼び出し方法などが含まれる。

  • 更新時には、オブジェクト全体ではなく、このスタブ情報のみを送ることで通信量を削減している。

JNDIツリーには2種類のオブジェクトが登録される：

  1. クラスター対応オブジェクト

  2. クラスター非対応オブジェクト

クラスター対応オブジェクトが更新されると、以下のプロセスが発生する：

  1. あるサーバーでJNDIツリーの内容が変更される。

  2. 変更されたのがクラスター対応オブジェクトの場合、更新情報を他のサーバーに送る必要がある。

  3. 更新情報は、IP ユニキャストを使って他の全サーバーに送信される。

  4. 送信されるのは、オブジェクト全体ではなく、スタブ情報（オブジェクトの位置や呼び出し方法などの簡潔な情報）のみである。

  5. 各サーバーは受け取った情報を元に、自身のJNDIツリーを更新する。

このプロセスにより、クラスター内の全サーバーのJNDIツリーが同期され、どのサーバーからでも同じ情報にアクセスできるようになる。また、スタブ情報のみを送ることで、通信量を抑え、ネットワーク負荷を軽減している。

この仕組みによって、クラスター全体で一貫性のある情報管理が可能となり、システムの信頼性と効率性が向上する。

２．クラスター内のハートビート

  • 各WebLogic Serverインスタンスは、他のインスタンスの正常動作を確認するためにハートビートを送信する。

  • ハートビートは通常10秒間隔で行われる。

  • 30秒間（3回連続）応答がないインスタンスは、クラスターから除外される。

IPソケット通信

IP ソケット通信は、クラスター内のサーバー間やクライアントとサーバー間で使用される。この通信方法は、T3またはT3Sというプロトコルを使用して、直接的な一対一（ピアツーピア）の通信を行う。

IP ソケット通信の主な目的は以下の2つである：

  1. インメモリレプリケーション

  2. EJBオブジェクトやRMIオブジェクトに対するリモート呼び出し

それぞれ解説していく。

１．インメモリレプリケーション

インメモリレプリケーションとは、サーバーのメモリ内にあるデータを他のサーバーにコピーする仕組みのこと。この仕組みは主に以下の2つの目的で使用される。

a) HTTPセッションオブジェクトの複製
b) ステートフルセッションBeanの複製

これらの複製には、IP ソケット通信が使用される。

a) HTTPセッションオブジェクトの複製

  • Webアプリケーションの状態を管理するために使用される。

  • プライマリーサーバー（主に使用するサーバー）とセカンダリーサーバー（バックアップ用のサーバー）の間で行われる。

  • Webコンテナ（Webアプリケーションを実行する環境）が、この複製を管理する。

b) ステートフルセッションBeanの複製

  • JavaEEアプリケーションの状態を保持するコンポーネント。

  • これもプライマリーサーバーとセカンダリーサーバーの間で行われる。

  • EJBコンテナ（Enterprise JavaBeansを実行する環境）が、この複製を管理する。

２．EJBオブジェクトやRMIオブジェクトに対するリモート呼び出し

リモート呼び出しとは、別のサーバー上にあるプログラムの機能を使用することです。WebLogic Serverでは、この仕組みにIP ソケット通信を使用しています。

主な用途：

  1. EJB（Enterprise JavaBeans）オブジェクトの呼び出し

  2. RMI（Remote Method Invocation）オブジェクトの呼び出し

これらのオブジェクトは「クラスター対応」で、クラスター内のどのサーバーからでもアクセスできます。

リモート呼び出しが行われる典型的な例：

  1. 外部のJavaクライアントからの呼び出し

  2. 別のJavaプロセスからの呼び出し

  3. コマンドラインからの呼び出し

  4. Webアプリケーション（Webコンテナ上）からEJBコンポーネント（EJBコンテナ上）への呼び出し

この仕組みにより、以下のようなメリットがあります：

  • 異なるサーバー上のオブジェクトを、同じサーバー上にあるかのように使える

  • システムの柔軟性が向上する

  • 負荷分散が可能になる

【補足】
上記以外にもWebLogic Server内のほとんどの通信に IP ソケット通信が使用されている

Web層のクラスタ化

Web層のクラスタ化とは、複数のサーバーを連携させて、Webアプリケーションの安定性と継続性を高める仕組み。

主な目的：

  1. アプリケーションの拡張性向上

  2. 可用性（常に利用可能な状態）の確保

仕組み：

  • サーブレットやJSPで使用するHTTPセッションオブジェクト（ユーザーの状態情報を保存するもの）を複製・保存。

  • この複製により、一つのサーバーに問題が発生しても、別のサーバーがシームレスに処理を引き継ぐことができる。

具体例：オンラインショッピングサイトの場合

通常の流れ：

  1. ユーザーがサイトにログイン

  2. 商品を検索・閲覧

  3. 購入する商品を決定

  4. 決済方法（クレジットカード、代引きなど）を選択

  5. 購入完了

この過程で、以下の情報がHTTPセッションオブジェクトに保存される：

  • ユーザーの識別情報

  • ログイン状態

  • 選択した商品情報

クラスタ化のメリット：

  • サーバーに問題が発生しても、ユーザーは中断することなくショッピングを継続できます。

  • ユーザーは障害を意識することなく、スムーズな体験を得られる。

クラスタ化していない場合：

  • サーバーに問題が発生すると、セッション情報が失われる。

  • ユーザーは最初からやり直す必要があります（再ログイン、商品選択のやり直しなど）。

クラスタ化している場合：

  • 一つのサーバーに問題が発生しても、別のサーバーが処理を引き継ぐ。

  • ユーザーは中断することなく、ショッピングを続けられる。

・サポートされる http Sessionオブジェクトの複製 永続化 方式

サポートされる http Sessionオブジェクトの複製 永続化 方式は以下の通り。

【ローカルのネットワーク内】
・インメモリレプリケーション
・インメモリセッション共有（Coherence*Web）
・JDBCによる永続化
・ファイルによる永続化
【広範囲ネットワーク内】
・MANレプリケーション
・WANレプリケーション

WebLogic Serveでサポートされる httpSessionオブジェクトの複製・永続化の方式

WebLogic Serverは、ネットワークの規模に応じて異なる方式をサポートしている。

１．ローカルネットワーク内での方式

　a. インメモリレプリケーション

  • セッション情報を他のサーバーのメモリにコピーする方式

  • 高速だが、サーバーがダウンするとデータが失われる可能性がある

２．広範囲ネットワーク内での方式

WebLogic Serverのクラスタ機能について理解したい！～MAN／WANレプリケーション～

a. MANレプリケーション（Metropolitan Area Network）

  • 都市圏規模のネットワーク内でのレプリケーション

  • 比較的近距離のデータセンター間で使用

b.WANレプリケーション（Wide Area Network）

  • 広域ネットワーク内でのレプリケーション

  • 遠距離のデータセンター間で使用

この分類により、ネットワークの規模や要件に応じて適切な方式を選択可能。
ローカルネットワーク内の方式は主に速度と信頼性のバランスを、広範囲ネットワーク内の方式は地理的な冗長性を重視している。

インメモリレプリケーション

インメモリレプリケーションとは、WebLogic Serverのクラスター内でHTTPセッション情報を複製する仕組み。

上の図では「管理対象サーバー1がプライマリーサーバーのとき、管理対象サーバー２がセカンダリサーバーになる」（２がプライマリの時は3がセカンダリ・・・）というイメージ図。

この技術の特徴は以下の通り：

  1. 動作原理

    • クラスター内のWebLogic Serverインスタンス間で直接通信（ピアツーピア）を行う

    • HTTPセッションオブジェクトを別のサーバーに複製する

  2. サーバーの役割

    • プライマリーサーバー：元のHTTPセッションオブジェクト（プライマリーオブジェクト）を持つサーバー

    • セカンダリーサーバー：複製されたHTTPセッションオブジェクト（セカンダリーオブジェクト）を保持するサーバー

  3. 効率的な設計

    • クラスター内の2つのサーバー間でのみ複製を行う

    • これにより、レプリケーションによる負荷（オーバーヘッド）を最小限に抑える

  4. 他のアプローチとの違い

    • 一部のアプリケーションサーバーは、クラスター内のすべてのメンバーにレプリケーションを行う

    • しかし、その方法ではサーバー数が増えるほど性能が低下する傾向がある

    • WebLogic Serverの方式は、この問題を回避し、効率的に動作する

この設計により、WebLogic Serverは高い可用性を維持しつつ、システム全体の性能を確保している。

レプリケーションのタイミング

インメモリレプリケーションは、特定のタイミングで実行される。このタイミングを理解することは、システムの動作と性能を把握する上で重要。

  1. レプリケーションが行われないタイミング

    • setAttribute()メソッドの呼び出し時

    • removeAttribute()メソッドの呼び出し時

    • これらのメソッドが実行されても、その時点では複製は行われない

  2. レプリケーションが行われるタイミング

    • サーブレットのDoGetメソッド（GETリクエストの処理）の終了時

    • サーブレットのDoPostメソッド（POSTリクエストの処理）の終了時

    • 具体的には、クライアントにサーブレットやJSPの処理結果を返信した直後

  3. このタイミングを選んだ理由

    • 一連の処理が完了した時点で複製を行うことで、不必要な複製を減らせる

    • クライアントへの応答速度に影響を与えにくい

    • セッション情報の一貫性を保ちやすい

このような設計により、WebLogic Serverは効率的にセッション情報を管理し、システムの性能と信頼性のバランスを取っている。

セカンダリーサーバーの選択ルール

WebLogic Serverでは、セカンダリーサーバー（複製先のサーバー）を選択する際に、いくつかのルールと概念があります。これらを理解することで、より効果的なクラスター設定が可能になる。

表6-1 セッション・レプリケーションのためのサーバー・インスタンスのランキング

https://docs.oracle.com/cd/E80149_01/wls/CLUST/failover.htm

  1. レプリケーショングループ

    • クラスター内で関連付けられた複数のサーバーで構成される論理的なグループ

    • セカンダリーサーバーの選択基準として使用される

  2. セカンダリープリファレンスグループ

    • 各サーバーに対して指定可能な、優先的に複製先として選ばれるサーバーのグループ

    • 自サーバーのレプリケーショングループとは別に設定できる

  3. セカンダリーサーバー選択の優先順位
    a) レプリケーショングループの指定
    b) セカンダリープリファレンスグループの指定
    c) サーバーが別のマシンに存在するか
    d) その他の細かい制限

  4. デフォルト設定

    • グループ設定をしない場合、システムのデフォルト設定に従ってセカンダリーサーバーが選択される

  5. カスタマイズの利点

    • ハードウェア構成による制限に対応可能

    • 運用上の要件に合わせてセカンダリーサーバーを明示的に設定可能

  6. レプリケーショングループの役割

    • セカンダリーサーバーの優先順位を決定する重要な選択基準となる

これらの設定により、システム管理者はクラスターの動作をよりきめ細かく制御し、効率的で信頼性の高いシステム構成を実現できる。
ハードウェアリソースの効果的な利用や、障害時の影響を最小限に抑えるための戦略的な複製先の選択が可能になる。

この記事が気に入ったらサポートをしてみませんか？