10億規模のWebシステムの構築: スタンドアロンから分散クラスタまで

Web システムのアクセス数が 1 日あたり 10 万件から 1,000 万件、さらには 1 億件以上に徐々に増加すると、Web システムにかかる負荷はますます大きくなります。この過程で、多くの問題に遭遇するでしょう。これらのパフォーマンス圧力によって引き起こされる問題を解決するには、Web システム アーキテクチャ レベルでマルチレベル キャッシュ メカニズムを構築する必要があります。ストレスの段階が異なれば、さまざまな問題が発生しますが、さまざまなサービスとアーキテクチャを構築することで解決できます。

[[273492]]

ウェブ負荷分散

Web 負荷分散 (ロード バランシング) とは、簡単に言えば、サーバー クラスターに「作業タスク」を割り当てることであり、適切な割り当て方法を採用することが、バックエンド Web サーバーを保護するために非常に重要です。

負荷分散戦略は数多くありますが、まずは簡単なものから始めましょう。

1. HTTPリダイレクト

ユーザーがリクエストを送信すると、Web サーバーは HTTP 応答ヘッダーの Location タグを変更して新しい URL を返します。その後、ブラウザーはこの新しい URL をリクエストし続け、実際にはページがリダイレクトされます。リダイレクトを通じて、「負荷分散」の目標が達成されます。たとえば、PHP ソース コード パッケージをダウンロードする場合、ダウンロード リンクをクリックすると、国や地域によってダウンロード速度が異なる問題を解決するために、近くのダウンロード アドレスが返されます。リダイレクトの HTTP 戻りコードは、以下に示すように 302 です。

10億レベルのWebシステムの構築 - 単一マシンから分散クラスタまで - hansionxu - Technology Sky

PHP コードを使用してこの関数を実装する場合、メソッドは次のようになります。

このリダイレクトは実装が非常に簡単で、さまざまな戦略でカスタマイズできます。ただし、トラフィック量が多い場合はパフォーマンスが低下します。さらに、ユーザー エクスペリエンスは良好ではなく、実際のリクエストがリダイレクトされるため、ネットワークの遅延が増加します。

2. リバースプロキシ負荷分散

リバース プロキシ サービスの主な機能は、ブラウザーとバックエンド Web サーバー間の中継役として、HTTP 要求を転送することです。 7 層ネットワーク構造の第 7 層である HTTP 層 (アプリケーション層) で動作するため、「7 層負荷分散」とも呼ばれます。リバース プロキシとして使用できるソフトウェアは多数ありますが、最も一般的なものの 1 つが Nginx です。

Nginx は、転送戦略を自由にカスタマイズしたり、サーバー トラフィックの重みを割り当てたりできる、非常に柔軟なリバース プロキシ ソフトウェアです。リバース プロキシでよくある問題は、Web サーバーによって保存されるセッション データです。これは、一般的な負荷分散戦略では、リクエストをランダムに分散するためです。同じログインユーザーからのリクエストが同じ Web マシンに割り当てられる保証はなく、セッションが見つからないという問題が発生する可能性があります。

主な解決策は 2 つあります。

同じユーザーからのリクエストが同じマシンに届くように、リバース プロキシの転送ルールを構成します (Cookie を分析します)。転送ルールが複雑になると、CPU の消費量が増え、プロキシ サーバーの負荷が増加します。

セッション情報を保存するには、redis/memchache などの別のサービスを使用することをお勧めします。

リバース プロキシ サービスではキャッシュを有効にすることもできます。有効にするとリバースプロキシの負荷が増加するため、注意して使用する必要があります。この負荷分散戦略は実装と展開が非常に簡単で、パフォーマンスも比較的良好です。しかし、これは「単一障害点」という問題があり、障害が発生すると大きなトラブルを引き起こします。さらに、後期にWebサーバーの数が増え続けると、それ自体がシステムのボトルネックになる可能性があります。

3. IP 負荷分散

