スケーラブルWordPress大量サイトのホスト？
大容量のスケーラブルなWebホストの推奨事項が必要ですWordPress Webサイト。私の目的では、大容量は10万から50万の訪問者/時間である可能性があります。100万/時間のバーストレートに向かって考えるかもしれません。 「最高水準点」として。
WPは、世の中で最もパフォーマンスの高いプラットフォームではありません（ha！））が、交渉の余地はありません。「通常の最適化」を行うことができます（たとえば、静的ファイルをCDNに配置します。 YSlowなどのパフォーマンスアナライザーのアドバイスに従って実行してください。ただし、それでもWordPressであり、数十のプラグインが関係します。
では、どこでサイトをホストするのですか？ほとんどの「最高のWordPressホストは何ですか？」」の議論は最低コストに焦点を当てているようです。反対が必要です。大量、スケーラブル、またはクラスター化されたWordPressあなたが素晴らしい経験をしたホストは？
Syed Karimasked ：「どこで/どのようにしてサイトをホストすることになったのか...」だからここに私の「正面からのメモ」があります：
「自動魔法」のサービスや解決策は見つかりませんでした。 Wordpress.com VIP Hosting、WP Engine、および他のいくつかはかなり興味深いように見えますが、この法案に適合しませんでした。そこで、AmazonWebで直接ホストしました。サービス（AWS）。
（少数の大きな）EC2サーバーインスタンス+ Elastic Load Balancer + I/OのS3/CloudFrontオフロード+最適化/ミニフィケーション+キャッシング+ CloudWatchモニタリング+ SNS通知+ Python/bash自動化/スクリプト+ Mercurialに基づくレプリケーションを使用しました。
TL; DRの詳細：
このサイトは、100万人以上のイベントのフラッシュモブサイトでした。イベントの15日前には名目上の訪問者しかいませんでしたが、その後、T-3日かそこらで激しい斜面の攻撃的な登りに加速し始めました。 Google Analyticsまたはサイトパフォーマンスモニターのいずれかを使用すると、負荷が時間ごとに著しく増加するのを監視できます。
Ubuntu "Natty Narwhal"、MySQL 5.1、およびWordPress 3.xを実行するEC2サーバーを使用しました。これらのサーバーの前には、Elastic LoadBalancerがありました。DNSをAmazonのRoute53サービスにシフトする必要がありました。 ELBをプライマリドメイン（www.domain.tldではなくdomain.tldなど）で正しく機能させる。
サーバーについては、共有/複製/クラスター化されたMySQLおよびNFS/CFSファイルプールの多くの複雑さと潜在的な障害モードを回避するために、スケールアウトよりもスケールアップすることを選択しました。スケールアウトすることは可能でしたが、「結果整合性」と「すべてのノードが独自のローカルストレージを使用する」方法でした。サイトの変更がマスターサーバーに対して行われ、ファイルとデータベースの変更が残りのWPプールに複製されました。複製はMercurialとSCPの組み合わせによって処理されました（より巧妙な方法があります、これらはシンプルでうまく機能します）。
この構成では、結果整合性<= 〜3分。つまり、一部のユーザーは、更新されてから数分間、古いコンテンツを見ることができました。
負荷がかかっているWordPressは、メモリよりもはるかに高速なCPUを必要としているため、メモリ上で大幅に過剰に構成されてしまいました。しかし、CPUが必要であり、価格と複雑さのトレードオフは、ピーク時の限られた時間数に対して適切でした。
自動スケーリング構成を検討しましたが、ピーク負荷の持続時間が短く、需要曲線の可能性が高く、パフォーマンスメトリックとアラームが良好である（CloudWatchとSNSから開始）ことを知っていたため、手動スケーリングを選択しました-さらに別の成功KISS選択。
最も一般的なスケーリング操作は、次に大きいサイズのインスタンスをアクティブ化し、必要なソフトウェアを自動ロードし、サイトコンテンツをそのインスタンスに自動複製し、ELBグループに追加することでした。インスタンスのアクティブ化は、最初から開始して、通常3分以内に完了します。サーバーが正しく動作し、ロードバランサーに追加されていることを人間が確認したところ、スケールアップには合計でおそらく5〜10分かかりました。次に、通常、置き換えられたサーバーインスタンスを静止します。同じ5〜10分で、数十台の新しいサーバーを起動できたはずです。テストしましたが、実際にデプロイする必要はありませんでした。
最終的なフルピークロードのために、インスタンスサイズをハイメモリクアドラプルエクストララージインスタンスまで実行しました。さらに高いCPU、高いネットワーク帯域幅のクラスターコンピューティングノードを検討しましたが、異なるLinuxビルド（UbuntuではなくRed Hat/CentOSに基づくAmazonAMI）が必要なため、そこにデプロイしませんでした。 2番目のソフトウェア基盤のビルド自動化またはQAに投資したい。
ファイルにはS3を使用し、クライアントはCloudFrontディストリビューション（つまり、CDNを介してフロントされたS3）を介してS3にアクセスし、I/Oをオフロードしました。数字で見ると、I/Oオフロードを積極的に使用することが私たちが行った最も重要なことです。それも最も簡単でした。
JS、CSS、およびPHPファイルのWPテーマとプラグインを可能な限り最適化/縮小しました。このような変更はコードを壊すことに伴うものであるため、 Mercurialは変更を追跡し、サイトを壊した変更をすぐに取り消します。残念ながら、デザイナーは画像ギャラリー用のプラグインをいくつか選択し、1時間に50件のリクエストを受け取ったときに優れていたが、スケーリングでは優れていなかったTwitterフィードを表示していました。 config、CPUとTwitter APIの割り当てを直接ザッピングします。真剣に、Twitterはあなたが1秒間に100回以上ドアを叩くことを望んでいません！スケーラブルであることが保証されたTwitterフィードプラグインまたはサービスを見つけることができなかったので、私は独自の単純なキャッシュメカニズムを作成しました。少なくとも微妙な方法で外観を変更せずに修正できなかった画像ギャラリーは、その悪いデザインを補うためにCPUを追加購入しました（次回：デザイナーは、PHPではなくJSのみを使用するものを選択してください！）
YSlow、FireBug、およびGoogleChromeの開発者ツールを使用して最適化プロセスをガイドしました。
W3 TotalCacheを使用して、サイトの負荷を軽減しました。残念ながら、サイトのデザインは完全なキャッシュと互換性がありませんでした（一部のプラグインが壊れました）。これらの問題を修正する時間がなかったため、キャッシュを安全に実行できるものに限定し、それを補うためにより多くのCPU時間を購入しました。
ほとんどの自動化は、BashシェルスクリプトまたはPythonプログラムで優れたBotoモジュール/ APIを使用して行われました。Fabric、Chef、Saltなどの高レベルのプロビジョニングイネーブラーの使用を検討しましたが、さまざまな不具合がありました。 「私たちは素晴らしいですが、戻ってきて、少し後でもう一度やり直してください」と言われました。
結果は素晴らしかった。私たちは決して降りることはなく、負荷がかかった状態でぐらつくこともありませんでした。私たちは準備ができており、受け取った負荷の5倍または50倍を処理できたはずです。もっとエレガントにできることはたくさんあります。それらのいくつかは、異なる要件を持つサービスで望ましいか、必要でさえあります。たとえば、より長い時間枠での高負荷、より大きな負荷変動、または予測できないスパイクなどです。しかし、多くのKISSトレードオフは機能しましたまあ、適度なDevOpsの努力と低い実行コストで実用的な勝利を獲得します。
私の最大の後悔は、コンテンツの変更を検出してフリート全体に複製するプロセスを自動化しなかったことです。サイト運営者とコンテンツ所有者の間で手動による調整が必要でした。ピークウィンドウが短いことを考えると、これは問題なく機能しましたが、面倒でした。すべてをやり直す必要がある場合は、マスターでファイル/データベースの変更を監視し、フリート全体でレプリケーションプロセスを自動起動することが一番のアップグレードになります。 （これには、企業のスケールアウト能力が大幅に向上するという副次的な利点があります。そうすれば、より小さく、より安価なサーバーインスタンスを使用できます。自動スケール構成は、より高度に活用されます。）
Dedicated, Dedicated, Dedicated, Dedicated </steveballmer>
わかりました、それは私のシステムからそれを得ました。これほどのトラフィックのあるサイトを真剣に検討しているとしたら、実際には、500khits /時間はかなりの量です。
私は本当に本当にそれをホストするために自分のネットワークとクラスターを構築することを検討したいと思います。私はおそらく4ノードシステムでスターオフしたいと思います。実行中の2つのフロントエンド Varnish Cache、 およびバックエンドとしてApacheとMySQLの両方を実行している2つのバックエンド。バックエンド間で循環レプリケーションを実行し、セッション同期のためにmemcachedを実行します。
または、VarnishとApacheをサーバーにまとめて、データベースサーバーにデータベースのみを実行させることもできます。考えてみると、これはより良い選択かもしれません。
仮想化サーバー上のトラフィックの多いサイトについて大きな懸念があります。主にIOパフォーマンスのためですが、同じサーバー上にある他の仮想マシンのパフォーマンスに非常に悪影響を与える可能性があるため、おそらくあなたの懸念ではありませんが、他の人のトラフィックを意味しますサイトに干渉する可能性があります。
WPはあなたが思っているほど悪くはありません。あなたは多くの最適化、メディアのためのクッキーレスドメインを作らなければならないでしょう、そしてあなたが言及したすべてのものが助けになります。 2層のキャッシュ、またはおそらく3/4層が必要になります。 CDN、ReverseProxyキャッシュ、およびmemcacheを使用したクエリキャッシング、およびAPCを使用したオペコードキャッシングのメリットもあります。
実行できる小さな最適化がたくさんあり、パフォーマンスが大幅に向上します。それらはすべて調査する価値があります。
VarnishCacheは、優れたリバースプロキシキャッシュを作成しますが、非常に優れたロードバランサーも作成します。私を信じてください。複数のバックエンドサーバーが必要になります。あなたのウェブサイトが重要であり、稼働時間があなたにとって何かを意味する場合（それはあなたにお金を稼ぎますか？）、あなたは間違いなく複数のサーバーが必要になります。
考えてみると、大量のメディアアセットや画像などを配信している場合は、おそらくApacheの代わりにnginxを実行し、media.yourdomain.comを提供するか、まったく異なるCookieを使用しない別のサーバーを検討します。スタックエクスチェンジサイトで使用されるsstatic.netドメインのようなドメイン。
これを行う方法の一例を示しますが、RFC1918の範囲外のIPアドレスを公的にルーティング可能なIPアドレスに変更する必要があります;）
誰かが複数のAレコードについて不平を言う前に、私はこれをつぼみに挟むつもりです。非常にレイヤー3に移行せず、BGPまたはGSLBで高可用性の側面を実行することなく、ラウンドロビンDNSを使用してインテリジェントでない負荷分散を実行することは、コストがかかりすぎず、実際には比較して非常に安価です。 Dynect のようなサービスを使用して、もう少しインテリジェントなDNSを実行できます。これにより、ロードバランサーにリクエストを送信する前に、ある程度のホストチェックが実行されます。
あなたが良い専用サーバーホストを選ぶなら、彼らはあなたのために上記のいくつか、またはすべてをするかもしれません。かなりの量のトラフィックが予想されることを考えると、安価な専用サーバー（200〜300米ドル/月未満）は誤った経済である可能性が高く、現在のトラフィックレベルをサポートできないと簡単に言えます。取得することを期待しています。
私たちはRackspaceCloudを使用しており、ニーズに合わせて拡張できます。クラウドサイトではなく、クラウドサーバーと混同しないでください。基本的に、独自のクラスターを構築し、必要に応じてスケーリングできます。
私はWordPress唯一のホスティング会社を運営していますが、正直なところ、あなたが話しているトラフィックの量に出くわしたことがないので、私は自分の帽子を実行したくありません、何がうまくいき、何がうまくいかなかったかについて、あなたを助け、あなたの経験から学ぶことができれば幸いです。
大量の場合WordPressホスティング私はWordPress VIP
WordPress VIP Hosting WordPress.comバックボーンで実行され、3つのデータセンターの1200台のサーバー間で負荷分散されます。
あなたが得るもの：
- WordPress.comグリッドで実行されているサイト（3つのデータセンターに1,200を超えるサーバー）
- 無制限のスペースと帯域幅
- 24時間年中無休のITサポート
- コンテンツ配信ネットワークと1時間ごとのバックアップ
- エンタープライズレベルのAkismetスパム保護
- より高速で安全なサイトのためのサイトのテーマに関する最適化とセキュリティフィードバック
- 今日のブログ、マイコメント、タグサーファー、GravatarsなどのWordPress.com機能との統合
- パブリッシャーブログでの新しいブログの宣伝
- より良い検索エンジンとGoogleニュースの露出のためのサイトマップとニュースサイトマップ
- WordPress.comにログインしているユーザーはドメインにログインするため、ブログへのコメントが簡単になります。
費用
月額約2,500ドルから。
私は個人的な経験から話すことはできませんが、 WPエンジン はこの質問のために特別に設立されました。
VPS.netは、高いフォールトトレランスを備えた完全にスケーラブルなソリューションです。強力で柔軟性がありながら安価です。 MediaTempleは、それほど強力ではない仮想マシンから始めて、基本的にボタンをクリックするだけで独自のサーバーにスケールアップできるため、もう1つの優れたプロバイダーです。水平方向（冗長性/クラスター）および垂直方向（より多くのストレージ/ CPU/RAM）に迅速に拡張できるプロバイダーを探す必要があります。