[製品紹介]
Sun ONEの基盤を提供するAPサーバ
iPlanet Application Server 6.5
栗田雅芳
東芝ITソリューション
2002/3/29
| iPlant Application Server（以下iAS）は、アプリケーション・サーバ・ベンチャーの草分けであるKIVA SoftwareのKIVA Application Serverを基に長年の経験を積み重ね、改良してきた製品だ。当初はWebアプリケーションの実行プラットフォームを目的としていたが、「Services on Demandを実現するため」のWebサービスの実行プラットフォームへ成長しつつある。本稿では、iASが持つスケーラビリティの確保と、無停止運転を実現できる耐障害性という特徴について紹介する。また、米国サン・マイクロシステムズ（以下Sun）の提唱している「Sun Open Net Environment」（以下Sun ONE）におけるiASの位置付けについても紹介しよう。 |
| 1.高可用性とスケーラビリティ実現を支えるアーキテクチャ |
短期間でユーザーが数千から数百万に増大する可能性のあるインターネットのECサイトでは、「期待以上の成功」への迅速な対応が非常に重要だ。iASは、需要の急激な増加に対応できる高い拡張性を備えている。サーバの増設といった水平方向の拡張が比較的容易にできるのも大きな特徴だ。
また、万が一の障害に耐え得る信頼性も兼ね備えている。高度なフェイルオーバー機能とそれを支える分散セッション管理アーキテクチャは、ミッションクリティカルなシステムにも十分対応することができる。
そのほか、システムのパフォーマンスを引き出すための機能が多数装備されている。これらについて、順に紹介しよう。
| 水平方向の拡張を容易にする システム・アーキテクチャ |
iASは、高拡張性を考慮したシステム構成を採用している。iASの高拡張性によって性能強化、サービスの拡大や機能強化を迅速に行えるようになる。図1は、iASを用いた標準的なシステム構成を示している。
 |
| 図1 標準システム構成 |
iASには、HTTPリクエストをハンドリングするためのiPlanet Web Server（以下iWS）と、iASの構成情報を格納するためのiPlanet Directory Server（以下iDS）がバンドルされており、これらのソフトウェア・コンポーネントによって構成される。もちろん、1台のきょう体にすべてのソフトウェア・コンポーネントを導入することも可能である。
iASは、iDSを構成情報のリポジトリ・コンポーネントとして利用する。iAS用のパスワードポリシーとユーザー・グループを管理し、サーバ内のコンポーネント情報、アプリケーションの構成情報およびJ2EEアプリケーション・コンポーネントのアクセス・コントロールを格納している。iASのコンポーネントとしてiDSを統合したことで、ユーザー情報やアプリケーション情報を格納するためにファイルやRDBMSを使用するよりも高いパフォーマンスをもたらしている。
iASとiWSとの間はWebコネクタと呼ばれるプラグインを使って通信する。このWebコネクタは、iASに配置されているアプリケーション情報や負荷分散設定情報をiDSから取得し、状況に応じて最適なリクエスト処理を実現する。
システムの各層がそれぞれ独立したソフトウェア・コンポーネントで構成されていることにより、水平方向の拡張を容易に行うことが可能となっている。すなわちシステムパフォーマンスのボトルネックとなる層に対して拡張を行うことで、容易にパフォーマンスを向上させることができる。例えばHTTPリクエストのハンドリング能力が不十分で接続性にも問題があると判断されたならば、iWSのノードを増やすことで対応が可能である。あるいは、アプリケーションへの負荷が高く、リクエスト処理能力に不満があるようならば、iASノードを追加して負荷を分散し、短時間でより多くのリクエストの処理を行えるように構成することも可能である。
パフォーマンスに限らず、システムの可用性を高めるために、iASを複数のノードに分けてセットアップし、クラスタを構成することもできる。サーバ構成の高い可用性を保証するためには、iAS クラスタに合わせてiDSもクラスタ化が可能だ。
このように、iASを用いたシステムは、サービスの特性や利用状況に合わせて、自由にそして簡単に拡張することができるのだ。
| 可用性とパフォーマンスに配慮した プロセス・アーキテクチャ |
iASのインスタンスは、5種類のプロセスから構成されている。管理サーバプロセス（以下KAS）、実行サーバプロセス（以下KXS）、Javaアプリケーション実行サーバプロセス（以下KJS）、C++アプリケーション実行サーバプロセス（以下KCS）、CORBAブリッジプロセス（以下CXS）だ。それぞれのプロセスが役割を分担し連携することで、アプリケーションを効率良く実行し、確実にサービスを提供する。図
2 はiASを構成するプロセスの関係を示している。
 |