IP ロード バランシング サービスは、ネットワーク層 (IP を変更) とトランスポート層 (ポートを変更、第 4 層) で動作し、そのパフォーマンスはアプリケーション層 (第 7 層) で動作する場合よりもはるかに高くなります。原理は、負荷分散の目的を達成するために、IP 層でデータ パケットの IP アドレスとポート情報を変更することです。この方法は「4 層負荷分散」とも呼ばれます。一般的な負荷分散方法は LVS (Linux 仮想サーバー、Linux 仮想サービス) であり、これは IPVS (IP 仮想サーバー、IP 仮想サービス) を通じて実装されます。

負荷分散サーバーは、クライアントから IP パケットを受信すると、IP パケットのターゲット IP アドレスまたはポートを変更し、そのまま内部ネットワークに配信し、データ パケットは実際の Web サーバーに流れ込みます。実際のサーバーが処理を完了すると、データ パケットが負荷分散サーバーに返され、負荷分散サーバーはターゲット IP アドレスをユーザーの IP アドレスに変更して、最終的にクライアントに返します。

上記の方法は LVS-NAT と呼ばれます。さらに、LVS-RD（ダイレクトルーティング）とLVS-TUN（IPトンネル）があります。これら 3 つはすべて LVS 方式に属しますが、いくつかの違いがあります。スペースの制約上、詳細には触れません。

IP ロード バランシングのパフォーマンスは、Nginx のリバース プロキシよりもはるかに高くなります。トランスポート層までのデータ パケットのみを処理し、それ以上のパケットの組み立ては実行せず、実際のサーバーに直接転送します。ただし、その構成とセットアップは比較的複雑です。

4. DNS 負荷分散

DNS (ドメイン ネーム システム) はドメイン名の解決を担当します。ドメイン名 URL は実際にはサーバーのエイリアスであり、実際のマッピングは IP アドレスです。解決プロセスは、DNS がドメイン名と IP のマッピングを完了することです。ドメイン名は複数の IP に対応するように設定できます。したがって、DNS は負荷分散サービスとしても使用できます。

この負荷分散戦略は構成が簡単で、パフォーマンスも優れています。しかし、ルールを自由に定義することができず、マッピングしたIPを変更したり、マシンが故障したときに面倒です。 DNS の有効開始が遅れるという問題もあります。

5. DNS/GSLB 負荷分散

私たちがよく使う CDN (コンテンツ配信ネットワーク) の実装方法は、実は同じドメイン名を複数の IP にマッピングするという考え方をさらに一歩進めて、GSLB (グローバル サーバー負荷分散) を通じて指定されたルールに従ってドメイン名の IP をマッピングするというものです。一般的に、地理的な位置に基づいてユーザーに最も近い IP アドレスがユーザーに返されるため、ネットワーク伝送におけるルーティング ノード間のジャンプ消費が削減されます。

図中の「上方向の検索」の実際のプロセスは、LDNS（ローカルDNS）が最初にルートドメイン名サービス（ルートネームサーバー）から最上位のルートネームサーバー（.comなど）を取得し、次に指定されたドメイン名の認可されたDNSを取得し、最後に実際のサーバーIPを取得します。

Web システムでは、CDN は一般に、より大きな静的リソース (html/Js/Css/画像など) を読み込む問題を解決するために使用されます。これにより、ネットワーク ダウンロードに大きく依存するこれらのコンテンツをできるだけユーザーに近づけることができ、ユーザー エクスペリエンスが向上します。

たとえば、imgcache.gtimg.cn（テンセントの自社構築CDN、qq.comドメイン名を使用しないのは、httpリクエスト中に不要なCookie情報が伝送されるのを防ぐためです）上の画像にアクセスすると、取得したIPは183.60.217.90でした。

この方法は、以前の DNS 負荷分散と同様に、優れたパフォーマンスを備えているだけでなく、複数の戦略の構成もサポートしています。しかし、建設と維持のコストは非常に高くなります。一流のインターネット企業は独自の CDN サービスを構築しますが、中小企業は一般的にサードパーティが提供する CDN を使用します。

