高可用性のOracle REST Data ServicesのOracle Cloud Infrastructureへのデプロイ

高可用性を備えたOracle REST Data Services (ORDS)をOracle Cloud Infrastructure (OCI)およびRESTにデプロイして、データベースを有効にし、マイクロサービスのアーキテクチャと機能の利点を公開します。

ORDSはHTTPSとOracleデータベースをブリッジします。中間層Javaアプリケーションとして、データベース管理REST API、SQL Developer Web、PL/SQL Gateway、SODA for REST、およびOracleデータベース内のデータおよびストアド・プロシージャと対話するためのRESTful Webサービスを公開する機能を提供します。

また、ORDSは、Oracle WebLogic ServerまたはApache Tomcatを使用するデプロイメント、またはスタンドアロン・モードであるデプロイメントをサポートすることで、柔軟性を高めます。ORDSでは、埋込みJDBCドライバが接続性を提供するため、Oracleホームは不要であるため、デプロイメント・プロセスがさらに簡素化されます。

このリファレンス・アーキテクチャでは、複数のVMコンピュート・インスタンスにORDSをデプロイし、Oracleデータベース・インスタンスの高可用性中間層を作成する方法について説明します。

アーキテクチャ

このアーキテクチャでは、高可用性を備えたOracle REST Data ServicesをOCIにデプロイする方法を示します。

アーキテクチャは、1つのリージョン内のVirtual Cloud Network (VCN)で始まります。このVCNは複数のアベイラビリティ・ドメイン(AD)にまたがることができますが、このリファレンス・アーキテクチャでは単一のADが使用されます。そのADには、ハードウェアとインフラストラクチャをグループ化したAD内の複数のフォルト・ドメインが含まれます。ORDSを含むコンピュート・仮想マシンは、高可用性の実現を支援するために、複数のフォルト・ドメインにデプロイされます。

VCNでは、複数のサブネットに特定のアーキテクチャ・コンポーネントが含まれています。これはインターネット・ゲートウェイから始まります。インターネット・ゲートウェイでは、指定したポートを介した、パブリック・サブネット内のこのVCNのフロント・エンドのロード・バランサへのトラフィックのみが許可されます。ロード・バランサには、必要に応じて、後でカスタム・ドメイン名を適用するために使用できるパブリック対応IPもあります。ロード・バランサは、ORDSコンピュート中間層を含むサブネットと通信します。通信は、サブネット全体のセキュリティ・リストおよびネットワーク・セキュリティ・グループ(NSG)によって保護されます。これらのNSGをコンピュートおよびロード・バランサのVNICのセットに適用して、これらのリソース間の通信に関する詳細なセキュリティ・ルールを提供できます。

最後に、セキュリティ・リストおよびNSGを再度使用すると、ORDS中間層はプライベート・サブネット内のOracleデータベースにアクセスできます。プライベート・サブネットを使用するリソースには、パブリック対応IPは付与されません。このようにして、NSGを使用して、パブリック・サブネットとプライベート・サブネット間のセキュアな通信レイヤーを作成できます。このプライベート・サブネットのOracleデータベース・インスタンスは、VM DBインスタンス、自律型データベースまたはExadata Cloud Serviceデータベースです。

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

ha-ords-oci3.pngの説明が続きます
図ha-ords-oci3.pngの説明

ha-ords-oci3.zip

