ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソフトウェア
  3. WebOTX
  4. アプリケーションサーバ
  5. 製品体系/価格
  6. 拡張製品
  7. WebOTX業務拡張オプション
ここから本文です。

WebOTX業務拡張オプション

「拡張製品」へ戻る

WebOTX業務拡張オプションは、業務システムの保守性、運用性、可用性を高めるオプション製品です。システムの特性に応じて必要な機能のみを選択して導入可能な製品体系となっています。

  • WebOTX Application Deployer(業務デプロイメント)JSR-88 に基づいて実装されたJava EEアプリケーションの汎用的な配備機能です。Javaアプリケーションをリポジトリ上で一元管理し、複数のJava EEアプリケーションサーバに対して配備することが可能です。
  • WebOTX Application Closure(業務閉塞)

    Javaアプリケーションを一時的に実行抑制(閉塞)する為のJavaアプリケーション用の部品です。
    本機能は、Javaアプリケーション内部で利用するAPIと、閉塞判定に利用する情報(任意のキーワード、アプリケーション名等)を動的に更新する為の運用基盤とを含みます。

  • WebOTX DataSource Proxy(業務パーティショニング)

    Java EEアプリケーションサーバ上で動作するJavaアプリケーションからJDBCデータソース取得部において、その振分制御を行う為の、Javaアプリケーション用の部品です。
    本機能は、Javaアプリケーション内部で利用するAPIと、振分制御に利用する情報を動的に更新する為の運用基盤とを含みます。

  • WebOTX Application Tracer(業務トレース)

    Javaアプリケーションの障害発生時の障害解析性を高める障害解析支援製品です。
    Javaアプリケーション情報採取ロジックを組み入れるトレース組込コマンドと、JVM上で動作情報を採取、出力する制御部、採取された情報の解析性を高める為の変換コマンドとを含みます。

従来のAPサーバだけではカバーできない業務APの運用面に着目

下図に示すように、システムダウン要因の約80%は「人的要因」と言われています。

システムダウン要因の80%は『人的要因』システムダウン要因の80%は『人的要因』

「ビジネスを止めないITシステムの構築」......高い信頼性を要する基幹業務システムで多くのを実績を誇るWebOTXですが、実運用の面で次に示すようないくつかの課題があったのも事実です。

従来のAPサーバだけではカバーできない業務APの運用面に着目

既に現在のWebOTXでも既に、アプリケーションの配置情報や稼動状況管理のための機能を数多く備えています。

ただ、単一サーバマシンの単一ノード上に配置されたアプリケーションの管理には威力を発揮するのですが、複数サーバマシン、複数ノードにまたがって動く業務について、全ての情報を束ねて管理する部分は十分とは言えないのが現状です。そのため次のような指摘を受けることがあります。

今までのWebOTXも運用管理機能は強力だが...今までのWebOTXも運用管理機能は強力だが...

システムダウン要因80%のうちの約40%は「人による運用操作ミス」と言われています。上述した課題は全てこのような運用操作ミスを引き起こす可能性をはらんでいるといっても過言ではないでしょう。

アプリケーション不具合の解析における課題

現在のWebOTXでも既に、アプリケーションの不具合内容を解析するための機能を備えています。

ただし実現するには、アプリケーション開発者によるプログラミングが必要であるため、実際のシステム運用の局面ではどうしても次のような指摘を受けてしまいます。

障害解析のためのトレース採取機能の課題障害解析のためのトレース採取機能の課題

システムダウン要因80%のうちの残り約40%は「アプリケーションの不具合」と言われています。確かに不具合のない完璧なアプリケーションを作るのは不可能です。そのため、不具合が発生した時にいかに解析作業を効率化し、迅速に復旧できるかが重要になってきます。

今回出荷したオプション製品のうち、「WebOTX Application Deployer」は1番目の課題に着目した製品です。また、「WebOTX Application Tracer」は2番目の課題に対応すべく今までのWebOTXが持つ障害解析機能を強化した製品です。

