トラフィックの多いWebサイトをスケールアウトするにはどうすればよいですか？

キャパシティを処理するために「スケールアウト」する必要があるWebサイトに対して、どのようなベストプラクティスを実施する必要がありますか？これは、人々がクラウドを検討している今、特に関連していますが、基本を逃している可能性があります。

開発レベルのタスクからインフラストラクチャー、管理まで、ベストプラクティスと思われるものについてお聞かせください。

並行性のための設計

つまり、コーディング中に、複数のスレッドを実行することを計画します。共有状態（多くの場合、データベースのみ）を計画します。複数のプロセスを計画します。物流を計画します。

これにより、システムを複数のマシンに分散し、負荷分散を使用して複数のプロセスに分散できます。障害が発生した場合に冗長プロセスを実行することができ、システムをその場で変更する必要がある場合は、すべてのサービスを強制終了する必要はありません。

あなたが考慮するかもしれないいくつかのこと：

• データストレージの読み取り側と書き込み側を分離します。
  
  • CQRS /イベントソーシング
  • CQS
  • メッセージパッシング/アクター
• 共有プロセスとスレッド状態の回避
  • したがって、ロックを回避する
  • 型システムを介してこれを回避するには、クラス、構造体、およびその他のデータ型を不変、つまり構築後に変更しないように作成します。特に複雑な抽象データ型の場合、驚くほどうまく機能します（たとえばjQueryの実装）
• IOでWebサーバースレッドをブロックしていません。ASP.Netを使用している場合は、APMパターン/タスク並列ライブラリ（TPL）で非同期ページ/アクションを使用します
• ユーザーセッションディクショナリに状態の負荷を保存しない
  • これは、IISでスレッドの移行が発生したときにスレッド間で移動する必要があります。
  • 保護されていない/静的なリソースが、オーバーヘッドを追加する同じアプリケーションフレームワーク（ASP.Netなど）で処理されないように、インテリジェントルーティングを使用します。たとえば、異なるWebサーバーがあることを確認してください。
• 非同期ワークフローパターンを使用した継続渡しコードの記述（例：bind（haskell）/callcc/Tasks.ContinueWith/F#の非同期）
• キューイング理論を使用して、ボトルネックが発生する可能性のある場所を計算します
• 読み取りモデルやその他のアプリケーションの状態に対して、プルベースの更新ではなくプッシュベースの更新を使用します。たとえば、RabbitMQ / nServiceBusを介して
• 適切な最小機能の「httpハンドラ」を使用する
• 静的ファイルの場合、e-tagを提供し、Webインフラストラクチャが正常に機能するように有効期限ポリシーをキャッシュします（たとえば、squidプロキシを使用）
• （スケーリングの問題を解決し、オンサイトのチュートリアルを入手してください;））

何も共有しないアーキテクチャ。

それを念頭に置いて、あなたが思うかもしれないこととは反対に、すぐにスケールアウトソリューションにジャンプしないでください。オフシステムオーバーヘッドとインシステムコールを比較検討する必要があります。たとえば、ローカルコールを行うよりも、ネットワークインターフェースを介してDB接続を行うのにLOT時間がかかります。真の大規模システムの場合、管理、電力、および調整作業にどれだけの時間をスケールアウトに必要とするかを予算に追加します。

とにかく、「何も共有しない」アーキテクチャにはまだ大きな価値があり、時が来たらシステムを階層化してスケールアウトできます。

複数のホスト名でリクエストを並列化する

HTTP標準の一部は、WebクライアントがDNSホストごとに最大2つのセッションを要求するというセクションです。以下は、あなたとwww.domain.comのエイリアスを作成し、リクエストの同時実行性を高めて、ページの読み込みを高速化するソリューションです。

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

基本的に、ASP.NET HTTPハンドラーを編集して、クライアントを送信するターゲットホストを変更します。各ホストは「www」へのCNAMEです。

安全で高速、信頼性の高いDNS

レジストラのDNSサーバーを使用して、稼働時間やパフォーマンスのSLAを持たない大容量のWebサイトをいくつか見つけました。さらに、それらのサーバーはインドにあり、遅延だけでDNSスプーファーが顧客または中間ISPのキャッシュを汚染する可能性が高くなります。これにより、SSLで保護されたトラフィックでさえ、誰にも知らされることなくリダイレ​​クトされます。

DNS速度は、レコードがキャッシュされるまでのサーバーの初期ロード時間にも影響します。

DynDNSまたはNeustarを使用しているのは、ほとんどの顧客がかなり堅牢なDNSインフラストラクチャを持っているためです（ただし、高価であり、他の企業とは提携していません）。

キーはシンプルになると思います。

簡単なコードを用意してください。それはあなたが見て理解していることを意味します。サーバーを拡張および変更する場合、何が起こっているのかを知る必要があります。また、すぐに理解する必要があるコーダーを追加する必要があります。明らかではないランダムなコードを呼び出すフックとXMLファイルは非常に悪いです。

その後、問題をテストして見つけることができます。

こちらをご覧ください：http : //blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

で、私たちstellarbuild試してダウンタイムなしに必ず当社のウェブサイトの規模を作成します。つまり、コードが何をするのか、どこでそれを行うのかを知る必要があるということです。別のマシンをテストしている場合でも、スケールに時間がかかりすぎることはありません。ほとんどの人は、悲しいことに、手遅れになったときから始めます。私の意見では、一度最適化することができます。