編集

次の方法で共有


Azure Kubernetes Service 上の WordPress

Azure Cache for Redis
Azure Front Door
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure NetApp Files

この記事では、ストレージを集中的に使用する大規模な WordPress on Azure のインストールをホストするためのコンテナー ソリューションについて説明します。 このソリューションによってスケーラビリティとセキュリティが最大化されます。 主要なコンポーネントには、Azure Front DoorAzure Kubernetes Service (AKS)Azure NetApp Files があります。

アーキテクチャ

AKS WordPress デプロイのアーキテクチャ図。Azure NetApp Files が静的コンテンツを格納します。プライベート エンドポイントが他のサービスへのアクセスを提供します。

このアーキテクチャの Visio ファイルをダウンロードします。

注意

特定の WordPress ホスティング方法に固有ではないヒントと推奨事項を実装することで、このソリューションを拡張できます。 WordPress インストールをデプロイするための一般的なヒントについては、「WordPress on Azure」を参照してください。

データフロー

  • ユーザーは、Azure Web Application Firewall が有効になっている Azure Front Door を介してフロントエンド Web サイトにアクセスします。
  • Azure Front Door は、Azure Load Balancer の内部インスタンスを配信元として使用します。 内部ロード バランサーは、AKS の不可視コンポーネントです。 Azure Front Door は、キャッシュされていないすべてのデータを取得します。
  • 内部ロード バランサーは、AKS 内のポッドに受信トラフィックを分散させます。
  • Azure Key Vault は、X.509 証明書の秘密キーなどのシークレットを格納します。
  • WordPress アプリケーションはプライベート エンドポイントを使用して、Azure Database for MySQL のフレキシブル サーバー インスタンスにアクセスします。 WordPress アプリケーションは、このマネージド データベース サービスから動的な情報を取得します。
  • すべての静的コンテンツは Azure NetApp Files でホストされます。 このソリューションは、NFS プロトコルで Astra Trident Container Storage Interface (CSI) ドライバーを使用します。

Components

  • Azure Front Door は、最新のクラウド コンテンツ配信ネットワークです。 サーバーの分散ネットワークとして、Azure Front Door はユーザーに Web コンテンツを効率的に配信します。 コンテンツ配信ネットワークは、キャッシュされたコンテンツをエンド ユーザーに近いポイントオブプレゼンスの場所のエッジ サーバーに格納することで、待機時間を最小限に抑えます。
  • Azure Virtual Network は、デプロイされたリソースが他のデプロイされたリソース、インターネット、オンプレミス ネットワークと安全に通信する手段を提供します。 仮想ネットワークは、分離とセグメント化を提供します。 また、トラフィックをフィルター処理してルーティングし、さまざまな場所の間に接続を確立できるようにします。 このソリューションでは、2 つのネットワークは仮想ネットワーク ピアリングを介して接続されます。
  • Azure DDoS Protection では、拡張 DDoS 軽減機能が提供されます。 これらの機能をアプリケーション設計のベスト プラクティスと組み合わせると、DDoS 攻撃からの防御に役立ちます。 境界仮想ネットワークで DDoS Protection を有効にする必要があります。
  • ネットワーク セキュリティ グループでは、セキュリティ規則の一覧を使用して、ソースまたはターゲット IP アドレス、ポート、プロトコルを基に、インバウンド/アウトバウンド ネットワーク トラフィックを許可または拒否します。 このシナリオのサブネットでは、ネットワーク セキュリティ グループの規則によって、アプリケーション コンポーネント間のトラフィック フローが制限されます。
  • Azure Load Balancer は、規則と正常性プローブの結果に基づいて受信トラフィックを分散させます。 ロード バランサーは、低待機時間と高スループットを実現します。 ロード バランサーは、複数のサーバーにトラフィックを分散させることで、伝送制御プロトコル (TCP) とユーザー データグラム プロトコル (UDP) のアプリケーションのスケーラビリティを向上させます。 このシナリオでは、ロード バランサーがコンテンツ配信ネットワークからフロントエンド Web サーバーへのトラフィックを分散させます。
  • AKS は、コンテナー化されたアプリケーションのデプロイ、管理、スケーリングに使用できるフル マネージド Kubernetes サービスです。
  • Azure NetApp Files は、高いパフォーマンスが要求され、待機時間の影響を受けやすいフル マネージド ストレージ ソリューションを提供します。 このソリューションでは、Azure NetApp Files がすべての WordPress コンテンツをホストして、すべてのポッドがデータにアクセスできるようにします。
  • Azure Cache for Redis はメモリ内データ ストアです。 Azure Cache for Redis を使用して、このソリューションでキー値のキャッシュをホストすることができます。 そのキャッシュは、すべてのポッドに共有され、WordPress パフォーマンス最適化プラグインに使用されます。
  • Key Vault は、パスワード、証明書、キーを格納し、それらへのアクセスを制御します。
  • Azure Database for MySQL - フレキシブル サーバーは、オープンソースの MySQL データベース エンジンに基づくリレーショナル データベース サービスです。 フレキシブル サーバー デプロイ オプションは、データベース管理機能と構成設定のきめ細かな制御と柔軟性を提供するために設計された、フル マネージド サービスです。 このシナリオでは、Azure Database for MySQL が WordPress データを格納します。

代替

  • Azure Cache for Redis マネージド サービスを使用する代わりに、AKS クラスター内のセルフホステッド ポッドをキャッシュとして使用することができます。
  • Azure NetApp Files などのマネージド ストレージ ソリューションを使用する代わりに、Rook-Ceph ストレージなどのセルフホステッド ソリューションを使用することができます。 詳細については、「Azure Kubernetes Service で Rook Ceph を使用する」に関するページを参照してください。