以下に、これらの製品を利用することで従来のWebOTXからどう便利になるのか、もう少し掘り下げてご紹介いたします。

WebOTX Application Deployer

複数サーバマシンにまたがった業務デプロイ管理機能

J2EEに準拠したアプリケーションサーバで動作させるWebアプリケーションやEJBコンポーネントを、実際にアプリケーションサーバ上で動かすためには、「デプロイ(配備)」という作業を行うことで、サーバ上の決まった場所に決まった形式で関連するファイルを配置し、アプリケーションサーバが管理できるようにします。

当然ながらWebOTXにもデプロイ機能はあります。ただし従来のWebOTXでは、一回のデプロイ作業につき単一のアプリケーションサーバにしか配置することができません。

従来のWebOTXを使ったデプロイ従来のWebOTXを使ったデプロイ

全てのアプリケーションが1台のアプリケーションサーバマシンで動く形態の業務システムであれば、従来のWebOTXが提供する運用環境製品を利用すれば事足りるでしょう。

しかし必ずしもそういった形態のものばかりではありません。複数のアプリケーションを機能に応じて複数のサーバマシンに点在させて動かすような運用を行うのが一般的でしょう。また同じアプリケーションを複数のサーバに置いてクラスタ構成をとる場合も考えられます。

そこで、冒頭のような要望を多く耳にすることになりますが、それには、「WebOTX Application Deployer」の、業務デプロイ管理機能が有効です。

「WebOTX Application Deployer」では、物理的なサーバマシンの配置やアプリケーション構成を意識せず、上述した一連の「業務」を視点において運用を行います。つまり複数のアプリケーションファイルを「業務単位」で管理し、複数のアプリケーションサーバに自動的にまとめて配置する機能を提供します。

WebOTX Application Deployerを使ったデプロイWebOTX Application Deployerを使ったデプロイ

確かに従来のWebOTXでもバッチファイル等を駆使すればある程度はこの機能を実現できるかもしれません。冒頭で記載した「人的要因」、さらには実現・保守のための工数を考えるとそれは得策ではないことはご理解いただけると思います。

「WebOTX Application Deployer」ではそれらの課題を克服するため、アプリケーションの自動配置、およびアプリケーションの配置状況確認のための運用管理コマンド群を提供しています。これによって配置漏れなどのオペレーションミスを事前に防ぐことができ、業務システム運用のためのコストを削減します。

稼動中業務アプリケーションファイルの動的置換機能・バージョン管理機能

システム要件の変更やアプリケーションのバグ修正などにより、稼動中のアプリケーションの置き換えを行うことは実際によくある話でしょう。実際は、休業日や連休の時期を狙って一斉にシステムを停止し、その間に作業を行うのが多いのではないでしょうか。その際に、「置き換えたアプリケーションに新たなバグが見つかった」、「ファイルの置き換え手順を間違った」といったトラブルによるシステム停止期間の延長、作業の巻き戻しも起こり得ます。サーバ台数が増えれば増えるほどそうなる確率も高まります。

「24時間365日連続稼動」を目指すような高信頼業務の場合、そのようなトラブルは致命的です。

従来ケースでのスケジュールの例。ファイル更新の度にシステム停止が必要従来ケースでのスケジュールの例。ファイル更新の度にシステム停止が必要

上述のケースを阻止するには、「WebOTX Application Deployer」の、業務アプリケーションファイルの動的置換機能、およびアプリケーションのバージョン管理機能が有効です。

実は、従来のWebOTXでも「アプリケーションの動的置換機能」は提供しています。ただし次のような制限が存在します。

  • Webアプリケーションは対象外。
  • 複数のサーバで稼動する複数のアプリケーションを一気に置換するにはエラー処理をきめ細かく意識したバッチファイル作成などの作りこみが別途必要。
  • 「アプリケーションのバージョン管理機能」はサポートしていない。

