システムのダウンタイムを最小にする
WebLogic Serverの
ミッションクリティカル機能とは

ミッションクリティカルの要求に応えるWebLogic Server

　インタビューの前編記事でも明らかにしたように、WebLogicは早い時期からJava EE対応のアプリケーションサーバとして確固たる地位を確立した。しかし、数多くあるアプリケーションサーバの中で、今もWebLogic Serverを選ぶべき理由は一体何なのだろうか。どうした機能強化がされてきているのだろうか？

日本オラクル Fusion Middleware事業統括本部 ビジネス統括本部 製品戦略部 担当シニアマネジャー新井庸介氏

　「一番の理由は、ミッションクリティカル性です。WebLogic Serverには停止時間を最小化するための機能群が備わっています。企業情報システムでのミッションクリティカルな運用を考えるとき、WebLogic Serverはきわめて魅力的といえます」（日本オラクル Fusion Middleware事業統括本部 ビジネス統括本部 製品戦略部 担当シニアマネジャー新井庸介氏）

　システムの停止時間を短くすること、できるだけゼロに近づけること、──シンプルな要求である。そして、基幹システムの停止がビジネスの成果に直結している以上、企業情報システムとして最も重要な要求でもある。しかし、その実現のためには、数多くの技術的な課題をクリアしなければならない。

　WebLogic Serverは、バージョンを重ねるたびにこれら技術的な課題を1つ1つ乗り越え、停止時間をゼロに近づけるための機能群を充実させてきた。その主なものを紹介していこう。

停止時間を最小化する機能群

　まず、計画停止を不要にする機能がある。Java EE対応のアプリケーションサーバの運用では、「設定を変えて再起動する」局面が発生する。チューニングの変更や、アプリケーションの更新など、何らかの変更が発生するたびにアプリケーションサーバを再起動するようでは、そのつど計画停止の手続きを踏む必要がある。

　WebLogic Serverと組み合わせて用いられることが多いJVM（Java仮想マシン）のJRockitには、運用時に有効となる大きな特徴がある。設定変更の際、再起動を必要としないことだ。リモートコマンドにより、設定のほとんどの項目を再起動なしで変更できる。

　例えば「ヒープサイズの変更」がある。通常はJVMのコマンドラインオプションを変更して再起動する操作だが、WebLogic/JRockitの組み合わせでは運用を続けながら変更できるのだ。

　アプリケーションサーバ上で開発したアプリケーションを配備する作業「デプロイ」も、従来は時間がかかる操作だった。そしてアプリケーションの更新のたびに、再デプロイを行い、稼働中のシステムを計画停止する必要があった。

　WebLogicでは、バージョン9.2以降で、プロダクション再デプロイメントと呼ぶ機能が備わった。これは、アプリケーションの更新を無停止で実施する機能だ。利用中のユーザーから見て、セッションが途中で切れることもない。新旧両バージョンのアプリケーションを同時に動かすようなデプロイが可能となる。

　「従来は、アプリケーションの更新は限られたタイミングでしか実施できませんでした。計画停止を伴うため、深夜なり休日なりに実施する必要があったからです。それが、完全無停止でアプリケーションを更新できるようになり、必要に応じたタイミングで実施可能となりました」（前出の新井氏）

再デプロイ機能を使えばアプリケーションの更新時に計画停止する必要がない

障害対策にも手厚い機能

　もうひとつ、システムが停止する要因には、障害などによる「計画外停止」がある。

　一般に、システムの負荷が極度に高まると、適切にチューニングできずにシステムダウンに陥る場合がある。このような事態を防ぐため、WebLogic Serverでは自動チューニング機能を備えている。アクセス負荷に応じて、自動的にアプリケーションサーバのリソースを配分する。

　アプリケーションサーバが処理する1個1個のトランザクションは、それぞれスレッドが割り当てられて処理が進む。このスレッド数の上限値は、負荷を予想してスレッドプールとして事前に割り当てる。ただし、予測が外れる場合がある。「スレッドプールを大きく取りすぎると重くなり、少なすぎると詰まる（処理が滞留する）。そこでチューニングが必要になります。WebLogic Serverではここを自動的に調整します」（前出の新井氏）

　また、アプリケーションごとに優先度を設定して、負荷が大きな場合でも重要なアプリケーションを優先的に実行することができる。アプリケーションに対して個別にSLA（サービスレベル契約）を守る必要があるケースではぜひ欲しい機能である。

WebLogic Serverはアプリケーションに割り当てるスレッド数を自動的に調整してくれる

障害切り分けの機能も充実

　停止時間ゼロを目標とした運用をしていても、想定外の障害が発生することはある。障害時の問題解決、原因究明は、システムの運用においてきわめて重要だ。特に、システムの種類によっては、監督官庁への報告が必要など、説明責任を厳しく求められる場合がある。ミッション・クリティカルなシステムであるほど、障害発生時に迅速に原因究明を進めながら問題解決できる仕組みが重要となるのだ。

　WebLogic Server/JRockitでは、問題解決のための「フライトレコーダ」と呼ぶ機能を活用できる。これはJVM（Java仮想マシン）及びその上のWebLogicの稼働状況を細かく記録するものだ。ヒープ利用量の推移、空きメモリ容量の推移、GC（ガーベジコレクタ）の動作、スレッドの稼働状況などを見ることができる。プロファイラを使えば同様のログ取得は可能だが、動作時の負荷が大きいために、開発時には使えても運用時の適用は難しい。一方、この「フライトレコーダ」は実運用時に利用するよう考えられており、低負荷で動くのが特徴だ。

Oracleデータベースとの親和性が高い

　WebLogic Serverのミッションクリティカル機能の中でも特筆すべきものとして、Oracleデータベースとの親和性がある。

　「Active Grid Link for RAC」は、複数サーバによるグリッド環境で稼働するデータベースOracle RAC（Real Application Clusters）とWebLogic Serverを密接に結ぶ仕組みだ。RACに対応してデータベース・リクエストを最適化する。

　「従来は、例えばRACのノード負荷にばらつきがある場合でもアプリケーションサーバ側でそれを知る術はありませんでした。これではスループットの最適化ができません。Active Grid Link for RACは、ランタイム接続ロードバランシングにより最適にRACを使うことができます」（前出の新井氏）

　「また、1個のWebリクエストで複数のupdate文がOracleデータベースに送られる場合がありますが、RACを適切に利用できないまま実行すると、複数ノードにまたがるグローバルトランザクションとなってしまい、性能が著しく劣化します。Active Grid Link for RACでは、特定のRACインスタンスにリクエストを割り当てることで、性能を大幅に改善できます」（新井氏）

　このように、WebLogic Serverは、計画停止の時間をゼロに近づけ、障害への素早い対応を可能とし、Oracle RACの性能を最大限に引き出す諸機能を備えている。ミッション・クリティカルな企業情報システムを支えるミドルウェアとして、心強いプロダクトといえるだろう。