このブログでクライアント側のバランス調整について読んだので、Webプロジェクトのスケーリングの基本原則を説明する記事を公開することにしました。 読んでみると面白いと思います。

スケーリングの基本

スケーラビリティ-デバイスがその能力を高める能力
可能性
機能ブロックの数を増やすことにより、
1つを実行し、
同じタスク。
Glossary.ru

通常、彼らはスケーリングについて考え始めます
サーバーは、割り当てられた作業を処理しません。彼は正確には何ですか
やってる？全体としてのWebサーバーの動作は、主に
コンピューターの職業-データ処理。 HTTP（またはその他の）要求への返信
特定のデータに対するいくつかの操作が含まれます。したがって、
2つの主要なエンティティがあります-これらはデータ（ボリュームによって特徴付けられる）と
計算（複雑さによって特徴付けられる）。サーバーは、
大量のデータのために機能します（物理的に適合しない場合があります
サーバー）、または大きな計算負荷のため。ここについてです、
もちろん、総負荷について-単一のリクエストの処理の複雑さは
小さいですが、それらの多数がサーバーを「いっぱいにする」ことができます。

スケーリングについて主に例で説明します
典型的な成長中のWebプロジェクトですが、ここで説明する原則は以下にも適しています
他のアプリケーション。まず、プロジェクトのアーキテクチャとシンプルな
そのコンポーネントを複数のサーバーに配布してから、
スケーリング計算とデータ。

典型的なサイトアーキテクチャ

典型的なサイトは、非常にシンプルなアーキテクチャから始まります。
-これは1つのWebサーバーです（通常、Apacheはその役割を果たします）。
HTTPリクエストを処理するすべての作業を誰が行うか、
訪問者から来ています。彼は顧客にいわゆる「静的」を与え、
サーバーのディスク上にあり、処理を必要としないファイルがあります：写真（gif、
jpg、png）、スタイルシート（css）、クライアントスクリプト（js、swf）。同じサーバー
計算を必要とする要求に応答します-通常、この形成
htmlページ。ただし、画像やその他のドキュメントがその場で作成される場合があります。
ほとんどの場合、そのようなリクエストに対する回答は、PHPで記述されたスクリプトによって生成されます。
perlまたは他の言語。

このような単純な作業スキームの欠点は、次の点で異なることです。
文字リクエスト（ディスクからのファイルのアップロードとスクリプトコンピューティング）
同じWebサーバーによって処理されます。クエリの計算には
サーバーのメモリに多くの情報を保持します（スクリプト言語インタープリター、
スクリプト自体、それらが使用するデータ）、多くの時間がかかる可能性があります
コンピューティングリソース。対照的に、静的な出力はほとんどリソースを必要としません
CPU。ただし、クライアントの負荷が低い場合は時間がかかることがあります。
通信速度。 Apacheサーバー内部では、それぞれが
接続は別のプロセスで処理されます。これはスクリプトを実行するのに便利です。
ただし、単純なクエリの処理には最適ではありません。重いことがわかりました（から
スクリプトおよびその他のデータ）Apacheプロセスは待機するのに多くの時間を費やします
リクエストを送信した後、レスポンスを送信するときにサーバーのメモリを浪費します。

この問題の解決策は、処理作業の分散です。
2つの異なるプログラム間のリクエスト-つまりフロントエンドに分割し、
バックエンド。軽量のフロントエンドサーバーは、静的変数の戻り時にタスクを実行し、残りは
フォーメーションが実行されるバックエンドへのリダイレクト（プロキシ）を要求します
ページ。遅いクライアントを待つこともフロントエンドにかかります。
多重化（1つのプロセスが複数のクライアントにサービスを提供する場合-
たとえば、nginxまたはlighttpdが動作します）、ほとんど何も待たない
それだけの価値がある。

サイトの他のコンポーネントのうち、データベースに注意する必要があります
通常、システムのメインデータを保存します-最も人気のあるものは次のとおりです
無料のDBMS MySQLおよびPostgreSQL。多くの場合、個別に割り当てられたストレージ
写真を含むバイナリファイル（たとえば、記事のイラスト
サイト、アバター、ユーザーの写真）またはその他のファイル。

したがって、私たちは
いくつかのコンポーネント。

