半年前、私の卒業証書翻訳のテキストについて質問がありました 。 集合的な精神の助けの結果は、 ケイト松平によって書かれたスケーラブルなウェブアーキテクチャと分散システムの章を翻訳する決定でした。 これは、このような量と複雑さの私の最初の翻訳であることに注意する必要があります。 テキストは比較的うまく翻訳されましたが、翻訳の質の観点からは10から6-7に設定しました。私の努力が無駄にならないように、作業の結果を公開します。



Habrの読者の要望により 、現在はトピック形式の完全版。

スケーラブルなWebアーキテクチャと分散システム

ケイト・マツデイラ

翻訳： jedi-to-be 。

訂正： Anastasiaf15 、 sunshine_lass 、 Amaliya 、 fireball 、 Goudron 。

オープンソースソフトウェアは、最大規模のWebサイトの主要な構成要素になりました。 これらのWebサイトの成長に伴い、アーキテクチャのベストプラクティスとガイドラインが登場しました。 この章では、大規模なWebサイトを設計する際に考慮すべき重要な問題のいくつかと、これらの目標を達成するために使用される基本的なコンポーネントのいくつかを取り上げます。

この章ではWebシステムの分析に焦点を当てていますが、一部の資料は他の分散システムに外挿することができます。

1.1分散Webシステム構築の原則

スケーラブルなWebサイトまたはアプリケーションの作成と管理とはどういう意味ですか？ 原始的なレベルでは、これは単にユーザーをインターネット経由でリモートリソースに接続することです。 また、リソースまたはこれらのリソースへのアクセスは、多くのサーバーに分散されており、Webサイトのスケーラビリティを保証するリンクです。

人生のほとんどのことと同様に、事前にWebサービスを計画するのに費やした時間は、将来的に役立ちます。 大規模なWebサイトの背後にある考慮事項とトレードオフの一部を理解すると、小規模なWebサイトを作成する際に、より賢明な決定を下すことができます。 以下は、大規模なWebシステムの設計に影響するいくつかの重要な原則です。

• アクセシビリティ：ウェブサイトの稼働時間は、多くの企業の評判と機能にとって非常に重要です。 一部の大規模なオンライン小売店では、数分間でもアクセスできない場合、数千または数百万ドルの収益が失われる可能性があります。 したがって、常にアクセス可能でフェールセーフなシステムの開発は、ビジネスと技術の両方の基本的な要件です。 分散システムの高可用性には、主要コンポーネントの冗長性の慎重な検討、部分的なシステム障害からの迅速な回復、および問題が発生した場合の機能のスムーズな削減が必要です。
• パフォーマンス： Webサイトのパフォーマンスは、ほとんどのサイトにとって重要な指標になっています。 ウェブサイトの速度は、ユーザーのパフォーマンスとユーザーの満足度、検索エンジンのランキングに影響します。これは、視聴者維持率と収益に直接影響する要因です。 その結果、重要なことは、高速応答と低遅延に最適化されたシステムを作成することです。
• 信頼性：システムは信頼性が高く、データに対する特定の要求が特定のデータを均一に返す必要があります。 データが変更または更新された場合、同じリクエストで新しいデータが返されます。 ユーザーは、何かがシステムに書き込まれているか、システムに保存されているかを知る必要があります。そうすれば、後でデータを取得できるように、その場所に確実に残ることができます。
• スケーラビリティ：大規模な分散システムの場合、サイズは、リストから考慮すべき1つの項目にすぎません。 同様に重要なのは、大量の負荷を処理するためのスループットを向上させる取り組みです。これは通常、システムのスケーラビリティと呼ばれます。 スケーラビリティは、システムのさまざまなパラメーターに関連する可能性があります。処理可能な追加トラフィックの量、ストレージデバイスの容量の増加の容易さ、または他のトランザクションをさらに処理できる量です。
• 管理性：操作しやすいシステムを設計することも重要な要素です。 システムの制御可能性は、操作の「保守」および「更新」の拡張性と同等です。制御可能性を確保するには、診断の簡素化と新たな問題の理解、更新または変更の容易さ、および稼働中のシステムの気まぐれの問題を考慮する必要があります。例外？）
• コスト：コストは重要な要素です。 明らかにハードウェアとソフトウェアのコストが含まれる場合がありますが、システムの展開と保守に必要な他の側面を考慮することも重要です。 開発者がシステムを構築するのに必要な時間、システムを起動するのに必要な操作の労力、さらには十分なレベルのトレーニングさえすべて提供されなければなりません。 コストは総所有コストです。

これらの原則はそれぞれ、分散型Webアーキテクチャの設計における意思決定の基礎となります。 ただし、一方の目標の達成は、他方の怠慢によるものであるため、それらは互いに対立する可能性もあります。 簡単な例：パフォーマンスソリューション（スケーラビリティ）として複数のサーバーを単純に追加することを選択すると、管理コスト（追加のサーバーを実行する必要があります）を増やし、サーバーを購入できます。

あらゆる種類のWebアプリケーションを開発する場合、プロジェクトがそれらの1つ以上を寄付できることを確認することであっても、これらの重要な原則を考慮することが重要です。

1.2基本