| 図2 iASを構成するプロセス |
それぞれのプロセスの役割は次のようになっている。
・KAS
KASは、ほかのサーバプロセスを監視する役目を担っている。万が一、プロセスがダウンした場合でも、KASによって速やかに再起動が行われる。また、iASの設定やアプリケーションの配備など、環境整備はこのプロセスを介して行われる。
・KXS
KXSは、リクエストマネージャ的な働きをする。リクエストを解析し、アプリケーション実行サーバに割り付ける。また、KXSはほかのiASサーバのインスタンスやWebコネクタと通信を行うことで、負荷分散、フェイルオーバーを実現している。
・KJS／KCS
KJSおよびKCSはユーザーアプリケーションの実行エンジンである。KJSはJavaアプリケーション・ロジックを実行するためのプロセスで、KCSはC++アプリケーション・ロジックを実行するためのプロセスである。これらのサーバプロセスは複数同時に起動することもできる。リクエストマネージャとユーザーアプリケーション実行エンジンのプロセスが異なるので、万が一、ユーザーアプリケーションによって障害が発生しプロセスがダウンしても、ほかのプロセスにリクエストを送信することでサービスを継続することができる。ダウンしたKJS／KCSは管理サーバによって自動的に再起動され、再び利用可能になる。
・CXS
CXSは、リッチクライアントからのRMI/IIOP接続をブリッジし、EJBコンポーネントやJavaサーバ上で処理されるコンポーネントとの直接通信を可能にする。
KJSおよびKCSは、CPU数に合わせて複数実行することができる。プロセス当たりのスレッド数はあまり多くしてもパフォーマンスが上がらない。CPU数に合わせたプロセスを稼働させ、最適なスレッド数に調整することで、最高のパフォーマンスを引き出すことができる。
| 高信頼性を実現するフェイルオーバー機能 |
ECサイトにおいて、セッションの切断は致命的な損害をもたらす。iASは高度なフェイルオーバー機能を装備し、あらゆる障害からユーザーを守る。iASのフェイルオーバー機能は、分散セッション管理アーキテクチャによって実現される。
■分散セッション管理アーキテクチャ
iASでフェイルオーバー機能を利用するためには、2台以上のiASでクラスタを構成する必要がある。
iASクラスタでは、ServletContextやHttpSession、Stateful Session Beanなど、アプリケーションの状態やユーザーとのセッションに関する情報を、iASクラスタに1つだけ存在するプライマリサーバに格納する。ほかのサーバは、プライマリサーバに格納されている情報を用いてアプリケーションの状態を把握し、ユーザーとのセッションを継続する。負荷分散機能によってセッションが複数のiASにまたがって実行されたとしても、プライマリサーバ上の情報を参照、更新することでユーザーとのセッションは維持され、1つのアプリケーションとして機能する。
図3は、iASの分散セッション管理の仕組みを示したものである。
 |
| 図3 分散セッション管理 |
フェイルオーバー機能は、この分散セッション管理アーキテクチャ上に成り立っている。プライマリサーバに格納されている情報は、常にバックアップサーバに複製され同期を取っている。
プライマリサーバに障害が発生したときは、バックアップサーバがプライマリサーバに昇格することで、ほかのサーバに情報を提供できるようになる（図4）。
 |
| 図4 分散セッション管理（障害発生時） |
クラスタを構成するiASは何台でも接続可能だ。極端にいえば、100台のiASでクラスタを構成すれば、99台のサーバがダウンしてもサービスを提供し続けることが理論的にはできるのである。
しかし、実際のシステムでは、100台のiASによるクラスタを構成することは難しい。分散セッション管理アーキテクチャでは、常にプライマリサーバへのアクセスが発生してしまう。また、iAS間の通信によるトラフィックが増大してしまい、システム全体のパフォーマンスが低下することもある。そのため、一般的には、4台から6台程度でクラスタを構成することになる。
また、iASのフェイルオーバーは瞬時に行われるものではない。iAS間の通信断を検知してから10秒程度の時間を要する。このため、フェイルオーバー時に発生したリクエストを処理できない可能性もある。アプリケーション設計においては、このことも十分に留意しておく必要がある。
| 高負荷状況への対応とパフォーマンス |
■高度な負荷分散機能
ECサイトにおいては、いついかなるときでも、リクエストを確実に処理しなければならない。iASは、突然発生する高負荷状況にも十分対応できる、高度な負荷分散機能を備えている。
iASには、WebコネクタによるWebサーバ側での負荷分散と、iAS自身による負荷分散の機能がある（図5）。
 |
