1. SaaSアプリケーションをホスティングするためのインフラストラクチャの設計
  2. SaaSアプリケーションをホスティングするためのインフラストラクチャの設計について

SaaSアプリケーションをホスティングするためのインフラストラクチャの設計について

独立したソフトウェア・ベンダー(ISV)がサービスとしてソフトウェアを提供する場合(SaaS )、サービスをホストし、テナントを管理するためにセキュアでスケーラブルなエンタープライズ・グループのインフラストラクチャが必要です。このソリューションは、Oracle CloudでSaaSアプリケーションをホストできるようにするベスト・プラクティスを含む検証済アーキテクチャを提供します。

SaaSアプリケーションについて

SaaSアプリケーションは、ベンダーがクラウドでサービスとして提供するアプリケーションです。ベンダーの顧客は、サービスをサブスクライブし、必要な場合にアプリケーションを使用します。

SaaSベンダーでは、各サブスクライバ(または顧客)がテナントです。

SaaSアプリケーションは、次のアーキテクチャのパターンを使用してクラウドにデプロイできます。
  • 単一の便利なアプリケーション・インスタンス

    このパターンでは、SaaSベンダーが、すべてのテナントが使用する単一のアプリケーション・インスタンスをデプロイします。アプリケーションでは、テナント固有のワークロードとデータの分離が処理されます。

    すべてのテナントは、共通のコード・ベースから構築された同じアプリケーション・バージョンを取得します。すべてのアプリケーション・デプロイメントは同じコードに基づいているため、ベンダーはサービスを効率的に構成、パッチ適用およびアップグレードできます。サービスのスケーリングと操作が簡単です。

    ただし、人為的認識型アプリケーション環境を作成するには、最初から作業量を増やす必要があります。また、このデプロイメント・パターンは、完全な独立性を必要とするSaaSのカスタマには適していません。

  • 複数のテナント固有のアプリケーション・インスタンス

    このパターンはソリューションの中心です。

    SaaSベンダーは、複数の独立したアプリケーション・インスタンスをデプロイおよび管理します。各デプロイメントは特定のテナント用です。SaaSベンダーは、共通の管理レイヤーを通して、個々のテナント・アプリケーション・インスタンスを管理します。

    ベンダーは、すべてのテナント・アプリケーション・インスタンスを単一のコード・ベースから作成するか、カスタマイズされたバージョンのアプリケーションを各テナントに提供するかを選択できます。このパターンは、アプリケーション環境を完全に分離する必要があるSaaSのお客様に最適です。

アーキテクチャ

このアーキテクチャは、SaaSベンダーの複数のテナントをホストするOracle Cloud Infrastructureテナンシを示します。アーキテクチャ内のすべてのリソースは、単一のリージョンにあります。

SaaSベンダーの管理インフラストラクチャと各テナントのアプリケーション・リソースは、別個のコンパートメントと仮想クラウド・ネットワーク(vcn)で分離されます。ネットワークの分離によって、アプリケーションとデータがテナンシの他のデプロイメントから分離されます。コンパートメントによって、リソースの論理的な分離が確保され、詳細なアクセス制御が可能になります。


複数のSaaSテナントをホストするISVテナンシのアーキテクチャ