システムのアーキテクチャを検討する際には、たとえば、どのコンポーネントを使用するか、どのように組み合わせるか、どのようなトレードオフを行うかなど、対処する必要があるいくつかの問題があります。 スケーラビリティを明らかに必要とせずにスケーラビリティに投資することは、合理的なビジネス上の決定とは見なされません。 ただし、計画の際に事前に考慮しておくと、将来多くの時間とリソースを節約できます。

このセクションでは、ほとんどすべての大規模なWebアプリケーションに不可欠ないくつかの基本的な要素、 サービス 、

冗長性 、 セグメンテーション 、およびフェールオーバー 。 これらの各要因には、特に前のセクションで説明した原則の文脈において、選択と妥協が伴います。 明確にするために、例を示します。

例：画像ホスティングアプリケーション

おそらくすでに画像をオンラインで投稿しているでしょう。 複数の画像の保存と配信を提供する大規模なサイトの場合、低応答遅延（迅速な取得）を特徴とする費用対効果の高い信頼性の高いアーキテクチャを作成する際に問題があります。

ユーザーが中央サーバーに画像をアップロードし、FlickrやPicasaのようなサイトまたはAPIへのリンクを介して画像を要求できるシステムを想像してください。 説明を簡単にするために、このアプリケーションには2つの主なタスクがあると仮定します。サーバーに画像をアップロード（書き込み）し、画像を要求する機能です。 もちろん、効果的なダウンロードは重要な基準ですが、優先度はユーザーのリクエストに応じて迅速に配信することです（たとえば、Webページまたは他のアプリケーションで表示する画像をリクエストできます）。 この機能は、コンテンツ配信ネットワーク（CDN）のWebサーバーまたはエッジサーバーによって提供される機能に似ています。 通常、CDNサーバーは多くの場所にデータオブジェクトを格納するため、地理的/物理的な場所がユーザーに近くなり、パフォーマンスが向上します。

システムの他の重要な側面：

• 格納されるイメージの数は無制限にすることができるため、ストレージのスケーラビリティはこの観点から考慮する必要があります。
  
  
• 画像のダウンロード/リクエストの待ち時間は短くする必要があります。
  
  
• ユーザーがサーバーに画像をアップロードする場合、ユーザーのデータは常に一貫性とアクセス可能性を維持する必要があります。
  
  
• システムは保守が容易でなければなりません（管理性）。
  
  
• 画像ホスティングはあまり利益をもたらさないため、システムは費用対効果が高いはずです。
  
  

図1.1は、機能の簡略図です。

図1.1：画像ホスティングアプリケーションの簡略化されたアーキテクチャ図

この画像ホスティングの例では、システムは非常に高速であり、そのデータは安全に保存され、これらの属性はすべてスケーラブルです。 このアプリケーションの小さなバージョンを作成することは標準的なタスクであり、単一のサーバーでホストできます。 ただし、このような状況はこの章では重要ではありません。 Flickrと同じくらい大きなものを作成する必要があるとしましょう。

サービス

スケーラブルなシステムの設計を検討する場合、機能を分離し、システムの各部分を明確に定義されたインターフェイスを持つ個別のサービスと考えると便利です。 実際には、この方法で設計されたシステムにはサービス指向アーキテクチャ（SOA）があると考えられています。 これらのタイプのシステムの場合、各サービスには独自の機能コンテキストがあり、このコンテキスト外の何かとの相互作用は、通常は別のサービスのパブリックAPIである抽象インターフェースを介して行われます。

システムをいくつかの補完的なサービスに分解すると、一部の部分の動作が他の部分から分離されます。 この抽象化により、サービス、その基盤となる環境、およびサービスコンシューマー間の明確な関係を確立できます。 明確なアウトラインを作成すると、問題の場所を特定するのに役立ちますが、各パーツを個別にスケーリングすることもできます。 広範囲の要求に対応するためのこのタイプのサービス指向システムの設計は、プログラミングにおけるオブジェクト指向アプローチに似ています。

この例では、すべてのダウンロードおよび画像取得リクエストは同じサーバーで処理されます。 ただし、システムは拡張する必要があるため、これら2つの機能を独自のサービスに分離することをお勧めします。

このサービスは将来頻繁に使用されると仮定します。 このシナリオは、2つの機能が共有リソースを奪い合うため、録画が画像の読み取りにかかる時間にどの程度影響するかを追跡するのに役立ちます。 アーキテクチャによっては、この効果は大きくなる場合があります。 送受信速度が同じであっても（少なくとも3：1の受信/出力速度比を持つように設計されているため、ほとんどのIPネットワークでは一般的ではありません）、読み取りファイルは通常キャッシュから抽出され、レコードは最終的にはディスクにアクセスします（同様の状況で複数回書き換えられる可能性があります）。 すべてのデータがメモリ内にある場合、またはディスク（SSDソリッドステートドライブなど）から読み取られた場合でも、データベースへの書き込みはほとんどの場合データベースからの読み取りよりも遅くなります。 （Pole Position、ベンチマークデータベース用のオープンソースツール、 http：//polepos.org/およびhttp://polepos.sourceforge.net/results/PolePositionClientServer.pdfの結果。）。

