確実にコピー：数千万のトラフィックを処理する大規模分散システムアーキテクチャの設計

この記事は、大規模な分散 Web サイト アーキテクチャの学習に関する技術的な概要です。この記事では、高パフォーマンス、高可用性、スケーラビリティ、拡張性に優れた分散 Web サイトの構築方法について簡単に説明し、アーキテクチャのリファレンスを提供します。記事の一部は読書メモであり、一部は個人的な経験の要約であり、大規模な分散型 Web サイト アーキテクチャの参考価値が高いです。

1. 大規模分散型ウェブサイト構築技術

1. 大規模ウェブサイトの特徴

• 多くのユーザーが広く分布
• 大規模なトラフィック、高い同時実行性
• 膨大なデータ、高いサービス可用性
• セキュリティ環境が悪く、サイバー攻撃に対して脆弱
• より多くの機能、より速い変更、頻繁なリリース
• 小規模から大規模へ、段階的な発展
• ユーザー中心
• 無料サービス、有料体験

2. 大規模ウェブサイトのアーキテクチャ目標

• 高性能: 高速なアクセスエクスペリエンスを提供します。
• 高可用性: ウェブサイト サービスには常に正常にアクセスできます。
• スケーラブル: ハードウェアを追加/削除することで処理能力を増減します。
• セキュリティ: 安全な Web サイト アクセス、データ暗号化、安全なストレージ、その他の戦略を提供します。
• スケーラビリティ: 新しい機能/モジュールを簡単に追加/削除できます。
• 敏捷性: ニーズに適応し、迅速に対応します。

3. 大規模ウェブサイトアーキテクチャモデル

• 階層化: 一般的に、アプリケーション層、サービス層、データ層、管理層、分析層に分けられます。
• セグメンテーション: 一般的には、ビジネス/モジュール/機能特性に応じて分割されます。たとえば、アプリケーション層は、ホームページとユーザー センターに分割されます。
• 分散: アプリケーションを個別に (たとえば、複数の物理マシンに) 展開し、リモート呼び出しを通じて連携します。
• クラスター: アプリケーション/モジュール/関数は複数のコピー (複数の物理マシンなど) に展開され、負荷分散を通じて外部アクセスを提供します。
• キャッシュ: アクセスを高速化するために、データをアプリケーションまたはユーザーに最も近い場所に配置します。
• 非同期: 同期操作を非同期にします。クライアントはリクエストを送信し、サーバーの応答を待機しません。サーバーはリクエストを処理した後、通知またはポーリングによってリクエスト元に通知します。一般的には、要求-応答-通知モードを指します。
• 冗長性: レプリカを追加して、可用性、セキュリティ、パフォーマンスを向上させます。
• セキュリティ: 既知の問題に対する効果的な解決策を用意し、未知または潜在的な問題に対する検出および防御メカニズムを確立します。
• 自動化: ツールによる人間の介入を必要としない反復的なタスクを機械を使用して完了します。
• 俊敏性: 要件の変更を積極的に受け入れ、ビジネス開発のニーズに迅速に対応します。

4. 高性能アーキテクチャ

ユーザー中心で、高速な Web アクセス エクスペリエンスを提供します。主なパラメータには、応答時間の短縮、同時処理能力の向上、スループットの向上、パフォーマンス パラメータの安定性などがあります。

フロントエンド最適化、アプリケーション層最適化、コード層最適化、ストレージ層最適化に分けられます。

• フロントエンドの最適化: ウェブサイトのビジネスロジックの前の部分。
• ブラウザの最適化: HTTP リクエストの数を減らし、ブラウザ キャッシュを使用し、圧縮を有効にし、CSS JS の場所、JS の非同期化を行い、Cookie の送信を減らします。 CDN アクセラレーション、リバース プロキシ。
• アプリケーション層の最適化: ウェブサイトの操作を処理するサーバー。キャッシュ、非同期、クラスタリングを使用する
• コードの最適化: 適切なアーキテクチャ、マルチスレッド、リソースの再利用 (オブジェクト プール、スレッド プールなど)、適切なデータ構造、JVM チューニング、シングルトン、キャッシュなど。
• ストレージの最適化: キャッシュ、ソリッド ステート ドライブ、ファイバー伝送、最適化された読み取りと書き込み、ディスク冗長性、分散ストレージ (HDFS)、NoSQL など。

5. 高可用性アーキテクチャ