「WebOTX Application Deployer」では、システムを停止することなく、業務アプリケーション群の置き換えを可能にしています。置き換え完了前の要求は、旧バージョンの業務アプリケーションが継続して担当し、置き換え完了後の要求は、新バージョンの業務アプリケーションが新たに担当します。つまりバージョン移行期間を設けます。

WebOTX Application Deployerを利用したスケジュールの例。新旧バージョンを並行稼動WebOTX Application Deployerを利用したスケジュールの例。新旧バージョンを並行稼動

この方式は、従来のWebOTXが提供する動的置換機能も同じなのですが、WebOTXは1つのアプリケーションファイルの動的置換しか管理しません。例として下図のようなWebサーバ(サーバ1)とAPサーバ(サーバ2)の2台のサーバに配置されたアプリケーションの構成を考えてみます。AP1とAP2を従来のWebOTXを使って同時に置き換えた場合、AP1から異なるバージョンのAP2を呼び出してしまうタイミングが発生します。その場合バージョン不一致で正常に動作しない可能性が高くなります。

従来のWebOTXだけでは異なるバージョンのAP呼び出しが発生する従来のWebOTXだけでは異なるバージョンのAP呼び出しが発生する

それに対して、WebOTX Application Deployerでは、AP1とAP2をまとめて一つの業務としてバージョン管理を行いますのでそういった不一致の発生を防ぐことができます。

つまり24時間365日連続業務を運用している最中でも、複数サーバに点在したファイルの整合性を保ったままのバージョンアップを保証します。

またこのようなWebOTX Application Deployerの「アプリケーションのバージョン管理機能」を使えば、利用者によって異なるバージョンのものを利用させるよう管理することもできます。例えば業務の都合で旧バージョンを使い続けたい利用者と、即座に新しいバージョンを導入したい利用者が混在していてもまとめて対応することができます。

WebOTX Application Tracer

従来のWebOTXでも、ユーザトレースを独自に出力するためのAPI(アプリケーションプログラミング用のインタフェース)を提供しており、トレース採取レベルによってファイルに情報を出力するかしないかを設定できます。しかし次で紹介するようなプログラムレスでの完全自動化はできません。プログラムへの組み込み工数は考慮する必要がありますし、組み込みの際に新たな問題を作りこんでしまう可能性も否定できません。

またこれだけだと、開発者によって採取する内容がバラバラ、従来のスタックトレースだけだと情報不足、結局「再現待ち」なのか?という、冒頭で示したような声も多く出てくるのが現状です。

トレースに対する従来の問題点トレースに対する従来の問題点

そのような課題を解決するのに有効な次の機能を本製品では提供します。

自動トレース組み込み機能

「WebOTX Application Tracer」では、アプリケーションソースの修正やリコンパイルをせずにトレース部品を自動的に組み込む機能を提供しています。

組み込む際には、対象となる業務を指定したコマンドを1回だけ実行します。これによってアプリケーションのメソッドの呼び出し単位にトレース部品を自動生成し、アプリケーション内部に組み込みます。

WebOTX Application Tracerを使うと...WebOTX Application Tracerを使うと...

自動生成されるトレース部品は、出力箇所、出力内容、および出力形式を統一していますので、高い可読性を実現します。

またトレース情報は、正常稼動時はファイル出力はせずにメモリ内で管理、障害発生時にファイルへ出力する、という形式になっており、性能劣化の原因となるファイルI/Oを最小限に抑えます。通常時のトレース情報採取による性能面の心配をする必要はありません。

障害発生時には、次に示す画像のようにメソッドの呼び出し履歴、受け渡しするパラメータの内容など、障害にいたるまでのシーケンスをきめ細かく出力します。障害解析に要する工数を削減できます。

さらには、障害情報不足により障害原因の解析ができず、一時的に情報を採るようにプログラムを修正して再現待ちにするといったケースも削減できます。

以上WebOTX業務オプションについて少し掘り下げてご紹介いたしました。J2EEシステムの運用性向上をお考えの方、ぜひご検討いただけたらと思います。また、ダウンロードのページに、別途紹介資料を公開していますのでご参照ください

ページの先頭へ戻る