この設計のもう1つの潜在的な問題は、ApacheやlighttpdなどのWebサーバーでは、通常、処理できる同時接続の数に上限があることです（デフォルト値は約500ですが、それ以上の場合もあります）トラフィックが多い場合、レコードはこの制限をすぐに使い果たす可能性があります。 読み取りは非同期であるか、gzip圧縮やバッチ転送などの他のパフォーマンス最適化を利用できるため、Webサーバーはフィードの読み取りをより速く切り替えてクライアントを切り替えることができ、最大接続数（Apacheを使用）接続の最大数を500に設定すると、1秒あたり数千の読み取り要求を処理することができます）。 一方、レコードは、ダウンロード時間中は開いた接続を維持する傾向があります。 そのため、ほとんどのホームネットワークでは、1 MBのファイルをサーバーに転送するのに1秒以上かかる可能性があります。その結果、Webサーバーは500件のこのような同時レコードしか処理できません。

図1.2：読み取りと書き込みの分離

このような潜在的な問題を予測することは、 図1.2に示すように、画像の読み取りと書き込みを独立したサービスに分離する必要があることを示しています 。 これにより、各レコードを個別にスケーリングできるだけでなく（常にレコードよりも多くの読み取りを行う可能性が高いため）、各サービスで何が起こっているかを認識できるようになります。 最後に、これにより、将来発生する可能性のある問題が区別され、読み取りアクセスが遅い問題の診断と評価が簡素化されます。

このアプローチの利点は、互いに独立して問題を解決できることです。この場合、1つのコンテキストで新しい画像を記録および受信する必要について考える必要はありません。 これらのサービスはどちらも引き続きグローバルイメージコーパスを使用しますが、特定のサービスに適したメソッドを使用する場合、独自のパフォーマンスを最適化できます（たとえば、リクエストをキューに入れたり、人気のあるイメージをキャッシュしたりすることで-詳細は後述） サービスとコストの両方の観点から、必要に応じて各サービスを個別にスケーリングできます。 上記のシナリオのように、これらの組み合わせと混合がパフォーマンスに不注意に影響を与える可能性があるため、これはプラスの要因です。

もちろん、2つの異なるエンドポイントがある場合、上記のモデルの作業は最適です（実際、これはクラウドストレージプロバイダーとコンテンツ配信ネットワークのいくつかの実装に非常に似ています）。 このような問題を解決するには多くの方法があり、それぞれのケースで妥協点を見つけることができます。

たとえば、Flickrは異なるモジュール間でユーザーを分散することでこの読み取り/書き込みの問題を解決します。これにより、各モジュールは限られた数の特定のユーザーのみにサービスを提供でき、ユーザー数が増加すると、より多くのモジュールがクラスターに追加されます

http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html ）。 最初の例では、実際の負荷（システム全体の読み取りと書き込みの数）に基づいてハードウェアをスケーリングするのが簡単ですが、Flickrのスケーリングはユーザーベースに基づいています（ただし、ここでは異なるユーザー間で均一に使用するという仮定が使用されるため、容量を計画する必要があります在庫）。 過去には、アクセス不能またはサービスの1つに問題があるとシステム全体の機能が無効になり（たとえば、誰もファイルを書き込めない）、Flickrモジュールの1つにアクセスできないと、それに関連するユーザーのみが影響を受けます。 最初の例では、Flickrアーキテクチャでは各モジュールを更新または検索する必要があります（または、検索サービスを更新する必要がありますが、新しいメタデータを含めるように記録サービスを更新する、画像のすべてのメタデータを検索するなど、データセット全体に対して操作を実行する方が簡単です実際にこれを目的とするメタデータをソートするために作成されます）。

これらのシステムに関しては、万能薬はありませんが、この章の冒頭で説明した原則から常に進める必要があります：システムのニーズを決定します（「読み取り」または「書き込み」のロード操作またはすべてを一度に、並列処理のレベル、データセットのクエリ、範囲、ソートなど）、さまざまな選択肢の比較ベンチマークテストを実施し、潜在的なシステム障害の状態を理解し、障害が発生した場合の包括的な計画を作成します。

冗長性

障害にエレガントに対処するには、Webアーキテクチャのサービスとデータに冗長性が必要です。 たとえば、単一のサーバーにファイルのコピーが1つしか保存されていない場合、このサーバーの損失はファイルの損失を意味します。 この状況が明確に特徴づけられる可能性は低く、通常、複数のコピーまたはバックアップコピーを作成することで回避できます。

これと同じ原則がサービスにも当てはまります。 複数のコピーまたはバージョンの同時操作を保証するアプリケーションの機能の不可欠な部分を提供する場合、単一ノードの障害から身を守ることができます。

システムに冗長性を作成すると、脆弱性を取り除き、緊急時にバックアップまたは冗長機能を提供できます。 たとえば、本番環境で同じサービスのコピーが2つあり、そのうちの1つが完全にまたは部分的に失敗した場合、システムは作業コピーに切り替えることで失敗を克服できます 。

切り替えは自動的に行われるか、手動の介入が必要になる場合があります。

。