Webシステムのキャッシュ機構の構築と最適化

Webシステムの外部ネットワーク環境についての説明は以上です。ここで、Web システム自体のパフォーマンスの問題に焦点を当て始めます。当社のウェブサイトへの訪問者数が増えるにつれて、多くの課題に直面することになります。これらの問題を解決するのは、機械の容量を拡張するほど簡単ではありません。適切なキャッシュ メカニズムを確立して使用することが基本的なことです。

当初、Web システムのアーキテクチャは次のようになり、各リンクには 1 台のマシンしか存在しない可能性があります。

最も基本的なデータストレージから始めましょう。

1. MySQLデータベースの内部キャッシュの使用

MySQL キャッシュ メカニズムは MySQL 内から始まります。以下のコンテンツでは、最も一般的な InnoDB ストレージ エンジンに焦点を当てます。

1. 適切なインデックスを作成する

最も簡単な方法はインデックスを作成することです。テーブル データが大きい場合、インデックスを使用するとデータをすばやく取得できますが、コストもかかります。まず、特に結合インデックスは一定量のディスク領域を占有します。結合インデックスによって生成されるインデックスはソース データよりも大きくなる可能性があるため、注意して使用する必要があります。次に、インデックスが作成された後、元のインデックスを更新する必要があるため、データの挿入/更新/削除などの操作に時間がかかります。もちろん、実際には、私たちのシステムは一般的に選択クエリ操作に基づいているため、インデックスの使用は依然としてシステム パフォーマンスの向上に大きな効果をもたらします。

2. データベース接続スレッドプールキャッシュ

すべてのデータベース操作要求で接続の作成と破棄が必要な場合は、データベースに大きなオーバーヘッドがかかることは間違いありません。このタイプのオーバーヘッドを削減するには、MySQL で thread_cache_size を構成して、再利用のために保持するスレッドの数を指定できます。スレッドが足りない場合はスレッドを追加し、アイドル状態のスレッドが多すぎる場合はスレッドを破棄します。

実際、pconnect (データベースの長時間接続) を使用するより根本的なアプローチがあり、スレッドが作成されると、長期間維持されます。ただし、トラフィックが大きく、マシンの数が多い場合、この使用法では、確立された接続がリサイクルされず、最終的にデータベースの max_connections (最大接続数) に達するため、「データベース接続数の枯渇」につながる可能性があります。したがって、長い接続を使用する場合、通常、CGI マシンによって「盲目的に」作成される接続の数を制御するために、CGI と MySQL の間に「接続プール」サービスを実装する必要があります。

データベース接続プール サービスを確立する方法は多数あります。 PHP の場合、swoole (PHP のネットワーク通信拡張機能) を使用して実装することをお勧めします。

3. Innodb キャッシュ設定 (innodb_buffer_pool_size)

innodb_buffer_pool_size は、インデックスとデータを格納するために使用されるメモリ キャッシュ領域です。マシンが MySQL 専用マシンである場合、通常はマシンの物理メモリの 80% にすることが推奨されます。テーブルデータを取得するシナリオでは、ディスク IO を削減できます。一般的に、この値が大きいほど、キャッシュヒット率が高くなります。

4. データベース/テーブル/パーティションを分割します。

MySQL データベース テーブルは通常、数百万単位のデータを処理します。ボリュームがさらに増加すると、パフォーマンスが大幅に低下します。そのため、データ量がこのレベルを超えることが予想される場合は、データベース/テーブル/パーティションを分割するなどの操作を実行することをお勧めします。ベストプラクティスは、最初からデータベースとテーブルを別々に持つストレージモードとしてサービスを設計し、中期および後期段階でのリスクを根本的に排除することです。ただし、リストベースのクエリなどの利便性が犠牲になり、メンテナンスの複雑さも増します。しかし、データの量が数千万以上になると、それらはすべて価値があることがわかります。

2. MySQLデータベースの複数サービス構築