このアーキテクチャには次のコンポーネントがあります。
  • リージョン

    OCIリージョンとは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立しており、長距離の場合は(国または大陸にまたがって)分離できます。

  • 可用性ドメイン

    可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、1つの可用性ドメインでの障害がリージョン内の他の可用性ドメインに影響を与えることはほとんどありません。このアーキテクチャのリソースは、1つの可用性ドメインにデプロイされます。

  • フォルト・ドメイン

    フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインに3つのフォルト・ドメインがあり、それぞれに電源とハードウェアが独立しています。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションは、物理サーバーの障害、システム・メンテナンスおよびフォルト・ドメイン内の電源障害を許容できます。このアーキテクチャのリソースは、複数のフォルト・ドメインにデプロイされます。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、ソフトウェアで定義されたカスタマイズ可能なネットワークであり、OCIリージョン内に設定します。VCNは、従来のデータ・センター・ネットワークと同様に、ネットワーク環境の完全な制御を可能にします。VCNには重複しない複数のCIDRブロックを含めることができ、VCNの作成後にそれらを変更できます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。

    このリファレンス・アーキテクチャでは、ORDSを持つコンピュート・インスタンスはロード・バランサとともにパブリック・サブネットにアタッチされますが、データベースはプライベート・サブネットまたはパブリック・サブネットのいずれかを使用できます。データベース・セキュリティのベスト・プラクティスは、可能なかぎりデータベース・インスタンスをプライベート・サブネットに配置します。

  • ロード・バランサ

    Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。このロード・バランサのパブリックIPは、必要に応じてカスタム・ドメイン名を登録できる場所としても機能します。

  • APIゲートウェイ

    Oracle Cloud Infrastructure API Gatewayでは、ネットワーク内からアクセスでき、必要に応じてパブリック・インターネットに公開できるプライベート・エンドポイントを使用してAPIを公開できます。エンドポイントは、API検証、リクエストとレスポンスの変換、CORS、認証と認可およびリクエスト制限をサポートします。

  • コンピュート・インスタンス/ORDSホスト

    Oracle Cloud Infrastructure Computeでは、コンピュート・ホストをプロビジョニングおよび管理できます。リソース要件(CPU、メモリー、ネットワーク帯域幅およびストレージ)を満たすシェイプでコンピュート・インスタンスを起動できます。コンピュート・インスタンスを作成したら、セキュアにアクセスし、再起動し、ボリュームをアタッチおよびデタッチして、不要になったら終了できます。このアーキテクチャのWebサーバーは、x86またはARM CPUアーキテクチャを使用してコンピュート仮想マシンで実行されます。

  • データベース・インスタンス

    Databaseサービスは、自律型および共同管理のOracle Database Cloudソリューションを提供します。Autonomous Databaseは事前構成済で、トランザクション処理またはデータ・ウェアハウス・ワークロードに適した完全に管理された環境です。共同管理ソリューションは、ベア・メタル、仮想マシンおよびExadata DBシステムであり、ニーズに合ったリソースや設定でカスタマイズできます。

    このリファレンス・アーキテクチャは、自律型データベースまたは共同管理データベース・インスタンスに使用できます。

  • ネットワーク・セキュリティ・グループ(NSG)

    NSGは、コンピュート・インスタンスの仮想ファイアウォールとして機能します。OCIのゼロ・トラスト・セキュリティ・モデルを使用すると、すべてのトラフィックが拒否され、VCN内のネットワーク・トラフィックを制御できます。NSGは、単一のVCN内の指定されたVNICのセットにのみ適用されるイングレスおよびエグレス・セキュリティ・ルールのセットで構成されます。このアーキテクチャでは、ロード・バランサ、Webサーバーおよびデータベースに対して個別のNSGが使用されます。

  • ルート表

    仮想ルート表には、通常ゲートウェイを介して、サブネットからVCN外部の宛先にトラフィックをルーティングするルールが含まれます。

  • インターネット・ゲートウェイ

    インターネット・ゲートウェイは、VCN内のパブリック・サブネットとパブリック・インターネット間のトラフィックを許可します。

  • セキュリティ・リスト

    セキュリティ・リストは、サブネット内のすべてのVNIC/インスタンスに対して入出力が許可されるトラフィックのタイプを指定する、イングレス・ルールおよびエグレス・ルールのセットです。セキュリティ・リストはサブネット・レベルで適用されますが、NSGはVNICレベルで適用されます。どちらも事実上、VNICのファイアウォールとして機能します。OCIのゼロトラスト・セキュリティ・モデルでは、VNICへのすべてのトラフィックが拒否されます。トラフィックをVNICに許可するには、SLとNSGの両方がトラフィックを明示的に許可する必要があります。

  • ゼロトラスト・パケット・ルーティング(ZPR)

    OCIには、SLおよびNSGに加えて、ゼロトラスト・パケット・ルーティングと呼ばれるネットワーク・セキュリティ構成があります。ZPRは、レイヤー4で動作するインテントベースのセキュア・ネットワーキングであり、人間が読めるポリシー言語で実装できます。セキュリティ属性(ZPRのタグ)をリソースに割り当てることで、認可されたエンティティのみがデータベースやアプリケーション・サーバーなどの機密コンポーネントと通信できるように、きめ細かいアクセス制御を作成できます。このアプローチにより、不正アクセスのリスクが軽減されるだけでなく、アプリケーションの進化に伴ってポリシー管理が簡素化されます。ZPRは既存のNSGおよびSLとともに動作し、ネットワーク・アーキテクチャの変更に適応するより包括的なセキュリティ・ポスチャを提供します。ここでは、ネットワークアーキテクチャーが将来どのように変化/変化しても、必要なトラフィック(フロー方向、プロトコル、およびポート)のみが許可されるように、各サブネットのノードにセキュリティー属性(特殊なZPRタグ)を割り当てることができます。