サービスの冗長性のもう1つの重要な役割は、リソース共有を伴わないアーキテクチャの作成です。 このアーキテクチャにより、各ノードは独立して動作することができ、さらに、他のノードの状態または調整アクションを制御する中央の「頭脳」がなくても動作できます。 新しいノードの追加は特別な条件や知識を必要としないため、スケーラビリティに貢献します。 そして、最も重要なことは、これらのシステムには致命的な脆弱点がなく、障害に対する回復力がはるかに高いことです。

。

たとえば、画像サーバーアプリケーションでは、すべての画像に別のハードウェアのどこかに冗長コピーがあり（理想的には、データセンターでの地震や火災などの災害時に地理的に異なる場所にあります）、画像アクセスサービスそれらはすべて潜在的にリクエストを処理しますが、冗長になります。 （ 図1.3を参照してください。）

将来的には、ロードバランサーはこれを可能にする優れた方法ですが、以下でさらに詳しく説明します。

図1.3：冗長イメージホスティングアプリケーション

セグメンテーション

データセットは非常に大きいため、単一のサーバーでホストすることはできません。 また、コンピューティング操作に必要なコンピューターリソースが多すぎて、パフォーマンスが低下し、電力の増加が必要になる場合もあります。 いずれの場合でも、2つのオプションがあります：垂直または水平スケーリング。

スケールアップには、単一のサーバーにリソースを追加することが含まれます。 したがって、非常に大きなデータセットの場合、これはより多くの（またはより多くの）ハードディスクを追加することを意味するため、データセット全体を単一のサーバーでホストできます。 計算操作の場合、これは、より高速なCPUまたはより多くのメモリを備えたより大きなサーバーに計算を移動することを意味します。 いずれにしても、追加のデータ処理が可能なコンピューティングシステムの個別のリソースを作成するために、垂直スケーリングが実行されます。

一方、水平スケーリングには、ノードの追加が含まれます。 大規模なデータセットの場合、これは合計データ量の一部を格納するために2番目のサーバーを追加することを意味し、コンピューティングリソースの場合、これはいくつかの追加ノードを通じて作業または負荷を共有することを意味します。 水平スケーリングの可能性を最大限に活用するには、システムアーキテクチャ開発の内部原則として実装する必要があります。 そうでない場合、水平スケーリングに必要なコンテキストの変更と強調表示に問題が生じる可能性があります。

水平スケーリングの最も一般的な方法は、サービスをセグメントまたはモジュールに分離することです。 機能の各論理セットが個別に機能するような方法で配布できます。 これは、地理的な境界、または有料ユーザーと無料ユーザーなどの他の基準に従って行うことができます。 これらのスキームの利点は、機能が強化されたサービスまたはデータウェアハウスを提供することです。

この例のイメージサーバーでは、イメージの保存に使用される唯一のファイルサーバーを多くのファイルサーバーに置き換えることができ、各ファイルサーバーには独自のイメージセットが含まれます。 （ 図1.4を参照してください。）このアーキテクチャにより、システムは各ファイルサーバーをイメージで満たし、ディスクスペースがいっぱいになるとサーバーを追加できます。 デザインには、イメージファイル名とそれを含むサーバーを関連付ける命名スキームが必要です。 イメージ名は、サーバーに関連付けられた一貫したハッシュスキームから作成できます。 または、各画像に増分識別子を付けることもできます。これにより、配信サービスは、画像を要求するときに各サーバーに関連付けられた識別子の範囲のみを（インデックスとして）処理できます。

図1.4：冗長性とセグメンテーションを備えたイメージホスティングアプリケーション

もちろん、データや機能を複数のサーバーに配布するのは困難です。 重要な問題の1つはデータの場所です。 分散システムでは、データが操作の場所または計算のポイントに近いほど、システムのパフォーマンスが向上します。 したがって、データを複数のサーバーに配布することには問題が発生する可能性があります。このデータが必要になる場合はいつでも、データが需要の場所にない可能性があるため、サーバーはネットワーク上で必要な情報の高価なサンプリングを実行する必要があるためです。

別の潜在的な問題がフォームで発生します

不整合（不整合）さまざまなサービスが共有リソース、潜在的に別のサービスまたはデータストアに対して読み取りおよび書き込みを行うと、「競合」状態の可能性があります。 -この場合、データには一貫性がありません。 たとえば、画像ホスティングスクリプトでは、一方のクライアントが犬の画像を更新する要求を送信し、「犬」の見出しを「ギズモ」に変更して、他のクライアントが画像を読んでいる場合に競合状態が発生する可能性があります。 このような状況では、「Dog」と「Gizmo」のどちらの見出しが2番目のクライアントによって受信されるかは明確ではありません。

。

もちろん、データのセグメンテーションに関連するいくつかの障害がありますが、セグメンテーションを使用すると、データ、ロード、使用パターンなどに応じて、各問題を他の問題と区別できます。 マネージドブロックに。 スケーラビリティと管理性の向上に役立ちますが、リスクはまだ残っています。 リスクを軽減し、障害を処理するには多くの方法があります。 ただし、簡潔にするため、この章では説明しません。このトピックに関する詳細情報が必要な場合は、フォールトトレランスと監視に関するブログ投稿をご覧ください。

1.3。 高速でスケーラブルなデータアクセスの構造コンポーネント

分散システムの開発におけるいくつかの基本原則を検討したので、今度はより困難なポイントであるデータアクセスのスケーリングに移りましょう。