1 台の MySQL マシンは実際には単一の高リスク ポイントです。これは、そのマシンがダウンすると、Web サービスが利用できなくなるためです。さらに、Web システムへのトラフィックが増加し続けた結果、ある日、1 台の MySQL サーバーでは対応しきれなくなり、さらに多くの MySQL マシンを使用する必要が生じました。複数の MySQL マシンが導入されると、多くの新たな問題が発生します。

1. MySQLマスタースレーブを確立し、スレーブデータベースをバックアップとして使用する

このアプローチは、純粋に「単一点障害」の問題を解決するためのものです。メイン データベースに障害が発生した場合は、スレーブ データベースに切り替えます。ただし、スレーブ ライブラリは実際にはアイドル状態であるため、このアプローチは実際にはリソースの無駄になります。

2. MySQL の読み取りと書き込みの分離。マスター データベースが書き込み、スレーブ データベースが読み取ります。

2 つのデータベースは読み取りと書き込みに分かれており、マスター データベースは書き込み操作を担当し、スレーブ データベースは読み取り操作を担当します。さらに、マスター データベースに障害が発生した場合でも、読み取り操作には影響せず、すべての読み取りおよび書き込み操作を一時的にスレーブ データベースに切り替えることができます (トラフィックが多すぎるとスレーブ データベースがダウンする可能性があるため、トラフィックに注意してください)。

3. マスターとマスターは相互にバックアップします。

2 つの MySQL サーバーは、お互いのスレーブ データベースであると同時にマスター データベースでもあります。このソリューションは、トラフィックの負荷を軽減するだけでなく、「単一点障害」の問題も解決します。いずれか 1 つが失敗した場合でも、別のサービス セットが利用できます。

ただし、このソリューションは 2 台のマシンを使用するシナリオでのみ使用できます。ビジネスが急速に拡大し続ける場合は、ビジネスを分離し、複数のマスター マスター バックアップ システムを確立することを選択できます。

3. MySQLデータベースマシン間のデータ同期

問題を解決するたびに、古い解決策に基づいて新しい問題が生まれます。複数の MySQL サーバーがある場合、ビジネスのピーク時間帯には、2 つのデータベース間のデータが遅延する可能性が高くなります。さらに、ネットワークやマシンの負荷もデータ同期の遅延に影響します。毎日のページビューが 1 億に近づき、スレーブ データベースのデータがマスター データベースのデータに追いつくまでに何日もかかるという特殊なシナリオに遭遇しました。このシナリオでは、スレーブ ライブラリは基本的に役に立ちません。

したがって、次に重点を置く必要があるのは、同期の問題を解決することです。

1. MySQLにはマルチスレッド同期機能が搭載されている

MySQL 5.6 では、マルチスレッドを使用して、マスター データベースとスレーブ データベース間のデータ同期をサポートするようになりました。ただし、制限も非常に明白で、ライブラリ内でのみ実行できます。 MySQL データの同期は、binlog ログを通じて行われます。マスター データベースによって binlog ログに書き込まれる操作は順次実行されます。特に、SQL 操作にテーブル構造の変更などの操作が含まれている場合、後続の SQL ステートメント操作に影響を与えます。したがって、データベースからデータを同期するには、単一のプロセスを実行する必要があります。

2. binlog 解析とマルチスレッド書き込みを自分で実装します。

データベーステーブルを単位として、複数の binlog テーブルを解析し、同時にデータを同期します。そうすることで、データ同期の効率が実際に向上します。ただし、テーブル間に構造的な関係やデータの依存関係がある場合は、書き込み順序に依然として問題が生じます。この方法は、比較的安定していて独立したデータ テーブルに使用できます。

国内の一流インターネット企業のほとんどは、データ同期の効率を高めるためにこの方法を採用しています。より根本的なアプローチは、テーブルを単位として無視して、binlog を直接解析し、直接書き込むことです。ただし、このアプローチは実装が複雑であり、使用範囲も限られています。特別なシナリオ (テーブル構造の変更やテーブル間のデータ依存性がないなどの特別なテーブル) を持つデータベースでのみ使用できます。