大規模な Web サイトは、いつでもアクセス可能であり、外部サービスを正常に提供できる必要があります。大規模 Web サイトの複雑さ、分散性、安価なサーバー、オープンソース データベース、オペレーティング システムなどの特性により、高可用性を確保することは非常に困難であり、Web サイトの障害は避けられません。

可用性をどのように向上させるかは、早急に取り組む必要がある問題です。まず、アーキテクチャレベルから検討し、計画時に可用性を考慮する必要があります。業界では一般的に、可用性の指標を表すために 9 の数を使用します。たとえば、9 が 4 つ (99.99) の場合は、1 年間に許容される利用不可時間は 53 分であることを意味します。

レベルによって使用する戦略は異なり、高可用性の問題を解決するために、通常は冗長バックアップとフェイルオーバーが使用されます。

• アプリケーション層: 通常はステートレスに設計されており、各リクエストの処理にどのサーバーが使用されるかは問題ではありません。一般的に、高可用性を実現するために、負荷分散テクノロジが使用されます (セッション同期の問題を解決する必要があります)。
• サービス層: 負荷分散、階層管理、高速障害 (タイムアウト設定)、非同期呼び出し、サービス低下、べき等設計など。
• データ層: 冗長バックアップ (コールド、ホット バックアップ [同期、非同期]、ウォーム バックアップ)、フェイルオーバー (確認、転送、回復)。データの高可用性の有名な理論的根拠は、CAP理論（永続性、可用性、データの一貫性[強い一貫性、ユーザーの一貫性、最終的な一貫性]）です。

6. スケーラブルなアーキテクチャ

スケーラビリティとは、元のアーキテクチャ設計を変更せずに、ハードウェア (サーバー) を追加/削減することで、システムの処理能力を増減することを指します。

• アプリケーション層: アプリケーションを垂直または水平に分割します。次に、単一の機能 (DNS、HTTP [リバース プロキシ]、IP、リンク層) の負荷を分散します。
• サービス層: アプリケーション層に似ています。
• データ層: シャーディング、シャーディング テーブル、NoSQL など。一般的に使用されるアルゴリズムはハッシュとコンシステントハッシュです。

7. スケーラブルなアーキテクチャ

機能モジュールは簡単に追加/削除できるため、コード/モジュール レベルで優れたスケーラビリティが実現します。

• モジュール化とコンポーネント化: 高い凝集性、低い結合性、再利用性とスケーラビリティの向上。
• 安定したインターフェース: 安定したインターフェースを定義します。インターフェースは変更されませんが、内部構造は「自由に」変更できます。
• デザイン パターン: オブジェクト指向のアイデアと原則を適用し、デザイン パターンを使用して、コード レベルの設計を実行します。
• メッセージ キュー: メッセージ キューを介して対話し、モジュール間の依存関係を分離するモジュール システム。
• 分散サービス: パブリック モジュールはサービス指向になり、再利用性とスケーラビリティを向上させるために他のシステムでも利用できるようになります。

8. セキュリティアーキテクチャ

既知の問題に対する効果的な解決策を用意し、未知または潜在的な問題に対する発見および防御メカニズムを確立します。セキュリティの問題に関しては、まずセキュリティ意識を高め、ポリシーレベルと組織レベルから保護を提供する安全で効果的なメカニズムを確立する必要があります。たとえば、サーバーのパスワードは漏洩せず、パスワードは毎月更新され、3 回以内に同じパスワードを繰り返すことはできません。毎週のセキュリティスキャンなど、制度化された形でのセキュリティシステムの構築を強化します。同時に、安全に関するあらゆる側面に注意を払う必要があります。インフラストラクチャのセキュリティ、アプリケーション システムのセキュリティ、データの機密性のセキュリティなど、セキュリティの問題は無視できません。

• インフラストラクチャ セキュリティ: ハードウェア調達、オペレーティング システム、ネットワーク環境のセキュリティ。一般的には、正規のチャネルを通じて高品質の製品を購入し、安全なオペレーティング システムを選択し、脆弱性を適時に修正し、ウイルス対策ソフトウェアとファイアウォールをインストールします。ウイルスやバックドアを防止します。ファイアウォール ポリシーを設定し、DDOS 防御システムを確立し、攻撃検出システムを使用し、サブネット分離を実行します。
• アプリケーション システムのセキュリティ: プログラムを開発するときは、正しい方法を使用して、コード レベルで既知の一般的な問題を解決します。クロスサイト スクリプティング (XSS)、インジェクション攻撃、クロスサイト リクエスト フォージェリ (CSRF)、エラー メッセージ、HTML コメント、ファイルのアップロード、パス トラバーサルなどを防止します。また、Web アプリケーション ファイアウォール (ModSecurity など) を使用して、セキュリティ脆弱性スキャンやその他の対策を実行し、アプリケーション レベルのセキュリティを強化することもできます。
• データの機密性とセキュリティ: ストレージ セキュリティ (信頼性の高い機器への保存、リアルタイムの定期バックアップ)、保存セキュリティ (重要な情報の暗号化された保存、複雑な保存と検出のための適切な人員の選択など)、送信セキュリティ (データの盗難とデータの改ざんの防止)。