LAMPスタックアプリケーションなどの最も単純なWebアプリケーションは、図1.5の画像に似ています。

図1.5：単純なWebアプリケーション

: . - , . . ; .

.

図1.6：簡略化されたWebアプリケーション

ほとんどのシステムは、内の回路に簡略化することができ、図1.6、

レビューのための良い出発点です。大量のデータがある場合は、テーブルの上部の引き出しにあるキャンディー付きのボックスと同じくらい簡単にアクセスできるようにすることができます。この比較は非常に単純化されていますが、データウェアハウスのスケーラビリティとデータへの迅速なアクセスという2つの複雑な問題を指摘しています。

このセクションを確認するために、多くのテラバイト（TB）のデータがあり、ユーザーがこのデータの小さな部分にランダムな順序でアクセスできるようにすると仮定します。（図1.7を参照。）

同様のタスクは、画像ホスティングアプリケーションの例で、ファイルサーバー上のどこかに画像ファイルを配置することです。

図1.7：特定のデータへのアクセス

, -. — , , , . ; 6 , , 100,000 — (. « », http://queue.acm.org/detail.cfm?id=1563874). ） , , , .

, , — , , . , , .

: . : , , -, - . : , , , , . , , , .

サンプルAPIの一部として、キャッシュを使用してデータへのアクセスを高速化するにはどうすればよいですか？この場合、キャッシュをホストするのに適した場所がいくつかあります。可能な配置オプションの1つとして、

図1.8に示すように、リクエストレベルでノードを選択できます。

図1.8：要求レベルのホストでキャッシュをホストする

要求レベルのノードにキャッシュを直接配置すると、応答データのローカルストレージが可能になります。サービスリクエストが実行されるたびに、ノードはローカルのキャッシュされたデータがあればすぐに返します。キャッシュにない場合、要求ノードはディスクからデータを要求します。要求レベルの1つのノードのキャッシュは、メモリ（非常に高速）とノードのローカルディスク（ネットワークストレージへのアクセスよりも高速）の両方に配置することもできます。

図1.9：キャッシュシステム

キャッシュを複数のノードに分散するとどうなりますか？図1.9でわかるように、要求レベルに多くのノードが含まれる場合、各ノードに独自のキャッシュがある可能性があります。ただし、ロードバランサーがノード間でリクエストをランダムに分散すると、同じリクエストが異なるノードに送信されるため、キャッシュエラーが増加します。このハードルを克服する2つの方法は、グローバルキャッシュと分散キャッシュです。

グローバルキャッシュ

: . , , , . , . , , . ( , , , ).

図に描かれているグローバルキャッシュには2つの標準形式があります。上の図1.10は、キャッシュされた応答がキャッシュ内で見つからなかった場合の状況を示し、キャッシュ自体はデータ・ベース・ストレージの不足している部分を取得する責任となります。上の図1.11キャッシュで発見されていない任意のデータを受信するノードを要求する義務を示します。

図1.10：キャッシュが取得を担当する







グローバルキャッシュ図1.11：要求ノードが取得を担当するグローバルキャッシュ

, , , , . , , . , , ; ( ) . — , , , . ( - — , — , .)

( 1.12 ), , , — , , . -. , , , , . , . , — , .

分散キャッシングの欠点は、ノードが欠落している状況で機能することです。一部の分散キャッシュは、データの冗長コピーを複数のノードに保存することにより、この問題を回避します。ただし、特にクエリレベルでノードを追加または削除する条件では、そのようなキャッシュの論理構造がどれほど迅速に複雑になるか想像できます。ノードが消えてキャッシュの一部が失われたとしても、結果は必ずしも壊滅的ではありません-要求はソースから直接データを受信するだけです！

図1.12：分散キャッシュ。

(, !) . , . , , .

Memcached (), , ); , ( ).

Memcached -, , , - , (O(1)) .

Facebookは、さまざまな種類のキャッシュを使用して、サイトで高いパフォーマンスを実現しています（ 「Facebook：キャッシュとパフォーマンス」を参照）。 これらは、 $GLOBALS



およびAPC、言語レベルのキャッシング（関数を呼び出すことでPHPで表される）を使用します。これは、中間関数呼び出しを高速化し、結果を取得するのに役立ちます。 （ほとんどの言語には、Webページのパフォーマンスを向上させるためにこれらのタイプのライブラリが装備されており、ほぼ常に使用する必要があります。）さらに、Facebookは複数のサーバーに分散するグローバルキャッシュを使用します（「 Facebookでのmemcachedのスケーリング 」を参照）キャッシュにアクセスする関数呼び出しは、異なるMemcachedサーバーに保存されたデータに対する多くのリクエストを同時に実行できます。 このアプローチにより、ユーザープロファイルデータのパフォーマンスとスループットを大幅に向上させ、データを更新するための集中型アーキテクチャを作成できます。 これは重要です。何千ものサーバーでは、キャッシュの一貫性を無効にして維持することが困難な場合があるためです。

さらに、キャッシュにデータがない場合のアクションのアルゴリズムについて説明します。

プロキシ