4. Webサーバーとデータベースの間にキャッシュを確立する

実際、大規模トラフィックの問題を解決するには、データベース レベルだけに焦点を当てるだけでは不十分です。 「80/20 ルール」によれば、リクエストの 80% はホット データの 20% にのみ焦点を当てます。したがって、Web サーバーとデータベースの間にキャッシュ メカニズムを確立する必要があります。このメカニズムでは、ディスクをキャッシュまたはメモリ キャッシュとして使用できます。それらを通じて、ホット データ クエリのほとんどはデータベースの前でブロックされます。

1. 静的ページ

ユーザーがウェブサイト上のページにアクセスした場合、そのページ上のコンテンツのほとんどは長期間変更されないことがあります。たとえば、ニュースレポートが一度公開されると、その内容が変更されることはほとんどありません。この場合、CGI によって生成された静的 HTML ページは、Web サーバーのディスクにローカルにキャッシュされます。動的 CGI を介してデータベースを照会して取得される最初の場合を除き、その後はローカル ディスク ファイルが直接ユーザーに返されます。

Web システムが比較的小さい場合、このアプローチは最適と思われます。しかし、Web システムの規模が大きくなり、例えば Web サーバーが 100 台になった場合、その場合、これらのディスク ファイルのコピーが 100 個存在することになり、リソースが無駄になり、維持が困難になります。このとき、すべてのデータを 1 つのサーバーに集中させることができると考える人もいるかもしれません。ハハ、次のようにキャッシュする方法を見てみませんか。

2. シングルメモリキャッシュ

ページの静的化の例から、ローカル Web マシン上に「キャッシュ」を構築することは維持が難しく、より多くの問題を引き起こすことがわかります (実際、PHP の apc 拡張機能を使用すると、Web サーバーのローカル メモリをキー/値で操作できます)。したがって、構築することを選択したメモリ キャッシュ サービスも独立したサービスである必要があります。

メモリ キャッシュの主な選択肢は redis/memcache です。パフォーマンスの点では両者にほとんど違いはありませんが、機能の豊富さの点では Redis の方が優れています。

3. メモリキャッシュクラスター

単一のメモリ キャッシュを構築すると、単一点障害の問題に直面するため、クラスターに変換する必要があります。簡単な方法は、スレーブをバックアップ マシンとして追加することです。しかし、リクエストの数が非常に多く、キャッシュヒット率が高くなく、より多くのマシンメモリが必要であることがわかった場合はどうなるでしょうか?したがって、クラスターとして構成することをお勧めします。たとえば、Redis クラスターのようなものです。

Redis クラスター内の Redis はマスターとスレーブの複数のグループで構成されており、各ノードはリクエストを受け入れることができるため、クラスターを拡張するときに便利です。クライアントは任意のノードにリクエストを送信でき、それが「責任がある」コンテンツである場合は、そのコンテンツが直接返されます。それ以外の場合、クライアントは実際に責任を持つ Redis ノードを見つけてそのアドレスをクライアントに通知し、クライアントは新しいリクエストを作成します。

これはすべて、キャッシュ サービスを使用するクライアントに対して透過的です。

メモリ キャッシュ サービスを切り替える際には、一定のリスクが伴います。クラスター A からクラスター B に切り替える場合、クラスター B を事前に「予熱」する必要があります (クラスター B のメモリ内のホット データは、クラスター A のものと可能な限り類似している必要があります。そうでない場合、切り替え時に大量のリクエスト コンテンツがクラスター B のメモリ キャッシュに見つからないため、トラフィックがバックエンド データベース サービスに直接影響し、データベースがクラッシュする可能性があります)。

4. データベースへの書き込みを減らす

上記のメカニズムはすべて、データベースの「読み取り」操作を削減しますが、書き込み操作も大きな負担となります。書き込み操作を削減することはできませんが、リクエストをマージすることで負荷を軽減できます。このとき、メモリ キャッシュ クラスターとデータベース クラスター間の変更同期メカニズムを確立する必要があります。