一般的に使用される暗号化および復号化アルゴリズム (一方向ハッシュ暗号化 [MD5、SHA]、対称暗号化 [DES、3DES、RC])、非対称暗号化 [RSA] など。

9. 敏捷性

ウェブサイトのアーキテクチャ設計と運用・保守管理は、変化に適応し、高いスケーラビリティと拡張性を提供する必要があります。急速なビジネス発展、高トラフィックアクセスの急増などの要件に便利に対応します。

上記で紹介したアーキテクチャ要素に加えて、アジャイル管理とアジャイル開発の考え方も導入する必要があります。ビジネス、製品、テクノロジー、運用と保守を統合し、ニーズに適応して迅速に対応します。

10. 大規模アーキテクチャの例

上記は 7 層の論理アーキテクチャを採用しています。第 1 層は顧客層、第 2 層はフロン​​トエンド最適化層、第 3 層はアプリケーション層、第 4 層はサービス層、第 5 層はデータ ストレージ層、第 6 層はビッグ データ ストレージ層、第 7 層はビッグ データ処理層です。

• クライアント層: PC ブラウザとモバイル アプリをサポートします。違いは、モバイル アプリが IP 経由でリバース プロキシ サーバーに直接アクセスできることです。
• フロントエンド層: DNS ロード バランシング、CDN ローカル アクセラレーション、リバース プロキシ サービスを使用します。
• アプリケーション層: ウェブサイト アプリケーション クラスター。製品アプリケーション、会員センターなど、業務に応じた垂直分割。
• サービス層: ユーザーサービス、注文サービス、支払いサービスなどのパブリックサービスを提供します。
• データ層: リレーショナル データベース クラスター (読み取りと書き込みの分離をサポート)、NOSQL クラスター、分散ファイル システム クラスター、および分散キャッシュをサポートします。
• ビッグデータストレージ層: アプリケーション層とサービス層でのログデータ収集、リレーショナルデータベースと NOSQL データベースの構造化および半構造化データ収集をサポートします。
• ビッグデータ処理層: Mapreduce を介してオフライン データ分析を実行するか、Storm を介してリアルタイム データ分析を実行し、処理されたデータをリレーショナル データベースに保存します。 (実際の使用では、オフライン データとリアルタイム データは、ビジネス要件に応じて分類および処理され、アプリケーション層またはサービス層で使用するために異なるデータベースに保存されます)。

2. 大規模電子商取引サイトのシステムアーキテクチャの進化

成熟した大規模ウェブサイト（Taobao、Tmall、Tencent など）のシステム アーキテクチャは、完全な高性能、高可用性、高スケーラビリティなどの機能を考慮して設計されていません。利用者数の増加や業務機能の拡大とともに、徐々に進化・改善してきました。このプロセスにおいて、開発モデル、技術アーキテクチャ、設計思想も大きく変化しました。技術スタッフも、数人から部門、さらには製品ラインにまで成長しました。

したがって、成熟したシステム アーキテクチャは、ビジネスの拡大に合わせて徐々に改善されるものであり、一夜にして達成できるものではありません。ビジネス特性が異なるシステムには、それぞれ独自の焦点が置かれます。たとえば、Taobao は膨大な商品情報の検索、注文、支払いを解決する必要があります。テンセントは数億人のユーザーへのリアルタイムメッセージ伝送の問題を解決する必要があります。 Baidu は大量の検索リクエストを処理する必要があります。

それぞれに独自のビジネス特性と異なるシステム アーキテクチャがあります。それにもかかわらず、これらのさまざまな Web サイトの背景から共通のテクノロジーを見つけることもできます。これらの技術と手段は、大規模な Web サイト システムのアーキテクチャで広く使用されています。以下では、大規模Webサイトのシステムの進化の過程を紹介しながら、これらの技術や手段について紹介します。

1. 初期のウェブサイトアーキテクチャ

