APサーバ構築 5（Webアプリ・デプロイ）

Webアプリ・デプロイ（開発環境）

デプロイ

さて、頑張って作ったDB接続確認用アプリのデプロイです。

APサーバ構築 4の最後に「次は本番環境でのデプロイと動作確認です」なんてことを書いてしまいましたが、いきなり本番環境にデプロイするのはさすがにちょっとリスキーなんで、まずは手順確認もかねてPC上の開発用WebLogicにデプロイしてみます。

startWebLogic.cmdをダブルクリックしてWeｂLogicを起動します。

startWebLogic.cmd
--------------------------------
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\base_domain\bin\startWebLogic.cmd

WebLogic Remote Consoleを立ち上げてAdmin Serverに接続、「ツリーの編集」の「アプリケーション・デプロイメント」をクリックします。

あれ、先客がいますね。一覧にConnCheckが表示されています。Eclipseがデプロイしたやつですか。

邪魔なので削除（名前の横にチェックを入れて「Delete」）します。

画面右上の「カートマーク」-「変更のコミット」で変更を確定させます。

きれいに削除したところで「新規」をクリック、以下の設定で「ConnCheck」をデプロイしなおします。

【アプリケーション・デプロイメント】

「作成」をクリックすると Conncheckの設定画面に表示がカラります。もう一度画面右上「カートマーク」-「変更のコミット」です。

DB接続確認用アプリのデプロイはこれで完了です。ただしデプロイ時に起動しない設定となっているためまだアプリは使用できません。画面左端にあるアイコンの上から3番目をクリックしてモニタリング・ツリーに移動してアプリを起動します。

画面左のツリーにある「デプロイメント」を展開して「アプリケーション管理」をクリックします。

アプリ一覧の「ConnCheck」にチェックを入れて「起動」-「すべてのリクエストを処理」でアプリを起動します。「状態」が”準備完了”から”アクティブ”に変われば完了です。

動作確認

ブラウザを立ち上げてDBAliveCheck、InstNameGetを実行します。DBAliveCheckの場合は”OK”、InstNameGetは”<日時> prdb”が返されればOKです。

DBAliveCheck
http://<PCのIPアドレス>:7001/ConnCheck/DBAliveCheck

InstNameGet
http://<PCのIPアドレス>:7001/ConnCheck/InstNameGet

Webアプリ・デプロイ（本番環境）

準備

DBサーバ

DBサーバ#1、DBサーバ#2のCRS、DBインスタンス、online_srvサービスが停止している場合は起動します。

APサーバ

APサーバ#1、APサーバ#2のAdmin Server、Managed Serverが停止している場合は起動します。

デプロイ

さて、本番環境のデプロイです。実際のシステムでは本番アプリのデプロイ、管理、リリース方法にはきちんとした手法やお作法があると思いますが、私はアプリまったくの門外漢なんでそこのところを全部すっ飛ばして、ともかく動けばOK的にやらせていただきます。

そういうこで本番環境のデプロイも開発環境のデプロイと基本的な手順は同じです。ただし本番環境のターゲットはAdmin ServerではなくManaged Serverです。

WebLogic Remote ConsoleからAPサーバ#1、APサーバ#2に接続して以下の手順でアプリのデプロイと起動を実行します。

【本番環境デプロイ手順】

動作確認

開発環境と異なり本番環境のアプリはManaged Serverをターゲットにデプロイされています。Managed Serverのリスニング・アドレスはAPネットワーク（192.168.40.0/24）にあるのでPCから直接アクセスすることができません。APサーバにログインしてアプリを実行します。

本番環境の動作確認ではラウンド・ロビン（APサーバ#1）やランタイム・ロード・バランシングの動きを把握しやすくするためブラウザ（Firefox）ではなくcurlを使用します。まずは各APサーバでDBAliveCheckとInstNameGetを1回ずつ実行してアプリが正しく動作することを確認します。

【prsap01 / 任意のユーザで実行】
-----------------------------------------------------------------------------
# DBAliveCheck動作確認
curl "http://192.168.40.51:7003/ConnCheck/DBAliveCheck"

# InstNameGet動作確認
curl "http://192.168.40.51:7003/ConnCheck/InstNameGet"

-----------------------------------------------------------------------------
【prsap02 / 任意のユーザで実行】
-----------------------------------------------------------------------------
# DBAliveCheck動作確認
curl "http://192.168.40.52:7003/ConnCheck/DBAliveCheck"