まず、外部クエリが正常に表示されるように、変更要求をキャッシュで有効にします。次に、これらの SQL 変更は保存用のキューに入れられます。キューがいっぱいになった場合、または一定の間隔で、それらは 1 つのリクエストにマージされ、データベースが更新されます。

前述のようにシステムアーキテクチャを変更して書き込みパフォーマンスを向上させることに加えて、MySQL 自体もパラメータ innodb_flush_log_at_trx_commit を構成することでディスク書き込み戦略を調整できます。マシンのコストが許せば、ハードウェア レベルから問題を解決するために、古い RAID (Redundant Arrays of independent Disks) または新しい SSD (Solid State Drives) を選択できます。

5. NoSQLストレージ

データベースの読み込み・書き込みに関わらず、トラフィックが増加し続けると、最終的には「人的リソースが限られている」という状況に陥ってしまいます。マシンを追加し続けるコストは比較的高く、必ずしも問題が解決されるとは限りません。現時点では、一部のコアデータについては、NoSQL データベースの使用を検討できます。ほとんどの NoSQL ストレージはキー値方式を使用します。ここでは上で紹介したRedisを使用することをお勧めします。 Redis 自体はメモリ キャッシュであり、ストレージとしても使用でき、データをディスクに直接保存できます。

この方法では、データベース内で頻繁に読み書きされるデータの一部を分離し、新しく構築した Redis ストレージ クラスターに配置することができ、元の MySQL データベースへの負荷がさらに軽減されます。同時に、Redis 自体がメモリレベルのキャッシュであるため、読み取りと書き込みのパフォーマンスが大幅に向上します。

国内の一流インターネット企業がアーキテクチャ面で採用しているソリューションの多くは、上記のソリューションに似ています。ただし、使用するキャッシュ サービスは必ずしも Redis ではありません。他にも選択肢は増え、自社のビジネス特性に基づいて独自の NoSQL サービスを開発することも可能になります。

6. 空ノードクエリの問題

上記のすべてのサービスを構築し、Web システムはすでに非常に強力になっていると考えます。新たな問題がまだ発生するだろうと言われています。空ノード クエリは、データベースにまったく存在しないデータ要求を参照します。たとえば、存在しない人物の情報を照会するように要求すると、システムはキャッシュの各レベルから段階的に検索し、最終的にデータベース自体を見つけ、見つからないと判断してフロントエンドに返します。すべてのレベルのキャッシュが無効であるため、この要求は大量のシステム リソースを消費し、多数の空のノードが照会されると、システム サービスに影響を与える可能性があります。

私は以前の仕事経験でこれに大いに苦しみました。したがって、Web システムの安定性を維持するためには、適切な空ノード フィルタリング メカニズムを設計することが非常に重要です。

当時私たちが採用したアプローチは、単純なレコード マッピング テーブルを設計することでした。既存のレコードを保存し、メモリ キャッシュに配置します。この方法では、空のノード クエリがある場合、それらはキャッシュ レベルでブロックされます。

リモート展開（地理的に分散）

上記のアーキテクチャ構築を完了した後、システムは十分に強力でしょうか?答えはもちろん「いいえ」です。最適化に制限はありません。 Web システムは表面的にはより強力であるように見えますが、ユーザーに提供するエクスペリエンスは必ずしも最良とは限りません。なぜなら、中国東北部出身の同級生が深圳のウェブサイトサービスにアクセスすると、距離のせいでネットワークの遅さを感じてしまうからです。現時点では、Web システムをユーザーに近づけるために、リモート展開を行う必要があります。

1. コア集中とノード分散

大規模なオンラインゲームをプレイしたことがある学生なら、オンラインゲームには多くのゾーンがあり、一般的に広東ゾーンや北京ゾーンなど地域ごとに分けられていることを知っているでしょう。広東のプレイヤーが北京ゾーンに行ってプレイすると、広東ゾーンよりもゲームが明らかに遅れていると感じるでしょう。実際、これらの地域の名前は、サーバーがどこに配置されているかをすでに説明しています。したがって、広東省のプレイヤーが北京のサーバーに接続すると、当然ネットワークは遅くなります。