元のアーキテクチャでは、図に示すように、アプリケーション、データベース、およびファイルはすべて 1 つのサーバーに展開されていました。

2. アプリケーション、データ、ファイルの分離

ビジネスが拡大するにつれて、1 台のサーバーではパフォーマンス要件を満たせなくなるため、アプリケーション、データベース、ファイルを別々のサーバーに展開し、サーバーの目的に応じて異なるハードウェアを構成することで、最高のパフォーマンス効果を実現します。

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

ハードウェアを通じてパフォーマンスを最適化すると同時に、ソフトウェアを通じてパフォーマンスも最適化します。ほとんどの Web サイト システムでは、システム パフォーマンスを向上させるためにキャッシュ テクノロジが使用されています。キャッシュが使用される主な理由は、ホット データの存在です。ほとんどの Web サイト アクセスは 28 の原則 (つまり、アクセス要求の 80% が最終的にデータの 20% に該当する) に従っているため、ホット データをキャッシュし、このデータへのアクセス パスを削減して、ユーザー エクスペリエンスを向上させることができます。

キャッシュを実装する一般的な方法は、ローカル キャッシュと分散キャッシュです。もちろん、CDN やリバース プロキシなども存在しますが、これについては後ほど説明します。ローカル キャッシュは、その名前が示すように、アプリケーション サーバー上でデータをローカルにキャッシュします。メモリまたはファイルに保存できます。 OSCache はよく使用されるローカル キャッシュ コンポーネントです。ローカルキャッシュの特徴は高速であることです。しかし、ローカルスペースが限られているため、キャッシュされるデータの量も限られています。分散キャッシュの特徴は、膨大な量のデータをキャッシュでき、拡張が非常に簡単なことです。ポータルサイトでよく使われます。速度はローカルキャッシュほど速くありません。一般的に使用される分散キャッシュは Memcached と Redis です。

4. クラスタを使用してアプリケーションサーバーのパフォーマンスを向上させる

ウェブサイトへの入り口として、アプリケーション サーバーは大量のリクエストを処理します。多くの場合、アプリケーション サーバー クラスターを通じてリクエストの数を共有します。負荷分散サーバーは、アプリケーション サーバーの前に配置され、ユーザー要求をスケジュールし、分散戦略に従って複数のアプリケーション サーバー ノードに要求を分散します。

一般的に使用される負荷分散技術のハードウェアには、比較的高価な F5 が含まれ、ソフトウェアには LVS、Nginx、HAProxy が含まれます。 LVS は、ターゲット アドレスとポートに基づいて内部サーバーを選択する 4 層の負荷分散方式です。 Nginx と HAProxy は、メッセージの内容に基づいて内部サーバーを選択できる 7 層の負荷分散方法です。したがって、LVS 配布パスは Nginx や HAProxy よりも優れており、パフォーマンスも高くなります。 Nginx と HAProxy は、動的および静的分離 (要求メッセージの特性に基づいて静的リソース サーバーまたはアプリケーション サーバーを選択する) に使用されるなど、より構成可能です。

5. データベースの読み取りと書き込みの分離とデータベースとテーブルのシャーディング

ユーザー数が増えると、データベースが最大のボトルネックになります。データベースのパフォーマンスを向上させる一般的な方法は、読み取りと書き込みの分離と、データベースとテーブルのシャーディングを実行することです。読み取り書き込み分離は、その名の通り、データベースを読み取りデータベースと書き込みデータベースに分割し、マスタースレーブ機能を通じてデータの同期を実現します。データベースとテーブルのシャーディングは、水平シャーディングと垂直シャーディングに分けられます。水平シャーディングは、ユーザー テーブルなどのデータベース内の特に大きなテーブルを分割することです。垂直セグメンテーションは、ユーザービジネスと製品ビジネスに関連するテーブルを異なるデータベースに配置するなど、異なるビジネスに基づいています。

6. CDNとリバースプロキシを使用してウェブサイトのパフォーマンスを向上させる

サーバーがすべて成都のコンピューター室に配備されている場合、四川省のユーザーのアクセスは速くなりますが、北京のユーザーのアクセスは遅くなります。これは、四川省と北京市がそれぞれ中国電信と中国聯通の異なる開発地域に属しているためです。北京のユーザーは、成都のサーバーにアクセスするために相互接続されたルーターを経由するより長い経路を通過する必要があり、戻り経路は同じであるため、データの転送時間は比較的長くなります。この場合、問題を解決するために CDN がよく使用されます。 CDN はデータ コンテンツをオペレーターのコンピューター ルームにキャッシュします。ユーザーがデータにアクセスすると、まず最も近いオペレータからデータを取得するため、ネットワーク アクセス パスが大幅に短縮されます。よりプロフェッショナルな CDN オペレーターとしては、ChinaCache や Wangsu などがあります。

