OCIでアプリケーションをSaaSifyする方法 (2026/02/10)

OCIでアプリケーションをSaaSifyする方法 (2026/02/10)

https://blogs.oracle.com/cloud-infrastructure/how-to-saasify-applications-on-oci

投稿者： Gururaj Mohan | Master Principal Cloud Architect

今日のクラウドファーストの世界では、企業や独立系ソフトウェアベンダー（ISV）が従来型のアプリケーションをSaaS（Software as a Service）へと移行するケースが増えています。この変革において重要な要素となるのが、マルチテナント・デプロイメント・モデルです。このモデルでは、複数の顧客がセキュリティ、パフォーマンス、そしてコスト効率を確保しながら、同じアプリケーションを共有できます。Oracle Cloud Infrastructure（OCI）は、共有テナンシーとハイブリッド・アプローチを用いたSaaSアプリケーションの容易な提供を可能にする、堅牢なサービスセットを提供します。

テナンシーについて

OCI テナンシーと SaaS アプリケーションのテナントの概念を混同しないことが重要です。

OCIテナンシー：OCIサービスにサインアップすると付与されるアカウントです。これはルートアカウントを表し、OCIリソースを整理・管理するための安全で分離されたパーティションとして機能します。

テナント  （SaaSのコンテキスト）：ISVがOCI上にSaaSプラットフォームを構築するとします。ISVが自社の顧客をプラットフォームにプロビジョニングする際、各顧客はテナントとみなされます。ここで言うテナントとは、顧客組織を表し、各テナントには複数のユーザーが関連付けられる場合があります。

つまり、OCI テナンシーは OCI アカウント自体を指し、テナントは ISV などの別のエンティティによって OCI 上でホストされているアプリケーションを使用する組織 (SaaS 顧客など) を指します。

アーキテクチャ

このアーキテクチャは、OCI 上のマルチテナント アプリケーション デプロイメント モデルを高レベルで表します。

次の図は、このリファレンス アーキテクチャを示しています。

マルチテナントアプリケーション展開モデル

この柔軟なアーキテクチャは、次の 3 つの層で構成されています。

層目的キーアクション
初期認証（OCI IAM）グローバルIDを確認する資格情報の検証後にJSON Web Token（JWT）を発行する
認証ミドルウェアリクエストごとにIDを確認するJWT からテナントとユーザーのコンテキストを抽出する
データアクセス層またはORMフックデータ分離を強制するすべてのクエリを自動的にフィルタリング tenant_id

各レイヤーについては以下で説明します。

初期認証とテナントコンテキストの確立

  • 認証サービス: 通常、ユーザーはテナント固有の URL (mycompany.app.com など) を使用するか、ログイン時にテナントを選択してログインします。
  • OCI Identity and Access Management (OCI IAM) をアイデンティティプロバイダーとして使用：  OCI IAM (具体的には 専用のアイデンティティドメイン) はユーザーの資格情報を検証します。重要なのは、ユーザーが有効であるだけでなく、アクセスしようとしている特定のテナントグループ (例: mycompany-users) のメンバーであることを確認することです。
  • JWT 発行: 認証が成功すると、OCI IAM アイデンティティドメインは署名付きの JSON Web Token (JWT) を発行します。このトークンには、以下の重要なクレームが含まれます。
    • sub : ユーザーの一意の識別子。
    • groups : ユーザーが所属するIAMグループのOCIDの配列。これはテナントを識別するためのキーとなります。
    • tenant_id またはなど  の カスタムクレームは、tenant_name  OCI IAM のカスタム属性を使用して追加できます。(オプション)

認証ミドルウェア – 「Who」層

バックエンドは、テナントコンテキストを安全に抽出・伝播するように設計する必要があります。このアーキテクチャは、OCI API GatewayまたはOCI Load Balancerのいずれかを使用して、リクエストごとの認証とテナントコンテキストの伝播を実行できます。

  • OCI API Gateway:推奨されるエントリポイント です 。JWT検証を自ら実行することで、アプリケーションコードの負担を軽減します。OCI IAMアイデンティティドメインのJWKSエンドポイントに対して署名を検証するように設定してください。
  • OCI ロード バランサ:  SSL 終了とルーティングを処理できますが、検証のために JWT を認証ミドルウェアに渡します。

アクション:  OCI API GatewayはJWTの署名と有効期限を検証します。無効な場合は、リクエストを直ちに拒否します。有効な場合は、リクエストを上流のサービスに転送し、検証済みのトークンまたは抽出されたクレームをヘッダー（例：  X-USER-ID、  X-TENANT-ID）に渡すことがよくあります。

OCI API Gateway の代わりに OCI Load Balancer を使用している場合、アプリケーション バックエンドの最初のコンポーネントは認証ミドルウェアである必要があります。

アクション:ヘッダー から JWT を抽出し Authorization: Bearer <token> 、OCI IAM の公開キーを使用して署名を検証し、クレームをデコードして、 後続のすべてのレイヤーが使用できるようにuser_id and  tenant_id (groups クレームから派生) をリクエスト コンテキストに挿入します。