基本レベルでは、プロキシサーバーはクライアントからのリクエストを受信し、それらをバックエンドソースサーバーに送信するハードウェア/ソフトウェアの中間部分です。 通常、プロキシは、リクエストのフィルタリング、リクエストのログ記録、またはリクエストの変換（ヘッダーの追加/削除、暗号化/復号化または圧縮）に使用されます。

図1.13プロキシサーバー

プロキシは、多数のサーバーからの要求を調整する際にも非常に役立ちます。これにより、システム全体の要求トラフィックを最適化できます。 プロキシを使用してデータへのアクセスを高速化する方法の1つは、同じまたは同様の要求を結合し、単一の応答を要求クライアントに送信することです。 この用語は、折りたたみ転送と呼ばれます。

いくつかのノードが同じデータに対するリクエストを受信するとします（littleBと呼びましょう）が、このデータの一部はキャッシュにありません。 この要求がプロキシを介して送信される場合、すべての要求を1つにまとめることができ、この最適化の結果、littleBはディスクから1回だけ読み取られます。 （ 図1.14を参照）この場合、要求を処理してそれらを結合するプロセスはわずかに長い遅延につながるため、少し速度を犠牲にする必要があります。 ただし、逆に負荷が高いと、特に同じデータに対する要求が繰り返される場合に、パフォーマンスが向上します。 プロキシの機能戦略はキャッシュに似ていますが、データを保存する代わりに、ドキュメントへのリクエストまたは呼び出しを最適化します。

たとえば、LANプロキシでは、クライアントはインターネットに接続するために独自のIPアドレスを必要としません。 プロキシは、同じコンテンツに対するクライアントからの要求を結合します。 ただし、多くのプロキシもキャッシュであるため（キャッシュを配置する論理的な場所であるため）、これによりあいまいさが生じますが、すべてのキャッシュがプロキシとして機能するわけではありません。

図1.14：プロキシサーバーを使用して要求を結合する

プロキシを使用するもう1つの優れた方法は、同じデータに対する要求を結合するだけでなく、ソースリポジトリ（ディスク上）で互いに空間的に近いデータの部分も結合することです。 この戦略を使用すると、クエリのデータの局所性が最大化され、クエリの待機時間が短縮されます。 たとえば、ノードのセットがパートBをリクエストする場合：パートB1、パートB2など、個々のリクエストの空間位置を認識するようにプロキシを構成し、それらを単一のリクエストに結合してbigBのみを返し、読み取りを大幅に最小化できますデータソースから。 （ 図1.15を参照）任意の順序でテラバイトのデータ全体にアクセスする場合、クエリの実装時間は非常に異なる可能性があります。 プロキシは基本的に複数の要求を1つにグループ化できるため、負荷が高い状況やキャッシング機能が制限されている状況で特に役立ちます。

図1.15：プロキシを使用して、空間的に近いデータの要求を結合する

プロキシとキャッシュを一緒に使用できることは注目に値しますが、多くの参加者とのマラソンでより速いランナーがスタートできるようにする方がよいのと同じ理由で、通常はプロキシの前にキャッシュを置く方が良いです。 これは、キャッシュがメモリからのデータを使用するためです。これは非常に高速であり、同じ結果に対する複数の要求と矛盾しません。 ただし、キャッシュがプロキシサーバーの反対側にある場合、キャッシュの前に各リクエストに追加の遅延が発生し、パフォーマンスが低下する可能性があります。

プロキシをシステムに追加することを検討している場合は、多くの選択肢があります。

イカと

ワニスは時の試練に耐え 、多くの生産的なウェブサイトで広く使用されています。 これらのプロキシソリューションは、クライアントとサーバー間の通信を最大限に活用するための多くの最適化オプションを提供します。 それらの1つをWebサーバーレベルでリバースプロキシモード（負荷分散のセクションで後述）に設定すると、Webサーバーのパフォーマンスが大幅に向上し、着信クライアント要求を処理するための作業量が削減されます。

指数

インデックスを使用してデータにすばやくアクセスすることは、データへのアクセスを効果的に最適化するためのよく知られた戦略です。 インデックスは、データベースで最も広く使用されています。 インデックスは相互に譲歩し、データストレージボリュームのオーバーヘッドを使用し、「書き込み」操作の速度を低下させます（データの書き込みとインデックスの更新を同時に行う必要があるため）。より高速な「読み取り」操作の形で勝つことができます。

リレーショナルデータセットのように、この概念をより大きなデータストアに適用することもできます。 インデックスのコツは、ユーザーがデータにアクセスする方法を明確に理解することです。 データセットのボリュームがテラバイト単位で測定され、有用な情報がほとんどない場合（たとえば1 KB）、データへのアクセスを最適化するためにインデックスを使用する必要があります。 このような大規模なデータセットで小さな有用な情報を見つけることは、妥当な時間内にこのような大量のデータを順番に並べ替えることができないため、実際の問題になる可能性があります。 さらに、このような大きなデータセットが複数の（または多数の）物理デバイスに分散している可能性が非常に高いため、必要なデータの正しい物理的な場所を何らかの方法で見つける必要があります。 これを行うには、インデックスが最適な方法です。

図1.16：インデックス