リバース プロキシは、Web サイトのコンピューター ルームに展開されます。ユーザー要求が到着すると、まずリバース プロキシ サーバーにアクセスします。リバース プロキシ サーバーはキャッシュされたデータをユーザーに返します。キャッシュされたデータがない場合、アプリケーション サーバーにアクセスしてデータを取得します。これにより、データ取得コストが削減されます。リバースプロキシには Squid や Nginx などがあります。

7. 分散ファイルシステムを使用する

ユーザー数が日々増加し、業務量が増大し、生成されるファイル数も増えるにつれ、単一のファイルサーバーでは需要を満たすことができなくなります。このとき、分散ファイルシステムのサポートが必要になります。一般的に使用される分散ファイルシステムには、GFS、HDFS、TFS などがあります。

8. NoSQLと検索エンジンを使用する

膨大なデータのクエリと分析には、NoSQL データベースと検索エンジンを使用してパフォーマンスを向上させます。すべてのデータをリレーショナル データベースに保存する必要はありません。一般的に使用される NoSQL には MongoDB、HBase、Redis などがあり、検索エンジンには Lucene、Solr、Elasticsearch などがあります。

9. アプリケーションサーバーをビジネスに分割する

ビジネスがさらに拡大するにつれて、アプリケーションは非常に肥大化します。このとき、Baidu がニュース、Web ページ、画像などの業務に分割されているように、アプリケーションを業務に分割する必要があります。各ビジネス アプリケーションは、比較的独立したビジネス操作を担当します。企業はメッセージを通じて、またはデータベースを共有することでコミュニケーションをとります。

10. 分散サービスを構築する

この時点で、各ビジネス アプリケーションは、ユーザー サービス、注文サービス、支払いサービス、セキュリティ サービスなどのいくつかの基本的なビジネス サービスを使用することが分かりました。これらのサービスは、各ビジネス アプリケーションをサポートする基本要素です。これらのサービスを抽出し、分散サービス フレームワークを使用して分散サービスを構築します。 AlibabaのDubboは良い選択です。

3. 電子商取引のアーキテクチャを示す図

IV.大規模電子商取引ウェブサイトアーキテクチャのケーススタディ

1. 電子商取引訴訟の理由

現在、分散型大規模 Web サイトには主にいくつかの種類があります。

• NetEase、Sina などの大規模ポータル。
• xiaonei、kaixin.comなどのSNSウェブサイト。
• Alibaba、JD.com、Gome Online、Autohome などの電子商取引 Web サイト。

大規模なポータルには通常ニュース情報が含まれており、CDN、静的化、その他の方法を使用して最適化できます。 Kaixin.com やその他の Web サイトはよりインタラクティブであり、より多くの NoSQL や分散キャッシュを導入し、高性能な通信フレームワークを使用する可能性があります。電子商取引ウェブサイトには、上記 2 つのカテゴリの特徴があります。たとえば、製品の詳細には CDN と静的を使用できますが、高いインタラクティブ性には NoSQL などのテクノロジを使用する必要があります。そこで、私たちは分析のケースとして電子商取引のウェブサイトを使用します。

2. 電子商取引ウェブサイトの要件

顧客のニーズ:

• ユーザーが商品をオンラインで購入し、オンラインまたは配達時に支払いができるフルカテゴリの電子商取引 Web サイト (B2C) を構築します。
• ユーザーは購入時にオンラインでカスタマーサービスと通信できます。
• 商品を受け取った後、ユーザーは商品を評価し、コメントすることができます。
• 現在、成熟した在庫管理システムがあり、これを Web サイトに接続する必要があります。
• 当社は、3年から5年にわたり事業の発展をサポートしたいと考えています。
• 3～5年後にはユーザー数が1,000万人に達すると予想されています。
• ダブル11、ダブル12、3月8日メンズデーなどのイベントを定期的に開催します。
• その他の機能については、JD.comやGome OnlineなどのWebサイトを参照してください。

顧客は顧客です。彼らは具体的に何が欲しいのかは言わないけれど、欲しいものだけは伝えます。顧客のニーズを導き、探求しなければならないことがよくあります。幸いなことに、明確な参考ウェブサイトが提供されています。したがって、次のステップは、業界と参考ウェブサイトを組み合わせて多くの分析を行い、顧客にソリューションを提供することです。