データアクセス層またはオブジェクトリレーショナルマッパー（ORM）フック – 「何」の層

このレイヤーは、すべての SQL クエリにテナント ID を自動的に挿入します。

  • 例: への呼び出しは getAllInvoices() に変換されます SELECT * FROM invoices WHERE tenant_id = :tenant_id。
  • 強制: 人為的なエラーを回避するには、集中型のデータ アクセス層または ORM (Hibernate など) フック、または「テナント対応」接続プールによって強制するのが最適です。
  • ORM フック: アプリケーション フレームワーク レベルでデータベース操作をインターセプトして変更することで、真の暗黙的なテナント分離を可能にするメカニズム。

テナントデータ分離戦略:

このアーキテクチャは、テナントのデータを分離して保護するための 2 つのオプションをサポートしています。

オプション1: アプリケーションレベル

ORM フック/スコープ:  Hibernate (Java)、Django ORM (Python)、Eloquent (PHP) などのフレームワークを使用すると、特定のモデルのすべてのクエリにテナント フィルターを自動的に追加するグローバル スコープを定義できます。

または

オプション2: データベースレベル

識別子列、テナントごとの個別のスキーマ、またはテナントごとの個別のデータベースを使用できます。

  • 識別子列（最も一般的）：テナント固有のテーブルまたはドキュメントごとに列 tenant_id が追加されます。アプリケーションのデータアクセス層（DAL）またはORMは、 WHERE tenant_id = ? すべてのクエリに句を自動的に追加する役割を担います。これは、以下の方法で実現されます。
    • リポジトリパターン：tenant_idすべてのデータベースアクセスは、中央のクラスまたはクラスセットを介して行われます。このリポジトリは 、現在のリクエストコンテキスト に基づいて、すべてのSELECT、INSERT、UPDATE、およびDELETE操作にテナントフィルターを自動的に追加します 。
    • 接続コンテキスト： 一部のSQLデータベース（Oracle HeatWave MySQLなど）では、アプリケーションがセッション変数（例：  SET @tenant_id = 'mycompany123';）を設定し、それをビューやストアドプロシージャで使用できます。ただし、接続ごとにこの値を設定するのは、依然としてアプリケーション層の役割です。
  • テナントごとのスキーマ:各テナントには、同じデータベース インスタンス内に専用のデータベース スキーマがあります。テナント ID に基づくアプリケーション ロジックは、データベース接続の現在のスキーマを切り替える必要があります。
    • テナントごとの接続プール: テナントごとに個別の接続プールを維持し、各接続はテナントのスキーマ (例:  USE tenant_mycompany;) を使用するように事前構成されます。
    • 動的接続切り替え: 現在の tenant_id に基づいてチェックアウト時にスキーマを設定する接続プールを使用します (たとえば、  SET search_path TO tenant_mycompany; PostgreSQL のコマンドを使用する)。
  • テナントごとのデータベース:各テナントには、企業向けの Bring Your Own Keys Encryption を備えた、物理的に独立した独自のデータベース インスタンスがあります。アプリケーションには、 正しいデータベース接続文字列に マップするための テナント データ検索サービスがtenant_id必要です 。
    • アプリケーションは複数のデータベースへの接続プールを保持します。
    • DAL は、要求コンテキストのテナント ID を使用してプールから正しい接続を取得し、専用のテナント データベースでクエリを実行します。
    このオプションには利点と欠点があります。
    • 利点： 最大限の分離性、セキュリティ、パフォーマンス。テナントは異なるデータベースバージョンやエンジンタイプでも利用可能です。
    • デメリット： 運用オーバーヘッド、コスト、複雑さが最も高くなります。データベースの移行とパッチ適用は、すべてのテナントデータベースで実行する必要があります。

考慮事項

