編集

仮想マシン上の WLS

Azure Front Door
Azure Key Vault
Azure Load Balancer
Azure Virtual Network
Azure 仮想マシン スケール セット

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

アーキテクチャ

Azure Virtual Machine Scale Sets 上の WordPress デプロイのアーキテクチャ図。Azure NetApp Files に静的コンテンツが保存されます。

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

注意

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

データフロー

  • ユーザーは、Azure Web Application Firewall が有効になっている Azure Front Door を介してフロントエンド Web サイトにアクセスします。
  • Azure Front Door では、Azure Load Balancer の内部インスタンスを配信元として使用します。 Azure Front Door は、キャッシュされていないすべてのデータを取得します。
  • 内部ロード バランサーは、要求を Azure Virtual Machine Scale Sets に分散します。 スケール セットは Ubuntu Web サーバーで構成されます。
  • キーや他のシークレットは Azure Key Vault に保存されます。
  • WordPress アプリケーションはプライベート エンドポイントを使用して、Azure Database for MySQL のフレキシブル サーバー インスタンスにアクセスします。 WordPress アプリケーションは、データベースから動的な情報を取得します。
  • すべての静的コンテンツは Azure NetApp Files でホストされ、NFS プロトコルを介して仮想マシン (VM) にマウントされます。

Components

  • Azure Front Door は、最新のクラウド コンテンツ配信ネットワークです。 Azure Front Door はサーバーの分散ネットワークであり、ユーザーに Web コンテンツを効率的に配信します。 コンテンツ配信ネットワークは、キャッシュされたコンテンツをエンド ユーザーに近いポイントオブプレゼンスの場所のエッジ サーバーに保存することで、待機時間を最小限に抑えます。
  • Azure Virtual Network は、デプロイされたリソースが他のデプロイされたリソース、インターネット、オンプレミス ネットワークと安全に通信する手段を提供します。 仮想ネットワークは、分離とセグメンテーションを提供します。 また、トラフィックをフィルター処理してルーティングし、さまざまな場所の間に接続を確立できるようにします。 このソリューションでは、2 つのネットワークが仮想ネットワーク ピアリングを介して接続されます。
  • Azure DDoS Protection は、強化された DDoS 軽減機能を提供します。 これらの機能をアプリケーション設計のベスト プラクティスと組み合わせると、DDoS 攻撃に対して防御するのに役立ちます。 境界仮想ネットワークで DDoS Protection を有効にする必要があります。
  • ネットワーク セキュリティ グループは、送信元または宛先の IP アドレス、ポート、プロトコルに基づいてインバウンドまたはアウトバウンドのネットワーク トラフィックを許可または拒否するセキュリティ規則のリストを使用します。 このシナリオのサブネットでは、ネットワーク セキュリティ グループの規則によって、アプリケーション コンポーネント間のトラフィック フローが制限されます。
  • Load Balancer は、規則と正常性プローブの結果に基づいて受信トラフィックを分散させます。 ロード バランサーは、低待機時間と高スループットを実現します。 ロード バランサーは、複数のサーバーにトラフィックを分散させることで、伝送制御プロトコル (TCP) とユーザー データグラム プロトコル (UDP) のアプリケーションのスケーラビリティを向上させます。 このシナリオでは、ロード バランサーはコンテンツ配信ネットワークからフロントエンド Web サーバーへのトラフィックを分散させます。
  • Virtual Machine Scale Sets では、負荷分散が行われる同一の VM のグループを作成して管理する手段を提供します。 需要または定義されたスケジュールに応じて、VM インスタンスの数を自動的に増減させることができます。 このシナリオでは、2 つの個別のスケール セットが使用されます。 1 つはコンテンツを処理するフロントエンド Web サーバー用、もう 1 つは新しいコンテンツの作成に使用されるフロントエンド Web サーバー用です。
  • 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 マネージド サービスを使用する代わりに、VM 内のセルフホステッド ポッドをキャッシュとして使用することができます。

シナリオの詳細

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

考えられるユース ケース

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

考慮事項

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

[信頼性]

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

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

  • このソリューションでは、Virtual Machine Scale Sets とロード バランサーを使用してイグレス トラフィックを分散します。 このアプローチでは、VM に障害が発生した場合でも高可用性が維持されます。
  • このソリューションでは、複数リージョン、データ レプリケーション、自動スケーリングがサポートされます。 ネットワーク コンポーネントがトラフィックを VM に分散させます。 正常な VM にのみトラフィックが分散されるように正常性プローブを使用しています。
  • すべてのネットワーク コンポーネントは 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 にはプライベート エンドポイントを使用します。

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

コストの最適化

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

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

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

パフォーマンス効率

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

このシナリオでは、各リージョンの 2 つのフロントエンド Web サーバー クラスターのために Virtual Machine Scale Sets を使用します。 スケール セットにより、顧客の要求に応じて、フロントエンド アプリケーション層を実行する VM インスタンスの数を自動的にスケーリングできます。 定義済みのスケジュールに基づいて VM の数をスケーリングすることもできます。 詳細については、Virtual Machine Scale Sets での自動スケールの概要に関する記事をご覧ください。

重要

最適なパフォーマンスを得るには、NFS プロトコル バージョン 4.1 を介してストレージをマウントすることが不可欠です。 Ubuntu に対する次の Bash の例では、vers オプションを構成する方法を示します。

# Install an NFS driver and create a directory.
$ apt-get install -y nfs-common && mkdir -p /var/www/html
# Add auto-mount on startup. (Replace the following code with
# instructions from the Azure portal, but change the vers value to 4.1.)
$ echo '<netapp_private_ip>:/<volume_name> /var/www/html nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 0 0' >> /etc/fstab
# Mount the storage.
$ mount -a

共同作成者

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

プリンシパル作成者:

その他の共同作成者:

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

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

次の手順

製品ドキュメント:

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