Oracle Cloud InfrastructureでのOracle Commerce Platform (ATG)のデプロイ
Oracle Commerce Platform (ATG)の顧客は、複雑さを処理し、それに応じてインフラストラクチャ・プロビジョニングをスケーリングできる必要があります。
静的プロビジョニングは非効率性につながる可能性があります。低プロビジョニングは顧客体験の低下につながる可能性があり、オーバープロビジョニングは収益への悪影響につながる可能性があります。
Oracle Cloud Infrastructure上のOracle Commerce Platform:
- パフォーマンスの向上:顧客トラフィックに基づいてすべてのコンポーネントをスケーリングします。
- 複雑さの軽減:ほとんどのサービスは、ボタンをクリックすると変更されます。
- インフラストラクチャ・コストの削減:ホット・セールス中の追加インフラストラクチャにPay - as - You - Goモデルを使用します。
- 市場投入までの時間の短縮:プロビジョニングは数時間ではなく数分で実行されます。
- ライセンスの最適化:独自のライセンス(BYOL)を使用すると、現在の顧客ライセンスが最大化されます。
アーキテクチャ
このリファレンス・アーキテクチャは、Oracle Cloud Infrastructure上のOracle Commerce Platformを示しています。Oracle Cloudコンポーネントは、プライベート仮想クラウド・ネットワーク(VCN)にデプロイされたクラスタ・グループを使用してすべてのカスタム・サード・パーティ・ネットワーク・コンポーネントを置き換え、フォルト・ドメインの独自の機能を活用してハードウェアのフォルト・トレランスを改善します。
次の図に、この参照アーキテクチャを示します。
このアーキテクチャには次のコンポーネントがあります。
- リージョン
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる、1つ以上のデータ・センターを含むローカライズされた地理的領域です。リージョンは他のリージョンから独立しており、大規模な距離で(国間または大陸間で)分離できます。
- 可用性ドメイン
可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各アベイラビリティ・ドメインの物理リソースは、フォルト・トレランスを提供する他のアベイラビリティ・ドメインのリソースから分離されます。アベイラビリティ・ドメインは、電源や冷却などのインフラストラクチャ、または内部のアベイラビリティ・ドメイン・ネットワークを共有しません。そのため、ある可用性ドメインで障害が発生しても、リージョン内の他の可用性ドメインに影響を与えることはほとんどありません。
- フォルト・ドメイン
フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティドメインには、独立した電源とハードウェアを備えた3つの障害ドメインがあります。リソースを複数の障害ドメインに分散する場合、アプリケーションは障害ドメイン内の物理的なサーバー障害、システム保守、および電源障害を許容できます。
- 仮想クラウド・ネットワーク(VCN)およびサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定するカスタマイズ可能なプライベート・ネットワークです。従来のデータ・センター・ネットワークと同様に、VCNを使用すると、ネットワーク環境を完全に制御できます。VCNはサブネットに分割でき、サブネットはリージョンまたは可用性ドメインにスコープ指定できます。リージョン・サブネットと可用性ドメイン固有のサブネットの両方を同じVCNに共存できます。サブネットはパブリックまたはプライベートのいずれかになります。
- VPN Connect
VPN Connectは、オンプレミス・ネットワークとOracle Cloud InfrastructureのVCN間のサイト間IPSec VPN接続を提供します。IPSecプロトコル・スイートは、パケットがソースから宛先に転送される前にIPトラフィックを暗号化し、着信時にトラフィックを復号化します。
- FastConnect
Oracle Cloud Infrastructure FastConnectを使用すると、データ・センターとOracle Cloud Infrastructure間に専用のプライベート接続を簡単に作成できます。FastConnectでは、インターネットベースの接続と比較して高帯域幅オプションと信頼性の高いネットワーキング体験が提供されます。
- ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
- Bastion host
Bastionホストは、クラウドの外部からトポロジへのセキュアで制御されたエントリ・ポイントとして機能するコンピュート・インスタンスです。Bastionホストは通常、非武装地帯(DMZ)でプロビジョニングされます。これにより、クラウドの外部から直接アクセスできないプライベート・ネットワークに機密リソースを配置することで、機密リソースを保護できます。トポロジには、定期的に監視および監査できる単一の既知のエントリ・ポイントがあります。そのため、トポロジのより機密性の高いコンポーネントへのアクセスを損なわずに、それらを公開することを回避できます。
- ストアフロント層
ストアフロント・アプリケーションによって、必要なすべてのWebコンポーネントがコンパイルされ、顧客のWebブラウザに送信されます。ストアフロントは、ATG APIまたはAPI GatewayからAPIサービスを直接消費するフロントエンド・テクノロジを使用してデプロイされます。
- ATG API層
ATGは、REST APIを介してすべての機能を公開し、カスタム・フロントエンドで直接使用するか、APIゲートウェイでエンリッチできます。
- Endeca MDEX層
Endecaは、ガイド付きナビゲーション、検索機能およびユーザー・セグメンテーションを提供します。Endecaトポロジには通常、2つのMDEXクラスタが含まれています。
次の図は、異なる障害ドメインに存在する2つのMDEXクラスタを示しています。
- 顧客サービス・センター(CSC)階層
CSCには、システムでより高い権限を持つ独自のユーザー・セットがあります。トラフィックをセグメント化すると、ファイングレイン・アクセス・コントロールが可能になり、監査機能が強化されます。
- 管理層
管理層は、専用サブネット上のビジネス・コントロール・センター、エクスペリエンス・マネージャ、WebLogic管理などのサービスを分離し、ユーザー・トラフィックを管理から分離して、より厳しいアクセス制御を可能にします。
- ファイル・ストレージ
Oracle Cloud Infrastructure File Storageサービスは、永続的でスケーラブルなセキュアなエンタープライズ・グレードのネットワーク・ファイル・システムを提供します。VCN内のベア・メタル、仮想マシンまたはコンテナ・インスタンスからFile Storageサービス・ファイル・システムに接続できます。VCNの外部からOracle Cloud Infrastructure FastConnectおよびIPSec VPNを使用してファイル・システムにアクセスすることもできます。
- Autonomous Transaction Processing
Oracle Autonomous Transaction Processingは、トランザクション処理ワークロード用にチューニングおよび最適化された自己稼働型の自己保護型自己修復型データベース・サービスです。ミッションクリティカルなアプリケーションの要求を満たすように、即座に拡張できます。ハードウェアを構成または管理したり、ソフトウェアをインストールする必要はありません。Autonomous Transaction Processingは、データベースの作成、バックアップ、パッチ適用およびアップグレードを処理します。また、データベースの拡大または縮小も処理します。
お薦め
次の推奨事項を開始点として使用します。実際の要件は異なる場合があります。
- クラスタ・グループ
各フォルト・ドメインに対応するには、アプリケーション・レイヤーごとに3つのクラスタ(MDEXを除く)を持つことを検討してください。
- サブネット分離
分離されたサブネットを使用すると、ファイングレイン・セキュリティ・リストおよびネットワーク・セキュリティ・グループを改善できます。顧客データ・パイプラインと管理パイプラインを混在させないでください。
- 自律型サービス
可能な場合は常に自律型サービスを使用します。デプロイメント設計時には、Autonomous LinuxおよびAutonomous Transaction Processingを検討してください。
- MDEX索引の更新
Endecaには、MDEX索引を更新するための2つのアプローチ(部分更新と完全更新)があります。どちらの更新でもMDEXを停止、更新および起動する必要があります。Endecaには、MDEX索引のセットの更新を可能にする分散グループと呼ばれる論理グループがあります。
一貫性を維持し、停止時間を回避するために、2つの配布グループを使用することをお薦めします。
次の図は、2つの配布グループを使用した索引更新プロセスを示しています。
配布グループ1の更新プロセス。 図update-group1-index.pngの説明
配布グループ2の更新プロセス。 図update-group2-index.pngの説明
注意事項
この参照アーキテクチャをデプロイする際は、次の点を考慮してください。
- バックエンド・サービス
使用可能なすべてのバックエンド・サービスをOracle Cloud Infrastructureに取り込みます。これにより、アーキテクチャが合理化され、Oracle Cloud Infrastructureとオンプレミス・データ・センター間の不要なトラフィックが回避され、待機時間が短縮され、カスタマ・エクスペリエンスが向上します。
Oracle Cloudは、既存のオンプレミス・データ・センターまたはプロバイダに接続するためのIPSec VPNおよび専用のFastConnectソリューションを提供します。
- セキュリティ
ユーザー・トラフィックと管理トラフィックを混在させないでください。クライアントサービスインスタンスにほかの仮想ネットワークインタフェースカード(VNIC)を追加すると、このようなトラフィックを分割できます。
- 可用性
一部のリージョンには複数の可用性ドメインが用意されており、より高い可用性と高い冗長性を実現できます。この冗長性を利用するには、E - Commerceソリューションを複数の可用性ドメインにデプロイすることを検討してください。
また、適切な冗長性を備えた別のリージョンに障害時リカバリ計画を作成することも検討してください。
- コスト
pay - as - you - goモデルを利用します。特別販売時により標準的な仮想マシンを割り当てると、コストが最小限に抑えられ、先行リソースの支払いが回避されます。
デプロイ
Oracle Commerce Platform (ATG)をOracle Cloud Infrastructureにデプロイするために必要なネットワーキング、コンピュートおよびストレージ・インフラストラクチャをプロビジョニングするTerraformコードは、GitHubで使用できます。
- GitHubに移動します。
- リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
README
ドキュメントの指示に従います。