この記事の位置づけ
WebLogicの解説は「ドメインを作り、AdminServerを起動し…」から始まるものがほとんどです。しかしその手前に、なぜこんな構造の製品が存在するのかという説明がないため、初学者はすべてを丸暗記することになります。
前編では理由だけを扱います。手順は一切出てきません。
- 対象読者: Linuxサーバをひととおり構築できる。Java・Tomcat・アプリケーションサーバの経験はない。これからWebLogicの構築に関わる。
- 前編のゴール: 「アプリケーションサーバとは何を解くために生まれた層か」を説明できる。とくにDB連携について、なぜAPサーバが要るのかを自分の言葉で言える。
- 後編: ドメイン構成、起動停止、デプロイ、ログ、監視、ライセンス、構築時の決定項目。
Javaプログラミングの知識は不要です。出てきません。
1. なぜ「真ん中の層」が生まれたのか
システムの形は、大きく三段階で変わってきました。
① メインフレーム（〜1980年代）
処理も業務ロジックもデータも、すべて中央の大型機の中。手元の端末は画面を表示するだけ。堅牢ですが、高価で柔軟性に欠けました。
② クライアント/サーバ（1990年代前半）
PCの性能が上がり、業務アプリを各PCにインストールする形が流行します。サーバにはDBを置き、PCから直接つなぐ。一見合理的ですが、規模が大きくなると破綻しました。
| 起きたこと | 内容 |
|---|---|
| 配布地獄 | 修正のたびに数百台のPCへアプリを配り直す |
| DB接続の枯渇 | 全PCがDBに直接つなぐ。1000人なら1000接続。DBが先に音を上げる |
| ロジックの散逸 | 業務ルールが各PCの中に散らばり、統制できない |
| セキュリティ | クライアントがDBの接続情報を持ってしまう |
③ 3層アーキテクチャ（1990年代後半〜）
そこで、業務ロジックを真ん中のサーバに集約し、クライアント側はブラウザだけにする形が採用されます。配布は不要になり、DB接続は真ん中の層がまとめて管理できる。
この「真ん中の層」がアプリケーションサーバです。 そして真ん中に置いた瞬間、そこには宿題が押し寄せました。
- 大量の同時アクセスを受け止める（多重処理）
- DB接続を集約し、使い回す（接続プール）
- 複数のDBやシステムにまたがる更新の整合をとる（トランザクション）
- 誰がアクセスしてよいかを判定する（認証・認可）
- 業務ロジックを止めずに入れ替える（デプロイ）
- 24時間動き続け、落ちない
WebLogicの機能一覧は、この6つの宿題とほぼ一致します。 以降に出てくる用語は、すべてこのどれかへの回答だと思って読んでください。太字にした2と3は第5章で深掘りします。
2. なぜJavaだったのか
真ん中の層に求められる性質は厳しいものでした。常時稼働し、多重処理をこなし、落ちない。
当時の選択肢と事情はこうです。
| 選択肢 | 事情 |
|---|---|
| C / C++ で自作 | 速いが、メモリ管理を人間が正しく書き続ける必要がある。リークや不正アクセスを自力で防ぐ負担が大きく、長期稼働サーバでは開発・運用コストが跳ね上がる |
| CORBA / TPモニタ | 分散処理の本命だったが、高価で難解。扱える技術者が限られた |
| Microsoft の COM+ / DCOM | Windows専用。当時の企業システムの主力はUNIXであり、選べない現場が多かった |
| Java | 中庸として勝った |
Javaが持っていたものを、インフラの言葉に翻訳します。
- メモリ管理の自動化（GC）: 長時間動かしても、人為的なメモリ管理ミスで落ちにくい
- スレッドとネットワークが言語標準: 多重処理と通信を、標準の部品で書ける
- OS非依存: 当時はUNIXベンダが乱立していた。ハードを乗り換えても資産が残る
- ベンダ中立の仕様: 1社の製品に縛られない。金融・公共がこれを重視した
つまりJavaは、「速さ」ではなく「壊れにくさと、乗り換えられること」で選ばれた技術です。そしてこの選択は当たりました。1990年代に書かれた業務ロジックが、ハードウェアを何度も更改しながら今日も動いています。
あなたがこれからWebLogicを学ぶ理由は、この30年前の判断の帰結です。
3. Tomcatはどこから来たのか ― 順番を確認する
| 年 | 出来事 |
|---|---|
| 1995 | WebLogic, Inc. 設立 |
| 1997 | WebLogic Tengah 出荷 |
| 1998 | BEA Systems が WebLogic, Inc. を買収（BEAはTPモニタ製品Tuxedoの会社） |
| 1999 | Tomcat 登場（Servlet/JSP仕様のリファレンス実装として） |
| 1999(12月) | J2EE 1.2 仕様が公開 |
| 2008 | Oracle が BEA Systems を買収 |
| 2020 / 2024 | WebLogic Server 14.1.1 / 14.1.2 |
WebLogicが先です。しかも、Java EEという仕様そのものより先です。
Tengahはサーブレット処理、JNDIによる名前解決、コネクションプール、分散RMIをすでに備えており、後から策定されたJ2EE仕様が、それらを標準として追認していきました。
**WebLogicは「仕様書を読んで作られた実装」ではなく、「現場の問題を先に解いた製品が、後から仕様に格上げされたもの」です。**だから仕様書を読んでも構造の理由は書いていません。
一方Tomcatは1999年、Servlet/JSP仕様のリファレンス実装 として登場しました。目的は「仕様どおりに動くことを示す」ことです。したがってWeb層だけを担当し、群れを管理する機能や、分散トランザクションを最初から持っていません。
これは機能不足ではなく、解こうとした問題が違うということです。単一のプロセスとして正しく速く動くことに集中した結果、軽く、学びやすいものになりました。
両者の関係は「高級品と廉価版」ではなく、「艦隊の管制システム」と「一隻の船」 です。
| 観点 | Tomcat | WebLogic |
|---|---|---|
| 登場 | 1999年、仕様のリファレンス実装として | 1997年、J2EE仕様より前に、現場の要求から |
| 中心思想（＝出自。現在の機能の有無ではない） | 1プロセスとして正しく動くこと | 多数のプロセスを一元管理すること |
| 管理の単位 | 1プロセス＝1サーバ | ドメイン（複数プロセスを集中管理） |
| 設定 | 各サーバの server.xml を個別に編集 |
AdminServerが持つ config.xml に集約 |
| デプロイ |
webapps に配置 |
ターゲットを指定して配布 |
| トランザクション | 基本は単一DB | 分散トランザクション（JTA/2PC）に対応 |
| DB連携 | 接続プールは持つ | 接続プール＋RAC連携、Application Continuity など |
| ライセンス | Apache License（無償） | 商用。エディションで機能が変わる |
優劣の表ではありません。これは出自と中心思想の違いであって、機能の有無の話ではありません。現在のTomcatにもクラスタリング、セッションレプリケーション、JNDI、JDBCデータソース、JMXは備わっています。単一DBのWebアプリならTomcatの方が軽く、ライセンスコストも抑えられる。複数システム横断の整合、無停止性、サポート責任が要件に入るとWebLogicが選ばれる、という関係です。
4. なぜ「素のJava」ではなくAPサーバなのか
「Javaで動くならJavaだけでいいのでは」という疑問への回答です。第1章の宿題を、Java標準の機能だけで解こうとするとどうなるかを並べます。
| 宿題 | Java SE だけだと | APサーバが用意しているもの |
|---|---|---|
| DB接続 | 毎回接続を確立し、性能が出ない | コネクションプール（貸出・返却・死活確認） |
| 接続先やパスワード | アプリのコードに書き込まれる | データソース＋JNDI（設定は運用側が持つ） |
| 複数DB・複数システム横断の更新 | アプリが独自に整合を作り込む | 分散トランザクション（JTA / 2フェーズコミット） |
| 同時実行の制御 | 自前でスレッドプールを実装 | Work Manager（負荷に応じた自己調整） |
| 認証・認可 | アプリごとにばらばらに実装 | セキュリティレルム |
| アプリの入れ替え | プロセスを止めて差し替え | 無停止デプロイ、ターゲット指定 |
| 稼働状況の把握 | ログや計測を自作するか、別の仕組みを組み合わせる | MBeanによる指標公開（後編で扱います） |
誤解しないでほしいのは、Java SEでこれらが「できない」わけではない ということです。できます。ただし誰かが自分で作らなければならない。 別のライブラリやフレームワークを組み合わせる手もあります。要点は一つです。
APサーバの機能は「アプリ開発者に書かせないための共通部品」であり、同時に「運用側が制御できる場所に、その部品を置く」ための仕組みでもある。
だから設定項目が膨大なのです。そしてだからこそ、インフラエンジニアが接続プールやスレッドの話を避けて通れません。 プールの上限値を決めるのは、アプリ開発者ではなく構築担当だからです。
5. データベース連携 ― APサーバの存在意義が最も濃い場所
ここが前編の核心です。APサーバの存在意義が最も具体的な形で現れるのがDB連携です。
5.1 接続は、想像よりはるかに高価である
アプリがDBに接続するとき、裏では次が起きています。
- TCPコネクションの確立
- 認証（ユーザ／パスワードの検証）
- DB側でのセッション等の接続リソースの確保
- （切断時）その後始末
環境によっては数ミリ秒で終わりますが、重要なのは絶対時間ではなく相対コストです。1回のSQL実行に比べて、接続の確立は固定的なコストが乗ります。それをリクエストごとに繰り返すのは無駄が大きい。しかもDB側は接続数の上限を持っており、同時接続が増えれば先にDBが倒れます。
だから、あらかじめ接続を張っておいて、貸して返させる。これが接続プールです。第1章の「クライアント/サーバの破綻」で挙げたDB接続の枯渇は、この仕組みで解決されました。
5.2 データソースとJNDI ― 設定を運用側が握る
WebLogicでは、接続プールの設定一式をデータソースとして定義します。アプリはそれを JNDI名（jdbc/OrderDS のような論理名）で借りるだけです。
これが効くのは、接続先・ユーザ・パスワードがアプリの外にあるからです。
- 開発環境と本番環境で、同じアプリのファイルをそのまま使える
- パスワード変更でアプリを作り直さなくてよい
- 接続数の上限を、運用側の判断で変えられる
**構築担当が握るのはここです。**アプリ開発者の領分ではありません。
5.3 プール設計で必ず揉める4点
| 論点 | 内容 |
|---|---|
| 最大接続数 | プール上限 × サーバ台数が、DB側の上限（processes / sessions）を超えてはいけない。Managed Serverを4台に増やした瞬間にDBが溢れる、という事故はここから起きる |
| 接続の死活確認 | 借りる直前にテストするか、定期的に確認するか。DB再起動やNW断の後、壊れた接続を貸してしまう事故を防ぐ |
| 接続リーク | アプリが借りたまま返さない。じわじわ枯渇し、数日後に落ちる。検出の設定がある |
| 待ち時間 | プールが空のとき、待つのか、即エラーにするのか。業務要件で決まる |
DB担当との事前合意なしにプールサイズを決めてはいけません。 これは技術というより調整の問題です。
5.4 トランザクション ― ここからがAPサーバの本領
単一のDBだけを更新するなら、DB自身のトランザクションで足ります。問題は複数のリソースにまたがる更新です。
受注DBに1件登録し、在庫DBの数量を減らし、基幹システムにメッセージを送る。途中で失敗したら、全部なかったことにしたい。
これを実現するには、複数のリソースに「準備できたか？」と問い合わせ、全員がOKなら「確定せよ」と指示する調停者が要ります。用語が3つ出てくるので、役割を分けて覚えてください。
| 用語 | 何か |
|---|---|
| JTA | Javaでトランザクションを扱うためのAPI／仕様 |
| XA | リソース（DBやJMS）が分散トランザクションに参加するための業界標準インタフェース |
| 2PC（2フェーズコミット） | 複数の参加者のコミットを調停するプロトコル |
一文にすると、WebLogicはJTAを通じて分散トランザクションを管理し、XA対応リソースの間では2PCによって整合性を取ります。
**この調停者を自前で書くのは現実的ではありません。**障害時にどちらか片方だけ確定してしまった状態（インダウト）の復旧まで面倒を見る必要があるからです。WebLogicはこれを内蔵し、復旧用のログ（TLOG）まで管理します。
**「なぜ素のJavaでは足りないのか」への、最も実務的な回答がこれです。**逆に言えば、単一DBしか触らないシステムなら、少なくとも分散トランザクションはWebLogicを選ぶ理由になりません。（クラスタ、JMS、管理機能、既存資産、サポートといった別の理由は残ります。）
5.5 DBが落ちても止めない ― Oracle RACとの連携
ここからが「WebLogicならでは」の領域です。相手がOracle Databaseの場合、統合の深さが他と違います。
Oracle RACは、複数のDBサーバが1つのデータベースを共有する構成です。1台落ちても他が処理を続けられます。ただしAPサーバ側がそれを理解していないと、意味が半減します。 落ちたノードへの接続を掴んだまま、タイムアウトを待ってしまうからです。
WebLogicには2つの方式があります。
| 方式 | 内容 |
|---|---|
| Multi Data Source (MDS) | RACの各ノードへのデータソースを並べ、上位でまとめる古典的な方式 |
| Active GridLink (AGL) | RACクラスタを1つのデータソースとして扱う。FAN/ONS（Oracleからの通知）を受け取り、ノードの増減・障害を待たずに知る。実行時の負荷分散、高速フェイルオーバー、XAトランザクションのアフィニティに対応 |
ライセンス注意。 Active GridLink for RAC は WebLogic Suite（Enterprise Editionの全機能＋Coherence＋AGL）に含まれる機能です。Enterprise Edition契約の案件でAGL前提の設計を書くと、そこで詰みます。RAC連携が要件にある案件では、エディションの確認が設計の前提条件になります。
5.6 Application Continuity ― エラーを見せない仕組み
WebLogicとOracle DBの統合で最も特徴的な機能です。
従来、DBへの接続が切れると、進行中の処理はエラーになりました。利用者には「エラーが発生しました。もう一度実行してください」と表示され、業務側で再実行の判断を迫られます。
**Application Continuity（JDBC Replay Driver）**は、条件を満たす場合に限り、失敗した処理を新しい接続でリプレイし、接続断をアプリケーションから隠蔽できる仕組みです。DB側の計画停止（ローリングパッチ適用など）でも、業務を止めずに済ませられます。
押さえるべき制約は3つです。
- Oracle Database と Oracle JDBC ドライバの、対応するバージョンが必要（12c以降）。相手がPostgreSQLやSQL Serverなら使えません
- 再生は無条件ではない。 再生した結果が、元の実行時とまったく同じ状態を返せると判断された場合にのみ承認されます
- Active GridLinkデータソースと、通常のデータソースの両方で利用できます
これがWebLogicの「ならでは」の正体です。単体のAPサーバとしての優劣ではなく、 Oracle Databaseと縦に統合されていることが価値になっている。裏を返せば、DBがOracleでない案件では、この価値の大半は手に入りません。 選定理由としてここを挙げるなら、DB側の前提とライセンスをセットで確認してください。
6. そしてWebLogicは、あの形になった
最後に、後編への橋を架けます。
1997年の前提は、いまとほぼ逆でした。
| 項目 | 1997年ごろ | 現在 |
|---|---|---|
| サーバ機 | 非常に高価な大型UNIX機。台数を増やせない | 安価。台数で増やす |
| JVM | 32bit、扱えるヒープが小さい | 大きなヒープを1プロセスで扱える |
| 台数の増やし方 | 1台の中にJavaプロセスを何個も立てる | サーバ／コンテナを複製する |
| サーバの位置づけ | 名前のついた固定資産 | 使い捨て |
| 組織 | 開発と運用が明確に分離 | 兼務・自動化 |
ここから導かれる状況は一つです。
高価な数台のマシンの上に、多数のJavaプロセスがひしめいている。それを、開発者とは別の運用担当者が、壊さずに管理しなければならない。
真っ先に起きる事故が設定のずれです。10個のJVMのうち1つだけ接続プールの上限が違い、そのサーバを引いたリクエストだけが失敗する。原因究明は困難を極めます。
WebLogicの構造は、すべてこの問題への回答です。
| 部品 | 何の制約への回答か |
|---|---|
| ドメイン / AdminServer | 設定の正本を1箇所に置き、各プロセスへ配る。個別に編集させない |
| Node Manager | 別マシンのプロセスを遠隔から起動・停止する。人がsshで回らずに済ませる |
| Machine | サーバが「名前のついた固定資産」だった時代の名残 |
| 本番モードの変更ロック | 複数の運用担当が同時に設定を変えて壊すのを防ぐ |
| クラスタ | サーバ同士が互いを認識し、セッションやJNDIを共有してフェイルオーバーする |
一言にすると、こうです。
WebLogicの構造は、「プロセスを増やすしかなかった時代に、増えたプロセスを人間が管理しきるための発明」である。
管理コンソールが重いのも、設定項目が膨大なのも、ここから来ています。アプリを動かす機能ではなく、群れを統治する機能が中心にあると捉えると、その多さの理由が見えてきます。中身は後編で扱います。
7. なぜ「いま」あなたが学ぶのか
正直に書きます。新しくJavaのWebアプリを作るなら、いまの主流はSpring Bootに小さなTomcatを内蔵させて単体で起動する形です。わざわざ商用APサーバを買って載せる理由は、新規開発ではほとんどありません。
それでも学ぶ理由は3つです。
- 既に大量に動いている。 第1章と第2章で見た経緯で選ばれ、構築された基幹システムが、金融・公共・製造に数え切れないほど残っています。それらは今日も止められず、更改もパッチ適用も誰かがやらねばならない。歴史の話をしてきましたが、その歴史の成果物の保守が、そのまま仕事になっています。
- 扱える人が減っている。 新しく学ぶ人がいないため、需要と供給が逆転しています。技術としての新しさと、市場での希少性は別物です。
- APサーバの「重い側」を知ると、軽い側の理解が深まる。 第1章に挙げた6つの宿題は、Spring Bootでも消えたわけではなく、内側に隠れているだけです。WebLogicではそれが全部、設定項目として表に出ています。仕組みを学ぶ教材としては、むしろ優れています。
「枯れた技術を仕方なく学ぶ」ではなく、「他人が降りた場所に立つ」 と捉えてください。
前編のまとめ
- アプリケーションサーバは、クライアント/サーバの破綻を解くために発明された「真ん中の層」 である
- その層には6つの宿題があり、WebLogicの機能一覧はそれとほぼ一致する
- Javaは速さではなく、壊れにくさと乗り換えられることで選ばれた
- Tomcatは仕様のリファレンス実装、WebLogicは仕様より前に現場の問題を解いた製品。解いた問題が違う
- 素のJavaでは足りないものの代表がDB連携。接続プール、データソース、分散トランザクション
- WebLogicならではの部分は、Oracle DBとの縦の統合（Active GridLink、Application Continuity）。ただしライセンスとDB側の前提とセット
後編では、この理由から生まれた構造（ドメイン、クラスタ、Node Manager）と、実際の運用（起動停止、デプロイ、ログ、監視、ライセンス）を扱います。
用語ミニ辞典（前編）
- 3層アーキテクチャ: クライアント／アプリケーションサーバ／DBの3層構成
- コネクションプール: あらかじめ確立したDB接続を貸し借りする仕組み
- データソース: WebLogic上での接続プールの設定単位
- JNDI: リソースを論理名で引くための仕組み
- JTA: Javaでトランザクションを扱うためのAPI／仕様
- 2PC: 複数の参加者のコミットを調停するプロトコル（全部成功か、全部取消）
- XA: 分散トランザクションのための業界標準インタフェース
- Oracle RAC: 複数サーバで1つのDBを共有するOracleのクラスタ構成
- Active GridLink (AGL): RACクラスタを1データソースとして扱うWebLogicの機能（WebLogic Suite）
- FAN / ONS: Oracle DB側からノードの状態変化を通知する仕組み
- Application Continuity: 接続断時に処理を再生し、エラーを見せない仕組み
以上