Pro アーキテクチャ
Adobe Commerce on cloud infrastructure Pro アーキテクチャは、ストアの開発、テスト、ローンチに使用できる複数の環境をサポートしています。
- マスター - Platform as a service （PaaS）コンテナにデプロイされる
masterブランチを提供します。 - 統合 – 開発用に 1 つの
integration分岐を提供しますが、1 つの分岐を追加で作成できます。 これにより、最大 2 つの アクティブ ブランチを、Platform as a Service （PaaS）コンテナにデプロイできます。 - ステージング - サービスとしての専用インフラストラクチャ（IaaS）コンテナにデプロイされた単一の
stagingブランチを提供します。 - 実稼働：専用の Infrastructure as a Service （IaaS）コンテナにデプロイされた単一の
productionブランチを提供します。
次の表に、環境の違いの概要を示します。
環境アーキテクチャ
プロジェクトは、integration、staging、production の 3 つのメイン環境ブランチを持つ単一の Git リポジトリーです。 次の図は、Pro 環境の階層関係を示しています。
マスター環境
Pro プロジェクトでは、master ブランチは実稼動環境でアクティブな PaaS 環境を提供します。 サービスを中断することなく実稼動環境をデバッグできるように、常に実 master 動コードのコピーを実稼動環境にプッシュします。
注意事項：
-
masterブランチに基づいてブランチを作成する しないでください。 統合環境を使用して、開発用のアクティブなブランチを作成します。 -
開発、UAT、パフォーマンステストに
master環境を使用しない
統合環境
統合環境は、PaaS と呼ばれるサーバーのグリッド上の Linux コンテナ（LXC）で動作します。 各環境には、サイトをテストするための web サーバーとデータベースが含まれます。 AWSと Azure の IP アドレスのリストについては、 地域の IP アドレスを参照してください。
推奨されるユースケース：
統合環境は、変更をステージング環境と実稼動環境に移行する前に、限定的なテストと開発のために設計されています。 例えば、統合環境を使用して、次のタスクを実行できます。
-
継続的統合（CI）プロセスへの変更がクラウドと互換性があることを確認します
-
ホーム、カテゴリ、製品詳細ページ（PDP）、チェックアウト、管理者などの主要なページでの重要なワークフローのテスト
統合環境で最高のパフォーマンスを得るには、次のベストプラクティスに従います。
-
カタログサイズの制限 – 参考までに、サンプルデータには約 2,048 個の製品が含まれています。 カタログサイズを約 4,000～5,000 の製品に減らしてみてください。
カタログ内の製品数を確認するには、次の MySQL クエリを実行します。code language-sql select distinct count(entity_id) from catalog_product_entity; -
顧客グループの数を減らす – 顧客グループが多すぎると、インデックス作成のパフォーマンスや全体的なパフォーマンスに影響を与える可能性があります。
-
使用を 1 人または 2 人の同時ユーザーに制限する
-
cron ジョブを無効にし、必要に応じて手動で実行する
注意事項：
-
Fastly CDN およびNew Relic サービスは、統合環境ではアクセスできません
-
統合環境のアーキテクチャがステージングおよび実稼動のアーキテクチャと一致しません
-
開発テスト、パフォーマンステスト、ユーザー受け入れテスト（UAT）に
integrationの環境を使用しない -
integration環境を使用してAdobe Commerce機能の B2B をテストしないでください -
統合環境のデータベースを、実稼動環境またはステージング環境のデータベースから復元することはできません
ステージング環境
ステージング環境は、サイトをテストするための実稼動環境に近い環境を提供します。 専用の IaaS ハードウェアでホストされるこの環境には、Fastly CDN、New Relic APM、検索などのすべてのサービスが含まれます。
推奨されるユースケース：
この環境は実稼動アーキテクチャと一致し、機能を実 production 動環境にプッシュする前の UAT、コンテンツのステージングおよび最終レビュー用に設計されています。 例えば、staging 環境を使用して、次のタスクを実行できます。
-
実稼動データに対する回帰テスト
-
Fastly キャッシュを有効にしたパフォーマンステスト
-
実稼動環境でパッチを適用する代わりに新しいビルドをテスト
-
新しいビルドの UAT テスト
-
Adobe Commerceのテスト B2B
-
cron 設定のカスタマイズと cron ジョブのテスト
デプロイメントワークフローおよび デプロイメントをテストを参照してください。
注意事項：
-
実稼動サイトの立ち上げ後、主にステージング環境を使用して、実稼動に不可欠なバグ修正のためのパッチをテストします。
-
staging分岐から分岐を作成することはできません。 代わりに、integrationブランチからstagingブランチにコードの変更をプッシュします。
実稼動環境
実稼動環境は、公開されている単一サイトおよびマルチサイトのストアフロントを実行します。 この環境は、冗長な高可用性ノードを備えた専用の IaaS ハードウェア上で動作し、継続的なアクセスとフェイルオーバー保護をお客様に提供します。 実稼働環境には、ステージング環境のすべてのサービスに加えて、アプリケーションデータとパフォーマンス分析に自動的に接続し、動的なサーバー監視を提供する New Relic インフラストラクチャ （NRI）サービスが含まれます。
注意事項：
production 分岐から分岐を作成することはできません。 代わりに、staging ブランチから production ブランチにコードの変更をプッシュします。
生産テクノロジースタック
実稼動環境には、Elastic Load Balancer の背後にある 3 つの仮想マシン（VM）があり、VM ごとに HAProxy によって管理されます。 各 VM には次のテクノロジーが含まれます。
-
Fastly CDN - HTTP キャッシュと CDN
-
NGINX – 複数のワーカーを持つ 1 つのインスタンスで PHP-FPM を使用する Web サーバー
-
GlusterFS：すべての静的ファイル展開と 4 つのディレクトリ・マウントによる同期を管理するファイル・サーバ：
varpub/mediapub/staticapp/etc
-
Redis:VM ごとに 1 台のサーバを稼働させ、他の 2 台をレプリカとして使用
-
Elasticsearch - クラウドインフラストラクチャー 2.2 から 2.4.3-p2 上のAdobe Commerceを検索します。
-
OpenSearch - Cloud Infrastructure 2.3.7-p3、2.4.3-p2、2.4.4 以降でAdobe Commerceを検索します。
-
Galera - ノードごとに 1 つの MariaDB MySQL データベースを持つデータベース・クラスタ。各データベースの一意の ID に対して自動インクリメント設定を 3 つ設定します。
次の図は、実稼動環境で使用されるテクノロジーを示しています。
冗長ハードウェア
Adobe Commerce on cloud infrastructure では、従来のアクティブ/パッシブ master ークフローやプライマリセカンダリセットアップを実行するのではなく、3 つのインスタンスすべてが読み取りと書き込みを受け入れる 冗長アーキテクチャ を実行します。 このアーキテクチャにより、スケーリング時のダウンタイムがなくなり、トランザクションの整合性が保証されます。
Adobeでは、独自の冗長ハードウェアを使用することで、3 台のゲートウェイ・サーバを提供できます。 ほとんどの外部サービスでは、1 つの許可リストに複数の IP アドレスを割り当てることができるので、複数の固定 IP アドレスを持っていても問題ありません。 3 つのゲートウェイは、実稼動環境クラスター内の 3 つのサーバーにマッピングされ、静的 IP アドレスを保持します。 これは完全な冗長性を備え、あらゆるレベルで高可用性を実現します。
- DNS
- コンテンツ配信ネットワーク（CDN）
- 弾性ロードバランサー（ELB）
- データベースと web サーバーを含むすべてのAdobe Commerce サービスで構成される 3 サーバークラスター
バックアップと障害回復
クラウドインフラストラクチャー上のAdobe Commerceでは、3 つの個別のAWSまたは Azure 可用性ゾーン（各ゾーンには個別のデータセンターがある）に各 Pro プロジェクトをレプリケートする高可用性アーキテクチャを使用します。 この冗長性に加えて、ステージング環境と実稼動環境は、致命的な障害 の場合に使用するように設計された、定期的なライブバックアップを受け取ります。
自動バックアップ には、MySQL データベースや、マウントされたボリュームに保存されたファイルなど、実行中のすべてのサービスからの永続的なデータが含まれます。 バックアップは、実稼働環境と同じリージョン内の暗号化された EBS （Elastic Block Storage）に保存されます。 自動バックアップは、別のシステムに保存されているので、公開ではアクセスできません。
app/ ディレクトリの一部は含みません。 他のファイルの場合は、 ビルドとデプロイメントプロセスによって作成および生成されます。また、Git リポジトリで残りのファイルを確認する必要もあります。CLI コマンドを使用して、ステージング環境および実稼動環境用のデータベースの 手動バックアップ を作成できます。 データベースのバックアップを参照してください。 integration 環境の場合、Adobeでは、クラウドインフラストラクチャプロジェクト上のAdobe Commerceにアクセスした後、大きな変更を加える前に、最初の手順としてバックアップを作成することをお勧めします。 バックアップ管理を参照してください。
RPO （目標復旧時点）
RPO （目標復旧時点）は、最後のバックアップまで最大 6 時間です（たとえば、06:00、12:00、18:00）。 バックアップの頻度は、計画のバックアップスケジュールと、ストレージサービスに書き込む変更のボリュームによって異なります。
保持ポリシー
Adobeは、次のデータ・リテンション・ポリシーに従って自動バックアップを保持します。
このポリシーは、クラウドインフラストラクチャプランによって異なる場合があります。
目標リカバリ時間
RTO はストレージのサイズによって異なります。 大規模な EBS ボリュームのリストアには、より多くの時間がかかります。 復元時間は、データベースのサイズによって異なる場合があります。
- 大規模なデータベース（200 GB 以上）の場合、5 時間かかる場合があります
- 中程度のデータベース（150 GB）の場合、2 1/2 時間かかる場合があります
- 小規模なデータベース（60 GB）の場合、1 時間かかる場合があります
Pro クラスタのスケーリング
Pro クラスターのサイズ設定と コンピューティング 設定は、選択したクラウドプロバイダー（AWS、Azure）、地域、サービスの依存関係によって異なります。 Adobeクラウドインフラストラクチャは、トラフィックの期待値とサービス要件の変化に合わせて Pro クラスタを拡張できます。
冗長アーキテクチャにより、Adobeのクラウドインフラストラクチャをダウンタイムなしでアップスケールできます。 アップグレード時には、3 つのインスタンスが回転して、サイトの運用に影響を与えることなく容量をアップグレードします。 例えば、データベース階層ではなく PHP 階層の制約を受ける場合、既存のクラスタに Web サーバを追加できます。 これにより、データベースレベルで追加の CPU によって提供される垂直方向のスケーリングを補完する 水平方向のスケーリング が提供されます。 拡張アーキテクチャを参照してください。
イベントやその他の理由でトラフィックが大幅に増加すると予想される場合は、一時的な容量増加をリクエストできます。 2}Commerce ヘルプセンターの一時的なアップサイズをリクエストする方法 を参照してください。