レコメンデーション

次の推奨事項を開始点として使用します。 実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。
  • VCN

    VCNを作成するときには、必要なCIDRブロックの数を決定し、VCN内のサブネットにアタッチする予定のリソースの数に基づいて各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。

    プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。

    VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。

    サブネットを設計するときには、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能できる同じサブネットにアタッチします。

    リージョナル・サブネットを使用します。

    ネットワーク境界ごとにファイアウォールをデプロイすることを検討してください。

  • ロード・バランシング

    OCIは柔軟なロード・バランシングを提供します。上限と下限を指定してロード・バランサを作成すると、受信するリクエストの数に基づいてスケーリングできます。境界の範囲は、10mbpsから8000mbpsまでです。マルチADまたはマルチリージョンのロード・バランシングが必要なインスタンスの場合は、トラフィック管理ステアリング機能でDNS Cloud Serviceを使用します。

  • セキュリティ

    Oracle Cloud Guardを使用して、Oracle Cloud Infrastructure内のリソースのセキュリティをプロアクティブにモニターおよびメンテナンスします。クラウド・ガードでは、定義できるディテクタ・レシピを使用して、リソースにセキュリティの弱点がないか確認し、オペレータおよびユーザーにリスクのあるアクティビティがないか監視します。構成の誤りやセキュアでないアクティビティが検出されると、クラウド・ガードは修正アクションを推奨し、ユーザーが定義できるレスポンダ・レシピに基づいてそれらのアクションの実行を支援します。

    最大限のセキュリティーを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーン内のリソースは、パブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。リソースをセキュリティ・ゾーンで作成および更新すると、Oracle Cloud Infrastructureでは、その操作がセキュリティ・ゾーン・レシピのポリシーに対して検証され、ポリシーに違反する操作が拒否されます。

  • データベース・インスタンス

    本番アプリケーションの場合、Oracleデータベース・インスタンスは、OCIのOracle Maximum Availability Architecture (MAA)デプロイメント・モデルに準拠している必要があります。これらのガイドラインに従うことで、データベースが高可用性であるだけでなく、停止や災害が発生した場合にも保護されます。これらのアーキテクチャでは、DRインスタンスを使用するレポート・データベースの利点も得られます。

    MAAアーキテクチャは、Oracle Cloud Infrastructure Databaseサービス(共同管理と自律の両方)に組み込まれています。Data Guard、GoldenGate、RACおよび自動バックアップはただちに使用可能であり、該当する場合は本番環境で使用する必要があります。

    Oracle Cluster Registry (OCR)Oracle DatabaseとともにRACを使用する場合は、ORDSで使用されるデータベース接続情報が個々のノードではなくSCANリスナーを指していることを確認してください。

  • Compute/ORDSインスタンス

    コンピュート中間層のサイズを設定する場合は、次のチャートで推奨事項を確認してください。

    リファレンス・アーキテクチャ・サイズ(仮想マシン)

    コンパートメントで使用可能なシェイプのリストを確認するには、CLI/SDKを介してList Shapes操作を実行することもできます。詳細は、List Shapes APIドキュメントおよび「Computes Shapes」を参照してください。詳細は、後述の「Explore More」からアクセスできます。

    OCIで予測される月次コンピュート・コストを確認するには、Cost Estimatorを使用します。請求の詳細は、「請求および原価管理」ページで確認できます。費用の見積りと「請求および原価管理」の両方には、次の「詳細」からアクセスできます。

    リファレンス・アーキテクチャ・サイズ(ベア・メタル)

