この記事では、Magento のオープンソース バージョン (PHP で記述された eコマース プラットフォーム) について説明します。 この記事は Adobe Commerce に関するものではありません。 このシナリオ例では、Azure Kubernetes Service (AKS) にデプロイされた Magento を示し、Azure で Magento をホストするための一般的なベスト プラクティスについて説明します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
- Azure Kubernetes Service (AKS) は、Varnish、Magento、Elasticsearch の Kubernetes クラスターを異なるポッドにデプロイします。
- AKS はエージェント ノードをデプロイするための仮想ネットワークを作成します。 事前に仮想ネットワークを作成し、サブネットの構成、プライベート リンク、およびエグレスの制限を設定します。
- Varnish は、フルページ キャッシュとして機能するために、HTTP サーバーの前にインストールされます。
- Azure Database for MySQL は、注文やカタログなどのトランザクション データを格納します。 バージョン 8.0 をお勧めします。
- Azure Files Premium、Azure NetApp Files、または同等のネットワーク接続ストレージ (NAS) システムには、製品イメージのようなメディア ファイルが格納されます。 Magento には、Azure Files Premium や Azure NetApp Files などの ReadWriteMany モードでボリュームをマウントできる、Kubernetes と互換性のあるファイル システムが必要です。 Azure Kubernetes Service (AKS) でのアプリケーションのストレージ オプション。 1 秒あたりの入出力操作 (IOPS) スループットをテストし、適切なオプションを選ぶことを強くお勧めします。
- コンテンツ配信ネットワーク (CDN) は、CSS、JavaScript、イメージなどの静的コンテンツを提供します。 CDN を介してコンテンツを提供することで、ユーザーとデータセンター間のネットワーク待機時間を最小限に抑えることができます。 CDN は、静的コンテンツをキャッシュして提供することで、NAS から大きな負荷を取り除くことができます。
- Redis は、セッション データを格納します。 パフォーマンス上の理由から、コンテナーで Redis をホストすることをお勧めします。
- AKS は、Microsoft Entra ID の ID を使用して、Azure ロード バランサー、ユーザー認証、ロールベースのアクセス制御、マネージド ID などの他の Azure リソースを作成および管理します。
- Azure Container Registry は、AKS クラスターにデプロイされたプライベート Docker イメージを格納します。 Docker Hub などの他のコンテナー レジストリを使用できます。 既定の Magento インストールでは、一部のシークレットがイメージに書き込まれます。
- Azure Monitor では、Azure サービスのプラットフォーム メトリックやアプリケーション テレメトリなど、メトリックとログが収集されて格納されます。 Azure Monitor は、コントローラー、ノード、コンテナーのメトリックや、コンテナーとマスター ノードのログを収集するために AKS と統合します。
コンポーネント
- Azure Kubernetes Service (AKS): マネージド Kubernetes サービスでコンテナーをスケーリングします。
- Azure Virtual Network: クラウド内の仮想ネットワーク。
- Azure Database for MySQL: コスト効率が高く、セットアップ、運用、スケーリングが簡単なクラウド内の MySQL。
- Azure Files: クラウド内のファイル共有。 このソリューションは、Premium レベルを使用します。
- Azure NetApp Files: NetApp を利用したエンタープライズレベルの Azure ファイル共有。
- Azure Content Delivery Network:高速で信頼性が高く、グローバルなコンテンツ配信ネットワーク。
- Microsoft Entra ID: マルチクラウド ID とアクセス管理。
- Azure Container Registry: Docker および Open Container Initiative (OCI) イメージのレジストリであり、すべての OCI 成果物をサポートします。
- Azure Monitor:アプリケーション、インフラストラクチャ、ネットワークのエンド ツー エンド監視。
シナリオの詳細
Magento の詳細については、「オンプレミスでのインストールの概要」を参照してください。
考えられるユース ケース
このソリューションは、小売業界向けに最適化されています。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
セキュリティ
このシナリオのセキュリティに関する考慮事項を次に示します。
MySQL の プライベート リンク を構成して、クライアントと MySQL の間のトラフィックがパブリック インターネットに公開されないようにします。 詳細については、「Azure Private Link とは」を参照してください。
Secure Sockets Layer (SSL) の終了をサポートするために、Azure Application Gateway のイングレスを追加ができます。
Azure Web Application FirewallをApplication Gatewayと共に有効にして、AKS クラスターでホストされている Web アプリケーションに入るトラフィックを保護することもできます。
ロール ベースのアクセス制御 (RBAC)
Kubernetes と Azure のどちらにも、ロールベースのアクセス制御 (RBAC) のメカニズムがあります。
Azure RBAC は、Azure リソースへのアクセス (リソースを作成する機能を含む) を制御します。 Azure RBAC では、ユーザー、グループ、またはサービス プリンシパルにアクセス許可を割り当てることができます。これは、アプリケーションによって使用されるセキュリティ ID です。
Kubernetes RBAC は、Kubernetes API へのアクセス許可を制御します。 たとえば、ポッドの作成とポッドの一覧表示は、Kubernetes RBAC がユーザーに対して承認できるアクションです。
AKS は、Azure と Kubernetes RBAC のメカニズムを統合しています。 AKS のアクセス許可をユーザーに割り当てるには、"ロール" と "ロール バインド" を作成します。
ロールは、名前空間内で適用される一連のアクセス許可です。 アクセス許可は、ポッドやデプロイなどのリソースに対して get、update、create、delete などの動詞として定義されます。
ロール バインドは、ロールにユーザーまたはグループを割り当てます。
ClusterRole オブジェクトは、すべての名前空間にわたって AKS クラスター全体に適用されるロールを定義します。 ClusterRole にユーザーまたはグループを割り当てるには、ClusterRoleBinding を作成します。
この記事では、Kubernetes 認可に Azure RBAC を使用する方法について説明します。これにより、Azure リソース、AKS、Kubernetes リソース全体で統合された管理とアクセス制御が可能になります。
AKS クラスターは、作成するときに、ユーザー認証に Azure AD を使用するように構成できます。
Microsoft Entra 統合を設定する方法の詳細については、「AKS マネージド Microsoft Entra の統合」を参照してください。
Kubernetes RBAC と Microsoft Entra の ID を使用してクラスター リソースへのアクセスを制御する方法の詳細については、Microsoft Entra ID での Kubernetes RBAC の使用に関するページを参照してください。
スケーラビリティ
このシナリオのスケーラビリティを最適化するには、いくつかの方法があります。
メディアと静的ファイル
Azure Files、Azure NetApp Files、または別のネットワーク接続ストレージ (NAS) システムを適切にプロビジョニングします。 Magento には、製品イメージなど、数千のメディア ファイルを格納できます。 "要求を処理するには、十分な 1 秒あたりの入出力処理 (IOPS) を持つ NAS 製品を確実にプロビジョニングしてください"。
HTML、CSS、JavaScript などの静的コンテンツのサイズを最小限に抑えます。 縮小により、帯域幅のコストを低減し、ユーザーへの応答を改善することができます。
データベース接続
MySQL データベースへの永続的な接続を有効にすると、Magento は、要求ごとに新しい接続を作成するのではなく、既存の接続を再利用し続けます。 永続的な接続を有効にするには、Magento の env. php ファイルの
dbセクションに次の行を追加します。'persistent' => '1'MySQL が過剰な CPU を消費している場合は、Magento 構成の階層ナビゲーションから製品数をオフにすることで、使用率を下げます。
magento config:set -vvv catalog/layered_navigation/display_product_count 0
キャッシュ
PHP コードのキャッシュと最適化のために OPcache を構成します。
php.ini で次のディレクティブが設定およびコメント解除されていることを確認します。
opcache.enable=1opcache.save_comments=1opcache.validate_timestamps=0ポッドで複数のインスタンスを実行して、Varnish キャッシュ を負荷分散し、スケーリングできるようにします。
ログ記録
パフォーマンスの問題を回避し、クライアントの IP アドレスなどの機密データを公開しないように、アクセス ログを制限します。
次の Varnish コマンドを使用して、ログ記録をエラーレベルに制限します。
varnishd -s malloc,1G -a :80 -f /etc/varnish/magento.vcl && varnishlog -q "RespStatus >= 400 or BerespStatus >= 400"Apache Web サーバーをイングレスに使用する場合は、Apache サーバー構成の Magento の
VirtualHostエントリに次の行を追加して、Apache ログをエラーレベルに制限します。CustomLog /dev/null commonすべての PHP-FPM 構成の
access.log設定をコメント アウトして、PHP-FPM のアクセス ログをオフにします。
可用性
このシナリオの可用性を最適化するには、次の方法を検討してください。
正常性プローブ
Kubernetes では、次の 2 種類の正常性プローブが定義されます。
- Readiness probe は、ポッドが要求を受け付ける準備ができたかどうかを Kubernetes に通知します。
- Liveness probe は、ポッドが削除され、新しいインスタンスが起動されるかどうかを Kubernetes に通知します。
Kubernetes 正常性プローブをカスタマイズし、それらを使用してポッドが正常かどうかを判断します。
可用性ゾーン
Availability Zones は Azure リージョン内の一意の物理的な場所です。この場所のアプリケーションとデータは、データセンターで障害が発生しても保護されます。 各ゾーンは、1 つまたは複数のデータセンタで構成されています。 ゾーン内のアプリケーションは、1 つのデータセンターで物理的な障害が発生しても引き続き使用できます。
高可用性レベルを実現し、ハードウェア障害や計画メンテナンス イベントから保護するために、複数の Availability Zones に AKS クラスターをデプロイできます。 複数のゾーンにまたがるようにクラスター ノード プールを定義すると、1 つのゾーンがダウンしても、ノードは動作し続けます。 Availability Zones への AKS のデプロイの詳細については、可用性ゾーンを使用する AKS クラスターの作成に関するページをご覧ください。
リソース制約
リソースの競合がサービスの可用性に影響を与える場合があります。 1 つのコンテナーがクラスター メモリおよび CPU のリソースを占有できなくなるように、コンテナー リソースの制約を定義します。 AKS 診断を使用して、クラスター内の問題を特定できます。
リソース制限を使用して、コンテナーに許可される合計数を制限します。これにより、1 つの特定のコンテナーによって、他のコンテナーが不足することはなくなります。
DevOps
このシナリオの運用に関する考慮事項を次に示します。
このシナリオでは、MySQL はパブリック エンドポイントを公開しません。 ビルド サーバーがバックエンド MySQL データベースに構成設定を格納する場合は、そのサーバーを、MySQL がサービス エンドポイント経由で接続するのと同じ仮想ネットワーク サブネットにデプロイしてください。
Azure Container Registry または Docker Hub などの別のコンテナー レジストリを使用して、クラスターにデプロイされているプライベート Docker イメージを格納します。 AKS では、その Microsoft Entra ID を使って Azure Container Registry に対して認証できます。
監視
Azure Monitor は、AKS からのコンテナー メトリックなど、すべての Azure サービスの主要なメトリックを提供します。 ダッシュボードを作成して、すべてのメトリックを 1 か所に表示します。
コンテナーに対する Azure Monitor の使用に加えて、 Prometheus のマネージド サービスを使用して、Prometheus 互換の監視ソリューションを使用して大規模なメトリックを収集および分析できるようになりました。
Azure Managed Grafana (またはセルフマネージド Grafana) を使用して、Prometheus メトリックを視覚化することもできます。 Azure Managed Grafana を使用する場合、Azure Monitor ワークスペースを Azure Managed Grafana ワークスペースに接続すると、Grafana は Grafana ダッシュボードで Azure Monitor ワークスペース データを使用できるようになります。 その後、Prometheus のメトリックを使用する複数の事前構築済みダッシュボードにアクセスしたり、任意の数のカスタム ダッシュボードを作成したりできます。
パフォーマンス テスト
パフォーマンス テストには、Magento パフォーマンス ツールキットを使用します。 このツールキットは Apache JMeter を使用して、サインイン、製品の閲覧、チェックアウトなどの顧客の行動をシミュレートします。
Azure Load Testing は、大規模な負荷を生成できるフル マネージドのロード テスト サービスです。 Azure Load Testing を使用すると、URL を使用して Web アプリケーションのロード テストをすばやく作成できます。 さらに高度なロード テスト シナリオでは、既存の JMeter テスト スクリプトを再利用してロード テストを作成できます。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
パフォーマンス テストに基づいて容量計画を行います。
コストの見積もりには、Azure 料金計算ツールをご利用ください。
コストに関するその他の考慮事項については、Microsoft Azure Well-Architected Framework の「コスト最適化の原則」をご覧ください。