通常、サイトのライフの開始時に、アーキテクチャのすべてのコンポーネント
1つのサーバーにあります。彼が負荷に対処するのをやめた場合、
簡単な解決策があります-最も簡単に取り外し可能な部品を別の部品に移動します
サーバーデータベースから始める最も簡単な方法は、データベースを別のサーバーに転送し、
スクリプトのアクセス詳細を変更します。ところで、この瞬間に私たちは直面しています
適切なコードアーキテクチャの重要性。データベースを使用する場合
サイト全体に共通の別のモジュールに移動-パラメーターを修正
接続は簡単になります。

コンポーネントをさらに分離する方法も明確です。たとえば、フロントエンドを別のサーバーに移動できます。しかし、通常はフロントエンド
システムリソースをほとんど必要とせず、この段階ではその削除は重要ではありません
パフォーマンスの向上。ほとんどの場合、サイトはパフォーマンスに依存しています
スクリプト-応答（htmlページ）の作成に時間がかかりすぎます。
したがって、次のステップは通常、バックエンドサーバーのスケーリングです。

コンピューティングの分布

成長するサイトの典型的な状況-データベースは既に
別のマシンに移動し、フロントエンドとバックエンドの分離が行われ、
ただし、トラフィックは増加し続け、バックエンドには処理する時間がありません
お問い合わせ。これは、計算をいくつかに分散する必要があることを意味します
サーバー。簡単です-2台目のサーバーを購入して装着するだけです
バックエンドが機能するために必要なプログラムとスクリプト。
その後、ユーザーリクエストが配信されることを確認する必要があります
（バランス）受信したサーバー間。さまざまなバランス調整方法について
以下で説明しますが、今のところ、フロントエンドは通常これを行うことに注意してください、
リクエストを均等に分配するように構成されています
サーバー。

すべてのバックエンドサーバーが正しく対応できることが重要です
お問い合わせに対応します。通常、このためには、それらのそれぞれがで動作することが必要です
同じ現在のデータセット。すべての情報を単一の
データベース、DBMS自体が共有アクセスとデータの一貫性を提供します。
一部のデータがサーバーにローカルに保存されている場合（たとえば、phpセッション
クライアント）、共有リポジトリへの移動、またはそれ以上について検討する必要があります
洗練されたクエリ割り当てアルゴリズム。

複数のサーバーに分散することは機能しません
スクリプトだけでなく、データベースによって実行される計算。 DBMSが多くを行う場合
複雑なクエリ、サーバーのプロセッサ時間を消費する、いくつかを作成できます
異なるサーバー上のデータベースのコピー。これにより、同期の問題が発生します
変更中のデータ、およびいくつかのアプローチがここで適用可能です。

アプリケーションレベルの同期。この場合、
スクリプトは、データベースのすべてのコピーに対する変更を独立して記録します
データの正確性に対する責任）。これは最良のオプションではありません
実装には注意が必要であり、高度なエラー耐性があります。
レプリケーション -つまり、自動レプリケーション
1つのサーバーで他のすべてのサーバーに加えられた変更。通常は
レプリケーションを使用する場合、変更は常に同じサーバーに書き込まれます。これはマスターと呼ばれ、残りのコピーはスレーブと呼ばれます。ほとんどのDBMSには
組み込みまたは外部の複製ツール。区別する
同期レプリケーション-この場合、データ変更のリクエストは待機します
データはすべてのサーバーにコピーされますが、その後は成功します-そして非同期に-この場合、変更はスレーブサーバーにコピーされます
遅延しますが、書き込み要求はより速く完了します。
マルチマスター複製。このアプローチは似ています。
前のものとは異なりますが、ここではデータの変更を行うことができます。
1つの特定のサーバー、およびデータベースの任意のコピー。この変更により
同期的または非同期的に他のコピーにアクセスします。時々そのようなスキームは呼ばれます
「データベースクラスター」という用語。

システムをサーバーに分散するためのさまざまなオプションがあります。
たとえば、1つのデータベースサーバーと複数のバックエンド（非常に
典型的なスキーム）、またはその逆-1つのバックエンドと複数のデータベース。そして、スケールする場合
バックエンドサーバーとデータベースの両方で、バックエンドとデータベースのコピーを結合できます。
一台。いずれにせよ、いくつかのインスタンスがあるとすぐに
どのサーバーでも、サーバー間で適切に配布する方法についての質問が発生します
ロード。

