今日のJava EEアプリケーション開発において、アプリケーション・サーバは不可欠の存在だ。特にミッション・クリティカルなシステムを構築する際には、信頼性の高いアプリケーション・サーバが必要となる。そうしたニーズに応えてオラクルが提供しているのが「WebLogic Server」であり、現在、国内外のさまざまな企業がミッション・クリティカルなシステムの実行基盤として利用している。本企画では2回にわたり、これからWebLogic Serverを利用する方に向け、同アプリケーション・サーバの特長、そして具体的な導入の流れを解説する。前編では、まずWebLogic Serverの主要機能と基本アーキテクチャを説明しよう（編集部）。

Java EEに完全準拠し、豊富な実績を持つアプリケーション・サーバ

　オラクルが提供するWebLogic Serverは、Java EE仕様に準拠しつつ、ミッション・クリティカルなシステムの開発で豊富な実績を持つアプリケーション・サーバだ。単にJava EE 仕様に準拠しているだけでなく、企業システム開発／運用の現場で役立つ実践的な機能が充実している点が大きな特長である。

　現状の最新バージョンは「WebLogic Server 12c（12.1.1）」であり、その提供形態にはStandard EditionとEnterprise Edition、WebLogic Suiteの3つがある。このうち、基本的な機能をカバーしたエントリー・エディションがStandard Edition、それに高可用性機能やクラスタリング機能、監視／診断機能を付加したものがEnterprise Editionだ。そしてWebLogic Suiteは、Enterprise Editionの機能に加え、レスポンスタイムの安定化や性能向上に貢献する「WebLogic Real Time」、インメモリ・グリッドを実現する「Coherence Enterprise Edition」などを備えた最上位エディションとなる。

開発や運用の負担を軽減する多彩な機能

　それでは以降、WebLogic Serverの具体的な特徴を紹介していこう。

大量の処理を効率良くさばき、可用性を高めるクラスタリング機能

　今日、Javaをベースにしたアプリケーション・サーバの標準規格はJava EE仕様で定められているが、WebLogic Serverは同仕様で規定された機能に加えて、多数の独自機能を搭載している。

　その代表的なものが、ロード・バランシングやフェールオーバーを目的としたクラスタリング機能だ。これは多数のクライアントから送られてくる大量のリクエストを効率良く処理するための仕組みであり、複数のサーバを使って負荷分散を行うことができる。単にそれぞれのサーバにリクエストを振り分けるだけでなく、一方のサーバに障害が発生した際、メモリ上のデータを消失させることなく別のサーバに処理を引き継ぐといったことが可能となっている。

サービスを止めずにアプリケーションを更新するプロダクション再デプロイメント機能

　また、システム運用時に便利なのが、新旧2世代のアプリケーションを並行稼働させながら徐々に新バージョンに移行することのできる「プロダクション再デプロイメント」機能だ。サーバ上で実行しているアプリケーションをバージョンアップする際、通常は既存のサービスを停止して新バージョンに切り換えるのが一般的である。しかし、これではサービス停止時間が発生してしまうため、業務に支障のない日時を選定したり、バージョンアップ手順を工夫したり、設定変更や運用管理が複雑になったりといった具合に、バージョンアップの機会が限られ、無駄な運用コストが発生してしまう。

　この問題を解消するためにWebLogic Serverに搭載されているのがプロダクション再デプロイメント機能である。同機能では、新旧2つのバージョンを並行して実行し、新バージョン起動前に受け付けたセッションは旧バージョンで処理しつつ、新たなセッションは新バージョンで処理する。そして、旧バージョンのセッションがすべて終了もしくはタイムアウトしたら、完全に新バージョンに切り替える仕組みだ。これにより、サービスを停止させることなく運用負荷を最小にしながらバージョンアップを行うことを可能にしているのだ。

実行スレッド数を適切な値に保つ自動チューニング機能

　実行スレッド数を適切な値に自動調整する「自動チューニング」の機能を搭載していることも、WebLogic Serverの魅力だ。一般に、Java EEアプリケーション・サーバでは処理要求を適切に処理するために、実行スレッド数を調整するチューニング作業が必須となる。だが、適正な実行スレッド数を割り出すには、設定とテスト、効果測定の作業を繰り返す必要があり、これが現場のエンジニアに大きな負担を強いている。しかし、WebLogic Serverを使えば、処理の実行状況や負荷状況に応じて自動的に最適なスレッド数を設定してくれるので、チューニング作業の負担が大幅に軽減されるのである。

