大規模分散サーバーアーキテクチャの原理の分析

技術者として、私たちはほぼすべてのプロジェクトが、単一のサーバーからクラスター サーバーまで、単純なものから複雑なものへと開発されていることを知っています。しかし、この背後にある技術的な原理を知っている人はどれくらいいるでしょうか?実際のところ、これはそれほど深い意味はありません。それでは、馬さんが一つずつ説明しましょう〜

***段階: ウェブサイトアーキテクチャの初期段階

一般的に、大規模な Web サイトは小規模な Web サイトから開発されます。初期のアーキテクチャは比較的シンプルです。ビジネスが複雑になり、ユーザー数が急増するにつれて、多くのアーキテクチャの改善が行われます。まだ小さなウェブサイトなので、訪問者は多くありません。一般的に言えば、サーバーは 1 台だけで十分です。この時点で、アプリケーション、データベース、ファイルなどのすべてのリソースが 1 つのサーバー上に存在します。ウェブサイトのアーキテクチャを下図に示します。

[[231114]]

フェーズ2: アプリケーションサービスとデータサービスの分離

ウェブサイトビジネスが発展し、ユーザー数が増えると、1つのサーバーでは需要を満たせなくなります。多数のユーザーがデータにアクセスすると、アクセス速度がどんどん遅くなり、データが徐々に増加するとストレージ容量が不足することになります。このとき、アプリケーションとデータを分離する必要があります。アプリケーションとデータが分離されると、Web サイト全体でアプリケーション サーバー、ファイル サーバー、データベース サーバーの 3 つのサーバーが使用されます。 3 つのサーバーにはそれぞれ異なるハードウェア リソース要件があります。

1. アプリケーションサーバーのビジネスロジックには強力なCPUが必要

2. データベース サーバーではディスクの読み取りおよび書き込み操作が多数行われるため、より高速なディスクとより多くのメモリが必要になります。

3. ファイルサーバーはユーザーがアップロードしたファイルを保存するため、より多くのディスク容量を必要とします。

この時点で、Web サイト システムのアーキテクチャは次のようになります。

フェーズ3: キャッシュを使用してウェブサイトのパフォーマンスを向上させる

ユーザー数が増加すると、Web サイトは再び課題に直面することになります。データベースへの過度の負荷により、サイト全体のアクセス効率が再び低下し、ユーザー エクスペリエンスに影響が及ぶことになります。ウェブサイトの場合、ビジネス訪問の 80% が 20% のデータに集中していることがよくあります。たとえば、Weibo で最もリクエストが多い投稿は、間違いなく最も多くのファンを持つ大手 V の投稿ですが、ほとんど誰も注目しないホームページは、あなたが忘れない限り開かれることはありません。ほとんどのビジネス アクセスは少量のデータに集中するため、この少量のデータは、毎回データベースから読み取るのではなく、事前にメモリにキャッシュする必要があります。これにより、データベースへのアクセス負荷が軽減され、Web サイト全体のアクセス速度が向上します。

ウェブサイトが使用するキャッシュは、一般的に、アプリケーション サーバーへのキャッシュと専用の分散キャッシュ サーバーへのキャッシュに分けられます。アプリケーション サーバー自体へのキャッシュははるかに高速ですが、独自のメモリ制限のために適用できないことがよくあります。リモート分散キャッシュは、キャッシュ サービス専用のクラスターを使用し、メモリが不足した場合に簡単に動的に拡張できます。

フェーズ4: アプリケーションサーバークラスターを使用してWebサイトの同時処理能力を向上させる

キャッシュを使用すると、データ アクセスの負荷は軽減されますが、単一のアプリケーション サーバーでは限られた数の要求接続しか処理できません。ウェブサイトへのアクセスがピークとなる時間帯には、アプリケーション サーバーがウェブサイト全体の効率のボトルネックになります。分散クラスターの使用は、Web サイトが高同時実行性と大量データの問題を解決するための一般的な方法です。サーバーの処理能力とストレージ容量が不十分な場合は、より強力なサーバーに交換しないでください。大規模な Web サイトの場合、サーバーがいかに強力であっても、Web サイトの継続的に拡大するビジネス ニーズを満たすことはできません。この場合、より適切なアプローチは、元のサーバーのアクセスとストレージの負荷を共有するサーバーを追加することです。ウェブサイトのアーキテクチャでは、サーバーを追加することで負荷圧力を改善できるのであれば、同様にサーバーを継続的に追加することでシステムパフォーマンスを向上させることができ、システムのスケーラビリティを実現できます。アプリケーション サーバー クラスターは、次の図に示すように、Web サイトのスケーラブルなアーキテクチャにおける比較的シンプルで成熟した設計です。

負荷分散スケジューリング サーバーを介して、ユーザーのブラウザーからのアクセス要求をアプリケーション サーバー クラスター内の任意のサーバーに分散できます。ユーザー数が増えると、クラスターにアプリケーション サーバーを追加できるため、アプリケーション サーバーへの負荷が Web サイト全体のボトルネックになることがなくなります。

フェーズ5: データベースの読み取りと書き込みの分離