このアーキテクチャには、次のコンポーネントが含まれています。

  • 管理コンパートメント

    管理コンパートメントは、個々のテナント・アプリケーション・デプロイメントの管理に使用される共通インフラストラクチャに必要なすべてのIsv固有リソースの論理コンテナです。次のリソースが含まれています。

    • ISV VCN

      SaaS ISVがテナントにアクセスして管理するために必要なリソースは、ISV VCNにアタッチされます。

    • 管理サーバー

      管理サーバーは、プライベート・サブネットのコンピュート・インスタンスです。このサーバーでインフラストラクチャ監視アプリケーションを実行して、テナント・サーバーを監視できます。管理サーバーは、ISV VCNのプライベート・サブネットに接続されます。管理サーバーは、ルーティング・ゲートウェイを介してテナント区分のサーバーと通信できます。

  • ピアリング・コンパートメント

    ISV VCN内のリソースとテナント・リソース間のプライベート通信では、ISV VCNと各テナントVCN間でローカル・ピアリング関係が必要です。ただし、VCNは最大10個のローカル・ピアリング関係を持つことができます。このスケーリング制限を解決するために、アーキテクチャは、複数のピアリングVcnに接続可能なルーティング・ゲートウェイを使用します。各ピアリングVCNは、最大10のテナントvcnとのローカル・ピアリング関係を持つことができます。そのため、ピアリング・コンパートメントにルーティング・ゲートウェイおよびピアリングVcnを追加することによって、トポロジをスケール・アップできます。

    • ピアリング・サブネット

      ピアリング・サブネットはISV VCNの一部です。すべてのルーティング・ゲートウェイがこのサブネットにアタッチされます。

    • ゲートウェイのルーティングおよびVcnのピアリング

      各ルーティング・ゲートウェイは、ピアリングVCNを介して、管理サーバーからテナントvcnにトラフィックをルーティングするOracle Linuxコンピュート・インスタンスです。

      各ルーティング・ゲートウェイ・インスタンスのプライマリVNICは、ISV VCNのピアリング・サブネットにアタッチされています。

      各ルーティング・ゲートウェイ・インスタンスのセカンダリVnicは、ピアリングvcnのサブネットにアタッチされます。ルーティング・ゲートウェイが処理できるピアリングVcnの最大数は、基礎となるコンピュート・インスタンスの形状がサポートしているセカンダリvnicの数によって異なります。たとえば、VM.Standard.2.4シェイプを使用するコンピュート・インスタンスでルーティング・ゲートウェイが実行されている場合、最大で3つのセカンダリvnicを使用でき、最大で3つのピアリングvcnを使用できます。各ピアリングVCNは、最大10のテナントvcnに接続できます。そのため、VM.Standard.2.4図形を使用するルーティング・ゲートウェイは最大30個のアプリケーション・テナントをサポートできます。

      各ルーティング・ゲートウェイの高可用性を確保するために、浮動IPアドレスを持つコンピュート・インスタンスのアクティブ/パッシブのペアを設定し、PacemakerやCorosyncなどのソフトウェアを使用して自動的なフェイルオーバーを確保できます。

  • テナント区分

    各テナントのリソースは、個別のコンパートメントにあります。各テナント区分には、そのテナントのすべてのリソースがアタッチされているVCNが含まれます。そのため、各テナントのリソースは、トポロジ内の他のすべてのテナントから分離されたネットワーク内の一意のアドレス領域を使用します。

    各テナント区分で、コンパートメント内のサーバーをモニターして、ISV VCNで管理サーバーにメトリックを送信できる、エージェントを実行しているコンピュート・インスタンスをプロビジョニングできます。

    新規アプリケーション・テナントを追加すると、新規テナントに必要なリソースが新規コンパートメントにプロビジョニングされます。

    テナントは、パブリック・インターネットまたはプライベート接続(IPSec VPNまたはFastConnect)を介して、アプリケーションにアクセスできます。パブリック・インターネットからアクセスするために、各テナントVCNではインターネット・ゲートウェイが必要です。VPNまたはFastConnectを使用してアクセスするには、DRGが必要です。アーキテクチャ図には、インターネット・ゲートウェイおよびテナントVcnに対するdrgは表示されません。

必要なサービスおよびポリシーの概要

このソリューションには、次のサービスおよびアクセス管理ポリシーが必要です。

サービス 次に対して必要なポリシー...
Oracle Cloud Infrastructure Identity and Access Management 区分を作成および管理します。
Oracle Cloud Infrastructure Networking Vcn、サブネット、インターネット・ゲートウェイ、ルート表、セキュリティ・リスト、lPgおよびdrgを作成および管理します
Oracle Cloud Infrastructure Compute コンピュート・インスタンスを作成および管理します。

必要なクラウド・サービスを取得するには、「Oracle Cloud Services for Oracle Solutions」を参照してください。