要件機能マトリックス

要件管理の従来のアプローチでは、ユースケース図またはモジュール図 (要件リスト) を使用して要件を記述します。そうすると、非常に重要な要件（非機能要件）が見落とされてしまうことが多いため、要件を記述するには要件機能マトリックスを使用することをお勧めします。

この電子商取引ウェブサイトの需要マトリックスは次のとおりです。

3. 主要なウェブサイトのアーキテクチャ

通常、Web サイトは、アプリケーションを展開するためのサーバー、データベースを展開するためのサーバー、NFS ファイル システムを展開するためのサーバーの 3 台から始まります。

これはここ数年間のより伝統的な慣習でした。会員数が10万人を超え、垂直的な衣服デザインポータルと大量の写真が掲載されているウェブサイトを見たことがあります。アプリケーション、データベース、およびイメージ ストレージを展開するためにサーバーが使用されました。パフォーマンスの問題がたくさんありました。

以下のように表示されます。

しかし、現在主流のウェブサイトのアーキテクチャは大きな変化を遂げています。一般的に、クラスタリングは高可用性設計に使用されます。少なくとも次のようになります:

• クラスターを使用してアプリケーション サーバーを冗長化し、高可用性を実現します。 （負荷分散デバイスはアプリケーションと一緒に導入できます）
• データのバックアップと高可用性を実現するために、データベース マスター/スレーブ モードを使用します。

4. システム容量の推定

推定手順:

• 登録ユーザー数 - 平均日次 UV ボリューム - 日次 PV ボリューム - 日次同時ボリューム。
• ピーク値推定値：通常量の2～3倍
• システム容量は、同時実行性（同時トランザクション数）とストレージ容量に基づいて計算されます。

顧客のニーズによると、ユーザー数は 3 ～ 5 年で登録ユーザー数 1,000 万人に達し、1 秒あたりの同時ユーザー数は次のように推定されます。

• 1日の紫外線量は200万（80/20ルール）です。
• 1日あたり30ヒット。
• PV数：200×30=6000万
• 集中的な訪問: 24*0.2=4.8 時間の場合、6,000 万*0.8=4,800 万になります (80/20 ルール)。
• 1 分あたりの同時実行数: 4.8*60=288 分、4800/288=1 分あたり 167,000 回の訪問 (おおよそ)。
• 1 秒あたりの同時実行数: 167,000/60 = 2780 (おおよそ)
• ピーク期間が通常値の 3 倍であると仮定すると、1 秒あたりの同時リクエスト数は 8340 に達する可能性があります。
• 1 ミリ秒 = 1.3 回の訪問

数学をちゃんと勉強しなかったことを後悔していますか? （上記の計算が間違っているかどうかは分かりませんが、笑）

サーバーの見積もり: (Tomcat サーバーを例に挙げます)

1 つの Web サーバーは 1 秒あたり 300 回の同時計算をサポートします。通常、約 10 台のサーバーが必要です。 [Tomcat のデフォルト構成は 150] であり、ピーク時には 30 台のサーバーが必要になります。

容量推定: 70/90 ルール

システム CPU は通常 70% 前後で維持され、ピーク時には 90% に達し、リソースを無駄にせず、比較的安定しています。メモリとIOは似ています。

上記の見積りは参考値であり、サーバー構成、ビジネス ロジックの複雑さなどが影響します。 CPU、ハードディスク、ネットワークなどはここでは評価されなくなりました。

5. ウェブサイトのアーキテクチャ分析

上記の推定に基づいて、いくつかの疑問が生じます。

• 多数のサーバーを展開する必要があります。コンピューティングのピーク時には、30 台の Web サーバーを展開する必要がある場合があります。さらに、これら 30 台のサーバーはフラッシュ セールやアクティビティ時にのみ使用されるため、大きな無駄が生じます。
• すべてのアプリケーションは同じサーバーにデプロイされており、アプリケーション間の結合が強くなっています。垂直方向と水平方向のセグメンテーションが必要です。
• 多くのアプリケーションには冗長なコードがある
• サーバーセッションの同期は大量のメモリとネットワーク帯域幅を消費します
• データはデータベースに頻繁にアクセスする必要があり、データベース アクセスの負荷は非常に大きくなります。