インデックスは、データの場所を示す目次として使用できます。 たとえば、セクション「B」のパート2のデータを探しているとしましょう。どこでそれを見つけることができますか。 データタイプ別にソートされたインデックスがある場合-データを「A」、「B」、「C」と呼びましょう-ソース内のデータ「B」の場所を示します。 次に、この場所を見つけて、必要な部分「B」を数えるだけです。 （ 図1.16を参照）

これらのインデックスは、多くの場合、メモリに格納されるか、着信クライアント要求に対して非常にローカルな場所に格納されます。 Berkeley DB（BDB）およびツリー状のデータ構造は、順序付きリストにデータを格納するために一般的に使用され、インデックスアクセスに最適です。

多くの場合、必要なデータの一部を取得するまで、マップとして機能する多くのレベルのインデックスがあり、ある場所から別の場所に移動します。 （ 図1.17を参照）

図1.17：マルチレベルインデックス

インデックスを使用して、同じデータの他のいくつかの表現を作成することもできます。 大規模なデータセットの場合、これは、データの多くの追加コピーを作成することなく、さまざまなフィルターとビューを定義する優れた方法です。

たとえば、上記の画像ホスティングシステムが実際に本のページに画像を配置し、サービスがこれらの画像でクライアント側のテキストクエリを有効にし、検索エンジンがHTMLで検索できるように、特定のトピックのすべてのテキストコンテンツを検索するとしますコンテンツ。 この場合、これらのすべての本の画像は多くのサーバーを使用してファイルを保存するため、ユーザーに表示する1つのページを見つけるのは非常に困難です。 最初は、任意の単語や単語セットを照会するための逆インデックスに簡単にアクセスできる必要があります。 次に、正確なページに移動してこの本に配置し、検索結果の正しい画像を抽出するタスクがあります。 したがって、この場合、転置されたインデックスは場所（ブックBなど）に表示され、Bにはすべての単語、場所、各部分の出現回数を含むインデックスを含めることができます。

上記の図でIndex1が表示できる逆索引は次のようになります。各単語または単語のセットは、それらを含む本の索引として機能します。

単語（s）	本（s）
素晴らしい	ブックB、ブックC、ブックD
いつも	Book C、Book F
信じる	ブックB

中間インデックスも同様に見えますが、ブックBの単語、場所、情報のみが含まれます。複数のレベルを含むこのようなアーキテクチャでは、すべての情報が1つの大きな逆インデックスに格納される場合よりも各インデックスのスペースを節約できます。

そして、これは大規模システムの重要なポイントです。なぜなら、これらのインデックスは圧縮されていても、非常に大きく、保存するのに費用がかかる可能性があるからです。 このシステムには世界中からたくさんの本があります-100,000,000（ブログエントリ「Inside Google Books」を参照）-各本は1ページあたり250ワードで10ページ（計算を簡単にするため）で構成されていると仮定します：これにより、合計2500億語になります。 単語の平均文字数を5とし、各文字が8ビット（または実際には2バイトを占有している場合でも1バイト）でエンコードされているため、単語ごとに5バイトを費やしている場合、インデックス各単語を1回だけ含めるには、1テラバイト以上の容量のストレージが必要です。 このように、単語セット、データの場所、使用回数などの他の情報も含むインデックスは、非常に急速に増加する可能性があることがわかります。

このような中間インデックスを作成し、データをより小さな部分で提示すると、「ビッグデータ」の問題を解決しやすくなります。 データは複数のサーバーに分散でき、同時に迅速にアクセスできます。 インデックスは、情報検索の基礎であり、今日の最新の検索エンジンの基盤です。 もちろん、このセクションでは一般にインデックス付けのトピックのみを扱い、インデックスを小さく、高速に、より多くの情報（関連性など）を使用して自由に更新する方法について多くの研究が行われています。 （特に関連性や評価が関係する場合、競合する条件の制御性、および新しいデータの追加や既存のデータの変更に必要な更新の数にいくつかの問題があります）。

データをすばやく簡単に見つける機能は非常に重要であり、これを実現するための最も簡単で効果的なツールはインデックスです。

ロードバランサー

最後に、分散システムのもう1つの重要な部分はロードバランサーです。 ロードバランサーの役割は、要求の処理を担当するノード間で負荷を分散させることであるため、ロードバランサーはアーキテクチャの重要な部分です。 これにより、複数のノードがシステム内の同じ機能を透過的に提供できます。 （ 図1.18を参照。）主な目標は、多くの同時接続を処理し、これらの接続を要求されたノードの1つにルーティングし、ノードを追加してより多くの要求に対応できるようにすることです。

図1.18：ロードバランサー

クエリを処理するためのさまざまなアルゴリズムがあります。ランダムノードの選択、循環アルゴリズムの選択、中央プロセッサやRAMの使用などの特定の基準に基づいたノードの選択も含まれます。 ロードバランサーは、ハードウェアデバイスまたはソフトウェアとして実装できます。 オープンソースソフトウェア上のロードバランサーの中で、 HAProxyは最も広く使用されています。

分散システムでは、ロードバランサーは多くの場合システムの「フロントエンド」にあるため、すべての着信要求はそれらを直接通過します。 以下に示すように、複雑な分散システムでは、リクエストが複数のバランサーを通過する必要がある可能性が非常に高くなります。