ウェブサイトがキャッシュを使用すると、ほとんどのデータ読み取り操作はデータベースを経由せずに完了できます。ただし、まだいくつかの読み取り操作 (キャッシュ アクセスが完了していない、キャッシュの有効期限が切れている) と、データベースにアクセスする必要があるすべての書き込み操作が残っています。ウェブサイトのユーザーが一定規模に達すると、過度の負荷圧力によりデータベースがウェブサイトのボトルネックになります。現在、主流のデータベースのほとんどは、マスタースレーブホットスタンバイ機能を提供しています。 2 つのデータベース間にマスター/スレーブ関係を構成することで、1 つのデータベース サーバーのデータ更新を別のサーバーに同期できます。ウェブサイトはデータベースのこの機能を使用してデータベースの読み取りと書き込みを分離し、データベースの負荷圧力を改善します。次の図に示すように:

アプリケーション サーバーがデータを書き込むときは、マスター データベースにアクセスします。マスター データベースは、マスター スレーブ レプリケーション メカニズムを通じて、データ更新をスレーブ データベースに同期します。このようにして、アプリケーション サーバーがデータを読み取るときに、スレーブ データベースからデータを取得できます。読み取り/書き込み分離後にアプリケーションがデータベースにアクセスしやすくするために、通常、アプリケーション サーバー側で特別なデータ アクセス モジュールを使用して、データベースの読み取り/書き込み分離をアプリケーションに対して透過的にします。

ステージ6: リバースプロキシとCDNを使用してウェブサイトの応答を高速化する

ウェブサイトビジネスが発展し続けるにつれ、ユーザー規模もますます大きくなってきています。中国の複雑なネットワーク環境により、地域によってユーザーによるウェブサイトへのアクセス速度は大きく異なります。調査によると、Web サイトへのアクセス遅延はユーザー離脱率と正の相関関係にあることがわかっています。ウェブサイトへのアクセスが遅いほど、ユーザーが我慢できなくなり離脱する可能性が高くなります。より良いユーザーエクスペリエンスを提供し、ユーザーを維持するために、Web サイトは Web サイトへのアクセスを高速化する必要があります。主な手段は、CDN とリバース プロキシを使用することです。次の図に示すように:

フェーズ 7: 分散ファイルシステムと分散データベースシステムの使用

大規模な Web サイトの継続的に増大するビジネス ニーズを単一の強力なサーバーで満たすことはできません。データベースは読み取りと書き込みが分離された後、1 つのサーバーから 2 つのサーバーに分割されます。しかし、ウェブサイトビジネスが発展しても、まだニーズを満たすことはできません。このとき、分散データベースが必要になります。ファイルシステムについても同様であり、分散ファイルシステムの使用が必要です。次の図に示すように:

分散データベースは、Web サイトのデータベースを分割する最適な方法であり、単一テーブルのデータ規模が非常に大きい場合にのみ使用されます。絶対に必要な場合を除き、Web サイトのデータベース分割のより一般的な方法は、ビジネス サブデータベースであり、異なるビジネスのデータを異なる物理サーバー上に展開します。

フェーズ8: NoSQLと検索エンジンの使用

ウェブサイトビジネスがますます複雑になるにつれて、データの保存と取得に対する需要もますます複雑になっています。ウェブサイトでは、NoSQL などの非リレーショナル データベース テクノロジや、検索エンジンなどの非データベース クエリ テクノロジを採用する必要があります。次の図に示すように:

NoSQL と検索エンジンはどちらもインターネットから派生した技術的な手段であり、スケーラブルな分散機能のサポートがより優れています。アプリケーション サーバーは、統合されたデータ アクセス モジュールを通じてさまざまなデータにアクセスし、複数のデータ ソースを管理するアプリケーション プログラムの手間を軽減します。

フェーズ9: 事業分割

ますます複雑化するビジネス シナリオに対処するために、大規模な Web サイトでは、分割統治法を使用して、Web サイト ビジネス全体をさまざまな製品ラインに分割します。たとえば、大規模なショッピング取引ウェブサイトでは、ホームページ、ショップ、注文、購入者、販売者などをさまざまな製品ラインに分割し、それぞれ異なるビジネス チームによって管理されます。

技術的な観点から見ると、Web サイトは製品ラインに基づいてさまざまなアプリケーションに分割され、各アプリケーションは個別に展開されます。アプリケーションは、ハイパーリンク (ホームページ上の各ナビゲーション リンクは異なるアプリケーション アドレスを指します) を通じて関係を確立したり、メッセージ キューを通じてデータを配布したりできます。もちろん、最も一般的な方法は、次の図に示すように、同じデータ ストレージ システムにアクセスして、関連付けられた完全なシステムを形成することです。

フェーズ 10: 分散サービス

ビジネスがますます小さな部分に分割され、ストレージ システムがますます大規模になるにつれて、アプリケーション システム全体の複雑さが飛躍的に増加し、導入と保守がますます困難になります。すべてのアプリケーションはすべてのデータベース システムに接続する必要があるため、数万台のサーバーを持つ Web サイトでは、これらの接続の数はサーバー サイズの 2 乗になり、データベース接続リソースが不足してサービス拒否が発生します。

各アプリケーション システムでは、ユーザー管理、製品管理など、多くの同じ業務操作を実行する必要があるため、これらの共通業務を抽出して個別に展開できます。これらの再利用可能なビジネスはデータベースに接続して共通のビジネス サービスを提供しますが、アプリケーション システムはユーザー インターフェイスを管理し、分散サービスを通じて共通のビジネス サービスを呼び出して特定のビジネス操作を完了するだけで済みます。次の図に示すように:

さて、大規模ウェブサイトのアーキテクチャ演習はここで終了しました。基本的に、ほとんどの技術的な問題は解決できます。いいねを押してください。