このアーキテクチャを展開するときは、次のオプションを考慮してください。

  • パフォーマンス：
    • API にテナントベースのレート制限を設定する
    • OKE の名前空間ごとに Kubernetes リソース クォータを使用して、テナントごとにポッド、CPU、メモリを制限する
    • 需要の高いテナント向けに専用のノードプールを活用する
    • データベース接続でテナントごとのプールサイズを設定する
  • 安全：
    • OCI IAMグループは、ユーザーがアクセスできるテナントを制御します。これはJWTによって強制されます。
    • Oracle Cloud Guardを有効にして誤った構成を検出します
  • コスト：ビジネスニーズに基づいて、テーブルレベル、スキーマレベル、あるいはエンタープライズレベルのお客様向けの専用データベースが必要かどうかを評価します。例：
    • 層 1: 標準 (識別子列): テナントは同じテーブル/スキーマを共有します。
    • レベル 2: プレミアム (テナントごとのスキーマ): テナントは同じデータベース内で専用のスキーマを取得します。
    • 層 3: エンタープライズ (テナントごとのデータベース): テナントは専用のデータベース インスタンスを取得します。
  • パッチ適用とアプリケーションアップデート単一インスタンス、マルチテナントのSaaSアーキテクチャでは、すべてのテナントにパッチを適用せずに1つのテナントにパッチを適用することはできません。すべての顧客が同じアプリケーションコードベース、ランタイム、インフラストラクチャを共有しています。この現実は、大きな課題を生み出します。ユーザーベース全体に混乱をもたらすダウンタイムを発生させることなく、安全かつ効率的にアップデートを展開するにはどうすればよいでしょうか？その答えは、この目的のために特別に設計された最新のDevOpsデプロイメント戦略にあります。ゼロダウンタイムのデプロイメント戦略を使用することで、ユーザーをオフラインにすることなく、バージョン間のシームレスな移行が可能になります。
    • ブルーグリーン・デプロイメント： これは、2つの同一の本番環境を維持することを意味します。1つは「ブルー」（現在のバージョンを実行）で、もう1つは「グリーン」（新しいバージョンを実行）です。グリーンで新しいバージョンをデプロイしてテストした後、すべてのトラフィックをブルーからグリーンにシームレスに切り替えます。何か問題が発生した場合は、即座に元の状態に戻すことができるため、ロールバックは問題なく行われます。その後、古いブルー環境は廃止されます。
    • カナリア展開： 段階的なロールアウトを行うことでリスクを軽減する戦略です。新バージョンは、管理された少数のユーザー（「カナリア」）に展開されます。このグループを綿密に監視し、エラーやパフォーマンスの問題がないか確認します。指標が良好であれば、段階的にアップデートをより多くのユーザーに展開し、全員が新バージョンを使用するまで進めます。
    ユーザーに必須のアップグレード期間を通知します（例：「アップグレード日が指定されていない場合、アップグレードは日曜日の12:00（mm/dd/yyyy）に自動的に実行されます」）。期間終了後、旧バージョンのセッションを終了し、すべてのトラフィックを新バージョンにリダイレクトします。その後、旧アプリケーションコードは完全にシャットダウンされます。
  • データベースに関する考慮事項アプリケーションのバージョンを切り替えると同時にデータベーススキーマを切り替えることはできません。多くのSaaS企業は、以下の方法でこれを回避しています。
    • 下位互換性のあるデータベース スキーマの変更
    • 機能フラグ/トグル
    • テナントメタデータベースのバージョン管理
    これにより、ロールアウト中に新しいコードを古いスキーマ バージョンに対して安全に操作できるようになり、ダウンタイムなしの移行と即時のロールバックが可能になります。

行動喚起

アプリケーションをモダナイズし、スケーラブルなサブスクリプションベースのSaaSモデルへの移行をご検討中ですか？Oracle Cloud Infrastructure（OCI）は、SaaSトランスフォーメーションを加速するために必要なパフォーマンス、セキュリティ、そしてコスト効率を提供します。
次のステップに進みましょう。現在のアーキテクチャを評価し、SaaSへの対応におけるギャップを特定し、OCIサービスがアプリケーションのモダナイズ、拡張、そしてSaaSプラットフォームとしての運用にどのように役立つかを検討し始めましょう。

さらに深く掘り下げたり、実際の実装方法について議論したい場合は、お気軽にお問い合わせください。

さらに詳しく

マルチテナント アプリケーションの展開について詳しく説明します。

以下の追加リソースを確認してください。

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

イメージ
ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
続きを読む

OCIサービスを利用したWebサイトの作成 その4～Identity Cloud Serviceでサイトの一部を保護 (2021/12/30)

イメージ
OCIサービスを利用したWebサイトの作成 その4～Identity Cloud Serviceでサイトの一部を保護 (2021/12/30) https://blogs.oracle.com/cloudsecurity/post/using-oci-services-part-4 投稿者： Christopher Johnson 今回は、OCI Native Servicesを使って完全にサーバーレスでWebサイトをホスティングするシリーズの第4弾です。     パート1 では、OCI WAF + API Gateway + Functionを使用して、OCI Object Store Bucketから静的コンテンツを提供する基本的な方法を紹介しました。     パート2 では、バケットを（公開ではなく）非公開にし、Resource Prinicpalを使用して安全にアクセスする方法を紹介しました。     パート3 では、ハードコードされた設定を削除し、代わりにそれらの設定をアプリケーションに保存する方法を紹介しました。 パート4では、サイトの一部をログインの後ろに置いてみようと思っています。 この記事は、ちょっとした「フクロウの描き方」のようなものになりそうです。でも、コードを見ればきっと理解できるはずです! IDCSでアプリケーションを作成 注：OCI Identity Domains は、OCI の新規顧客に対して IDCS の機能を直ちに提供します。現在 IDCS を使用している顧客については、既存の IDCS ストライプは今後数ヶ月の間に OCI Identity Domains に移行される予定です。詳細については、OCI Identity Domainの ドキュメント を参照してください。この変更は、このブログで説明したセキュリティ・パターンに影響を与えるものではありません。このブログで IDCS に起因するセキュリティ機能は、OCI Identity Domainsでも提供されます。 まず最初に、サイトを表現するために IDCS で実際にアプリケーションを作成する必要があります。 IDCSコンソールを開き、「アプリケーション」に移動し、「作成」をクリックします。Functionアプリケーシ...
続きを読む