| 図5 Webコネクタ駆動およびiAS駆動の負荷分散の違い |
おのおのの特徴を説明しよう。Webコネクタ駆動の負荷分散機能は、WebコネクタがiASからのレスポンスタイムに基づいて判断するか、またはあらかじめ設定された重み付けに基づいてWebコネクタが負荷分散を行う方式である。一方、iAS駆動の負荷分散では、iAS同士が負荷状況を交換し合い、負荷が低く余裕のあるiAS上で処理をする方式である。iAS駆動の負荷分散は、Webコネクタ駆動の負荷分散に比べ、ち密な制御が可能であるが、一度iASに送信されたリクエストがほかのiASに渡されるため、オーバーヘッドが発生する欠点もある。
表1に、おのおのの負荷分散オプションとその特徴を記述する。
| アプリケーション・コンポーネント当たりのレスポンス時間 （Webコネクタ駆動） |
アプリケーション・コンポーネントごとのレスポンスタイムをWebコネクタでダイナミックに集計し、これを基にコンポーネントごとにリクエストを分散する |
| サーバインスタンス当たりのレスポンス時間 （Webコネクタ駆動） |
サーバインスタンス全体のレスポンスタイムをWebコネクタでダイナミックに集計し、これを基にリクエストを分散する |
| ラウンドロビン （Webコネクタ駆動） |
ラウンドロビンによる負荷分散を行う。ハードウェアのリソースを加味し、あらかじめサーバごとのウェイトを設定することができる。Webコネクタは、ユーザーが指定したウェイト方式に基づいて、サーバ全体にリクエストを分散する。この負荷分散オプションは、ユーザーが指定するウェイトだけに基づき、コンポーネントやサーバ応答時間に関するダイナミックなデータの集計を必要としないので、オーバーヘッドが発生しない |
| ユーザー定義による負荷分散 （iAS駆動） |
サーバのレスポンス時間、CPU負荷、ディスクI/O、メモリスラッシュ、キューイングされているリクエスト数に応じて、リクエストを分散する |
| 表１ 負荷分散のオプション | |
このように、iASでは複数の負荷分散方式を選択することが可能となっているが、iAS駆動の負荷分散機能を利用しているユーザーは少ない。それは、iAS駆動の負荷分散機能が、最適な調整を行うことが難しく、またその指針もないために試行錯誤することになるためである。そのため、多くのユーザーは、動作の仕組みを理解しやすい、ラウンドロビンやサーバインスタンスのレスポンス時間によるWebコネクタ駆動の負荷分散を利用しているのが現状だ。
■きめ細やかなリザルト・キャッシュ機能
サーバのリソースは限られている。常に同じ結果を返すアプリケーション・ロジックの実行結果をキャッシングして、応答速度を向上させ、リソースを効率良く利用することはシステム全体にとって非常に有効なことである。iASには、アプリケーション・ロジックの実行結果をキャッシングする機能（リザルト・キャッシュ）を提供している。
iAS は、アプリケーション・ロジックの実行結果をキャッシュすることによってアプリケーションのパフォーマンスを向上させることが可能だ。
開発者は、アプリケーションの設定を変更することで任意にこの機能を有効にすることができる。リザルト・キャッシュ機能は図6のように動作する。
 |