システムの稼働状況を詳細に記録するJRockit Flight Recorder

　WebLogic Serverは、ミッション・クリティカル・システム向けに特別に設計された「JRockit」というJVMを搭載しているが、同JVMの稼働状況を自動的に記録してくれる「JRockit Flight Recorder」と呼ばれる機能も極めて有用だ。

　例えば、サービスが停止するような異常事態が発生した際には、JRockit Flight Recorderによって時系列に記録された情報を見ることにより、サービス実行中に何が起きたのかを詳細に確認することができる。また、JRockit Flight Recorderで記録した情報を分析するためのツールとして「JRockit Mission Control」が用意されており、これを使えばGUIベースでサービスの稼働状況を分析することができる点も大きなポイントである。

業界最速の性能、そしてOracle Databaseとの高い親和性も魅力

　アプリケーション・サーバの選定基準の1つとして、処理性能が挙げられるだろう。Java EEアプリケーション・サーバの性能を評価するための業界標準ベンチマークに「SPEC jApp Server2004」や「同2010」があるが、歴代のWebLogic Serverはこれらのベンチマークで高いパフォーマンスを記録している。

　アプリケーションの性能を向上させるための機能や設定も充実している。Java EEアプリケーションのレスポンスタイムを厳格に制御したい場合、問題となるのがJVMにおけるガベージ・コレクション（GC）の挙動だ。プログラムにおけるメモリ管理の手間が省けるという大きなメリットをもたらすGCだが、一方でGC処理中はアプリケーション・サーバの処理が停滞あるいは完全停止するため、レスポンスタイムが悪化してしまうという難点がある。こうした課題を解決するために用意されているのがWebLogic Real Timeだ。これはGCによる性能への影響を最小限に抑制するための機構で、これによりレスポンスタイムが重要なアプリケーションでも、GCによる性能低下を心配することなくコーディングできるようになる。

　加えて、WebLogic Serverでは、パフォーマンスに関する設定項目において、セッション数の最大値を指定することができるようになっている。例えば大量のリクエストが発生した際、システムが無際限にリクエストを受け付ければ、レスポンスを返せなくなるという事態にも発展しかねない。だが、WebLogic Serverであれば、セッション数の最大値を設定することによって過負荷状態を防げるわけだ。

　アプリケーションの優先順位を設定するための仕組みも用意されており、システム・ユーザーに対しては特権ユーザーとしてリクエストのスレッドを速やかに割り当てるといった設定も可能になっている。これにより、リクエストが集中するような状態になった場合でも、必要な処理を速やかに実行することができるのだ。

　同じオラクルの製品であるOracle Databaseとの親和性の高さも、他のJava EEアプリケーション・サーバにはない特徴である。具体的には、Oracle Databaseのクラスタリング構成を実現する「Oracle Real Application Clusters（RAC）」との緊密な連携をサポートしている。これにより、Oracle RACの稼働状況を検知し、無効なデータソースを自動的に識別してアクセスを切り替えるといったことが可能となっている。いずれもオラクルの製品なので、WebLogic ServerとOracle Database、そして両者の接続に必要なコンポーネントについて総合的にサポートを受けられる点も大きなメリットだ。

WebLogic Serverにおける構成／監視

　さて、WebLogic Serverのアーキテクチャにおいて重要な概念となるのが「ドメイン」という考え方だ。ドメインとは、WebLogic Serverの管理／設定を行うための単位であり、1つのドメインの中に複数のサーバ・マシンを配置できるほか、複数のクラスタを組むことも可能だ。

　1つのドメイン内には1台の管理サーバが置かれ、同サーバがサービスを実行する各サーバ（管理対象サーバ）の構成／管理を行う。管理者は管理ツールを使って管理サーバに接続し、ドメイン内の管理対象サーバを構成／監視するという具合になる。

　なお、ドメインの構成方法はいくつか考えられる。例えば、営業管理アプリケーションや在庫管理アプリケーションなど、アプリケーション単位でドメインを構成する方法がある。また、東京や大阪、名古屋などの地域単位でドメインを構成するといった方法もあるだろう。

　以上、前編では、WebLogic Serverの特徴や基本的なアーキテクチャを紹介した。後編では、WebLogic Serverのインストールや設定などの方法を具体的に解説する。

後編に続く