第2回:Oracle Application Serverの特徴とOracleが目指す方向性 (1/3)

Oracle Special Interview
第2回:Oracle Application Serverの特徴とOracleが目指す方向性
日本オラクル株式会社 システム製品統括本部 営業推進部 Fusion Middlewareグループ 担当シニアマネージャー 杉 達也

日本オラクル株式会社
システム製品統括本部 Fusion Middlewareグループ
担当シニアマネージャー
杉 達也

1996年4月に入社。Oracle Fusion MiddlewareのSOA/Java関連マーケティング業務を担当する。

日本オラクル株式会社 システム製品統括本部 営業推進部 Grid Computingグループ 担当シニアマネジャー 山本 哲也

日本オラクル株式会社
システム製品統括本部 Fusion Middlewareグループ
担当シニアマネージャー
山本 哲也

2000年2月に入社。Oracle Gridおよび運用管理ツール関連のマーケティング業務を担当する。

1   2  次のページ
現在、企業システムにおいてデータベースやアプリケーションサーバは不可欠な存在となっている。求められる高い可用性を備えた企業情報システム基盤を実現する「Oracle Fusion Middleware」にはどのようなメリットがあるのだろうか。
後編では、システム製品統括本部 営業推進部 Fusion Middlewareグループ 担当シニアマネージャーの杉 達也氏とシステム統括に、Oracle Application Serverの実用上のメリットと今後のOracleの目指すものについてお話を伺った。

−一般的なアプリケーションサーバに対するOracle Application Serverの特徴はなんでしょうか

杉氏: アプリケーションサーバが問題なく動いている状況下では、パフォーマンスを除けば実は大きな違いはありません。ではどこに差が出るかと言えば、1つにはトラブル発生時があります。運用開始時には問題がでなくても、何かの拍子にアプリケーションがハングアップしたりパフォーマンスが低下するケースです。

良くある例は、それまでアプリケーションは普通に動いていたため、アプリケーションベンダーではなく、アプリケーションサーバのベンダーに問い合わせるというものです。そこでチェックしてみるとアプリケーションサーバ側のトラブルではなく、原因を追究する中で、関連部署間で結果的にたらい回しになります。最終的にアプリケーションのコードの問題だったことが判明するまで、3〜8ヶ月もかかった例もあります。

Oracle Applicarion Serverでは、どのページでパフォーマンスの劣化が起こっているのかについてを判断する管理ツールで、この問題解決までの時間を大幅に短縮しています。

−それはどのようなツールなのでしょうか
杉氏: 管理ツールではポイントごとに詳細な内容をドリルダウンして検証することができます。グラフ表示を交えて、そのアプリケーションが単に遅いというだけではなく、どの部分で遅いのかまでを確認できます。

もちろんアプリケーションに限らず、データベースのネットワーク速度やJSP/サーブレット、EJB、JDBCなど様々なポイントをグラフ表示で一目で判別できます。このツールはシームレスにシステム全体をチェックできるため、多くの場合は10分程度で問題のポイントを探り当てることが可能です。

ポイントがわかってしまえば、状況の改善は非常に容易になります。この改善についても、アドバイザー機能で適切な対応が表示され、その場で適応を加えることができます。

−もう1つの特徴はどのようなものでしょうか
日本オラクル株式会社 システム製品統括本部 営業推進部 Fusion Middlewareグループ 担当シニアマネージャー 杉 達也 杉氏: ミッションクリティカルなシステムを利用されているお客様は、データベースをOracle RACで多重化/クラスタ化されているケースがあります。データベースをクラスタ化していれば、通常は運用面での問題がないと思われるでしょう。

しかし実際には、それだけではトラブルに対応できないケースもあります。多くのアプリケーションサーバは、データベースに対してコネクションプーリングを行います。RACはノードが分かれているため、1つのアプリケーションサーバが異なるコネクションプールを張っているケースがあります。

例えば2つのノードがある状況で片方のノードにトラブルが起こった場合、RAC自体は新しいリクエストを動作を続けているノードに割り振ります。しかし一般的なアプリケーションサーバでは、RAC側のノードの割り振りを知ることができません。このため、トラブルの起こったサーバに対してプールしているコネクションをそのまま利用しようとしてしまい、新たなトラブルが発生します。

これに対してOracleの場合、データベースとアプリケーションサーバに同じプロセス管理機能を持たせ、トラブル状況を通知し、通知した部分を再取得できる仕組みを用意しています。データベースの障害をアプリケーションサーバ側に通知したり、問題のあるコネクションを自動でリフレッシュできます。

−同一ベンダーのデータベース&アプリケーションサーバならでの機能ですね
杉氏: そうです。これは通知の仕組みが統一されていることで実現できています。

−実際のトラブル発生時には、どういった処理が行われるのでしょうか
日本オラクル株式会社 システム製品統括本部 営業推進部 Grid Computingグループ 担当シニアマネジャー 山本 哲也 山本氏: ノード障害が発生した時点でデータベースサーバからアプリケーションサーバに対して通知があり、タイムアウトを待たずに再取得を行います。その際には障害が発生しているデータベースサーバ以外を使ってコネクションを再取得するため、処理は継続されます。

同様のことは一般的なアプリケーションサーバでも、Javaアプリケーション側でエラーを常にチェックする機能を搭載することで実現できます。しかしOracle Application Serverなら基盤で対応しているので、わざわざコードを書く必要はありません。

ここも「トラブルが起こってわかること」なのです。正常に動いているうちは、わざわざコードを書く必要性に思い当たりません。実際にトラブルやエラーが出て、はじめて必要だと感じるわけです。
−余分なコードを追加しないので、そこからトラブルが発生することがないわけですね
山本氏: トラブルを避けるためにコードが肥大すると、それに伴ってコードそのものが複雑化し、結果としてメンテナンスの労力やコストがかかるようになります。

こういった機能が基盤側にあることで、余分なことを意識せずにアプリケーションを作れるというのは大きなメリットだと考えています。

1   2  次のページ

Oracle Special Interview
第1回 アプリケーションサーバの環境向上を果たす「Oracle Fusion Middleware」
第2回 Oracle Application Serverの特徴とOracleが目指す方向性

人気記事トップ10

人気記事ランキングをもっと見る