Pro アーキテクチャ

Adobe Commerce on cloud infrastructure Pro アーキテクチャは、ストアの開発、テスト、ローンチに使用できる複数の環境をサポートしています。

次の表に、環境の違いの概要を示します。

環境アーキテクチャ

プロジェクトは、次の 3 つの主な環境ブランチを持つ 1 つの Git リポジトリーです。 integration, staging、および production. 次の図は、Pro 環境の階層関係を示しています。

マスター環境

Pro プロジェクトでは、 master ブランチは、実稼動環境にアクティブな PaaS 環境を提供します。 常に実稼動コードのコピーを master 環境：サービスを中断することなく実稼動環境をデバッグできます。

注意事項：

統合環境

統合環境は、PaaS と呼ばれるサーバーのグリッド上の Linux コンテナ（LXC）で動作します。 各環境には、サイトをテストするための web サーバーとデータベースが含まれます。 参照： 地域の IP アドレス AWSおよび Azure の IP アドレスのリストについては、を参照してください。

推奨されるユースケース：

統合環境は、変更をステージング環境と実稼動環境に移行する前に、限定的なテストと開発のために設計されています。 例えば、統合環境を使用して、次のタスクを実行できます。

統合環境で最高のパフォーマンスを得るには、次のベストプラクティスに従います。

注意事項：

ステージング環境

ステージング環境は、サイトをテストするための実稼動環境に近い環境を提供します。 専用の IaaS ハードウェアでホストされるこの環境には、Fastly CDN、New Relic APM、検索などのすべてのサービスが含まれます。

推奨されるユースケース：

この環境は実稼動アーキテクチャと一致し、機能をにプッシュする前の UAT、コンテンツのステージングおよび最終レビュー用に設計されています production 環境。 例えば、 staging 環境：次のタスクを実行します。

参照： デプロイメントワークフロー および デプロイメントをテスト.

注意事項：

実稼動環境

実稼動環境は、公開されている単一サイトおよびマルチサイトのストアフロントを実行します。 この環境は、冗長な高可用性ノードを備えた専用の IaaS ハードウェア上で動作し、継続的なアクセスとフェイルオーバー保護をお客様に提供します。 実稼動環境には、ステージング環境のすべてのサービスに加えて、 New Relicインフラストラクチャ（NRI） サービス。アプリケーションデータおよび performance analytics と自動的に接続され、動的なサーバー監視を提供します。

注意事項：

から分岐を作成することはできません production 分岐。 代わりに、からコードの変更をプッシュします staging の分岐 production 分岐。

生産テクノロジースタック

実稼動環境には、Elastic Load Balancer の背後にある 3 つの仮想マシン（VM）があり、VM ごとに HAProxy によって管理されます。 各 VM には次のテクノロジーが含まれます。

次の図は、実稼動環境で使用されるテクノロジーを示しています。

冗長ハードウェア

従来のアクティブ/パッシブを実行するのではなく、 master または、プライマリー/セカンダリ設定として、クラウドインフラストラクチャー上のAdobe Commerceでは次を実行します 冗長アーキテクチャ 3 つのインスタンスすべてが読み取りと書き込みを受け入れる場所。 このアーキテクチャにより、スケーリング時のダウンタイムがなくなり、トランザクションの整合性が保証されます。

Adobeでは、独自の冗長ハードウェアを使用することで、3 台のゲートウェイ・サーバを提供できます。 ほとんどの外部サービスでは、1 つの許可リストに複数の IP アドレスを割り当てることができるので、複数の固定 IP アドレスを持っていても問題ありません。 3 つのゲートウェイは、実稼動環境クラスター内の 3 つのサーバーにマッピングされ、静的 IP アドレスを保持します。 これは完全な冗長性を備え、あらゆるレベルで高可用性を実現します。

バックアップと障害回復

クラウドインフラストラクチャー上のAdobe Commerceでは、3 つの個別のAWSまたは Azure 可用性ゾーン（各ゾーンには個別のデータセンターがある）に各 Pro プロジェクトをレプリケートする高可用性アーキテクチャを使用します。 この冗長性に加えて、ステージング環境と実稼動環境は、以下の場合に使用するように設計された、定期的なライブバックアップを受け取ります。 壊滅的な失敗.

自動バックアップ mysql データベースや、マウントされたボリュームに格納されたファイルなど、実行中のすべてのサービスからの永続的なデータを含めます。 バックアップは、実稼働環境と同じリージョン内の暗号化された EBS （Elastic Block Storage）に保存されます。 自動バックアップは、別のシステムに保存されているので、公開ではアクセスできません。

以下を作成できます 手動バックアップ CLI コマンドを使用したステージング環境および実稼動環境用のデータベースの。 参照： データベースのバックアップ. の場合 integration Adobeでは、クラウドインフラストラクチャプロジェクト上のAdobe Commerceにアクセスした後、大きな変更を加える前に、最初の手順としてバックアップを作成することをお勧めします。 参照： バックアップ管理.

RPO （目標復旧時点）

RPO （目標復旧時点）は、最後のバックアップまで最大 6 時間です（たとえば、06:00、12:00、18:00）。 バックアップの頻度は、計画のバックアップスケジュールと、ストレージサービスに書き込む変更のボリュームによって異なります。

保持ポリシー

Adobeは、次のデータ・リテンション・ポリシーに従って自動バックアップを保持します。

このポリシーは、クラウドインフラストラクチャプランによって異なる場合があります。

目標リカバリ時間

RTO はストレージのサイズによって異なります。 大規模な EBS ボリュームのリストアには、より多くの時間がかかります。 復元時間は、データベースのサイズによって異なる場合があります。

Pro クラスタのスケーリング

Pro クラスターのサイジングと compute 設定は、選択したクラウドプロバイダー（AWS、Azure）、地域、サービスの依存関係によって異なります。 Adobeクラウドインフラストラクチャは、トラフィックの期待値とサービス要件の変化に合わせて Pro クラスタを拡張できます。

冗長アーキテクチャにより、Adobeのクラウドインフラストラクチャをダウンタイムなしでアップスケールできます。 アップグレード時には、3 つのインスタンスが回転して、サイトの運用に影響を与えることなく容量をアップグレードします。 例えば、データベース階層ではなく PHP 階層の制約を受ける場合、既存のクラスタに Web サーバを追加できます。 これが提供する機能 水平スケーリング データベースレベルで追加の CPU によって提供される垂直方向のスケーリングを補完します。 参照： 拡張されたアーキテクチャ.

イベントやその他の理由でトラフィックが大幅に増加すると予想される場合は、一時的な容量増加をリクエストできます。 参照： 一時的なアップサイズをリクエストする方法 が含まれる Commerceヘルプセンター.