| Oracle® Fusion Middleware WebLogic Server Multitenantの使用 12c (12.2.1.1.0) E77392-02 |
|
 前 |
 次 |
この章では、WebLogic Server MTを紹介し、マルチテナント環境でのその使用方法について説明します。
この章の内容は次のとおりです。
注意:
リソース・グループ、リソース・グループ・テンプレート、デプロイメント・プランのオーバーライドなどのWebLogic Server MTの新機能の多くは、WebLogic Serverの非MTバージョンである12.2.1でも使用可能です。この章では、特定の機能が非MTバージョンで使用可能になる場合について記載し、必要に応じてWebLogic Serverドキュメントおよびオンライン・ヘルプを参照します。
WebLogic Serverのマルチテナントにより、複数の組織で使用できる共有可能なインフラストラクチャが提供されます。これらの組織は、テナントとして考えることができる、独自に選択した概念的なグループです。1つのドメインが複数のテナントをサポートできるようにすることによって、WebLogic Server MTは、複数のアプリケーションを共有しようとする際によく発生する困難(アプリケーション間のランタイムの影響、セキュリティの相違、データの混在、管理の課題など)を排除しながら、密度を改善し、リソースの効率的な使用を実現します。
WebLogic Server MTにより、テナントに対する実行中のアプリケーション・インスタンスおよび関連リソースの専用WebLogic Serverドメインの管理スライスとランタイム・スライスであるドメイン・パーティション内のリソースの分離が実現します。ドメイン・パーティションによって、アプリケーション・インスタンスと関連リソースがドメイン、WebLogic Server自体、Java仮想マシン(JVM)およびオペレーティング・システムを共有できるようにすることで密度が改善されることに加えて、図1-1に示すように、テナント固有のアプリケーション・データ、構成およびランタイム・トラフィックが分離されます。
各ドメイン・パーティションには、独自のアプリケーションおよびリソースのランタイム・コピーが含まれます。WebLogic Serverによるクラス・ロードの処理方法の変更により、アプリケーションの分離と効率性の両方が実現します。マルチテナント環境にデプロイする場合は、アプリケーションを変更する必要はありません。たとえば、アプリケーションを変更せずに、異なるドメイン・パーティションにある給与計算アプリケーションの複数のインスタンスを実行できます。
WebLogic Server MTでは、ロード・バランサから中間層、キャッシュ層およびデータベース層までのマルチテンシを含む、エンドツーエンドのマルチテナント・インフラストラクチャが実現されます。WebLogic Server MTでは、Oracle WebLogic Server Enterprise EditionとOracle WebLogic Suiteの各製品が拡張されて、次のコンポーネントが含まれます。
Oracle WebLogic Server MT。セキュアな分離を維持しながら、(ドメイン内のパーティションを許可することによって)アプリケーションをより少数のドメインに統合できます。
Java SE Advancedに対するWebLogic MTの拡張機能。これにより、JVM内でアプリケーションのメモリー、CPUおよびI/Oの分離、モニタリングおよび管理が可能になります。
Oracle WebLogic Coherence Enterprise EditionからGrid Editionまでのオプション。セキュアな分離を維持しながら、キャッシュをより少数のOracle Coherenceクラスタに統合できます。
Oracle Traffic Director。WebLogic Server MTに対応し、完全に統合されたテナント対応ローカル・ロード・バランシングを提供します。
ライセンス情報の詳細は、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle WebLogic Server Multitenantに関する項を参照してください。
WebLogic Server MTのこのリリースでは、Java Platform, Enterprise Edition (Java EE)アプリケーションのみがサポートされます。Oracle Java Required Files (JRF)に依存する製品はサポートされません。
JRFは、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークに共通の機能を提供する、WebLogic Serverインストールに含まれていないコンポーネントで構成されています。JRFは他に依存することなく開発されたライブラリやアプリケーションで構成されており、これらが共通の場所にデプロイされます。JRFの一部とみなされるコンポーネントには、Oracle Application Development Framework、Oracle Fusion Middleware監査フレームワーク、ダイナミック・モニタリング・サービス、Fabric Common、HTTPクライアント、インフラストラクチャ・セキュリティ、Javaオブジェクト・キャッシュ、JMXフレームワーク、JPS、ロギング、MDS、OJSP.Next、Oracle Webサービス、Oracle Web Services Manager、Oracle TopLink、UCP、XDKなどがあります。
これは、WebLogic Server MTは次の製品をサポートしないことを意味します。
Oracle Web Services Manager。
Oracle SOA Suite
Oracle Application Development Framework (Oracle ADF)
Oracle WebCenter
Oracle Service Bus
Oracle Enterprise Scheduler
Oracle WebLogic Service Component Architecture (SCA)
ドメイン・パーティションに加えて、WebLogic Server MTには次の新しい概念があります。
WebLogic Serverドメイン内でアプリケーションおよびリソースを使用する異なる外部の企業(たとえば、CompanyAとCompanyB)や、1つの企業内の異なる部署(たとえば、HRと会計)などの、個別のユーザー組織です。
テナントは独自に選択した論理グループで、これは構成可能なオブジェクトではありません。つまり、テナントではなく、ドメイン・パーティションを管理します。
テナントのアイデンティティは、特定のユーザーの特定のテナントとの関連付けです。たとえば、テナントFinanceをFinance-partitionという特定のドメイン・パーティションと関連付けるように選択できます。
ユーザー・アイデンティティ・ストアの指定に従い、ユーザーのアイデンティティから、特定のユーザーが属するテナントが識別されます。さらに、ユーザーのアイデンティティは、そのユーザーがユーザーの属するテナントを含む(ただしこれに限定されない)システム全体を移動する際の、認可される操作の適用に役立ちます。
(通常は)デプロイ可能な関連リソースの名前付きのコレクションです(たとえば、Java EEアプリケーションとそのデータ・ソース、JMSアーティファクト、アプリケーションが使用する他のリソースなどです)。
従来のWebLogic Serverドメインには、Java EEアプリケーション、JMSサーバーおよびキュー、データ・ソースなどの、複数のタイプのデプロイ可能なリソースを含めることができます。この従来のモデルでは、アプリケーション・スイートに複数のJava EEアプリケーションとそれらのアプリケーションをサポートする様々なリソースが含まれる場合は、管理者が一貫性のある単位としてではなく、個別にこれらのリソースを定義し、これらのアプリケーションをデプロイします。
WebLogic Server MTは、Java EEアプリケーションとそれらが使用するリソースを、ドメイン内の個別の管理単位にグループ化するための便利な方法として、リソース・グループを導入しています。リソースとアプリケーションは完全修飾されており、その中に、それらのリソースを開始したりそれらに接続するために必要なすべての情報(データ・ソースに接続するための資格証明やJava EEアプリケーションのターゲット指定情報を含む)が管理者によって提供されます。リソース・グループは、これらのデプロイ可能なリソースを直接含むか、リソースを定義するリソース・グループ・テンプレートを参照します。リソース・グループは、ドメイン・レベルで定義することも、ドメイン・パーティションに固有のものとすることもできます。
リソース・グループ内のすべてのリソースまたはリソース・グループによって参照されるすべてのリソースは、(同じターゲットに)まとめてターゲット指定されます。リソース・グループは起動および停止できます。
(通常は)複数のリソース・グループによってパターンとして使用されるデプロイ可能なリソースの名前付きのドメイン・レベル・コレクション。特定のテンプレートを参照する各リソース・グループには、そのテンプレートに定義されているリソースの独自のランタイム・コピーが含まれます。リソース・グループ・テンプレートは、複数テナント用にリソースを定義およびレプリケートする便利な方法です。リソース・グループ・テンプレートにより、アプリケーションとリソースの同じコレクションを複数のドメイン・パーティションにデプロイすることが非常に簡単になります。
リソース・グループ・テンプレートでは、次を定義できます。
アプリケーションのデプロイメント
ライブラリのデプロイメント
Java Database Connectivity (JDBC)システム・リソース
JMSシステム・リソース
Oracle Coherenceシステム・リソース
ファイル・ストア
JMSサーバー
メッセージング・ブリッジ
パス・サービス
永続ストア
ストア・アンド・フォワード(SAF)エージェント
外部JNDIプロバイダ
メール・セッション
WebLogic診断フレームワーク(WLDF)モジュール
リソース・グループ・テンプレートはドメイン・レベルで定義され、その後1つ以上のリソース・グループに参照されます。
リソース・グループ・テンプレートは、WebLogic Server MTが同じアプリケーションとリソースを複数回アクティブ化する(ドメイン・パーティションごとに1回ずつ) SaaS環境で特に役立ちます。そのようなリソースに関する情報のいくつかはすべてのドメイン・パーティションで同じになり、JMSキューの属性やデータベース接続の属性などのそのいくつかはパーティション間で異なります。たとえば、データ・ソースへの接続に使用されるURL、ユーザー名およびパスワードは、パーティション間で異なります。WebLogic Server MTは、パーティションごとに異なるテンプレートによって表されるアプリケーション・スイートをアクティブ化します。オーバーライド構成MBeanとリソース・デプロイメント・プランを指定して、パーティションのいくつかの属性値をオーバーライドできます。詳細は、「リソース・オーバーライドの構成」を参照してください。
パーティションまたはリソース・グループが実行される場所であり、トラフィックをこれらにルーティングする手順(アドレス、プロトコル設定およびターゲット指定を含む)です。リクエスト・ルーティングは、ホスト名とオプションのURIで決定します。
次が含まれます。
ホスト名とポート
オプションのURI
ネットワーク・アクセス・ポイント/チャネル
プロトコル固有構成
ターゲット・クラスタおよび管理対象サーバー
仮想ターゲットにより、ドメイン・パーティションとグローバル(ドメイン・レベル)ランタイムがターゲットのWebLogic Serverインスタンスの物理属性から分離されるため、アプリケーションがこれらの詳細を認識する必要がなくなります。
アプリケーションまたはライブラリをデプロイする場合、4つのデプロイメント・スコープ・オプションから選択できます。
グローバル。これは、非パーティション環境のドメイン・レベルと同等です。
リソース・グループ・テンプレートこれは常にドメイン・レベルです。リソース・グループ・テンプレートにデプロイするアプリケーションまたはライブラリがドメイン・レベルとパーティションのいずれで使用できるかは、リソース・グループ・テンプレートを参照するリソース・グループのスコープに応じて異なります。
パーティション内のリソース・グループ。これは、パーティションに制限される唯一のスコープです。
ドメイン・レベルでのリソース・グループ。
ドメイン・パーティション間でアプリケーションまたはライブラリを共有できません。アプリケーションまたはライブラリはパーティション内でのみ使用可能です。アプリケーションまたはライブラリをデプロイするときに、パーティション内のリソース・グループを指定します。Fusion Middleware Controlでは、パーティション内のリソース・グループにデプロイされるアプリケーションおよびライブラリに、ドメイン・パーティションの名前と、それらがデプロイされたそのパーティション内のリソース・グループが表示されます。
ドメイン・レベルで実行されるアプリケーションまたはクラスと、パーティションのコンテキストで実行されるアプリケーションまたはクラスの主な違いは、次のとおりです。
ドメイン・レベルで実行されるアプリケーションまたはクラスはドメイン全体で使用できますが、パーティションでは使用できません。
パーティションのコンテキストで実行されるアプリケーションまたはクラスは、そのパーティション内でのみ使用できます。
注意:
ベスト・プラクティスとして、すべてのアプリケーションおよびリソースをドメイン・パーティションにデプロイすることをお薦めします。
リソースの分離は、パーティション環境では非常に重要です。ドメイン・パーティションにリソース・グループを作成すると、WebLogic Server MTによって、JMSサーバー、JMSストアおよびJMSモジュール(接続ファクトリ、キュー、トピックなど)、Java Connector Architecture (JCA)アダプタおよびその他の関連するリソースを含む、アプリケーションに必要なすべてのリソースのランタイム・コピーが作成されます。
パーティション内にアプリケーションまたはライブラリをデプロイすると、行った構成の変更はそのパーティションに固有のものとなります。WebLogic Server MTでは、1つのパーティション内のアプリケーションはそのパーティションに適用されたリソースのみを参照するようになり、他のパーティションに関連付けられたリソースは参照しません。
WebLogic Server MTのリソースの分離には次が含まれます。
セキュリティ: 各ドメイン・パーティションの一意のセキュリティ・レルムおよびアイデンティティ・ドメイン。
管理:
パーティション固有の管理
独立したデプロイメント、構成およびソフトウェア更新
パーティション固有のモニタリングおよびトラブルシューティング
ランタイム:
専用のJava Naming and Directory Interface (JNDI): パーティションを認識する、JNDIレベルでのパーティション間の分離。アプリケーションで名前付きオブジェクトをバインドして、パーティションごとにそれらを取得できます。各リソースはパーティション固有の名前で(内部的に)タグ付けされ、パーティション専用のJNDIツリーに配置されます。クラスタ内のパーティションのアプリケーション内通信およびアプリケーション間通信は、パーティションで自動的に分離されます。
分離されたデータ: JMS、ファイル・システムおよびデータ・ソース。
リソースの分離と公平性: JVMまたはOSによって提供されるリソースのリソース消費管理(RCM)。これにより、システム管理者が、CPU、ヒープ、ファイル、ネットワークなどのリソースに対して、リソース消費管理ポリシー(制約、リコース・アクション、通知など)を指定できるようになります。
パーティション・ワーク・マネージャ: 同じWebLogic Serverインスタンスを共有するパーティション間での、作業リクエストのスレッド使用量の公平な分配および作業リクエストの優先度付け。
WebLogic Server MTの2つの主なユーザーは、WebLogic Serverシステム管理者とパーティション管理者です。
WebLogic Serverシステム管理者は、テナントのパーティションを作成および削除します。システム管理者は、パーティションのセキュリティ特性(セキュリティ・レルムやSSL構成など)の設定または変更と、共有(ドメイン・レベル)リソース・グループまたはリソース・グループ・テンプレートの参照を行うことができます。
「構成および管理用の管理ロール」で説明しているように、WebLogic Serverシステム管理者とパーティション管理者の大きな違いは、パーティション管理者はパーティション固有のセキュリティ・レルムに直接ログインすることです。
パーティション管理者は、パーティション内のリソース・グループごとに、パーティション構成の変更、アプリケーションのデプロイ、JMSリソース、データ・ソースおよびJDBC接続の作成など、パーティション・レベルでパーティションを管理します。パーティション管理者は、パーティションに関連付けられているセキュリティ・レルム・データ(ユーザーおよびグループ、資格証明マップ、ロール、ポリシーなど)を管理することもできます。パーティション管理者のセキュリティ管理機能を有効にするには、システム管理者が、パーティション管理者が属するマネージメント・アイデンティティ・ドメインを指定する必要があります。マネージメント・アイデンティティ・ドメインは、「セキュリティ・レルムおよびプライマリ・アイデンティティ・ドメインの構成: 主な手順および例」の手順5に示されているパーティションのプライマリ・アイデンティティ・ドメインと同じである必要があります。
システム管理者とパーティション管理者の両方が、次の操作を行います。
パーティション内のリソース・グループを作成、変更および削除します。
パーティション内のリソース・グループに対してアプリケーションをデプロイおよびアンデプロイします。
パーティションを起動および停止します。すべてのリソース・グループとそれらのリソース・グループにデプロイされたすべてのアプリケーションが起動または停止されます。
パーティション内のユーザーおよびグループ、資格証明マップ、ロールおよびポリシーを管理します。
WebLogicのロールと同様に、デプロイヤ、オペレータおよびモニターにはパーティションで制約されたロールが存在します。
SaaS環境で、アプリケーションが内部的にテナントごとのビューまたは必要なテナントごとの分離を提供できない場合は、かわりにテナントごとに個別のアプリケーションのインスタンスとその関連するサーバー側リソースをデプロイできます。これは、少なくとも非効率的です。各テナントで、ハードウェア容量またはJava仮想マシン、WebLogic Serverドメイン、管理サーバー、管理対象サーバー、クラスタ、およびWebサーバー、データ・グリッド、ネットワーキング、記憶域などのその他の関連リソースを含む独自のスタックが取得される場合があります。
WebLogic Server MTのSaaSモデルでは、引き続きリソースの分離を提供しながら、サーバー・リソースを最大限効率的に使用する方法が提供されます。各テナントで、アプリケーション・インスタンスと、ターゲット・サーバーおよびクラスタのリソース・インスタンスが取得されます。複数のドメイン・パーティションで、1つ以上の同じアプリケーションが同時に独立して実行されます。アプリケーションのコードの変更は必要なく、WebLogic Serverによってドメイン・パーティションの識別と分離が管理されます。
SaaSモデルでは、通常、1つ以上のアプリケーションと、それらがリソース・グループ・テンプレートで依存するリソースを定義します。その後、同じアプリケーションを使用するすべてのドメイン・パーティションからこのテンプレートを参照します。ドメイン・パーティション固有の変更を行うには、関連するリソース・グループの値を編集します。
SaaSモデルの手順フローの概要は次のとおりです。
WebLogic Serverシステム管理者が、リソース・グループ・テンプレートのJMSリソース、データ・ソースおよびその他のリソースを作成します。
WebLogic Serverシステム管理者は、必要なアプリケーションをリソース・グループ・テンプレートにデプロイします。
テナントに対してデプロイする準備ができたら、システム管理者が次の手順を実行します。
必要な場合は、仮想ターゲットを作成します。
リソース・グループ、プラガブル・データベース情報、仮想ターゲット、セキュリティ・レルムを含むドメイン・パーティション構成を作成し、パーティションのターゲットとしてクラスタまたは一連の管理対象サーバーを指定します。
特定のリソース・グループの一部の属性とすべてのアプリケーション・デプロイメント値をオーバーライドします。
パーティションを起動することで、そのパーティションのリソース・グループにデプロイされたすべてアプリケーションを起動します。
パーティションが起動された後は、パーティション管理者がパーティションのアプリケーションおよびリソースのランタイム状態を確認したり、パーティションのログ・エントリを確認したり、パーティションのセキュリティ・レルム・データを管理したり、パーティションのアプリケーションを停止および再起動できます。
デプロイ時に、リソース・グループ・テンプレートのアプリケーションおよびリソースがリソース・グループの各ドメイン・パーティションにレプリケートされてデプロイされ、さらに結果として次のようになります。
WebLogic Serverインフラストラクチャがドメイン・パーティション間で共有されます。
個々のアプリケーション・インスタンスが独自のJNDIツリーとリソースを持つようになります。
ランタイム・トラフィックが分離されます。アプリケーションには仮想ターゲットを使用してアクセスします。
パーティション・ワーク・マネージャにより、パーティション間で作業リクエストのスレッド使用量および優先度付けの公平性が実現します。
データがプラガブル・データベースによって分割されます。データ・ソースの実装によって、各ドメイン・パーティションに、そのパーティションに割り当てられているプラガブル・データベース対する個別の物理接続プールが作成されます。
SaaS環境でドメイン・パーティションを使用する多くの利点のうちの1つは、制御された本番環境で新しいバージョンのアプリケーションをテストできることです。
たとえば、ビジネスで重要なアプリケーションがPartition Aにデプロイされているとします。このアプリケーションに大きな変更を行う場合は、多くの場合それがユーザーに一般提供される前に、それを本番環境でテストする必要があります。WebLogic Server MTでは、これを簡単に実行できます。Partition Aで実行されているアプリケーションの安定したバージョンに影響を与えることなく、Partition Bを作成して、更新されたアプリケーションをデプロイできます。
Partition Bで実行されているアプリケーションの更新バージョンのターゲットとして実際の本番クラスタおよびデータ・ソースを指定して、制御された環境内でパフォーマンス・メトリックなどのすべてをテストして調整できます。
WebLogic Server MT PaaSモデルは、統合と同じ意味です。統合は、多数のテナントからの異なるアプリケーションを同じWebLogic Serverインフラストラクチャにデプロイできることを意味します。WebLogic Server MTでは、インフラストラクチャと、ドメイン、クラスタ、管理対象サーバー、ハードウェア、ネットワークなどの基礎となるリソースが共有されます。
SaaSユースケースでは、通常、WebLogic Serverシステム管理者がすべてのドメイン・パーティションと、それらのリソース・インスタンスを管理します。ただし、PaaSユースケースでは、多くの場合パーティション管理者がリソースの構成、パーティションのセキュリティ・レルム・データの管理、アプリケーションのデプロイなどを行って、それぞれのドメイン・パーティションとその中のリソースを管理します。
統合:
多数のテナントからのアプリケーションを同じWebLogic Serverインフラストラクチャに簡単にデプロイできます。
結果として、管理するドメインが1つ、リソースを消費するJVMが1つになります。
管理を分離します。WebLogic Serverシステム管理者がインフラストラクチャを管理します。パーティション管理者が、パーティションのセキュリティ・レルム・データ、パーティションのデプロイメントおよび関連するリソースを管理します。
パーティション固有のコンポーネント(セキュリティ・レルム(テナントごと)、仮想ターゲット(アドレス)、プラガブル・データベース、JNDI (内部トラフィック)、JMS、パーティション・ワーク・マネージャ)を含むランタイムを分離します。各テナントで、アプリケーション・インスタンスと専用リソースの独自のセットを取得します。
PaaSユースケースでは、通常、各テナントで異なるアプリケーションが実行されて、これらのアプリケーションが他のテナントで実行されたアプリケーションと重複する場合としない場合があります。WebLogic Server MT PaaSソリューションを実装すると、通常、リソース・グループ・テンプレートを参照しないが、かわりにドメイン・パーティション内でのみ使用可能になるアプリケーションとその関連リソースを表す、自己完結型のリソース・グループを作成します。ただしこれは、PaaSソリューションではリソース・グループ・テンプレートがあまり使用されないとしても、それらがユースケースに適合する場合にPaaSソリューションでリソース・グループ・テンプレートを使用できないことを意味するわけではありません。
PaaSモデルの手順フローの概要は次のとおりです。
WebLogic Serverシステム管理者が、必要に応じて仮想ターゲットを作成します。
WebLogic Serverシステム管理者が、ワークロードを管理する指定されたパーティション・ワーク・マネージャまたはサービス品質(QoS)定義とともにドメイン・パーティションを作成します。
パーティション・ワーク・マネージャでは、パーティションの相対的な優先度と、基礎となるメモリーとCPUの可用性が定義されます。
WebLogic Serverシステム管理者が、ドメイン・パーティションのセキュリティ・レルムを選択し、使用可能なターゲットのリストを設定します。
ドメイン・パーティションのリソースとアプリケーションは、ドメイン・パーティションのセキュリティ・レルム内のユーザーのみが使用できます。他のテナントでは、リソースまたはアプリケーションを表示することもアクセスすることもできません。
WebLogic Serverシステム管理者が、パーティション管理者にパーティションを割り当てます。
リソース、アプリケーションおよびパーティションのセキュリティ・レルム・データは、パーティション管理者が管理します。(基礎となる管理対象サーバーとクラスタはパーティション管理者によって管理されません。)
パーティション管理者が、そのドメイン・パーティションに1つ以上のリソース・グループを作成し、使用可能なターゲットのリストからリソース・グループを選択します。
パーティション管理者が、ドメイン・パーティションの各リソース・グループに、異なるJMSリソース、データ・ソース、PDB情報、アプリケーションのデプロイメントなどを作成します。
パーティション管理者がパーティションを起動し、これによってパーティションのリソース・グループにデプロイされたすべてアプリケーションを起動します。
追加のテナントごとに、手順1-4を繰り返します。
Oracle Fusion Middlewareのエンタープライズ・デプロイメントは複雑になる場合があります。WebLogic Server MTは、分離のためのパーティションを使用して、多くのドメインを1つに統合することを簡略化し、コンポーネント構成間の新しいレベルの調整を導入します。
WebLogic Server MTライフサイクル管理は、異なるコンポーネント間のパーティションを接続して、テナントのニーズに応える1つの結合ユニットを形成します。これを行うために、ライフサイクル・マネージャ(LCM)は、コンポーネント全体の構成を統合します。
Representational State Transfer (REST)、WebLogic Scripting Tool (WLST)、Fusion Middleware ControlまたはOracle WebLogic Server管理コンソールのいずれかを使用して、パーティションが作成、更新または削除されると、ライフサイクル・マネージャはこれらのバンド外のアクションを検出して、その構成を管理サーバーの構成と同期します。ライフサイクル・マネージャは、登録されているプラグイン(Oracle Traffic Directorプラグインなど)にこれらの変更を通知して、環境全体で同期を維持します。
WebLogic Server MTでドメイン・パーティションが作成または更新されると、変更は複数の層にわたって編成されます。
Oracle Traffic Director構成が更新され、新しいパーティションと同期されます。
アプリケーションがOracle Coherenceのキャッシュまたはサービスと関連付けられます。
データ・ソースが既存のデータベースまたはプラガブル・データベース(PDB)に関連付けられるか、新しいプラガブル・データベースが作成されます。
図1-2に、トラフィックの分離と、Web層からデータベース層へのフローを示します。
