この記事では、Oracle データベースが存在するか、併置されている Azure IaaS に Oracle アプリケーションをデプロイするための参照アーキテクチャについて説明します。
Oracle ワークロードは、Oracle データベースだけでなく、Siebel、PeopleSoft、JD Edwards、E-Business Suite、またはカスタマイズされた WebLogic サーバー アプリケーションなどの Oracle ファースト パーティ アプリケーションで構成されます。 Azure Infrastructure as a Service (IaaS) への Oracle アプリケーションのデプロイは、Oracle データベースと共に Oracle ワークロードにクラウドを使用することを検討している組織にとって一般的なシナリオです。 Microsoft では、このプロセスを容易にするための参照アーキテクチャとベスト プラクティスを提供しています。
一般的なアプリケーション移行ガイドライン
Oracle アプリケーションが Azure IaaS に移行する際に、アプリケーションの種類に関係なく従う必要がある一般的な設計上の考慮事項があります。 いくつかの考慮事項は、アプリケーションに固有のものです。 このセクションでは、すべてのアプリケーションの共通の設計上の考慮事項を示し、アプリケーション固有の考慮事項については、各アプリケーションで説明します。
ネットワークとセキュリティ
Azure 上の Oracle アプリケーションに対して提供されるネットワーク設定では、ネットワークとセキュリティに関する考慮事項のさまざまな側面について説明します。 推奨されるネットワーク設定の内訳を次に示します:
Microsoft Entra ID と SAML でのシングル サインオン (SSO): Security Assertions Markup Language (SAML) プロトコルを使用してシングル サインオン (SSO) に Microsoft Entra ID を使用 します。 この SSO を使用すると、ユーザーは 1 回認証で複数のサービスにシームレスにアクセスできます。
Microsoft Entra アプリケーション プロキシ: Microsoft Entra アプリケーション プロキシ (特にリモート ユーザー向け) の使用を検討してください。 このプロキシを使用すると、ネットワークの外部からオンプレミスのアプリケーションに安全にアクセスできます。
ExpressRoute を介した 内部ユーザーのルーティング: 内部ユーザーの場合は、Azure サービスへの専用のプライベート接続のために Azure ExpressRoute 経由でトラフィックをルーティングし、待機時間が短く、安全な通信を確保します。
Azure Firewall: 必要に応じて、セキュリティを強化するためにアプリケーションの前に Azure Firewall を構成できます。 Azure Firewall は、承認されていないアクセスや脅威からリソースを保護するのに役立ちます。
外部ユーザー向けの Application Gateway: 外部ユーザーがアプリケーションにアクセスする必要がある場合は、Azure Application Gateway の使用を検討してください。 Web アプリケーションを保護するための Web アプリケーション ファイアウォール (WAF) 機能と、トラフィックを分散するためのレイヤー 7 負荷分散機能が用意されています。
ネットワーク セキュリティ グループ (NSG): ネットワーク セキュリティ グループ (NSG) を使用してサブネットをセキュリティで保護します。 NSG を使用すると、セキュリティ規則を定義することで、ネットワーク インターフェイス、Virtual Machines、サブネットへの受信トラフィックと送信トラフィックを制御できます。
ロールベースのアクセス制御 (RBAC): 特定の個人またはロールにアクセス権を付与するには、Azure RBAC を使用します。 RBAC は、ロールとアクセス許可に基づいて、Azure リソースへのきめ細かいアクセス制御を提供します。
SSH アクセス用の Bastion ホスト: SSH アクセスのセキュリティを 強化するために、ジャンプ ボックスとして Bastion ホスト を使用します。 Bastion ホストは、管理者が仮想ネットワーク内の Virtual Machines にアクセスするためのセキュリティで保護されたゲートウェイとして機能します。 このホストは、セキュリティのレイヤーを追加します。
その他の考慮事項:
- データ暗号化: 保存データおよび転送中のデータが暗号化されていることを確認します。 Azure には、この目的のために Azure Disk Encryption や SSL/TLS などのツールが用意されています。
- パッチ管理: 既知の脆弱性から保護するために、EBS 環境を定期的に更新してパッチを適用します。
- 監視とログ記録: Azure Monitor と Azure Defender for Security を実装して、セキュリティの脅威と異常について環境を継続的にチェックします。 監査とフォレンジック分析のログ記録を設定します。
要約すると、これらのネットワークとセキュリティの設定は、Azure IaaS で Oracle アプリケーションをホストするための堅牢で安全な環境を提供することを目的としています。 内部ユーザーと外部ユーザーの両方に対して、認証、アクセス制御、およびネットワーク セキュリティのベスト プラクティスが組み込まれています。 また、アプリケーション サーバーへの SSH アクセスの必要性も考慮します。 これらのレコメンデーションは、Azure IaaS に Oracle アプリケーションをデプロイするための成熟したセキュリティ体制を設定するのに役立ちます。
Web 層: Web 層は要求を負荷分散し、アプリケーション層、データベース層、バックアップに応じて要求を送信します。
アプリケーション層: 通常、アプリケーション層には、アプリケーション サーバーと共有ファイル システムが含まれます。
自動スケールの場合、Virtual Machine Scale Sets は、 ワークロードに適応するためのカスタム スケーリング ルールを使用して、需要に基づいて複数の仮想マシンをスケールアウトするのに最適な選択肢です。
Azure Subject Matter Experts (SM) と共同作業して、アーキテクチャの徹底的な評価を実行します。 これらは、パフォーマンス、可用性、スケーラビリティなど、特定の要件に基づいて最適な Azure サービスを決定するのに役立ちます。 アーキテクチャを設計するときは、コスト、データ セキュリティ、コンプライアンス、ディザスター リカバリーなどの要因を考慮することを忘れないでください。
また、効率とコスト効率を確保するために、Azure リソースを継続的にチェックして最適化することも不可欠です。
負荷分散とスループット: アプリケーション サーバーのワークロード特性を評価することが重要です。 一部のサーバーは、他のサーバーよりも多くのタスクを処理し、高いスループットを作成します。 この情報は、リソースが効果的に割り当てられるように Azure 仮想マシン スケール セットと負荷分散構成を設計する際に重要です
データベース層: Azure IaaS 上の Oracle Data Guard for Oracle では、HA アーキテクチャをお勧めします。 アプリケーションには特定の種類の HA セットアップが必要であり、各アプリケーションの下に一覧表示されます。
Backup - Backup は、アプリケーション層とデータベース層から送信されます。 これら 2 つのレベルを 2 つの異なるベンダーに分割すべきではない理由の 1 つに過ぎません。 データベースのバックアップは、Premium Files 上の Azure Backup ボリューム スナップショット によってセカンダリ リージョンに対して実行されます。
ディザスター リカバリー - 選択できるさまざまなソリューションがあります。 それはあなたの要求次第です。 アーキテクチャは高可用性を実現するように構築されています。 アプリケーション層をレプリケートする場合は、Azure Site Recovery を使用できます。 選択できるもう 1 つのソリューションは、 マネージド ディスクの冗長性オプションです。どちらのソリューションもデータを複製します。 マネージド ディスクの冗長性オプションは、アーキテクチャを簡略化できるソリューションですが、いくつかの制限もあります。
Azure 上の Siebel
Oracle Siebel CRM は、多くの企業で推奨されるエンタープライズ グレードの CRM ソリューションです。 Oracle のポートフォリオで最も複雑なアプリケーションの 1 つであり、トランザクション、分析、エンゲージメントの機能を組み合わせて、顧客向けの運用を管理します。
イノベーション パック 16 以前の Azure Virtual Machines での Siebel アプリケーションデプロイの推奨アーキテクチャを次に示します:
イノベーション パック 16 以前の Azure Virtual Machines での Siebel アプリケーション デプロイの推奨アーキテクチャを示す図。
次の図は、イノベーション パック 17 以前の Azure Virtual Machines での Siebel アプリケーションのデプロイのアーキテクチャです:
イノベーション パック 17 以前の Azure Virtual Machines での Siebel アプリケーション デプロイの推奨アーキテクチャを示す図。
Oracle Siebel の設計に関する考慮事項
ネットワークとセキュリティ: Azure 上の Oracle Siebel のネットワーク設定は、一般的なネットワークとセキュリティに関する考慮事項に従う必要があります。
移行は、Siebel Tool サブネットを使用して行う必要があります。
アプリケーション層
- バージョン 17 以降 - アプリケーションとデータベース上の特定のサーバーとユーティリティの構成が必要です。
データベース層
- データベースと Siebel のバージョンが一致していることを確認します。
- Oracle Data Guard の Oracle リファレンス アーキテクチャを使用して、プライマリ データベースとレプリケートされたデータベースがセカンダリ データベースにコピーされていることを確認します。
Azure 上の E-Business スイート
Oracle E-Business Suite (EBS) は、サプライ チェーン管理 (SCM) および顧客関係管理 (CRM) を含む一連のアプリケーションです。 EBS は SCM および CRM システムであるため、通常はサードパーティ システムへの多くのインターフェイスがあります。 次のアーキテクチャは、1 つのリージョン内で高可用性を実現するように構築されています。
次の図では、外部ユーザーが企業ネットワークを通過しないことを前提としています。
外部ユーザーが企業ネットワークを通過しないオンプレミスのネットワークを示す図。
Oracle EBS の設計に関する考慮事項
データベース層 - プライマリおよびセカンダリ データベースは、1 つのデータセンター内に存在する必要があります。 同期構成を使用する必要があります。 データセンター間でアプリケーションをインストールする場合は、非同期モードで Data Guard を構成する必要があります。
JD Edwards on Azure
Oracle の JD Edwards は、包括的なエンタープライズ リソース計画ソフトウェアの統合アプリケーション スイートです。 JD Edwards は現在、サプライ チェーン、倉庫管理、ロジスティクス、製造リソース計画などで使用されています。 アプリケーションを使用しているため、他のシステムへのインターフェイスも重要であることがわかります。
次のアーキテクチャは、高可用性を実現するように構築されています。 外部ユーザーが企業ネットワーク経由でアクセスしていないと想定しました。 外部ユーザーが企業ネットワークを使用してアプリケーションにアクセスする場合、次のようにネットワーク上でアーキテクチャを簡略化できます。
オンプレミス ネットワークと外部ユーザー示す図。
JD Edwards の設計上の考慮事項
Web 層: 通常、アプリケーション Web 層は複数のアプリケーション サーバーで構成されます。 JD Edwards では、多くの場合、ルールはこれらのアプリケーション Web サーバーに保存されます。
プレゼンテーション層: プレゼンテーション層の各インスタンスはストレージに関連付けられます。 インスタンス間の依存関係を切断すると、待機時間が長くなる可能性があるため、慎重に評価することが重要です。
サーバーのパフォーマンスの変動: 一部のサーバーでは、他のサーバーよりも多くのタスクを処理し、より高いスループットを作成できます。 設計フェーズでは、インフラストラクチャがピーク時のワークロードを効率的に処理できるように、このスループットの変動を評価することが不可欠です。
再設計: 自動スケールに Azure 仮想マシン スケール セットを使用する場合、JD Edwards セットアップの再設計は必要ありません。 これは、アプリケーションのアーキテクチャに大きな変更を加えることなく実装できるスケーラブルなソリューションです。
データベース層 - プライマリとセカンダリは 1 つのデータセンター内に留まり、同期構成を使用する必要があります。 データセンター間でアプリケーションをインストールする場合は、非同期モードで Data Guard を構成する必要があります。 データベース層のデータは、Azure Storage に直接送信されます。 ストレージは、現在のアーキテクチャのセットアップに依存します。
Azure 上の PeopleSoft
Oracle の PeopleSoft アプリケーション スイートには、人事管理と財務管理のためのソフトウェアが含まれています。 このアプリケーション スイートは多層化されており、アプリケーションとしては人事管理システム (HRMS)、顧客関係管理 (CRM)、財務およびサプライ チェーン管理 (FSCM)、エンタープライズ パフォーマンス管理 (EPM) が含まれています。
オンプレミス ネットワークと ExpressRoute を使用する内部ユーザーを示す図。
PeopleSoft の設計に関する考慮事項
アプリケーション層: アプリケーション層には、いくつかのタスクとサーバーが含まれています。 ビジネス ロジックとプロセスを実行するだけでなく、データベースへの接続も維持します。 この依存関係が切断されるとすぐに、待機時間が発生します。
アプリケーション層とデータベース層の依存関係: アプリケーション層とデータベース層の間の待機時間を最小限に抑えることが重要です。 アプリケーションとデータベース層を同じクラウド プロバイダー (この場合は Azure) に配置することで、ネットワーク待機時間を短縮できます。 Azure には、層間の低遅延接続を確保するために、仮想ネットワーク (VNet) ピアリングや ExpressRoute などのさまざまなネットワーク オプションとサービスが用意されています。
オペレーティング システムに関する考慮事項: プロセス スケジューラで Windows オペレーティング システムが特に必要な場合でも、Azure Virtual Machines で実行できます。 Azure ではさまざまな Windows Server バージョンがサポートされており、アプリケーションの要件を満たすバージョンを選択できます。
アーキテクチャの評価: スケーラビリティ、可用性、パフォーマンスなど、アーキテクチャの要件を慎重に評価します。 高可用性とスケーラビリティを確保するために、負荷分散された構成で複数のアプリケーション サーバー インスタンスを設定することを検討してください。
データベース層 - プライマリ データベースとセカンダリにレプリケートされたデータベースは、1 つのデータセンター内に存在する必要があります。 同期構成を使用する必要があります。 データセンター間でアプリケーションをインストールする場合は、非同期モードで Data Guard を構成する必要があります。
次のステップ