Oracle Cloud Infrastructureで高可用性を備えたOracle REST Data Servicesを展開

Oracle Cloud InfrastructureおよびRESTに高可用性を備えたOracle REST Data Services (ORDS)をデプロイして、データベースを有効にします。

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

ORDSは、Oracle WebLogic Server、Apache Tomcatおよびスタンドアロン・モードを使用したデプロイメントをサポートすることで、高い柔軟性を提供します。組込みのJDBCドライバを使用して接続が提供されるため、Oracleホームが必要ないため、ORDSによってデプロイメント・プロセスがさらに簡略化されます。

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

アーキテクチャ

このアーキテクチャでは、Oracle Cloud Infrastructureで高可用性を持つOracle REST Data Servicesをデプロイする方法について説明します。

アーキテクチャは、単一のリージョン内の仮想クラウド・ネットワーク(VCN)から始まります。このVCNは複数の可用性ドメイン(AD)にまたがることができますが、この参照アーキテクチャでは単一のADを使用します。そのADには、ハードウェアとインフラストラクチャをグループ化したAD内の領域である複数のフォルト・ドメインが含まれます。複数のフォルト・ドメインにわたってORDSを使用したコンピュートVMをデプロイし、高可用性の目標を支援します。

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

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

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

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

ha-ords-oci2-oracle.zip

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

    Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる、1つ以上のデータ・センターを含むローカライズされた地理的領域です。リージョンは他のリージョンから独立し、広大な距離(国または大陸間)を分離できます。

  • 可用性ドメイン

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

  • フォルト・ドメイン

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

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

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

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

  • ロード・バランサ

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

  • Computeインスタンス/ORDSホスト

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

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

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

    このリファレンス・アーキテクチャは、Autonomous DatabasesまたはCo-Managed Databaseインスタンスのいずれかに使用できます。

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

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

  • ルート表

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

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

    インターネット・ゲートウェイを使用すると、VCN内のパブリック・サブネットとパブリック・インターネット間のトラフィックが許可されます。

  • セキュリティ・リスト

    セキュリティ・リストは、インスタンスの仮想ファイアウォールとして機能し、内外で許可されるトラフィック・タイプを指定するイングレスおよび出力ルールが含まれます。

推奨

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

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

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

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

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

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

  • セキュリティ

    Oracle Cloud Guardを使用して、Oracle Cloud Infrastructureでのリソースのセキュリティを予防的に監視およびメンテナンスします。Cloud Guardは、セキュリティ上の弱点についてリソースを調査し、オペレータやユーザーにリスクのあるアクティビティを監視するために定義できるディテクタ・レシピを使用します。構成ミスや安全でないアクティビティが検出された場合、クラウド・ガードは是正措置を推奨し、定義できるレスポンダ・レシピに基づいてこれらのアクションの実行を支援します。

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

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

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

    MAAアーキテクチャはOCI Databaseサービスに適切に組み込まれており、共通管理型と自律型の両方です。Data Guard、GoldenGate、RACおよび自動バックアップは最初から使用可能で、必要に応じて本番環境に使用する必要があります。

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

  • コンピューティング/ORDSインスタンス

    コンピュート・ミッドティアのサイズを設定する場合は、次のチャートを参照して推奨事項を確認してください。

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

    参照アーキテクチャ・サイズ(ベア・メタル)

  • 柔軟性の高いロード・バランシング

    ロード・バランサの上限と下限を作成して、受信するリクエスト数に基づいてスケーリングできるようになりました。最大8000mbpsの10mbpsほど小さくすることができます。

注意事項

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

  • パフォーマンス

    コンピューティング、ロード・バランサ、データベース・クラウド・インスタンスはあらゆる規模で、増大するロードを処理できます。コンピュート/ORDS層を使用すると、追加インスタンスを迅速に作成してロード・バランサ構成に追加できます。データベース層の場合、Autonomous Databaseは、負荷が増加したときにCPU/メモリーの自動スケールに設定できます。共同管理インスタンスの場合、VMベースのサービスはVMで使用されるCPUの数をスケールできます。Exadata Cloud Serviceの場合、X8MプラットフォームはCPUをスケーリングするだけでなく、ノードをRACクラスタに追加して、追加のコンピューティング能力を追加できます。

  • セキュリティ

    サブネットおよびNSGイングレス/エグレス・ルールには、きわめて詳細なルールを使用してください。必要なポートを介したトラフィックは、サブネット内のインスタンスの特定のIPにのみ必要です。コンピュート層またはデータベース層にアクセスする必要がある場合は、Bastion as a Serviceを使用してアクセスします。これにより、認可されたユーザーのみがこれらのインスタンスにアクセスでき、アクセス権を付与されている特定のインスタンスにのみアクセスできます。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で使用可能なアーキテクチャでは単一の自律型データベースを使用しますが、前述のアーキテクチャでは、本番シナリオでの障害時リカバリ・データベースをお薦めします。このサンプル・リファレンス・アーキテクチャでは、Compute/ORDSの高可用性デプロイメントに、コスト削減、速度および注意を集中させるために使用されます。
Oracle Cloud Infrastructure Resource Managerのサンプル・スタックを使用して、このアーキテクチャをデプロイします。
  1. Oracle Cloudに展開をクリックします。

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

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

    変更を行うには、「スタック詳細」ページに戻り、「スタックの編集」をクリックして必要な変更を行います。次に、「計画」処理を再実行します。

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