大規模な Web サイトでは、一般的に次のアーキテクチャ最適化を行う必要があります (最適化はアーキテクチャ設計時に考慮する必要があり、通常はアーキテクチャ/コード レベルで解決されます。チューニングは主に、JVM チューニングなどの単純なパラメータの調整です。チューニングに大量のコード変更が含まれる場合は、チューニングではなくリファクタリングです)。

• 事業分割
• アプリケーション クラスタの展開 (分散展開、クラスタ展開、負荷分散)
• マルチレベルキャッシュ
• シングル サインオン (分散セッション)
• データベース クラスター (読み取りと書き込みの分離、データベースとテーブルの分離)
• サービス指向
• メッセージキュー
• その他の技術

6. ウェブサイトのアーキテクチャの最適化

（１）事業分割

業務属性に応じて垂直に分割され、商品サブシステム、ショッピングサブシステム、決済サブシステム、コメントサブシステム、顧客サービスサブシステム、インターフェースサブシステム（購買・販売・在庫管理やテキストメッセージなどの外部システムとの接続用）に分かれています。

ビジネスサブシステムのレベル定義に基づいて、コアシステムと非コアシステムに分類できます。コアシステム: 製品サブシステム、ショッピングサブシステム、支払いサブシステム。非コア: レビュー サブシステム、顧客サービス サブシステム、インターフェース サブシステム。

ビジネス分割の役割: サブシステムへのアップグレードは、モジュール間の結合とスケーラビリティの問題を解決するために専門家が専門的な作業を行うことで、専用のチームまたは部門によって管理できます。各サブシステムは個別に展開され、集中展開によって 1 つのアプリケーションがクラッシュし、すべてのアプリケーションが使用できなくなるという問題が回避されます。

レベル定義機能: トラフィックバーストが発生したときに主要なアプリケーションを保護し、段階的な劣化を実現するために使用されます。重要なアプリケーションが影響を受けないように保護します。

分割後のアーキテクチャ図:

リファレンス展開ソリューション 2

上図に示すように、各アプリケーションは個別に展開され、コアシステムと非コアシステムは組み合わせて展開されます。

（２）アプリケーションクラスタの展開（分散、クラスタ、負荷分散）

• 分散展開: ビジネスを分割した後にアプリケーションを個別に展開し、アプリケーションは RPC を介して直接リモートで通信します。
• クラスター展開: 電子商取引 Web サイトの高可用性要件を満たすには、クラスター展開用に各アプリケーションを少なくとも 2 台のサーバーに展開する必要があります。
• 負荷分散: 高可用性システムには必須です。一般的なアプリケーションは負荷分散によって高可用性を実現し、分散サービスは組み込みの負荷分散によって高可用性を実現し、リレーショナル データベースはマスター/スレーブ モードによって高可用性を実現します。

クラスター展開後のアーキテクチャ図:

（３）マルチレベルキャッシュ

キャッシュは一般に、保存場所に応じて、ローカル キャッシュと分散キャッシュの 2 つのカテゴリに分類されます。このケースでは、二次キャッシュ方式を使用してキャッシュを設計します。第 1 レベル キャッシュはローカル キャッシュであり、第 2 レベル キャッシュは分散キャッシュです。 （ページキャッシュ、フラグメントキャッシュなど、より細かい区分もあります）

第 1 レベルのキャッシュは、データ ディクショナリ、よく使用されるホット データ、およびその他の基本的に不変/定期的に変更される情報をキャッシュし、第 2 レベルのキャッシュは必要なすべてのキャッシュをキャッシュします。第 1 レベル キャッシュの有効期限が切れているか使用できない場合は、第 2 レベル キャッシュのデータにアクセスします。第 2 レベル キャッシュが利用できない場合は、データベースにアクセスします。

キャッシュ比率は通常 1:4 なので、キャッシュの使用を検討できます。 （理論的には1：2で十分です）。

ビジネス特性に応じて、次のキャッシュ有効期限ポリシーを使用できます。

• キャッシュは自動的に期限切れになります。
• キャッシュトリガーの有効期限。

（4）シングルサインオン（分散セッション）

システムを複数のサブシステムに分割し、個別に展開すると、セッション管理の問題が避けられません。一般的には、セッション同期、Cookie、分散セッション方式を使用できます。電子商取引の Web サイトでは通常、分散セッション実装が使用されます。

さらに、分散セッションに基づいて完全なシングル サインオンまたはアカウント管理システムを確立できます。

プロセスの説明