考慮事項

このリファレンス・アーキテクチャをデプロイする場合は、次の点を考慮してください。

  • パフォーマンス

    コンピュート、ロード・バランサおよびデータベース・クラウド・インスタンスはすべて、負荷の増加に対応するようにスケーリングできます。コンピュート/ORDS層を使用すると、追加のインスタンスをすばやく作成してロード・バランサ構成に追加できます。データベース層では、負荷が増加したときにCPU/メモリーを自動スケーリングするようにAutonomous Databaseを設定できます。共同管理インスタンスの場合、VMベースのサービスは、VMで使用されるCPUの数をスケーリングできます。Exadataクラウド・サービスの場合、X8MプラットフォームはCPUのスケーリングのみできませんが、RACクラスタにノードを追加して計算能力を追加できます。

  • セキュリティ

    サブネットおよびNSGイングレス/エグレス・ルールでは、必ずきめ細かいルールを使用してください。サブネット内のインスタンスの特定のIPに対する、予想されるポート経由のトラフィックのみが必要です。コンピュート層またはデータベース層へのアクセスが必要な場合は、Bastion as a Serviceを使用してアクセスします。これにより、権限のあるユーザーのみがこれらのインスタンスにアクセスでき、アクセス権が付与されている特定のインスタンスにのみアクセスできます。要塞をサービスとして使用することは、SSHポートをパブリック・インターネットに公開するよりもはるかに安全な方法です。

  • 可用性

    データベース・デプロイメントについては、Oracle Maximum Availability Architecture (MAA)ガイドに従ってください。ORDSでは、ロード・バランサを含む複数の中間層をお薦めします。再度、Oracle DatabaseとともにRACを使用する場合は、ORDSで使用されるデータベース接続情報が個々のノードではなくSCANリスナーを指していることを確認してください。

  • コスト

    各コンピュート層および各データベース層に自動スケーリングおよび一般的に使用すると、CPU、メモリーまたはインスタンスを過剰または無駄にすることなく、使用した分のみの支払を行うことができるコストの管理に役立ちます。柔軟なロード・バランサを使用してコストを制御することもできます。

デプロイ

1回のクリックで、このアーキテクチャのコードをOracle Cloud Infrastructure Resource Managerにプルし、スタックを作成してデプロイできます。

Oracle Cloud Infrastructure Resource Manager Serviceを介して利用可能なアーキテクチャでは単一の自律型データベースが使用されますが、前述のアーキテクチャでは、Oracleは本番シナリオでディザスタ・リカバリ・データベースを推奨しています。このサンプル・リファレンス・アーキテクチャでは、コスト削減を可能にし、速度を向上させ、コンピュート/ORDS高可用性(HA)デプロイメントに集中させるために使用されます。
Oracle Cloud Infrastructure Resource Managerのサンプル・スタックを使用して、このアーキテクチャをデプロイします:
  1. をクリックしますOracle Cloudへのデプロイ

    まだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。

  2. スタックをデプロイするリージョンを選択します。
  3. 画面に表示されるプロンプトと手順に従ってスタックを作成します。
  4. スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
  5. ジョブが完了するまで待機し、計画をレビューします。

    変更を行うには、「スタックの詳細」ページに戻り、「スタックの編集」をクリックして、必要な変更を行います。次に、「プラン」アクションを再度実行します。

  6. これ以上の変更が必要ない場合は、「スタックの詳細」ページに戻り、「Terraformアクション」をクリックして、「適用」を選択します。

詳細の参照

次の追加のリソースを使用して、Oracle Cloud Infrastructureに高可用性を備えたOracle REST Data Servicesのデプロイについてさらに学習します:

.

確認

  • 作成者: Gagan S.コーリ
  • コントリビュータ: Eric Peterson, Mayur Raleraskar, Robert Wunderlich, Sherwood Zern

変更ログ

このログには、重要な変更が一覧表示されます。