バランス方法

http、データベースなど、あらゆる目的で複数のサーバーを作成し、それぞれがリクエストを処理できるようにします。前に
私たちには仕事があります-彼らの間で仕事を分配する方法、どのように見つけるか
サーバーはリクエストを送信しますか？リクエストを配信するには、主に2つの方法があります。

バランシングノード 。この場合、クライアントは1つのリクエストを送信します
彼が知っている固定サーバー。このサーバーは既にリクエストを次のいずれかにリダイレクトします。
稼働中のサーバー。典型的な例は、1つのフロントエンドと複数のフロントエンドを持つサイトです
リクエストがプロキシされるバックエンドサーバー。ただし、「クライアント」は
システム内にある-たとえば、スクリプトはリクエストを送信できます
データベースプロキシサーバー。DBMSサーバーの1つに要求を転送します。
バランシングノード自体は、別個のサーバーと1つのサーバーの両方で機能します。
本番サーバーから。

このアプローチの利点は
クライアントがシステムの内部構造について何も知る必要がないこと-量
サーバー、そのアドレスと機能について-この情報のみが知っている
バランサー。ただし、不利な点は、バランシングユニットが単一であることです。
システム障害ポイント-障害が発生した場合、システム全体が
手術不能。さらに、負荷が大きい場合、バランサーは単純に停止することがあります
彼らの仕事に対処するため、このアプローチは常に適用できるとは限りません。
クライアント側のバランス 。避けたいなら
単一障害点、代替があります-サーバー選択を指示します
クライアントに。この場合、クライアントは私たちの内部構造を知っている必要があります
アクセスするサーバーを選択できるようにするためのシステム。
間違いない利点は、障害点がないことです-のいずれかの障害の場合
サーバー、クライアントは他の人に連絡することができます。ただし、これの料金は
より複雑なクライアントロジックとバランスの柔軟性の低下。

もちろん、これらのアプローチの組み合わせがあります。例えば
DNSバランシングなどのよく知られた負荷バランシング方式は
サイトのIPアドレスを決定するときにクライアントが発行されること
複数の同一サーバーの1つのアドレス。したがって、DNSは
クライアントが「配布」を受け取るバランスノードの役割。しかし
DNSサーバーの構造は、次の原因による障害点がないことを示唆しています。
複製-つまり、2つのアプローチのメリットが組み合わされます。もちろん、これ
また、バランスを取ることには不利な点もあります-例えば、そのようなシステムは動的に行うのが難しいです
再構築します。

通常、サイトの操作は1つのリクエストに限定されません。
したがって、設計時には、順次クエリができるかどうかを理解することが重要です
クライアントは異なるサーバーによって正しく処理される必要があります。または、クライアントは
サイトでの作業中に1つのサーバーに関連付けられています。これは特に重要です
サイトはユーザーのセッションに関する一時的な情報を保存します
無料配布も可能です-しかし、それは保存する必要があります
一般にすべてのストレージサーバーのセッション）。訪問者を「バインド」する
特定のサーバーは、そのIPアドレスである場合があります（ただし、変更可能）。
またはCookie（サーバー識別子が事前に書き込まれている）、または
目的のドメインにリダイレクトするだけです。

一方、コンピューティングサーバーは等しくない場合があります。
場合によっては、反対のことをすることが有益です。
いずれかのタイプのリクエストを処理し、垂直方向の分離を取得します
機能。次に、クライアントまたはバランシングノードがサーバーを選択します
受信したリクエストのタイプに応じて。このアプローチにより、分離することができます
残りからの重要な（またはその逆、重要ではないが重い）要求。

データ配信

計算を分散する方法を学びました。
出席は問題ではありません。ただし、データ量は増え続けており、
それらを保存して処理することがますます困難になっています-つまり、構築する時間です
分散データウェアハウス。この場合、1つまたは
データベースの完全なコピーを含む複数のサーバー。代わりに、データ
異なるサーバーに分散されます。どのような配布スキームが可能ですか？