図1.19

図1.19：複数のロードバランサー

プロキシと同様に、一部のロードバランサーは、リクエストのタイプに応じて異なる方法でリクエストを送信することもできます。 それらは逆プロキシとしても知られています。

特定のユーザーセッションに固有のデータの管理は、ロードバランサーを使用する際の問題の1つです。 eコマースサイトでは、顧客が1人だけの場合、ユーザーが買い物かごに物を入れたり、訪問の間にその内容を保存したりすることは非常に簡単です（製品がまだサイトに返されると、製品を販売する確率が大幅に増加するため、これは重要です）彼のバスケットにあります）。 ただし、ユーザーが最初のセッションで1つのノードに誘導され、次の訪問中に別のノードに誘導された場合、新しいノードにはそのユーザーのバスケットの内容に関するデータがないため、矛盾が発生する可能性があります。 （Mountain Dewのパッケージをバスケットに入れた場合、動揺しませんか。返品してもセッションはありません。）1つの解決策は、セッションが「スティッキー」になり、ユーザーが常に同じノード。 ただし、自動フォールトトレランスなどの特定の信頼性機能を利用することは非常に困難です。 この場合、ユーザーのバスケットには常にコンテンツがありますが、スティッキーノードにアクセスできなくなった場合、特別なアプローチが必要になり、バスケットのコンテンツに関する仮定はもはや成り立たなくなります（ただし、この仮定はアプリケーションに組み込まれないことが望まれます）。 もちろん、この問題は、この章で説明するサービスやその他の多く（ブラウザキャッシュ、Cookie、URL書き換えなど）など、他の戦略やツールを使用して解決できます。

システムに少数のノードしかない場合、DNSカルーセルなどの手法はロードバランサーよりも実用的である可能性が高く、コストがかかり、不要なレベルを追加することでシステムの複雑さを増す可能性があります。 もちろん、大規模なシステムには、ランダム選択やカルーセルアルゴリズムなどの単純なアルゴリズムと、システム使用モデルのパフォーマンス機能を考慮したより複雑なメカニズムの両方を含む、あらゆる種類の異なる計画および負荷分散アルゴリズムがあります。 これらのすべてのアルゴリズムを使用すると、トラフィックと要求を分散でき、自動フォールトトレランスや破損したノードの自動削除（たとえば、応答停止時）などの便利な信頼性ツールを提供できます。 ただし、これらの高度な機能を使用すると、問題の診断が面倒になります。 たとえば、高負荷の状況では、ロードバランサーは、実行が遅くなったり、待機時間が長くなる（リクエストの急増により）ノードを削除します。これにより、他のノードの状況が悪化するだけです。 これらの場合、システム全体のトラフィックと負荷が減少したように見える場合でも（ノードの要求が少ないため）、個々のノードが過負荷になる可能性があるため、広範な制御が重要です。

ロードバランサーは、システムの電源を構築する簡単な方法です。 この記事で説明した他の方法と同様に、分散システムのアーキテクチャで重要な役割を果たします。 ロードバランサーは、ノードの状態を検証するための重要な機能も提供します。 そのようなチェックの結果に基づいて、ノードが応答しないか、過負荷になっている場合、要求処理プールから削除できます。システムの冗長性により、残りの作業ノード間で負荷が再分配されます。

キュー

これまで、データをすばやく読み取るための多くの方法を検討してきました。 同時に、データレイヤーのスケーリングのもう1つの重要な部分は、レコードの効率的な管理です。システムがシンプルで、最小限の処理負荷と小さなデータベースを備えている場合、記録は予想以上に高速になります。ただし、より複雑なシステムでは、このプロセスに無期限に長い時間がかかる場合があります。たとえば、異なるサーバーまたはインデックスの複数の場所にデータを記録する必要がある場合や、システムの負荷が高い場合があります。記録やタスクだけでも時間がかかる場合、パフォーマンスと可用性を実現するには、システムに非同期性を組み込む必要があります。これを行う一般的な方法は、リクエストをキューに入れることです。

図1.20：同期リクエスト

, . , . , ( ) , , . , , , , . — , 1.20 .

このタイプの同期動作は、クライアントのパフォーマンスを大幅に低下させる可能性があります。実際にアイドル状態の場合、クライアントは要求に対する応答を受信するまで待機する必要があります。システムの負荷に対処するためにサーバーを追加しても、実際には問題は解決しません。効率的な負荷分散が行われている場合でも、顧客の生産性を最大化するために必要な均等かつ公平な負荷分散を確保することは非常に困難です。さらに、この要求を処理するサーバーが利用できない（または失敗した）場合、それに接続されているクライアントも動作を停止します。この問題を効果的に解決するには、クライアントのリクエストと、サービスを提供するために行われた実際の作業を抽象化する必要があります。

図1.21：キューを使用してリクエストを管理する

. : , , «» , . (. 1.21 .) - . , ; . , .

, . , , , . , , , , , , . , , , . — , .

. , , , - . , , , .

— , . RabbitMQ ,

ActiveMQ ,

BeanstalkD ,

Zookeeper , Redis .

1.4。 おわりに

, , . , — .

---

Creative Commons Attribution 3.0 . . .

The Architecture of Open Source Applications .