55
1
Page 1
2
Page 2
Oracle9iApplication Server
システム構築技法
バージョン 1.0.2.X対応
3
Page 3
はじめに
このセッションでは、Oracle9i Application Server(以下Oracle9iAS)を利用したシステム構築で考慮
すべきポイントを説明します。
このセッションでは、Oracle9iASを使用したシステム構築で考慮すべきポイントをアーキテクチャ面から説明します。
4
Page 4
Agenda
Architecture高可用性システム構成
Oracle9iASの必要リソースの見積もり
パフォーマンスチューニング
Cacheサービスの適用
Adendaです。
初にOracle9iASのアーキテクチャの説明をします。どんなコンポーネントがあり、どういったプロセスが何をしているのか紹介します。
次に高可用性システム構成ということで、障害に強いシステム構成を紹介します。
次に、構成とともにマシンに必要なリソース（メモリー）の見積もりのガイドラインを示します。
パフォーマンスチューニングの項目では、Oracle9iASで特にパフォーマンスに関わる設定を紹介します。
後に、Oracle9iASの先のVersionでAvailableになる予定のCacheサービスについて軽く触れます。
5
Page 5
Architecture
ここからOracle9iASのアーキテクチャについての説明です。
6
Page 6
Oracle9i Application Server
Oracle Enterprise Manager、Oracle Advanced Security、Oracle Internet Directory
Oracle9iAS Forms Services
Oracle9iAS Reports Services
Oracle HTTP Serverpowerd
byApache
コミュニケーションサービス
プレゼンテーションサービス
ビジネスロジックサービス
キャッシング
サービス
システムサービス
Oracle9iAS Portal
Oracle9iAS Wireless
Oracle9iAS Discoverer
BusinessComponents
for Java
XDK
Oracle9iASDatabase
Cache
Oracle PL/SQL
OracleJSP / PSP
OracleEJE
Apache JServ
mod_plsql
mod_jserv
mod_perl
mod_ssl
Oracle9iASWeb
Cache
mod_oseAny Clients
Oracle DB
Oracle9iASの説明ではおなじみの図です。
Communication Serviceここは特定のプロトコルの通信を受け持つServiceレイヤーです。ここにはOracle HTTP Serverがあります。OHSはHTTPDですので、基本的にOracle9iASを利用する場合にはHTTPを使用することになります。Clientとしてブラウザを使用するWeb Applicationが作成できることになります。
例外として、EJBはRMI、CORBAはIIOP、Developerは独自通信（TCP/IP）を行ないます。
Presentation Serviceここは、HTMLを出力を受け持つServiceレイヤーです。（図のコンポーネントを列挙します）開発者は自分の得意な言語やコンポーネントを選択して、開発することになります。
Bussiness Logic Serviceここはビジネスロジックを実装するServiceレイヤーです。
EJB、CORBAを実装することが出来ます。BC4Jはビジネスロジックの作成を支援するライブラリとウィザードです。 終的にはJARという形で配布可能な形になります。
DataManagementServiceOracle Database Cacheは、Data ServerのデータをMiddle Tireにキャッシュするサービスです。
7
Page 7
ブラウザへ Oracle HTTP Server
Oracle HTTP Serverpowered by Apache
親プロセス
１リクエストmodule
子プロセス
module子プロセス
module子プロセス
生成
フロントとなるHTTPDです。HTMLをブラウザに返します。
Oracle HTTP Server powered by Apacheは、その名の通り、オープンソースのHTTP Serverで有名なApacheです。（ Oracle HTTP Server powered by Apacheは、以降「OHS」と表記を略します。）
普通のHTTP Serverと同様に、静的なHTMLファイルをブラウザに返すことが出来ます。
さらにモジュールと呼ばれるものによって動的な内容のHTMLを生成して返すことも出来ます。OHSではモジュールは、Apacheを自分でDownloadしてコンパイルしたときにデフォルトでコンパイルされるモジュールをサポートしています。（例外があります。サポートされるモジュールの詳細はリリースノートを参照のこと。）それに加えてJServとmod_plsql,mod_ose等をサポートします。mod_plsqlはOASのPL/SQLカートリッジと同様にPL/SQL Procedureで動的なHTMLの生成が可能になります。（mod_plsql自身が行っている作業は、PL/SQL Procedureの実行です）
それでは、図のほうにもどってOHSのアーキテクチャです。OHSを起動すると、基本的に２種類のプロセスが起動します。「親プロセス」と「子プロセス」です。親プロセスが 初に起動し、子プロセスを生成します。子プロセスを起動した後は、子プロセスの数を監視して設定通りの数にします。子プロセスは、リクエストの実際の処理を行ないます。そのため、
１リクエスト＝１子プロセスとなります。
8
Page 8
OHS Child process
子プロセス
mod_includemod_perl
mod_jservmod_plsql
mod_osemodulemodulemodule
Core module
「子プロセスはすべて等価」
です。ですので、どの子プロセスでも設定しているすべてのモジュールが実行可能です。リクエストのURLを解析して、HTMLファイルへのリクエストなのか特定のモジュールを実行するのかを判断して必要なモジュールを実行します。
Apache Coreと呼ばれる基本的な機能～HTTPのリクエスト受付や返答など～といくつかの重要な機能は子プロセスの実行イメージに組み込み済みとなっています。その他の拡張機能は共有ライブラリとして作成し、実行時に動的に読み込まれ使用されます。その他のモジュールもApacheコンパイル時にモジュールをハードリンクして実行イメージに組み込むことが可能です。基本的にモジュールは共有ライブラリとしてリンクし、実行時に動的にロードを行ないます。
既に説明したように１リクエストにつき１子プロセスが必要ですので、可能な限り共有ライブラリ化することによってメモリ消費を押さえています。
実際、OHSのメモリ消費を（１子プロセスのメモリ消費を）PSコマンドのVSZで見ると16MByte程度消費しているように表示されます。この値は共有ライブラリを含んでいますので、実際に子プロセス毎に消費される値ではありません。おおよその値になりますが、Solaris版OHSで約４.5MByte程度消費するようです。
9
Page 9
OHSの状態遷移
リクエスト受付中
待機中
待機中
リクエスト処理中
リクエスト処理中
子プロセス
子プロセス
子プロセス
子プロセス
子プロセス
tcptcp queuequeue
子プロセスのライフサイクルとHTTPの受け付けについての説明です。
起動した子プロセスは、待機中となります。初期段階で起動されるプロセス数はStartServerです。待機中のプロセス数の 大値を決めるのはMaxSpareServersディレクティブです。 小値をきめるのはMinSpareServersです。この数を下回ると親プロセスが子プロセスを立ち上げます。
待機中の子プロセスのうちひとつがセマフォのロックを獲得し、HTTP受付中となります。
リクエストを受け付けると、受付処理を行ない、セマフォのロックを返却し、その場を譲ります。あとは、直接ブラウザと通信をやりとりします。（リクエスト処理中」）
リクエストの処理が終わると、待機中になります。
10
Page 10
Oracle HTTP Server
mod_plsql
子プロセス
子プロセス
１リクエスト 子プロセスHTTP
Net8mod_plsql
mod_plsql
mod_plsql
ブラウザへ
親プロセス
PL/SQLWebToolkit
mod_plsqlは動的にHTMLを作成することができます。
ブラウザからHTTPのリクエストが来て、それがmod_plsqlのURLであった場合、指定のスキーマに対してNet8接続を行ないます。それから、指定のパッケージのプロシージャを実行します。Procedureの実行結果をブラウザに返します。
mod_plsqlではProcedureでHTMLを生成する為のPL/SQLパッケージであるPL/SQL WebToolkitを提供しています。これを利用して動的にHTMLを生成するようなProcedureを開発者は作成することになります。
システム構築を考える上でのポイントは、各子プロセス毎に接続が行われることです。mod_plsqlの設定によって、接続をプールしたり、毎回接続するようにしたり設定することが出来ます。どちらにせよ、HTTPの同時接続数分のDB接続が発生することになります。
11
Page 11
JServ
JServ
ApacheJServApacheJServ
JavaVMJavaVMOracle HTTP Server
AJP ServletServlet子プロセスmod_jserv
AJP ServletServlet子プロセスmod_jserv
親プロセス
JServは、Servletを実行することができます。Servletは、Sun社から提供されているJava Servlet API specificationとして仕様が規定されています。それによると、「Servletは、コンテナによって管理されるWebコンポーネントであり、動的なコンテンツを生成するものです。Servletは小さく、プラットフォームインディペンデントなJavaのクラスで、WebServer上で実行されます。Web Clientとやりとりをしてサービスを提供します。主にWebClientとの通信はHTTPを使用します。」
JServのアーキテクチャに戻ります。JServはmod_jservとApacheJServから成ります。mod_jservは、ブラウザからのリクエストをApacheJServへFWDします。mod_jservとApacheJServ間はApacheJServProtocolで通信します。AJPはTCP/IP通信上のJServ独自プロトコルです。ApacheJServは、Javaで作成されたServletEngineです。JavaVM上で動作します。このエンジン上でServletは動作することになります。
Servletでの処理が終わってHTMLが生成されると来た道を逆に戻って終わりとなります。
システム構築を考慮する場合のポイントはApachJServ自身はOHSと別のプロセスで動作するという点です。そして、mod_jservとApacheJServはAJPによって通信をおこなっているという点です。よって別マシンへの分散も可能となりますし、同じマシンで２つ以上のプロセスで起動することも可能です。また、同じマシン上で動作させた場合にはtcp loopbackを利用しますので、他のマシンへ分散させた場合と比べて、高速に通信できます。
12
Page 12
JServ（自動起動時）
JServ
ApacheJServApacheJServ
JavaVMJavaVMOracle HTTP Server
ServletServlet子プロセスmod_jserv
AJP ServletServlet子プロセスmod_jserv
親プロセス
自動起動自動起動
JServは、ApacheJServを自動起動することができます。
OHSのデフォルトの設定では、この自動起動になっています。
このPPTの一番 初のほうのOHSのアーキテクチャの説明で、子プロセスはすべて等価で、すべての子プロセスは、各々リクエストを処理すると説明しましたが、この子プロセスは例外で、ApacheJServの起動と監視しか行いません。
ApacheJServ（JavaVMプロセス）が落ちると、自動的に再起動してくれます。
但し、この機能は同一マシン上にmod_jserv(つまりOHS）とApacheJServがある場合にしか使えません。
別マシンにApacheJServを分散したい場合には、手動で起動する必要があります。
13
Page 13
JServ（ロードバランス機能）
Oracle HTTP Server
子プロセスmod_jserv
親プロセス
JServ
ApacheJServApacheJServ
JavaVMJavaVM
ApacheJServApacheJServ
JavaVMJavaVM負荷分散負荷分散
耐障害耐障害
JServは、ApacheJServプロセスを複数起動し、処理を分散、ロードバランスを行うことができます。
分散の仕方については、別マシンに分散することも可能ですし、同一マシンにいくつも起動することも、それらを混在させることも可能です。
ロードバランス機能は、ApacheJServ毎に重み付けをすることができます。あるマシンにはリクエストの２０％、あるマシンには３０％といった具合に割り振ることが可能です。
分散、ロードバランスの機能を使用するには、ApacheJServを手動で起動しなければなりません。
ここで、ServletのSession機能を使用していた場合に、Session情報はどうなるのだろう？と思うかもしれません。JServでServletのSession機能を使用すると、 初にSessionを開始したApacheJServ上にSession情報が保管されることになります。以降、Sessionが終了するまで、同じApacheJServのプロセスへルーティングされるようにCookieが発行されます。
14
Page 14
Oracle HTTP Server
子プロセスmod_jserv
親プロセス
JServ
ApacheJServApacheJServ
JavaVMJavaVM
ApacheJServApacheJServ
JavaVMJavaVM
JServ（ロードバランス機能使用時）
自動監視
AJPServletServlet子プロセス
mod_jserv
スコアボードスコアボード
JServの耐障害機能についての説明をします。
ロードバランスの設定を行なうとこの機能も自動的に利用可能となります。
図の上の方にいる子プロセスはWatchdogと呼ばれるプロセスです。これも例外的にHTTPのリクエストを受け取らないプロセスです。このWacthdogプロセスは、定期的にApachJServに通信を行ない正常に動作しているか確認します。正常に動作している場合、スコアボードに「正常に動作している」旨を記録します。
mod_jservへのリクエストがくるとServletを実行するためにApacheJServにリクエストを出します。このときスコアボードを見て、動作しているApacheJServへリクエストを出します。もし、ApacheJServが応答しなかった場合には、スコアボードに「動作していない旨」を記録してから、自動的に別のApacheJServへ接続します。
15
Page 15
EJB
Oracle EJEJNDI
仮想JVMEJBEJB
NameService
RMI over IIOP 仮想JVMEJBEJB
仮想JVMEJBEJB
OracleJVMは、EJBを実行することが出来ます。
EJBは、Sun社が提唱したEnterprise JavaBeansのことです。EJBのSpecificationによると
「Enterprise JavaBeansのアーキテクチャは、コンポーネントベースの分散コンピューティングアーキテクチャです。Enterprise JavaBeansは、トランザクション可能なエンタープライズアプリケーションのコンポーネントです。」
EJBのクライアントは、EJBとRMIによって通信します。EJBの仕様書ではRMI以下の下層通信レイヤーについては規定していません。OracleJVMではIIOP通信を使用しています。
EJBでは、JNDIを使用してNameServiceからEJBのHomeオブジェクトのリファレンスを取得し、create()メソッドを実行してEJBのインスタンスを起動し、Remoteインタフェースのリファレンスを取得し、目的のメソッドを実行することによって処理を行ないます。
16
Page 16
SGA
共有プール共有プールDatabaseバッファキャッシュ
REDOログ・バッファ
要求キュー 応答キュー
Oracle Enterprise Java Engine (Oracle EJE)
リスナー
共有共有サーバーサーバー
ディスパッチャディスパッチャ
Oracle EJE
OracleJVMの処理についてです。
OracleJVMもDatabaseで処理を実行するのと同じようにリクエストが受け付けられます（Net8通信）。
「JNDIでEJBのリファレンスを取得する＝DBのセッションの開始」
であり、
「EJBのメソッドを実行する」ことは「Javaストアドプロシージャを実行する」のとほぼ同等となります。（Javaストアドプロシージャの実行だけでなくEJBのサービスも行なう為完全にイコールという訳ではありません。）
MTSで、SQL文を実行するのと同じように処理は行なわれます。リスナーに接続し、ディスパッチャへリダイレクトされます。ディスパッチャでは、受け取ったSQLを要求キューに入れます。共有サーバーは、要求キューからSQLを取り出して、処理を行ないます。処理を行なった後、結果を応答キューに入れます。ディスパッチャは応答キューから結果を返します。
17
Page 17
OracleJSP
Servletエンジンに依存しないJSPエンジン
OracleJSPOracleJSP
JavaVM
Your JSP
OSE
OracleJSPOracleJSP
Oracle JVM
Your JSP
JServ
OracleJSPはJava Server PagesのOracleによる実装です。JSPはSun社が提唱したもので、それによると
「Java Server Pages技術は、、強力で柔軟性を保ったまま、Webコンテンツの作成を簡単に可能にします。」
IISを使用されている方は、ASPをご存知かと思いますが、ASPのJava版といったようなものです。
OracleJSPはなるべくServlet Engineに依存しない様に作成されています。実際、現在のOracle製品のJSPを使用しているほとんどすべてはOracleJSPを使用しています。OAS,Oracle9iAS,Oracle Applications,CRM…これらはVersionの違いはあってもすべてOracleJSPです。
18
Page 18
高可用性システム構成
ここまででOracle9iASの主なコンポーネントのアーキテクチャを説明しました。それを踏まえた上で、高可用なシステムの構成について考えて行きたいと思います。
19
Page 19
StatelessとStateful
Stateless– セッション情報を持たない
– クライアントを区別しない
– ページをまたがるトランザクションを行う場合にはアプリケーション側の作りこみが必要
Stateful– セッション情報を持つ
– クライアントと１対１
– ページをまたがるトランザクションを行う場合に作りこみの必要はない
Clientとアプリケーション間の通信についてです。
まずは用語の説明
Stateless（状態がない）と言った意味の通り、各リクエストの区別がない作りのものを指します。
StatefulはStatelessの逆で、従来のクライアントサーバー形式と同様にClientを識別し、以前に行なった何かの操作などを記憶している作りのものを指します。
20
Page 20
StatelessとStateful
Stateless– mod_plsql– JServ– EJB– OSE
Stateful– EJB– OSE
Oracle9iASの各コンポーネントはどうか？という紹介です。実際にはアプリケーション側で作り込みを行なえばどのコンポーネントでもStatefulなアプリケーションを作成することは可能です。
特にJServ（Servlet）はSession機能がありますので、かなり簡単にStatefulなアプリケーションを作成できます。クライアントの識別はServlet EngineがCookieを使用して自動的に行なってくれますので、情報の保持のためのコードを少し書くだけで済みます。
Statefulに上げられているEJB（Stateful SessionBean）とOSEのStatefulでは、そういった作り込み無しにClientを識別してサービスを行なうことが出来ます。EJBのStateful Session Beanに関しては、もともと仕様にそういう目的で使用するものだと書かれているのであたりまえなのですが……
21
Page 21
No single point of failure
ClientNetworkLoadBalancer
OracleHTTPServer
JServOracle Database
Oracle9iASでは、もはや、どのコンポーネントが落ちてもサービスは停止しません。
特にアプリケーションがStatelessであるならば、まったく影響なくサービスは続行されるでしょう。
Oracle9iASでは、OHSを複数台設置し、その前にNetworkLoadBalancer（以降NLBと略記します）を設置することをお勧めします。この構成ならばNLBの機能に頼ることになりますが、URLを同じにしておくことも可能です。
22
Page 22
復旧レベル
Statefulなアプリケーションのダウン時の動作を以
下のようにレベル分けします
– レベル１：ログイン画面に戻ってしまう
– レベル２：HTTPのエラーが出てしまうがリロードすれ
ば作業を続けられる
– レベル３： ダウンにまったく気がつかない (transparentfailover)
前のページでStatelessであれば、どこがダウンしようともサービスは停止しないと話しましたが、Statefulの場合はどうなるのでしょうか？機能的にStatelessなコンポーネントの場合には、アプリケーション側で作り込みを行なっているはずですから、そのState情報を保管していたインスタンスが落ちると復旧できないはずです。例えば、JServのSession機能を使用しているならばJServが落ちてしまうと、もうState情報（Session情報）は復旧できないでしょう。mod_plsqlを使用していてテンポラリ表に書き込み（毎回Commit）を行なっていた場合はDBが落ちようとも復旧可能でしょう。
では、各コンポーネントがダウンした場合のクライアント側からの見え方をレベル分けしてみました。
レベル１：ログイン画面にもどってしまう。
レベル２：HTTPのエラーが出てしまうがリロードすれば作業を続けられる。
レベル３：ダウンにはまったく気がつかない。（transparent failover）
以降の数ページでOracle9iASでStatefulなアプリケーションを作成していた場合で、各コンポーネントが落ちた場合、ここに書いてあるどのレベルで復旧が可能か挙げてみます。
23
Page 23
復旧レベル mod_plsql
ClientNetworkLoadbalancer
OracleHTTPServer
※Cookieを使用して、Session情報をDBに記録するように
アプリケーションを作成したとした場合
レベル３ レベル２復旧レベル
Oracle Database
mod_plsqlを使用した場合です。
説明に入る前に図の意味の説明です。四角は、各コンポーネントのインスタンスを表します。一起動単位です。OHSならhttpdctlを使って起動した親プロセス毎、DBなら起動したDBインスタンス毎に四角を書いています。どこのどのマシンに配置したか？といったことについてはここでは触れず、後のセクションで触れます。
mod_plsqlそのものはStatelessですので、アプリケーション側に作り込みが必要です。ここでは、Cookieを使用してSession情報をDBのテンポラリ表（毎回コミット）に記録し、 後の作業終了のページでテンポラリ表から実際の表に移して終わりとするようなアプリケーションを作成したとします。この場合、Clientを識別するのはCookieです。Session情報はDBのテンポラリ表に入ることになります。
OHSが落ちてしまった場合、この場合はNLBは多くの場合障害検知の機能を持っていますのでルーティングがかわり、ユーザ－はDownに気がつきません、よってレベル３になります。（例外として、まさに落ちる瞬間にアクセスした大変運の悪いユーザーにはErrorが返るかもしれません）
Databaseが落ちてしまった場合、この場合には、データはロールバックされますが、テンポラリ表に毎回コミットしていますので、当然データは残っています。よって、そのまま作業をユーザーは続けることが出来ます。データベールが落ちている間、もしくはOPSを使用していた場合には、切り替わるまでの間、サービスが停止し、Errorページが返ることになりますが、DBが復旧すればユーザーは作業を継続することができます。よってレベル２となります。
24
Page 24
復旧レベル JServ
ClientNetworkLoadbalancer
OracleHTTPServer
JServ
レベル１ レベル３復旧レベル
※ServletのSession機能、OCI8 JDBC Driver、TAF、OPSを使用した場合
レベル３
Oracle Database
mod_jservの場合です。
mod_jservそのものはStatelessですので、アプリケーション側に作り込みが必要です。ServletにはSession機能がありますのでこれを利用するとします。ServletのSession機能を使用してSession情報を記録し、作業の終了時にSession機能で保持していた情報をJDBCでDBに記録して終わりとするアプリケーションを作成したとします。
OHSが落ちてしまった場合、これはmod_plsqlと同様NLBが検知してルーティングを変更してくれますのでユーザーは気がつきません。よってレベル３です。
JServが落ちてしまった場合、Session機能を使用している為、このコンポーネントが落ちてしまうとSession情報はすべて消えてなくなってしまいます。ユーザーは行なっていた作業を始めからやり直さなければなりません。もし、そういった動作では困るといったアプリケーションであるならばmod_plaqlと同様に毎回DBに情報をテンポラリな表にコミットしておき、作業終了時に一気に移すといったように作り込む必要があります。↑この方法にしておけばClientのブラウザが落ちない限り、ユーザーの作業は復旧できることになります。このあとで説明するEJBやOSEでも同じように作り込めば障害に強くすることが可能です。
DBが落ちた場合、これはアプリケーションの作りにもよりますが、OPSのTAFを設定している場合には、生き残っているインスタンスへ再接続できますので、行なおうとしていたTransactionをロールバックの後、もう一度やり直すように作成しておけばユーザーは気づきません。よってレベル３です。
25
Page 25
復旧レベル EJB
Oracle HTTP Server
Oracle EJE＆
Oracle Database
レベル１復旧レベル レベル３レベル１
JServ
※ServletのSession機能、Stateful Session Bean、サーバー側JDBC内部ドライバを使用した場合
EJBの場合です。
EJBのStateful Session Beanはクライアントと１対１に作成するものですので、Statefulなのですが、Jservはそうではないので、通常上記のようなClient－Servlet－EJBといった構成ではServletのSession機能を使用してEJBのリファレンスを保持します。Oracle製品で統一する場合、 EJBからDBへの書き込みは、同一インスタンスのOracle8iにたいしてkprb Driver（サーバー側内部ドライバ）を使用しましょう。このドライバはOracle8iJVM上でしか動作しませんが、内部的にショートカットを行ないますので大変高速に動作します。
前のページでは見かけなかった谷折線は、マシン１台の区切りです。後述といいましたが、ここではマシンを切り離せない構成を前提にしていますのであえて記述しました。
OHSが落ちてしまった場合、これは省略します。復旧レベルは、レベル３。
JServが落ちてしまった場合、これはSession情報が消えてしまいますので、すべてやり直しとなってしまいます。前のページのJServと同じとなります。レベル１となります。実はEJBのリファレンスを取り出す為のハンドルクラスはSerializableなのでCookieに載せて毎回Clientに送るなどといった作りにしておけば、JServに巻き込まれてしまうことも無くなりますが、毎回Serializeを行なうのは処理が重いのでお勧めはできません。
DBのインスタンスが落ちてしまった場合ですが、この場合同時にOracle EJEとDBが落ちることになります。OPSでフェィルオーバーしたとしても現行のトランザクションはロールバックとなっていまいますので結局レベルは１、ユーザーは作業のやり直しになってしまいます。
26
Page 26
マシンへの配置 mod_plsql
ClientNetworkLoadbalancer
OracleHTTPServer
Oracle Database
アーキテクチャと復旧に関しての話をしましたので、コンポーネントのマシンへの配置を考えてみます。
mod_plsqlは、Statelessですので、OHSと共にマシンに分散したほうが可用性が高まります。ここでは障害検知機能をもつNLBを用意すれば、OHS、もしくはそのマシンが落ちたとしても、それを検知して生きているノードへ割り振ってくれるはずです。
DBは、Oracle parallel serverを使用して、障害時には自動的にフェィルオーバーするように設定することをお勧めします。
27
Page 27
マシンへの配置 JServ
ClientNetworkLoadbalancer
OracleHTTPServer
JServOracle Database
JServです。
OHSとJServ（ApacheJServ）は、マシンを別にして分散することも可能ですが、よほどアプリケーションの処理が重いものでなければ、分散する必要はないと思われます。（※ApacheJServだけを別マシンに分散したとしてもOracle9iASのライセンスを購入しなければなりません。）
マシン構成としてはMiddleTireマシンにOHSとJServ（ApacheJServ）プロセスを立ち上げることをお勧めします。
Oracle9iASの「パフォーマンスチューニングガイド」によるとJServ（ApacheJServ）プロセスはCPU１つにつき２つ程度起動することをお勧めするとの記述があります。ここでは1CPUのマシンとして、２つのJServプロセスを起動します。
JServ－Oracle8i間はJDBC Driverを使用します。
Oracle8iはOPS構成として障害に備えます。
28
Page 28
マシンへの配置 EJB
OracleHTTPServer
Oracle EJE＆
Oracle DatabaseJServ
EJBです。
OHSに関しては同じで、NLBで分散させます。
JServは前のページで説明した通り、OHSと同一マシンで２つ起動します。
EJB（OracleJVM）ですが、Oracle8iDatabaseインスタンスと同一インスタンスで動作させることをお勧めします。 kprb Driver（サーバー側内部ドライバ）を使用する為です。図では四角を重ねて表示しています。DatabaseインスタンスとＥＪＢコンテナが同一インスタンスで動作することになりますので、よりいっそうこのインスタンスは重要となりますので、OPS構成にして障害に備えることをお勧めします。
29
Page 29
ネットワーク配置例
Fire wall
外部ネットワーク
境界ネットワーク
内部ネットワーク
HTTP
リダイレクト
Oracle HTTP Server(mod_plsql,Jserv,mod_ose)
Oracle8iOracle EJE
Proxy ServerOracle Web Cache
Fire wall
では、ここまでのマシンへの各コンポーネントの配置を考慮して、ネットワーク構成の例を挙げた図がこのページです。
外部ネットワークとの間には、当然ＦｉｒｅＷａｌｌを配置します。この境界ネットワークには通常Proxy Serverを配置し、直接内部ネットワーク内にあるHTTP Serverへはアクセスさせないように構成します。ここで初めて出てきたOracle Web Cache（以降、「OWC」）は、このセッションの一番 後で説明します。OWCは、HTTP Serverの前に配置し、コンテンツをキャッシュします。
境界ネットワークと内部ネットワークの間にもＦｉｒｅＷａｌｌを配置します。このＦｉｒｅＷａｌｌでは、上記Proxy ServerからのOHSへのアクセスのみ許可するように設定し、その他の外からのアクセスは拒否するように設定します。
ＯＨＳとDatabaseはイントラネット内に配置しますので安全です。ＯＨＳは、複数台配置し、障害に備えます。
DatabaseはＯＰＳ構成とし、障害に備えます。
30
Page 30
ネットワーク配置例
Fire wall
外部ネットワーク
境界ネットワーク
内部ネットワーク
Oracle EJE Oracle8i
Oracle HTTP Server(mod_plsql,Jserv,mod_ose)
Oracle8i（画面表示用）
DB LINK等に
よるデータ参照
mod_plsql
mod_ose
Fire wall
もうひとつの配置例です。
この場合には境界ネットワークに画面表示用のOracle Databaseを置いています。mod_plsqlを使用している場合に、境界ネットワークから直接のDatabase参照を行わないようにするためです。
mod_oseを使用する場合には、内部ネットワーク内にOSE（OracleJVM）およびDatabaseインスタンスを起動したマシンを配置します。よって、Firewallは、OSEの通信のみを通すように設定します。
31
Page 31
Oracle9iASの必要リソースの見積もり
32
Page 32
同時接続数とOracle9iASプロセス mod_plsql
Oracle HTTP Server
子プロセス
子プロセス
１リクエスト 子プロセスHTTP
Net8mod_plsql
mod_plsql
mod_plsql
親プロセス
同時接続数＝子プロセス数
mod_plsqlを使用している場合の、同時接続数とOracle9iASのプロセス数との相関関係についてです。
既に何度も説明に挙がっているように、１リクエストにつき１つの子プロセスが処理を行います。よって、同時接続数分の子プロセスが起動することになります。MaxClientsディレクティブによって起動する子プロセス数を制限することができますが、 MaxClientsに達するまでは、
同時接続数＝子プロセス数
となります。
33
Page 33
DB接続数の見積もり mod_plsql
Oracle HTTP Server
子プロセス
子プロセス
１リクエスト 子プロセスHTTP
Net8mod_plsql
mod_plsql
mod_plsql
親プロセス
同時接続数＝同時ＤＢ接続数
mod_plsqlを使用している場合のDatabase接続数の関係についてです。
子プロセス毎にDatabaseへの接続を行います。１リクエストにつき１つの子プロセスが処理を行いますので、Database接続数は、同時接続数分の子プロセス数と同じになります。。MaxClientsディレクティブによって起動する子プロセス数を制限することができますが、 MaxClientsに達するまでは、
同時接続数＝子プロセス数＝Database接続数
となります。
もし、init<SID>.oraのprocessesパラメータの値が十分でないと接続エラーとなってしまいますので注意してください。
34
Page 34
DB接続数の見積もり mod_plsql
Oracle HTTP Server
子プロセス Net8
子プロセスmod_plsql
mod_plsql
親プロセス
子プロセス起動時
mod_plsqlへの初回アクセス時
Database接続の張られるタイミングについてです。
これは、その子プロセスのmod_plsqlにはじめてアクセスがあったときにDatabase接続が張られることになります。その他のモジュール、例えばJServなどを使用していた場合、JServが呼ばれたときにはmod_plsqlは接続を行いません。あくまでmod_plsqlが 初に呼ばれたときにDatabase接続が張られます。
35
Page 35
DB接続数の見積もり mod_plsql
Oracle HTTP Server
子プロセス Net8mod_plsql
mod_plsqlへの２回目以降のアクセス(Enable Connection Pooling? Yes)
子プロセス Net8mod_plsql
mod_plsqlへの２回目以降のアクセス(Enable Connection Pooling? No)
２回目以降のアクセスがあったときです。
これはＤＡＤの設定によって動作が異なってきます。
ＤＡＤの設定のEnableConnection Poolingの項をYesにしていた場合、１回目の接続で張られたDatabase接続がプールされているので、２回目以降のアクセスでは、Database接続はそれを使いまわすのみで、新しくDatabase接続を張るようなことはしません。
対してEnableConnection Poolingの項をNoにした場合には、毎回新規にDatabase接続を張ってからPL/SQL Procedureを実行します。パフォーマンスが悪くなりますのでお勧めしません。
36
Page 36
DB接続数の見積もり mod_plsql
Oracle HTTP Server
子プロセス Net8mod_plsql
mod_plsqlへの２回目以降のアクセス(Enable Connection Pooling? Yes)
子プロセス Net8mod_plsql
mod_plsqlへの２回目以降のアクセス(Enable Connection Pooling? No)
DADが複数設定されている場合
では、ＤＡＤに複数のエントリがある場合です。
EnableConnectionPoolingがNoの場合を先に説明します。この設定の場合、DADが複数あろうが関係なく、毎回新規Database接続を行い、PL/SQLを実行後Database接続を閉じます。
EnableConnectionPoolingがYesの場合で、DADが複数ある場合です。これは各DAD毎に接続が保持されます。その子プロセスでそのDADを初めて使用する時にDatabase接続が張られ、以降はその接続は保持されます。ですので、２つ以上のDADを設定して、使用する場合
同時接続数＊２＝ 大Database接続数
になります。
37
Page 37
メモリー見積もり mod_plsql
最低必要メモリ＝同時接続数＊子プロセスのプライベートな消費メモリ＋共有ライブラリ（主にmodule）＋親プロセス
マシン構成 Oracle HTTP Server Oracle Database
mod_plsqlを使用した場合のメモリ使用量の概算について説明します。
OHSでmod_plsql使用時に見込まれるメモリ消費は、OHSの親プロセス＝１個＋同時接続数分の子プロセス分となります。OHSでは、多くの部分を共有ライブラリ化していますので、１個の子プロセスが必要とするメモリ消費はそれほど大きくありません。
ここでは、私が実測した時のメモリ使用量をお教えします。あくまで例ですので作成のシステムでの測定をお勧めします。
Solaris版のOracle9iASのmod_plsqlでHelloと表示するだけのページに対して同時１００アクセスを行っていたときの消費量です。psコマンドで仮想メモリ使用量を見ると子プロセスは１つにつき約１２Mbyteのメモリを使用しています。しかし、これには共有ライブラリ等、プロセス間で共有される部分を含んでいます。Solarisにはpmapという現在メモリ上にあるプロセス内のメモリマップを見るコマンドがありますので、これを用いて、子プロセスのPrivateなメモリを測定してみたところ実メモリ上に載っている子プロセスのメモリ消費は
Resident合計 NonMap Shard Private８Mbyte ４Mbyte ５Mbyte ３Mbyteシステムで必要な実メモリ合計は
子プロセス数＊3MByte + 5MByte（Shared分）＋3MByte(親プロセス分）
マップされていない部分のPrivateとSharedを１：１とすると
システムで必要な仮想メモリ合計は
子プロセス数＊5MByte + 7.5MByte（Shared分）＋5MByte(親プロセス分）
38
Page 38
メモリー見積もり mod_plsql
最低必要メモリ＝DB同時接続数＊専用サーバー＋SGA,PMON,SMON……
マシン構成 Oracle HTTP Server Oracle Database
さて、mod_plsqlを使用している場合のDBマシン側のメモリ消費量です。
こちらのほうは、Databaseの資料や本が既にたくさんありますのであまり詳しくは触れません。
以下は、あくまで私が測定した例です。
接続を専用サーバー接続とした場合には、Database接続数の専用サーバープロセスが起動しますので、その分、＋Databaseのインスタンスを起動した場合に立ち上がっている必須のプロセス群、PMON、SMON…などです。結局のところ、専用サーバーもPMONなども同じ実行イメージOracleでした。
予想される実メモリ（Mbyte）＝10＊専用サーバー数＋50（インスタンス分）＋１３（Shared分）＋SGASGAが１Gbyteなどと取りますので、専用サーバーの使用部分は、微々たるものとなります。接続数が大きくなる場合にはカウントする必要があるでしょう。
pmapで見れないマップされていない部分のPrivateとSharedを１：１とすると
予想される仮想メモリ使用量（Mbyte）＝14＊専用サーバー数+ ７０（インスタンス分）＋1７（Shared分） + SGA
mod_plsqlの説明はここで終わりです。
39
Page 39
同時接続数とOracle9iASプロセス JServ
Oracle HTTP Server
子プロセスmod_jserv
親プロセス
JServ
ApacheJServApacheJServ
JavaVMJavaVM
ApacheJServApacheJServ
JavaVMJavaVM
AJPServletServlet子プロセス
mod_jserv
スコアボードスコアボード
JServの見積もりのについて
JServのプロセス構成について既に説明していますので、ざっとおさらいです。実は、このPPTでは勤めて図の形と意味を統一しています。一部例外もありますが角の丸い四角はプロセスを表しています。角のとがっている普通の四角は概念的な一塊を表しています。実際にこの四角は目に見える形では存在しません。
話を元に戻します。
ここでは、JServを手動起動でロードバランスを行っているという構成で話を進めます。この場合には、OHSの親プロセス、JServ監視用子プロセス（Watchdog）、実際の処理をハンドリングする子プロセス～これは同時接続分起動～、手動起動したApacheJServプロセス（ここでは２つ）となります。
40
Page 40
メモリー見積もり JServ
Oracle HTTP ServerJServ
最低必要メモリ＝同時接続数＊子プロセスのプライベートな消費メモリ＋共有ライブラリ（主にmodule）＋親プロセス＋子プロセス（Watchdog）＋JavaVMプロセス（ApacheJServ）＊２
Oracle Database
既にマシン構成のところで説明した構成をとっていると仮定しています。
この場合MidTireのマシンにはOHSおよびApacheJServプロセスが存在しています。ですのでメモリ使用量は（上の箇条書きを読む）
ここで、ちょっとした小技ですが、JServを使用するが、mod_plsqlを使用しない場合にはmod_plsqlの設定をOHSからはずすとメモリ消費を押さえることができます。これから挙げる例は、OHSの設定からmod_plsqlの設定をはずしてあります。
これは私が測定したあくまで参考です。Helloを表示する簡単なServletを１００同時接続中のメモリ消費です。
測定したところOHSの親、子、子（Watchdog）の差はほとんどなく、
Resident合計 NonMap Shard Private５Mbyte ほぼ０ ３MByte ２MbyteApacheJServプロセスのメモリ消費量は
Resident合計 NonMap Shard Private１１Mbyte ほぼ０ ２，５Mbyte ９Mbyte
予想される実メモリ使用量（Mbyte)＝子プロセス数＊2 + 5（Shared分）＋2 (親プロセス分）
＋２．５（ApacheJServ Shared）＋９＊２（ApacheJServ Private）Residentと仮想メモリとの差があまりないので同様です。
ただし、このApacheJServのPrivateメモリに関しては作成したServletに依存して大きく変わりますのでシステム毎の測定が必ず必要になると思われます。
41
Page 41
メモリー見積もり JServ
最低必要メモリ＝DB同時接続数＊専用サーバー＋ SGA,PMON,SMON……
Oracle HTTP ServerJServ Oracle Database
Database接続を行っていた場合のDatabaseサーバー側のメモリ消費についてです。
ここも一般的なOracleDBのメモリ見積もりに準じますのであまり詳しくは触れません。既にmod_plsqlのところで触れたものと同じです。
今回測定した例です。
予想される実メモリ（Mbyte）＝10＊専用サーバー数＋50（インスタンス分）＋１３（Shared分）＋SGASGAが１Gbyteなどと取りますので、専用サーバーの使用部分は、微々たるものとなります。接続数が大きくなる場合にはカウントする必要があるでしょう。
pmapで見れないマップされていない部分のPrivateとSharedを１：１とすると
予想される仮想メモリ使用量（Mbyte）＝14＊専用サーバー数+ ７０（インスタンス分）＋１７（Shared分） + SGA
JServの説明はここで終わりです。
42
Page 42
メモリー見積もりEJB
SGA
共有プール共有プールDatabaseバッファキャッシュ
REDOログ・バッファ
要求キュー 応答キューリスナー
ディスパッチャディスパッチャ
Oracle EJE
共有共有サーバーサーバー
EJBのメモリ見積もりについてです。
EJBを使用する場合のプロセス構成について考えます。
存在するプロセスは、
リスナー、ディスパッチャ、共有サーバー（プロセスではありませんがSGA）となります。既に説明したようにOracleDatabaseのMTS構成のアークテクチャを使用していますので、MTSの見積もりと同じとなります。
43
Page 43
メモリー見積もり EJB
最低必要メモリ＝リスナー＋ディスパッチャ＊起動数＋共有サーバー＊起動数＋SGA,PMON,SMON……
Oracle HTTP ServerJServ
Oracle JVMOracle8i
マシン構成例のところで出た図の一部を持ってきました。
画面表示系はServletで作成するシステムを例としています。ここではServletEngineはJServを使用した場合を挙げています。この場合のMidTierの見積もりについては既にJServの説明で行っているので割愛します。
では、OracleJVMおよびOracle8iのマシンのメモリ消費の見積もりです。マシン構成のところでも触れましたが、kprb Driver（サーバー側内部JDBCドライバ）を使用できるようにするためにOracleJVMとOracle8iのインスタンスは同一インスタンスとすることをお勧めします。この場合、メモリの見積もりは単なるMTS構成Databaseと同じになります。ただし、SGA領域にOracleJVMの分も取ることになりますので、その分普通のMTS構成にプラスでSGAをとってください。SGA内にOracleJVMの領域をどれだけ取るかといった設定は、init.oraのlarge_pool_sizeとjava_pool_sizeになります。詳しくはマニュアルを参照してください。
実際のところですが、予想される実メモリ(Mbyte)＝10＊（ディスパッチャ数＋共有サーバー数）＋50（インスタンス分）＋１３（Shared分）＋SGASGAが１Gbyteなどと取りますので、ディスパッチャや共有サーバー分は、微々たるものとなります。接続数が大きくなる場合にはカウントする必要があるでしょう。ディスパッチャ数と共有サーバー数は、init.oraのmts_dispatchersとmts_servers mts_maxserversで設定できますのでマシンのスペックにあわせて設定してください。先ほどと同様に予想される仮想メモリ使用量（Mbyte）＝14 ＊（ディスパッチャ数＋共有サーバー数） + ７０（インスタンス分）＋１７（Shared分） + SGA
44
Page 44
パフォーマンスチューニング
45
Page 45
ｔｃｐの設定
Solaris版– $ORACLE_HOME/Apache/Apache/bin/tcpset.sh
このスクリプトはSolarisのtcp設定を変更します
特にtcp_slow_start_initialは２にする。（デフォルトは１
）上記のスクリプトを実行すれば２に設定されます。クライアントのOSがWindows系の場合に圧倒的にパフ
ォーマンスが良くなります
iASのマニュアルの「パフォーマンスチューニングガイド」に詳しい理由も記述されています。
46
Page 46
OHS設定のチューニング
UNIX– StartServers 初期起動プロセス数
– MinSpareServers 最小待機プロセス数
– MaxSpareServers 最大待機プロセス数
– MaxClients 最大プロセス数
– MaxRequestsPerChild プロセス毎の
WindowsNT – ThreadsPerChild 最大同時処理数
最大リクエスト処理数
StartServers：OHSを起動したときに起動される子プロセス数を設定します。予想される同時接続数を設定すると良いでしょう。
MinSpareServers：待機中の子プロセス数の 小値を設定します。通常はデフォルト値で問題ありません。この設定は急激なアクセス数の増加に対する設定です。
MaxSpareServers：待機中の子プロセス数の 大値を設定します。予想される同時接続数を設定することをお勧めします。
MaxClients：起動する子プロセス数の 大値を設定します。マシンリソースが限られている場合には、マシンがダウンしないように、子プロセス数を制限することができます。
MaxRequestPerChild：各子プロセス毎にリクエストを処理した回数をカウントし、この値に設定されている回数に達すると、その子プロセスは終了します。自分で作成したモジュールやCGIが不安定な場合に、この設定を行うと子プロセスが定期的に終了するのでメモリリーク等が起きていてもどうにか運用が可能となります。
ThreadsPerChild： 大同時処理数を設定します。
47
Page 47
Cacheサービスの適用
48
Page 48
Cache
Client Application Server Database Server
Oracle9iAS Database CacheOracle9iAS Database CacheOracle9iAS Web CacheOracle9iAS Web Cache
Oracle9iASからCacheサービスがリリースされていきます。提供されるCacheサービスは２つ、Oracle Web CacheとOracle Database Cacheです。
Oracle Web Cacheは、ClientとApplication Serverの間に配置します。ClientからアクセスされるWebコンテンツをCacheすることにより、ユーザーへの応答時間を短縮します。
Oracle Database Cacheは、Application ServerとData Serverの間、正確にはApplication Serverと同じマシンに配置して、DataをCacheし、データの検索時間を短縮します。また、これによりData Serverの負荷をMiddleTireへ移動させることが可能となります。
49
Page 49
Oracle9iAS Database Cache
Origin Database
Middle tire
JServ
Oracle HTTP Server
HTTP
ServletServlet
JDBC OCI8
更新
自動同期
Oracle9iAS Database CacheOracle9iAS Database Cache
キャッシュヒットキャッシュヒットキャッシュヒットキャッシュヒット
ここではJServから、Oracle Database Cacheを利用する場合を例として挙げています。Table単位でのCachingOracle Database Cacheは、Table単位でCacheを行います。
透過的なRoutingServletからDatabaseへの検索は、自動的にOracle Database CacheへルーティングされMiddle tire内で検索が行われます。ServletからのDatabaseへの更新、挿入は自動的にOrigin databaseへルーティングされます。このようにアプリケーション側ではOracle Database Cacheを意識したコーディングの必要なしに使用することが可能です。調整可能なData同期機能
CacheされているDataとOrigin databaseとの同期は、GUIによって設定可能です。
50
Page 50
Oracle9iAS Database Cache
導入した場合の効果– Data setsが中間層に配置され、検索が行われるため
検索が速く、ネットワークのオーバーヘッドが少なくなる
– 中間層のCache dataで(最も実行される)SQLリクエストを処理し、バックエンドのDatabaseに対する負荷を
減少させる。
更に多くのユーザーをサポート可能
スケーラビリティの向上が可能
51
Page 51
Oracle9iAS Database Cache
特徴– 現在使用しているApache JServ or OCI アプリケーシ
ョンのコード変更が不要
– パフォーマンスを改善するのにお客様は存在するアプリケーションにてこ入れして、プログラミングの調査を行えばよい
– エンドユーザーは（レスポンスタイムが改善したことを除いて）Cacheの存在に気づかない
52
Page 52
Oracle9iAS Database Cacheターゲットアプリケーション
– ネットワーク越しにOracle DBにアクセスするAP– 巨大な読み取り専用動的コンテンツが存在するAP – Dataが中間層に存在していることにより効果が得ら
れそうな大量に実行されるSQLが存在するAP– 変化が少なく関連が無いTable群が存在するAP
例:– e-Business Applications
– オンラインショッピング、オンラインサポート 、オーダー トラッキングなど
– CRM/ERP Applications– Vertical Applications
53
Page 53
Oracle9iAS Web CacheOracle HTTP Server
Oracle HTTP Server
コンテンツをキャッシュ
リクエストの内容に応じて
判断
Cacheの無効化
Oracle Web CacheOracle Web Cache
Oracle Web CacheはClientとApplication Server（Oracle HTTP Server）との間に配置し、WebコンテンツをCacheすることにより、Clientへの応答時間を大幅に短縮します。
Cacheを行うか否か、いつ破棄すべきかどうを設定することが可能です。
Cacheを行うかの判断は
・URLの正規表現による選別
・Cookieによる選別
・Oracle Web Cache専用タグによる選別
・HTTPヘッダによる選別
が可能です。
Cacheの破棄に関しては
・時間
・Invalidation messageの受信
による破棄が可能です。とくにInvalidation messageの受信による方法は、Oracle databaseとの親密な連携が可能となります。Database内のデータ更新にともないトリガーからInvalidation messageを送信することにより、Oracle Web Cache内のCacheとの整合性を常に保つことが可能となります。
54
Page 54
まとめ
アーキテクチャを考慮した上でマシンへの配置– EJBからのDatabaseへのアクセスはサーバー側
JDBC内部ドライバを推奨
No single point of failureな冗長構成
– アプリケーションの復旧レベルに一考を
このセッションの前半を大きく使ってゆっくり説明しましたのでOracle9iASのアーキテクチャについて理解していただけたと思います。実際のシステムでのマシン構成と配置では、アーキテクチャを考慮した上での構成と配置をお勧めしたます。とくにEJBやOSEを使用する場合にはサーバー側JDBC内部ドライバを使用するために同一インスタンスでの構成を推奨します。
復旧レベルの説明のところで、マシンのダウンとアプリケーションの復旧レベルについて説明しました。作成するシステムの要件に応じて、どの程度の復旧レベルが求められるのか？そのための作りこみの必要性について考慮していだたければと思います。
55
Page 55
日本オラクル株式会社
無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。
Oracleは、オラクル社の登録商標です。Oracle8、Oracle8i、Net8は、オラクル社の商標または登録商標です。
他のすべての企業名と製品名は、識別のためにのみ掲載されており、それぞれの所有者の商標の場合があります。