システムまたはサービスが十分に大きい場合は、リモート展開を検討する必要があります。サービスをできるだけユーザーに近いものにしましょう。以前、Web 上の静的リソースを CDN に保存し、DNS/GSLB を通じて「全国」に配布できることについて説明しました。しかし、CDN は静的リソースの問題のみを解決するものであり、巨大なバックエンド システム サービスが固定された都市に集中するという問題は解決しません。

この時点で、リモート展開が開始されます。リモート展開は、一般的に、集中型コアと分散型ノードの原則に従います。

• コア集中: 実際の展開プロセスでは、複数のセットに展開できないデータやサービスが常に存在し、複数のセット展開にかかるコストも膨大です。これらのサービスとデータについては、依然としてセットが維持され、展開場所は比較的中央のエリアに選択され、ネットワーク内の専用回線を通じて各ノードと通信します。
• ノード分散: 一部のサービスを複数のセットに展開し、さまざまな都市のノードに分散することで、ユーザーは最も近いノードを選択してサービスにアクセスできます。

たとえば、上海をコアノードとして展開し、北京、深セン、武漢、上海を分散ノードとして展開することを選択します (上海自体も分散ノードです)。当社のサービスアーキテクチャは以下の通りです。

なお、上図の上海ノードとコアノードは同じコンピュータ室にあり、その他の分散ノードはそれぞれ独立したコンピュータ室にあります。

中国には大規模なオンラインゲームが数多く存在し、いずれもおおよそ上記の構造に従っています。少量のデータを含むユーザーのコアアカウントはコアノードに配置され、装備、タスク、その他のデータやサービスなどのオンラインゲームデータの大部分は地域ノードに配置されます。もちろん、コアノードとリージョンノード間のキャッシュメカニズムもあります。

2. ノードの災害復旧と過負荷保護

ノードの災害復旧とは、ノードに障害が発生した場合でも、サービスが引き続き利用可能であることを保証するメカニズムを確立する必要があることを意味します。ここでのより一般的な災害復旧方法は、近くの都市ノードに切り替えることであることは間違いありません。システムの天津ノードに障害が発生した場合、ネットワーク トラフィックを近くの北京ノードに切り替えます。負荷分散を考慮すると、トラフィックを複数の近くの地域ノードに同時に切り替えることが必要になる場合があります。一方、コアノード自体も独自の災害復旧とバックアップを行う必要があります。コアノードに障害が発生すると、国のサービスに影響が及びます。

過負荷保護とは、ノードが最大容量に達し、それ以上の要求を受け入れることができなくなったことを意味します。システムには保護メカニズムが必要です。サービスがすでに完全にロードされていて、新しいリクエストを受け入れ続けると、クラッシュが発生し、ノード全体のサービスに影響する可能性があります。少なくともほとんどのユーザーにとって正常な使用を保証するためには、過負荷保護が必要です。

過負荷保護を解決するには、一般的に次の 2 つの方法があります。

• サービス拒否: フルロードを検出すると、新しい接続要求は受け入れられなくなります。たとえば、オンライン ゲームにログインするときのキューなどです。
• 他のノードに転送します。この場合、システムの実装はより複雑になり、負荷分散の問題が伴います。

まとめ

Web システムへのアクセス規模が拡大するにつれて、需要は単一のサーバーから「モンスター」クラスターへと徐々に拡大していきます。この Web システムが拡大していくプロセスは、実は私たちが問題を解決するプロセスなのです。さまざまな段階で、さまざまな問題が解決され、古い解決策に基づいて新しい問題が生まれます。

システムの最適化には制限はありません。ソフトウェアとシステムアーキテクチャは急速に発展しています。新しい解決策は古い問題を解決すると同時に、新たな課題ももたらします。