| 図6 リザルト・キャッシュ |
キャッシュを有効にすると、iASはアプリケーション・ロジックに入力されたパラメータと結果をキャッシュに保存する。次回、同じリクエストが実行されると、サーバは入力パラメータがキャッシュ内の入力パラメータと一致するかどうかをチェックし、それらが一致する場合、リクエストされたロジックを実行する代わりにキャッシュから結果のみが取り出される。リザルト・キャッシュ機能は、長い処理時間を要する大きなデータ・リクエストや、頻繁にアクセスされるアプリケーション・ロジックに対して特に有効だ。
リザルト・キャッシュ機能が有効に利用されると、アプリケーション・ロジックの実行回数が減る。ロジックの実行回数が減るということは、アプリケーション・サーバの処理能力に余裕がでてくることになり、システム全体のリソースに余裕が生まれる。リソース不足でパフォーマンスが十分でなかったシステムでも、リザルト・キャッシュ機能によって大きくパフォーマンスが向上することだろう。
ただし、やみくもにリザルト・キャッシュ機能を使用していてはサービスが成り立たないこともある。バックエンドのデータが更新されたときに、キャッシュが使われることがないよう、注意して設計する必要があることは忘れないでいただきたい。
■アプリケーション・パーティショニング
iASは、インスタンスごとに、アプリケーションをコンポーネントごとに分割して配置することが可能だ。この機能はアプリケーション・パーティショニングと呼ばれている。
アプリケーション・パーティショニングを行うメリットとしては、性能にばらつきのあるハードウェアで構成されたシステムにおいて、ロジックの利用頻度、負荷状況などに応じて、アプリケーションを分割し配置することで、限られた資源を有効に活用し均質なサービスを提供できることが挙げられる。
分割配置といっても、実際にコンポーネント単位で分割して配置するわけではない。配置されたアプリケーションの中から、不要なコンポーネント（ServletやEJB）を無効化することで、そのコンポーネントに対するリクエストが送信されないようにしているだけである。
図7はアプリケーション・パーティショニングを実施したときの、リクエストの送信先を示している。この図では、3つのモジュールで構成されているアプリケーションを、3つのiASに分割して配置している。
 |
| 図7 アプリケーション・パーティショニング |
iAS1には、アプリケーションのすべてのモジュールを配置する。iAS2には、アプリケーション構成モジュールのうち、Module2とModule3を配置する。iAS3には、Module3のみを配置する。
アプリケーションを実行したとき、Module1に対するリクエストは、常にiAS1に送信される。Module2に対するリクエストは、iAS1、iAS2に対して送信される。Module3へのリクエストはすべてのiASに対して送信される。
このように、アプリケーション・コンポーネントの配置状況に合わせて、リクエストを分散することが分かる。コンポーネントが複数のiAS上で実行されたとしても、分散セッション管理アーキテクチャによって、1つのアプリケーションとして機能するので問題ない。
例えば、オンライン・カタログ・アプリケーションでは、注文処理、在庫管理およびチェックアウト処理のアプリケーション・コンポーネントを、別々のサーバに分割して配置することができる。 アプリケーションの配置や分割の方法にかかわらず、アプリケーションは1つのシステムとして機能する。
このように、アプリケーション・パーティショニングにより、システム管理者は非常に柔軟にアプリケーションのパフォーマンスを拡張し、調整することができる。さらに、同じアプリケーション・コンポーネントを複数のサーバ上に配置することによって、あるサーバがシャット・ダウンした場合でもサービスを提供し続けることができる。
| 高品質な「Services
on Demand」システムを スピーディに開発 |
最後に「Services on Demand」システムを高品質・短期期間開発を実現するためのiASのフレームワークと開発環境を紹介しよう。
■開発期間を大幅に短縮するiPlanet Application Framework
アプリケーションをJ2EEのAPIだけで構築するのは、生産性が低く、コストが増大してしまう。iASでは、iPlanet Application Frameworkと呼ばれるフレームワークが提供される。iPlanet Application FrameworkはJava ServerPagesおよびサーブレットをベースにしたアプリケーションインフラを提供する。
本フレームワークを利用することで、低レベルの機能を作成する必要がなくなるばかりか、J2EEデザインパターンに沿ったMVCモデルの実装を容易にし、短期間で品質の高いアプリケーションを開発できるようになる。
■Forte for Java 3.0 Enterprise Editionとのシームレスな連携
いまやIDEがなければサービスやアプリケーションの開発は困難といっても過言ではない。iASでは、Forte for Java 3.0 Enterprise
Edition（以下FFJ3.0 EE）との連携によって、コーディングから配置、デバッグまでをFFJ3.0 EE上ですべて行うことができる。
また、すでにWebGain VisualStudioやBorland JBuilderといった代表的なJava開発環境との連携も可能であり、それらのツールに使い慣れたユーザーが蓄積した資産を有効利用できる。
以上、iASのテクニカルな特徴を紹介した。次ページでは、Sun ONEにおけるiASの位置付けと役割について解説しよう。
|
||||||
|
||||||||||||||||||||||||
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
