1.1.3 共有サーバー・アーキテクチャの理解

Oracle Databaseの共有サーバー・アーキテクチャにより、アプリケーションの拡張性とデータベースへ同時に接続できるクライアント数は増大します。また共有サーバー・アーキテクチャでは、既存のアプリケーションの能力を、アプリケーション自体に何ら変更を加えずにスケールアップできます。

共有サーバーを使用すると、クライアントはデータベース・サーバー・プロセスと直接通信しません(サーバー・プロセスは、データベース上の1つのプロセスで、データベースにかわってクライアントの要求を処理します)。かわりに、クライアントの要求は1つ以上のディスパッチャにルーティングされます。ディスパッチャはクライアントの要求を共通のキューに登録します。サーバー・プロセスの共有プールにあるアイドル状態の共有サーバーは、このキューから要求を取り出して処理します。つまり、サーバー・プロセスの小規模プールによる多数のクライアントの処理が可能になります。

共有サーバー・アーキテクチャの図と専用サーバー・アーキテクチャの図では、共有サーバー接続モデルと従来の専用サーバー接続モデルの基本的な違いを示します。共有サーバー・モデルでは、ディスパッチャは同時に複数のクライアント接続をサポートします。専用サーバー・モデルでは、各クライアントに対してサーバー・プロセスは1つです。接続要求が受け取られるたびに、サーバー・プロセスが起動され、処理が完了するまでその接続の専用になります。このモデルでは、処理の遅延が起こります。

図1-8 共有サーバー・アーキテクチャ

図1-8の説明が続きます。
「図1-8 共有サーバー・アーキテクチャ」の説明

図1-9 専用サーバー・アーキテクチャ

図1-9の説明が続きます。
「図1-9 専用サーバー・アーキテクチャ」の説明

共有サーバーは、接続が多い場合に理想的な構成です。これは、この構成によってサーバーのメモリー要件が軽減されるためです。共有サーバーは、インターネットおよびイントラネットの両方の環境に適しています。

サーバー・リソースの使用率は、Oracle Connection Managerによって、さらに高めることができます。Oracle Net ServicesのコンポーネントであるOracle Connection Managerでは、データベースへのネットワーク接続を単一化することにより、複数のクライアント・ネットワーク・セッションを多重化、つまり集中化できます。

セッションの多重化機能は、サーバーが着信要求に使用するネットワーク接続のエンドポイントの数を少なくすることにより、2つのプロセス間で複数の接続を維持するために必要なリソースを削減します。これにより、サーバーが処理できるネットワーク・セッションの総数が増加します。1つのOracle Connection Managerを複数のゲートウェイで構成すると、数千のユーザーをサーバーに同時接続できます。

次の図では、Webアーキテクチャにおいてセッションの多重化をどのように使用できるかを示します。Oracle Connection ManagerがアプリケーションWebサーバーと同じコンピュータ上で実行されると、アプリケーションWebサーバーは、複数のクライアント・セッションをOracle Connection Managerからルーティングでき、これらのセッションは、継続的にOracle Databaseサーバーにアクセスできます。この機能は特に、セッションの可用性と応答時間が主要課題であるWebアプリケーションで利用価値があります。

図1-10 セッションの多重化

図1-10の説明が続きます
「図1-10 セッションの多重化」の説明

セッションの多重化の長所と短所は、次のとおりです。セッションの多重化は、継続的な接続が必要なネットワークに推奨されます。

セッション多重化の長所

  • 各プロセスに対して使用されるネットワーク・リソース数を制限します。

  • 多数のクライアントがサポートされます。

  • 一定数に制限されたプロセス接続数に対するクライアント/サーバー・セッション数を最大化します。

  • リソースの利用を最適化します。

  • 実ユーザーの識別および監視が可能になります。

  • 中間層のアプリケーションによって追加サービスをサポートできるようになります。

  • 複数のアプリケーションを持つクライアントに対して必要なトランスポートが1つのみで済みます。

  • データベース・リンクに対して必要なネットワーク接続が1つのみで済みます。

セッション多重化の短所

クライアントはOracle Connection Managerに接続する必要があります。