# InstNameGet動作確認
curl "http://192.168.40.52:7003/ConnCheck/InstNameGet"

【prsap01実行結果】
-----------------------------------------------------------------------------
[oracle@prsap01 ~]$ curl "http://192.168.40.51:7003/ConnCheck/DBAliveCheck"
OK
[oracle@prsap01 ~]$ curl "http://192.168.40.51:7003/ConnCheck/InstNameGet"
2025/08/13 02:01:28 prdb1
[oracle@prsap01 ~]$

-----------------------------------------------------------------------------
【prsap02実行結果】
-----------------------------------------------------------------------------
[oracle@prsap02 ~]$ curl "http://192.168.40.52:7003/ConnCheck/DBAliveCheck"
OK
[oracle@prsap02 ~]$ curl "http://192.168.40.52:7003/ConnCheck/InstNameGet"
2025/08/13 01:51:16 prdb2
[oracle@prsap02 ~]$

アプリの正常動作の確認はこれでおしまい。結果をみるとおっけーおっけーです。

しかしこれで終わりかといえばそういうわけにはいきません。このアプリを作った目的が何かといえばデータ・ソースによるリクエスト振り分けなので、アプリ正常動作の次は続けてこちらを確認します。

開発環境でInstNameGetの実行で返されるインスタンスは”prdb”だけだったのが本番環境のDBはRAC構成なので”prdb1”か”prdb2”のどちらかが返されます。これを1回ではなく連続してコールすればデータソースのラウンド・ロビンまたはランタイム・ロード・バランシングがうまく機能しているかどうかがわかります。

まず、マルチ・データソースにラウンド・ロビンを設定したAPサーバ#1でInstNameGetを連続10回コールしてみます。ラウンド・ロビンが機能していればprdb1とprdb2が交互に返されるはずです。

[oracle@prsap01 ~]$ for ((i=0;i<10;i++)) ;do curl "http://192.168.40.51:7003/ConnCheck/InstNameGet";done
2025/08/13 02:08:48 prdb2
2025/08/13 02:08:48 prdb1
2025/08/13 02:08:48 prdb2
2025/08/13 02:08:48 prdb1
2025/08/13 02:08:48 prdb2
2025/08/13 02:08:48 prdb1
2025/08/13 02:08:48 prdb2
2025/08/13 02:08:48 prdb1
2025/08/13 02:08:48 prdb2
2025/08/13 02:08:48 prdb1
[oracle@prsap01 ~]$

おっ、prdb1とprdb2がきれいに並んでまさにラウンド・ロビン。想定通りの結果です。

続けてActive Grid Linkを使用しているAPサーバ#2。こちらはランタイム・ロード・バランシング、DB側のワークロードの状況に応じたリクエスト振り分けです。

[oracle@prsap02 ~]$ for ((i=0;i<10;i++)) ;do curl "http://192.168.40.52:7003/ConnCheck/InstNameGet";done
2025/08/13 02:09:20 prdb2
2025/08/13 02:09:20 prdb1
2025/08/13 02:09:20 prdb2
2025/08/13 02:09:20 prdb1
2025/08/13 02:09:20 prdb2
2025/08/13 02:09:20 prdb2
2025/08/13 02:09:20 prdb1
2025/08/13 02:09:20 prdb1
2025/08/13 02:09:20 prdb1
2025/08/13 02:09:20 prdb2
[oracle@prsap02 ~]$

おお、交互でいないけど振り分けは行われている、なんとなくランタイム・ロード・バランシングっぽい！　

まあ、各インスタンスの負荷状況と付け合わせているわけじゃないので正確なところは確かめようがないですが、こちらも想定通りの結果といえそうです。

とりあえずアプリを作ってリクエスト投入先のDBインスタンス確認という本来の目的はこれで達成です。リクエスト投入先DBインスタンス振り分けという観点ではAPサーバ#1のマルチ・データソースもAPサーバ#2のActive Grid Linkもうまく機能しているようです。

他にもDB障害に伴う振り分け停止や接続フェイルオーバー、ダウンタイム計測などいろいろ確認しなきゃいけないことはありますが、全部やるとなかなか先に進まないので一旦置いといて、アプリも揃ったところでドメインを開発モードから本番モードに切り替えます。