• ユーザーが初めてログインすると、例えばユーザーIDをキーとしてセッション情報（ユーザーIDとユーザー情報）が分散セッションに書き込まれます。
• ユーザーが再度ログインすると、配布されたセッションを取得して、セッション情報があるかどうかを確認します。そうでない場合は、ログイン ページを呼び出します。
• 通常は、Cache ミドルウェアを使用して実装されます。 Redis は永続化機能を備えているため、分散セッションがクラッシュした後に永続ストレージからセッション情報を読み込むのに便利なのでお勧めです。
• セッションを保存するときに、15 分などのセッション保持時間を設定できます。この時間が経過すると、セッションは自動的にタイムアウトします。
• Cache ミドルウェアと組み合わせると、分散セッションは Session セッションを非常に適切にシミュレートできます。

（５）データベースクラスタ（読み書き分離、データベースとテーブルを分離）

大規模な Web サイトでは、膨大な量のデータを保存する必要があります。大規模なデータストレージ、高可用性、高パフォーマンスを実現するために、冗長システム設計が一般的に使用されます。一般的には、読み取りと書き込みの分離とデータベースとテーブルのシャーディングの 2 つの方法があります。

読み取りと書き込みの分離: 一般的に、読み取り率が書き込み率よりもはるかに大きいシナリオを解決します。 1 つのマスターと 1 つのバックアップ、1 つのマスターと複数のバックアップ、または複数のマスターと複数のバックアップを使用できます。

このケースでは、データベースとテーブルのシャーディングを、ビジネス分割に基づく読み取り/書き込み分離と組み合わせます。以下のように表示されます。

• 事業分割後: 各サブシステムには個別のライブラリが必要です。
• 単一のデータベースが大きすぎる場合は、商品分類データベースや製品データベースなど、ビジネス特性に基づいて 2 つのサブデータベースに分割できます。
• データベースを分割した後、テーブル内に大量のデータがある場合は、テーブルに分割することができます。一般的にはIDや時間などでテーブルを分割できます（高度な使い方は一貫性のあるハッシュです）
• サブライブラリとサブテーブルに基づいて、読み取りと書き込みの分離が実行されます。

関連するミドルウェアについては、Cobar (Ali、現在はメンテナンスされていません)、TDDL (Ali)、Atlas (Qihoo 360)、および MyCat を参照してください。

データベースとテーブルのシャーディング後のシーケンスの問題、JOIN、トランザクションの問題について、データベースとテーブルのシャーディングのトピック共有で紹介します。

（6）サービス指向

複数のサブシステムに共通する機能/モジュールを抽出し、パブリックサービスとして使用します。たとえば、この場合のメンバーシップ サブシステムは、パブリック サービスとして抽出できます。

(7) メッセージキュー

メッセージ キューは、サブシステム/モジュール間の結合を解決し、非同期、高可用性、高性能のシステムを実現します。分散システムの標準構成です。この場合、メッセージキューは主にショッピングと配達で使用されます。

• ユーザーが注文を行うと、メッセージキューに書き込まれ、クライアントに直接返されます。
• インベントリサブシステム：メッセージキュー情報を読み取り、在庫削減を完了します。
• 配布サブシステム：メッセージキュー情報を読み取り、配布を実行します。

現在、最も一般的に使用されるMQには、アクティブMQ、ウサギMQ、ゼロMQ、MS MQなどが含まれており、特定のビジネスシナリオに基づいて1つを選択する必要があります。ウサギMQを研究することをお勧めします。

（8）その他のアーキテクチャ（テクノロジー）

ビジネスの分割に加えて、アプリケーションクラスタリング、マルチレベルキャッシュ、シングルサインオン、データベースクラスタリング、サービス指向、および上記で紹介したメッセージキュー。また、CDN、リバースプロキシ、分散ファイルシステム、ビッグデータ処理、その他のシステムもあります。

ここで詳しくは紹介しません。Baidu/Googleに尋ねることができます。チャンスがあれば、私はあなたとそれを共有することもできます。

7。アーキテクチャの概要

大規模なWebサイトのアーキテクチャは、ビジネスニーズに応じて常に改善されており、さまざまなビジネス特性に応じて特定の設計と考慮事項が行われます。この記事では、すべての人にインスピレーションを与えることを望んでいる通常の大規模なウェブサイトに関係するテクノロジーと方法の一部のみについて説明します。

著者について

Lan Zhupiには10年以上の実務経験があり、Googleなどの外国企業で数年間働いています。彼は、Java、分散アーキテクチャ、マイクロサービスアーキテクチャ、データベースに熟練しています。彼は現在、ビッグデータとブロックチェーンを研究しており、より高いレベルに突入することを望んでいます。