垂直分割-最も単純な場合
個々のデータベーステーブルの別のサーバーへの転送を表します。で
これは、異なるサーバーにアクセスするためにスクリプトを変更する必要があります
異なるデータ。制限では、各テーブルを個別のサーバーに保存できます
（実際にはこれが有益である可能性は低いですが）。明らかに、これで
配布すると、データを結合するSQLクエリを作成する機能が失われます
異なるサーバーにある2つのテーブル。必要に応じて、実装できます
アプリケーションの統合ロジック。ただし、DBMSほど効果的ではありません。
したがって、データベースを分割するときは、テーブル間の関係を分析する必要があります。
最も独立したテーブルにまたがります。

より複雑なケース
ベースの垂直分布は、一部のテーブルの分解です
その列は1つのサーバーに表示され、一部は別のサーバーに表示されます。そのようなテクニック
あまり一般的ではありませんが、たとえば、小さな
まれにしか使用されない大量のデータを頻繁に更新します。
水平分布 （水平分割）-で構成
1つのテーブルのデータを複数のサーバーに分散する。実際、
各サーバーは同じ構造のテーブルを作成して保存します
データの特定の部分。さまざまな方法でサーバー間でデータを分散できます。
基準：範囲（ID <100000のレコードはサーバーAに、残りはサーバーBに移動）、値のリスト（タイプ「CJSC」および「OJSC」のレコードはサーバーに保存されます）
A、残り-サーバーB）または特定のフィールドのハッシュ関数の値
レコード。水平データ分割により、無制限に保存できます
ただし、レコードの数は選択を複雑にします。最も効果的に選択できます
どのサーバーに保存されているかがわかっている場合にのみ記録します。

正しいデータ配布スキームを選択するには、以下を行う必要があります
ベースの構造を注意深く分析します。既存のテーブル（および場合によっては
個々のフィールド）は、レコードへのアクセス頻度、頻度によって分類できます
更新と関係（いくつかから選択する必要性
テーブル）。

前述のように、データベースに加えて、サイトでは多くの場合、
バイナリファイル用のストレージ。分散ファイルストレージシステム
（実際には、ファイルシステム）は2つのクラスに分けることができます。

オペレーティングシステムレベル 。また、
そのようなシステムでファイルを操作するアプリケーションは、通常の作業と違いはありません
ファイル。サーバー間の情報交換は、オペレーティングシステムによって行われます。
このようなファイルシステムの例には、
NFSファミリーまたはあまり知られていませんが、より最新のLustreシステム。
アプリケーションレベルで配布
リポジトリは、情報自体の交換を意味します
アプリケーション。通常、利便性のためにストレージを操作する機能は、
別のライブラリ。このようなストレージの1つの鮮明な例は、MogileFSです。
LiveJournalのクリエイター。別の一般的な例は
WebDAVプロトコルとそのサポートストレージ。

データの分布は解決するだけではないことに注意してください
ストレージの問題だけでなく、部分的に負荷分散の問題-それぞれ
サーバーのレコードが少なくなるため、処理が高速になります。
計算方法とデータ配布方法の組み合わせにより、構築することができます
潜在的に無制限のスケーラブルアーキテクチャで動作可能
任意の量のデータと負荷。

結論

上記を要約するために、簡単な要約の形で結論を定式化します。

2つの主要な（および関連する）スケーリングタスクは、分散の計算とデータの分散です。
典型的なサイトアーキテクチャには、役割の分離と
フロントエンド、バックエンド、データベース、および場合によってはファイルストレージが含まれます
少量のデータと重い負荷の場合
データベースミラーリング-同期または非同期レプリケーション
大量のデータでは、データベースを配布する必要があります-分割
彼女の垂直または水平
バイナリファイルは分散ファイルシステムに保存されます
（OSレベルまたはアプリケーションで実装）
バランシング（要求の分散）は均一にすることも、
機能分離あり; バランシングユニット付き、またはクライアント側
メソッドの適切な組み合わせは、あらゆる負荷を維持します;）

参照資料

興味深い英語のサイトやブログでこのトピックを引き続き学習できます。

PSコメントはもちろん歓迎です;）

スケーリングの基本

スケーリングの基本

典型的なサイトアーキテクチャ

コンピューティングの分布

バランス方法

データ配信

結論

参照資料

More articles: