トラフィックの多い Web サイトをスケールアウトするにはどうすればよいですか?
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
容量を処理するために「スケールアウト」する必要がある Web サイトでは、どのようなベスト プラクティスを実行する必要がありますか?これは、人々がクラウドを検討しているものの、基本を見逃している可能性がある現在、特に重要です。
開発レベルのタスクからインフラストラクチャ、管理まで、ベスト プラクティスと考えられるあらゆるものについて聞きたいと思っています。
解決
並行性のための設計
つまり、コーディング中に、複数のスレッドが進行することを計画しています。共有状態を計画します（多くの場合、DBのみ）。複数のプロセスの計画。物理的な分布の計画。
これにより、複数のマシンにシステムを配布し、ロードバランスを備えた複数のプロセスに分散できます。障害が発生した場合に冗長なプロセスを実行することができます。また、システムを内容を変更する必要がある場合は、すべてのサービスを殺す必要はありません。
他のヒント
考慮すべき点がいくつかあります:
- データ ストレージの読み取り側と書き込み側を分離します。
- CQRS/イベントソーシング
- CQS
- メッセージパッシング/アクター
- 共有プロセスとスレッド状態の回避
- したがって、ロックを回避します
- クラス、構造体、その他のデータ型を不変になるように作成することで、型システムを通じてこれを回避できます。施工後も変化なし。特に複雑な抽象データ型の場合、驚くほどうまく機能します (例:jQueryの実装)
- IO で Web サーバーのスレッドをブロックしません。ASP.Net を使用している場合は、APM パターン/タスク並列ライブラリ (TPL) で非同期ページ/アクションを使用します。
- ユーザーセッションディクショナリに大量の状態を保存しない
- IIS でスレッドの移行が発生する場合、これをスレッド間で移動する必要があります。
- インテリジェントなルーティングを備え、安全でない/静的なリソースが同じアプリケーション フレームワークで提供されないようにします (例:ASP.Net) によりオーバーヘッドが追加されます。たとえば、さまざまな Web サーバーを使用する場合を考えてみましょう。
- 非同期ワークフロー パターンを使用して継続を渡すコードを作成します (例:bind (haskell)/callcc/Tasks.ContinueWith/F# の非同期)
- キュー理論を使用してボトルネックが発生する可能性のある場所を計算する
- 読み取りモデルやその他のアプリケーション状態に対して、プルベースではなくプッシュベースの更新を使用します。例えば。RabbitMQ/nServiceBus 経由
- 該当する最小限の機能の「http ハンドラー」を使用する
- 静的ファイルの場合、電子タグとキャッシュ有効期限ポリシーを提供して、Web インフラストラクチャが正常に機能できるようにします (例:イカプロキシを使用)
- (スケーリングの問題を解決し、オンサイトのチュートリアルを得るために私を雇ってください ;))
アーキテクチャは何も共有しません。
それを念頭に置いて、あなたが思うかもしれないことに反して、すぐにスケールアウトソリューションにジャンプしないでください。オフシステムのオーバーヘッドとシステム内の呼び出しは、十分に進むべきではありません。たとえば、ローカルコールを行うよりも、ネットワークインターフェイス全体でDB接続を作成するのに時間がかかります。予算は、真の大規模システムの余分な$と、スケールアウトでの管理、電力、チューニングの努力が必要な時間です。
とにかく、私はまだ「Share Nothing」アーキテクチャには大きな価値があり、時が来たときにシステムを重ねて拡大することができます。
いくつかのホスト名を並べる要求を並列化します
HTTP標準の一部は、WebClientsがDNSホストごとに最大2セッションを要求すると言うセクションです。これは、あなたとエイリアスをwww.domain.comを外し、より高いリクエストの並行性を取得し、ページの読み込みをより速くするソリューションです。
基本的に、ASP.NET HTTPハンドラーを編集して、クライアントに送信するターゲットホストを交互に行います。各ホストは「WWW」のcnameです。
安全で高速で信頼性の高いDNS
稼働時間やパフォーマンスにはSLAがないレジストラのDNSサーバーを使用して、いくつかの大容量のWebサイトを見つけました。さらに、彼らのサーバーはインドにあり、遅延だけでDNSスプーファーがお客様の顧客、または中級ISPのキャッシュを毒する可能性が高くなります。これにより、SSL保護されたトラフィックでさえ、誰も知らずにリダイレクトされます。
DNS速度は、レコードがキャッシュされる前に、サーバーの初期負荷時間にも影響します。
DyndnsまたはNeustarをほとんどの顧客に使用しています。なぜなら、彼らはかなり堅実なDNSインフラストラクチャを持っているからです（それは高価であり、それらの企業に他の提携はありませんが）。
キーはシンプルになると思います：
簡単なコードがあります。それはあなたが見て理解していることを意味します。サーバーを拡張して変更するにつれて、何が起こっているのかを知る必要があります。また、すぐに理解する必要があるコーダーを追加する必要があるかもしれません。明らかではないランダムコードを呼び出すフックとXMLファイルは非常に悪いです。
その後、テストして問題を見つけることができます。
ここを見て： http://blog.servint.net.net/2013/08/27/going-big-how-to-scale-a-website-1-infrastructure-thatscales/
私たちは Stellarbuildは、ダウンタイムなしでWebサイトを拡大するようにしようとします。 つまり、コードが何をし、どこで行うかを知ることができる必要があります。別のマシンをテストしていても、スケーリングするのにそれほど時間がかかることはありません。ほとんどの人は、それがほとんど手遅れであるときにのみ始まります、悲しいことに。私の意見では、それを行うと最適化できます。
