Webサイトアーキテクチャのスケーラビリティ設計

ウェブサイト開発の初期の頃、私たちはすべてのコードを 1 つのプロジェクトに記述することに慣れています。

フロントエンド、バックエンド、キャッシュ、データベース、静的リソースなど。

Web サイト システムの物理的な分離

システムは徐々に大きくなり、明らかに多数のユーザーによる同時アクセスに直面し、大量のデータを保存する必要があります。

多くのユーザーリクエストを 1 つのサーバーで完了することはできません。

大量のキャッシュデータとデータベースデータを 1 つのサーバーで完了することはできません。

現時点では、Web サイトのスケーラビリティ アーキテクチャが特に重要になります。

以下に示すように。

原則

当社は複数のサーバーをまとめて全体としてサービスを提供し、クラスターにサーバーを継続的に追加することで、同時ユーザーアクセスの圧力の高まりとデータストレージの需要の増大を軽減します。

アーキテクチャのスケーラビリティを測定するための主な基準:

新しいサーバーをクラスターに追加するのがどれだけ簡単か。

新しいサーバーを追加する場合、元のサーバーと同じサービスを提供できますか?

クラスターに収容できるサーバーの総数に制限はありますか?

アプリケーション サーバー クラスター

サーバーにデータが保存されていない限り、すべてのサーバーは同等であり、負荷分散デバイスを介してサーバーをクラスターに追加できます。

リレーショナル データベース クラスター (MYSQL)

リレーショナル データベースのクラスター スケーラビリティ ソリューションはデータベースの外部に実装する必要があり、複数のデータが展開されたサーバーは、ルーティング パーティショニングやその他の手段を通じてクラスターを形成できます。

例: Mysql など。

非リレーショナル データベース クラスター (NOSQL)

非リレーショナル データベースは本質的に大規模なデータベース用に準備されているため、スケーラビリティを非常によくサポートします。

例: Redis、Memcache など。

キャッシュ サーバー クラスター

新しいサーバーを追加すると、キャッシュ ルーティングが無効になり、クラスター内のキャッシュされたデータのほとんどにアクセスできなくなる可能性があります。

展開前に、キャッシュされたデータへのアクセス性を確保するために、キャッシュ ルーティング アルゴリズムを改善する必要があります。

静的リソース サーバー クラスター

CSS、JS、Img などのリソースは、トラフィックを削減し、ページのレンダリング速度を向上させるためにサーバー クラスターにデプロイされます。

Web サイトの垂直分離

ビジネス処理プロセスのさまざまな部分を分離して展開し、システムの拡張性を実現します。

以下に示すように。

Web サイトの水平分離

システムの拡張性を実現するために、さまざまなビジネス モジュールを個別に展開します。

以下に示すように。

単一の関数はクラスターのサイズに合わせてスケーリングします。

異なる機能を分離して配置すると、ある程度の拡張性を実現できますが、Web サイトのアクセス数が徐々に増加すると、最新の粒度で分離した単一サーバーを独立して配置しても、ビジネス規模の要件を満たすことができなくなります。

したがって、サーバー クラスターを使用する必要があります。つまり、同じサービスを複数のサーバーにデプロイして、外部サービス全体のクラスターを形成します。

例: 検索機能。

サーバーが 1 秒あたり 1,000 のリクエスト サービスを提供できる場合、Web サイトのピーク時に、1 秒あたりの検索訪問数は 10,000 になります。

次に、クラスターを形成するには 10 台のサーバーをデプロイする必要があります。

同様に、この状況はキャッシュサーバーでも発生します。

実際、サービスのクラスター サイズを計算するときは、可用性、パフォーマンス、および関連するサービス クラスターへの影響を考慮する必要があります。

概要

クラスターのスケーラビリティは、アプリケーション サーバー クラスターのスケーラビリティとデータ サーバー クラスターのスケーラビリティに分類できます。

データステータスの管理が異なるため、これら 2 つのクラスターの技術的な実装も大きく異なります。

皆さん、それぞれの具体的な建築設計に基づいて詳細な調査を行うことができます。

この記事は、書籍「大規模ウェブサイトのテクニカル アーキテクチャ」から借用しました。