シナリオの詳細

このシナリオ例は、大規模でストレージを集中的に使用する WordPress のインストールに適しています。 このデプロイ モデルは、サイトへのトラフィックの急増に合わせてスケーリングすることができます。

考えられるユース ケース

  • WordPress をコンテンツ管理システムとして使用している高トラフィックのブログ
  • WordPress を使用しているビジネス Web サイトまたは eコマース Web サイト

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

このソリューションをデプロイするときは、次の推奨事項を考慮してください。

  • このソリューションでは、AKS のポッドとロード バランサーを使用して受信トラフィックを分散させます。 この手法では、ポッドに障害が発生した場合でも高可用性が維持されます。
  • このソリューションは、複数リージョン、データ レプリケーション、自動スケーリングをサポートしています。 コンポーネントがトラフィックをポッドに分散させます。 正常なポッドにのみトラフィックが分散されるように正常性プローブを使用しています。
  • すべてのネットワーク コンポーネントは Azure Front Door によってアクセスされます。 この手法では、トラフィックを中断し、エンドユーザーへのアクセスに影響を及ぼす可能性のある問題に対する回復性をネットワーク リソースとアプリケーションに持たせます。
  • Azure Front Door は、別のリージョンにデプロイされる仮想マシン スケール セットをサポートするグローバル サービスです。
  • Azure Front Door を使用してすべての応答をキャッシュすれば、可用性が多少向上します。 具体的には、配信元が応答しない場合でも、コンテンツにアクセスできます。 ただし、キャッシュには、完全な可用性ソリューションを提供する機能はありません。
  • 可用性を向上させるには、ペアになっているリージョン間で Azure NetApp Files ストレージをレプリケートします。 詳細については、「Azure NetApp Files を使用したリージョン間レプリケーション」を参照してください。
  • Azure Database for MySQL の可用性を向上させるには、ニーズに合った高可用性オプションを選択します。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

このソリューションをデプロイするときは、次の推奨事項を考慮してください。

  • Azure Front Door の Web Application Firewall を使用して、フロントエンド アプリケーション層に流入する仮想ネットワーク トラフィックを保護します。 詳細については、「Azure Front Door の Azure Web Application Firewall」を参照してください。
  • データベース層からのアウトバウンド インターネット トラフィックは許可されません。
  • プライベート ストレージへのパブリック アクセスは許可されません。リソースへのパブリック アクセスは無効になります。 Azure Database for MySQL、Azure Cache for Redis、Key Vault、Azure Container Registry にはプライベート エンドポイントを使用します。 詳細については、Azure Private Link に関するページを参照してください。

WordPress のセキュリティの詳細については、「WordPress のセキュリティとパフォーマンスに関する一般的なヒント」および「Azure のセキュリティに関するドキュメント」を参照してください。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

このソリューションをデプロイする場合は、コストに関する次の考慮事項を確認してください。

  • 想定トラフィック (GB/月)。 トラフィック量は、コストに最大の影響を及ぼす要因です。 必要とされる AKS ノードの数と送信データ転送の価格は、受信するトラフィック量によって決まります。 トラフィック量はコンテンツ配信ネットワークが提供するデータ量とも直接関連しています。送信データ転送の方がコストが安くなります。
  • ホストされているデータの量。 Azure NetApp Files の価格は予約容量に基づいて決まるため、ホストするデータの量を考慮することが重要です。 コストを最適化するには、データに必要な最小限の容量を予約します。
  • 書き込み率。 Web サイトに書き込む新しいデータの量と、そのデータを保存するためのコストを考慮します。 マルチリージョン デプロイの場合、Web サイトに書き込まれる新しいデータの量はリージョン間でミラーリングされるデータの量と関連しています。
  • 静的コンテンツと動的コンテンツ。 データベース ストレージのパフォーマンスと容量を監視して、より安価な SKU がサイトをサポートできるかどうかを判断します。 データベースは動的コンテンツを格納し、コンテンツ配信ネットワークは静的コンテンツをキャッシュします。
  • AKS クラスターの最適化。 AKS クラスターのコストを最適化するには、VM のサイズや Azure 予約に関するガイダンスなど、AKS についての一般的なヒントに従います。 詳しくは、「AKS コストの最適化」を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

このシナリオでは、AKS のポッドを使用してフロントエンドをホストします。 自動スケーリング機能を使用すれば、フロントエンド アプリケーション層を実行するポッドの数を顧客の需要に応じて自動的にスケーリングすることができます。 定義済みのスケジュールに基づいてポッドの数をスケーリングすることもできます。 詳細については、「Azure Kubernetes Service (AKS) でのアプリケーションのスケーリング オプション」を参照してください。

重要

最適なパフォーマンスを得るには、NFS プロトコル バージョン 4.1 を使用する永続ボリュームをマウントすることが不可欠です。 次の YAML の例は、この目的で PersistentVolume オブジェクトを構成する方法を示しています。 mountOptions フィールドの値に注目してください。

kind: PersistentVolume
...
    accessModes:
    - ReadWriteMany
    mountOptions:
    - vers=4.1
    nfs:
      server: xx.xx.xx.xx

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

その他の共同作成者:

  • Adrian Calinescu | シニア クラウド ソリューション アーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次の手順

製品ドキュメント:

Microsoft トレーニング モジュール: