Oracle アプリケーションを設計する
Oracle アプリケーションをクラウドに移行するのは複雑なプロセスです。 移行中の問題を回避したり、移行の失敗を回避したりできるように、アプリケーションの各バージョンでサポートされている機能を理解する必要があります。 組織は、アプリケーションをリフトアンドシフトすることを望んでいません。 また、アーキテクチャを最新化し、機能要件と非機能要件を整合させたいと考えています。 移行の目標を確実に達成するには、これらの要件を主要なクラウド アプリケーション設計パターンと共に確認する必要があります。
一般的な Oracle アプリケーションの例としては、Siebel、E-Business Suite、JD Edwards、PeopleSoft があります。 これらのアプリケーションには、アプリケーション層とデータベース層の間に強い依存関係があります。 異なるクラウド ベンダー間で 2 つの層を分離すると、待機時間が発生し、顧客のエクスペリエンスが低下する可能性があります。 2 つのレベルをホストする方法を決定する前に、常に適切な技術的評価を行う必要があります。
アプリケーションごとに、アプリケーション ベンダーが提供する設計上の考慮事項に注意し、各設計に使用する Azure サービスの特性を考慮する必要があります。 Azure クラウドには、パフォーマンス、信頼性、セキュリティ、高可用性のソリューションにつながる可能性のある多くの機能が用意されています。
より具体的なアーキテクチャ ガイダンスについては、「Azure Virtual Machines 上のデータベースを使用した Oracle アプリケーションのアーキテクチャ」を参照してください。
Recommendations
Oracle アプリケーションのクラウドへの移行を計画するには、次の推奨事項を使用します。
ネットワークとセキュリティ
- Microsoft Entra IDを使用してシングル サインオン (SSO) を構成することを検討してください。 お客様は、SSO を使用して、インターネット ブラウザー経由で Oracle アプリケーションに接続できます。 詳細については、「 エンタープライズ アプリケーションの SSO を有効にする」を参照してください。
- クラウド インストールへのプライベート接続の使用を検討してください。 Azure には、 Azure ExpressRoute 接続やサイト間 VPN 接続などのプライベート接続機能が用意されています。
- 顧客がインターネットからアプリケーションにアクセスする場合は、 アプリケーション ゲートウェイを検討してください。 Azure Application Gatewayには、2 つの組み込み機能が用意されています。 Web アプリケーション ファイアウォールとして動作し、レイヤー 7 ロード バランサーが組み込まれています。 Application Gatewayでは、ポート 443 (HTTPS) でのアクセスのみがサポートされます。
- ネットワークをセキュリティで保護するもう 1 つのオプションは、Azure Firewallです。 このコンポーネントは、Web サービスを一般的な悪用や脆弱性から保護します。 Oracle アプリケーションの高可用性を維持し、コンプライアンス要件を満たすのに役立ちます。
- ネットワークが特定のポートと IP アドレスでのみトラフィックを許可するように、サブネット レベルでネットワーク セキュリティ グループ を設定することを検討してください。
- アプリケーションで Secure Shell (SSH) プロトコルまたはリモート デスクトップ プロトコル (RDP) アクセスが必要な場合は、 Azure Bastion ホストをジャンプ サーバーとしてデプロイして、高度で成熟したセキュリティ体制のための追加のセキュリティを提供します。
Web 層とアプリケーション層
- 仮想マシン (VM) にアプリケーションをデプロイします。 可用性 セット にこれらの VM をグループ化して、全体的な可用性を向上させます。
- アプリケーションを自動スケーリングする必要がある場合は、Azure Virtual Machine Scale Setsの使用を検討してください。
- VM を 1 つの可用性ゾーンに配置して、それらを物理的に近づけます。 ただし、Azure フットプリントが増えるにつれて、1 つの可用性ゾーンが複数の物理データセンターにまたがる可能性があることに注意してください。 物理データセンター間の距離によって、アプリケーションに影響するネットワーク待機時間が発生する可能性があります。 VM を可能な限り近づけ、可能な限り短い待機時間を実現するには、 近接配置グループ内にデプロイします。
データベース層
- Oracle Data Guard を使用してセカンダリ サーバーにレプリケートされるプライマリ サーバーとしてデータベース層をデプロイすることを検討してください。
- 2 つのゾーンを使用してプライマリ サーバーとセカンダリ サーバーを 1 つのリージョンにデプロイする場合は、リージョン内のゾーン間のネットワーク待機時間を確認した後、Data Guard 同期レプリケーション構成の使用を検討してください。
- プライマリ サーバーとセカンダリ サーバーを 2 つのリージョンにデプロイする場合は、Data Guard 非同期レプリケーション構成の使用を検討してください。
- データ損失ゼロ レプリケーション戦略が必要な場合は、非同期レプリケーション構成の使用を検討してください。
- Data Guard に加えて、Striim、Qlik、GoldenGate、Active Data Guard などの統合オプションもあります。
バックアップとデータ保護
- Azure Backupを使用して、アプリケーションとデータベースの VM をバックアップすることを検討してください。
- プライマリ リージョンとは異なるリージョンにバックアップを配置して、リージョンの障害に対する追加の保護を提供することを検討してください。
- レプリケーション機能が組み込まれているストレージ コンポーネントを使用してデータベースをバックアップすることを検討してください。
障害復旧
- 次の例のような信頼性の高いアーキテクチャを構築します。
- Azure Site Recovery などの Azure 組み込みのディザスター リカバリー ソリューションの使用を検討してください。
次のステップ
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示