高可用性のために2つのVMでWordPressを実行する方法

Microsoft Azureでは、「高可用性」SLAを達成し、サイトが定期的なメンテナンスのためにダウンしないようにするために、アプリケーションが複数のデータセンターにまたがる2つのインスタンスを利用する必要があります。彼らは、どのデータセンターのペアが同時にメンテナンスに行くことは決してないだろうとさえ教えてくれます。

これで十分ですが、同じVMにMySQLデータベースを備えたWordPressなどのアプリで実際にこれを簡単に行うにはどうすればよいでしょうか。2つのVM間のロードバランシングに慣れているわけではありませんが、データベースレプリケーションのセットアップではわかりません。同期が取れなくなる可能性のある2つのバージョンのデータは必要ありません。MySQLレプリケーションには、ユーザーがスレーブインスタンスに到達した場合にマスターDBへの変更を同期できないマスター/スレーブセットアップが必要なようです。

私はこの概念を誤解しているだけですか？どんな助けでも大歓迎です！

— ヤーロン
ソース

なぜAzureでWordPressをホストするのですか？WordPressのホスティングには、より優れた安価なものがあります。たとえばデジタルオーシャン。

— Alexus

Alexus、それはここではあまり関係ありませんが、WordPressが1つのコンポーネントにすぎないAzureのインフラストラクチャ全体にかなり大きなスタックが広がっています。Azureは素晴らしいプラットフォームであり、非常に満足しています。

— Yaron、2015

落とし穴。あなたは自分のやるべきことをやらなければならない:)私は、ほとんどの.NET要素についてもAzureが好きですが、常にWPサイトを個別にホストしました。

— Alexus

ヤロン、以下の答えは役に立ちましたか？これまでに3件の賛成票を受け取りましたが、重要な概念が見つからないかどうかを確認したいので、更新して特定のユースケースに対応できるようにします。

— ブライアン 'BJ'ホフパウアーJr.

@ Bryan'BJ'Hoffpauirの完全な回答に感謝します。申し訳ありませんが、私たちの実装で動作するかどうかを確認するための指示に従うための時間はありませんでした。正解としてマークを付けています。問題が発生した場合は再度連絡します。再度、感謝します！！

— Yaron

悪いニュース：Wordpressのコアオープンソースベースは、単一のサーバーで実行されることについてかなりの数の仮定を行います（いくつか挙げると、WPコンテンツ、ユーザーアップロード、およびメディアライブラリ）。

朗報：ほとんどすべてのクラウドプロバイダー（Azureを含む）には、これらの設計上の制限を回避できる抽象化機能があります。

基本的に、次の懸念事項に対処します。

2つ（またはそれ以上）の「フロントエンド」Wordpress Web /アプリサーバー間のトラフィックの負荷分散。ユーザーにサイトへのログインを許可しない限り、Wordpressはほとんどステートレスであるため、それほど難しくありません。これは、DNSとロードバランサーの組み合わせを介して行われます。アプリサーバー用に2つのIPのサポートが必要です-1つのセットはインターネット経由でルーティング可能なサブネットに接続します（ただし、以下で概説されていないファイアウォールで保護されていることが望ましいです）。他の2つは、他のネットワークにはデータベースサーバーインスタンスが含まれますが、基本的なアウトラインは次のようになります。

                     /-（10.0.0.1-eth0）wp1.domain.com（10.0.1.1-eth2）
（パブリックIP）wp.domain.com          
                     \-（10.0.0.2-eth1）wp2.domain.com（10.0.1.2-eth3）

ユーザーにサイトへのログインを許可する場合のセッションの管理。その場合、ユーザーがサーバー1にログインするときに、今後のすべての要求がそのサーバーにルーティングされる（スティッキーセッション）か、セッションが他のメカニズムによって管理されるため、どのサーバーにアクセスするかが問題にならないようにする必要があります。（Zend Server Session Clusteringなどを介して）。
管理者ログインの管理コンテンツを管理するために一部のユーザーにバックエンドへのログインを許可する場合（上記と同様）。
高可用性も備えたDBシステムの選択。DBがクラッシュしてシステム全体がダウンした場合、2つのフロントエンドサーバーが存在しても意味がありません。ClearDB経由でMySQLマスター/スレーブレプリケーションを利用するか、SQL Serverを利用するためにプラグイン経由でWordPressを変更して、ネイティブクラスターシステムを使用できるようにする必要があります。これは、DBレイヤーを自分で管理する場合（2 xアプリ＆2 x DB）、少なくとも4つのVMが必要であることを意味します。これは次のようになります。

               /-wp1.domain.com（10.0.1.1）\ --- /（10.0.1.3）db1.domain.com（10.0.2.3）\
         wp.domain.com X |           
               \-wp2.domain.com（10.0.1.2）/ --- \（10.0.1.4）db2.domain.com（10.0.2.3）/

注 -信頼性の高いフェイルオーバーを確保し、システムのセキュリティを保護するために、通常、THIRDネットワークサブネットを使用して、アプリサーバーが通信するために使用する他の通信ネットワークから分離されたプライベートチャネルを介して2つのデータベースノードを相互に接続しますデータベースとアプリサーバーは外界との通信に使用します。
接続プーリングを有効にして、アプリサーバーのデータベース接続のパフォーマンスと信頼性を最大化します。
W3 Total CacheやSuper Cacheなどのキャッシュプラグインを活用して、フロントエンドサーバーの負荷を最小限に抑えます。

以下のガイドは、上記の課題のそれぞれにどのように対処できるかについての詳細を提供します。Azureでそれぞれを処理する方法はいくつかあります。そのため、各チャレンジをどのように攻撃するかを決定し、スタックを上下に移動する際に各選択肢が課す制約に対処する必要があります。

— ブライアン 'BJ'ホフパウアJr.
ソース