高性能、高可用性の大規模分散Webサイトの構築方法を段階的に学習します

この記事は、大規模な分散 Web サイト アーキテクチャの学習に関する技術的な概要です。高性能、高可用性、スケーラビリティ、拡張性に優れた分散 Web サイトの構築について概要を説明し、アーキテクチャのリファレンスを提供します。

記事の一部は読書メモであり、一部は個人的な経験の要約であり、大規模な分散型 Web サイト アーキテクチャの参考価値が高いです。

大規模分散型ウェブサイトアーキテクチャ技術

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

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

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

大規模 Web サイトのアーキテクチャ上の目標は次のとおりです。

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

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

上の図は、大規模な Web サイトのアーキテクチャ モデルを示しています。

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

高性能アーキテクチャ

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

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

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

高可用性アーキテクチャ

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

可用性をどのように向上させるかは、早急に取り組む必要がある問題です。まず、アーキテクチャレベルから検討し、計画時に可用性を考慮する必要があります。

業界では一般的に、可用性の指標を表すために複数の 9 が使用されます。たとえば、4 つの 9 (99.99) は、1 年間に許容される非可用性時間が 53 分であることを意味します。

異なるレイヤーでは異なる戦略が使用されます。一般的に、高可用性の問題を解決するには、冗長バックアップとフェイルオーバーが使用されます。

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

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

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

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

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

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

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

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

既知の問題に対する効果的な解決策を用意し、未知または潜在的な問題に対する発見および防御メカニズムを確立します。セキュリティの問題に関しては、まずセキュリティ意識を高め、ポリシーレベルと組織レベルで保護を提供するための効果的なセキュリティメカニズムを確立する必要があります。

たとえば、サーバーのパスワードは漏洩してはならず、パスワードは毎月更新する必要があり、3 回以内に同じパスワードを繰り返すことはできません。毎週のセキュリティスキャンなど

制度化された形での安全保障体制の構築を強化する。同時に、安全に関するあらゆる側面に注意を払う必要があります。

インフラストラクチャ セキュリティ、アプリケーション システム セキュリティ、データ機密性セキュリティなど、セキュリティの問題は無視できません。

• インフラストラクチャ セキュリティ: ハードウェア調達、オペレーティング システム、ネットワーク環境のセキュリティ。一般的には、正規のチャネルを通じて高品質の製品を購入し、安全なオペレーティング システムを選択し、脆弱性を適時に修正し、ウイルス対策ソフトウェアとファイアウォールをインストールします。

ウイルスやバックドアを防止します。ファイアウォール ポリシーを設定し、DDOS 防御システムを確立し、攻撃検出システムを使用し、サブネットの分離を実行します。

• アプリケーション システムのセキュリティ: プログラムを開発するときは、正しい方法を使用して、コード レベルで既知の一般的な問題を解決します。

クロスサイト スクリプティング攻撃 (XSS)、インジェクション攻撃、クロスサイト リクエスト フォージェリ (CSRF)、エラー メッセージ、HTML コメント、ファイルのアップロード、パス トラバーサルなどを防ぎます。

また、Web アプリケーション ファイアウォール (ModSecurity など) を使用して、セキュリティ脆弱性スキャンやその他の対策を実行し、アプリケーション レベルのセキュリティを強化することもできます。

• データの機密性とセキュリティ: ストレージ セキュリティ (信頼性の高い機器への保存、リアルタイムの定期バックアップ)、保存セキュリティ (重要な情報の暗号化された保存、複雑な保存と検出のための適切な人員の選択など)、送信セキュリティ (データの盗難とデータの改ざんの防止)。

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

敏捷性

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

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

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

上記では 7 層の論理アーキテクチャを採用しています。

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

（実際の使用では、オフラインデータとリアルタイムデータは、ビジネス要件に応じて分類および処理され、アプリケーション層またはサービス層で使用するために異なるデータベースに保存されます）

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

成熟した大規模ウェブサイト（Taobao、Tmall、Tencent など）のシステム アーキテクチャは、最初から完全な高性能、高可用性、高スケーラビリティなどの機能を考慮して設計されたわけではありません。利用者数の増加や業務機能の拡大とともに、徐々に進化・改善されていきました。

このプロセスの中で、開発モデル、技術アーキテクチャ、設計アイデアは大きく変化しました。技術スタッフも、数人から部門、さらには製品ラインにまで成長しました。

したがって、成熟したシステム アーキテクチャは、ビジネスの拡大に合わせて徐々に改善されるものであり、一夜にして達成できるものではありません。ビジネス特性の異なるシステムには、それぞれ独自の焦点が置かれます。

たとえば、Taobao では膨大な量の商品情報の検索、注文、支払いを解決する必要があります。テンセントは数億人のユーザーに対するリアルタイムのメッセージ伝送の問題を解決する必要があります。 Baidu は膨大な量の検索リクエストを処理する必要があります。

それぞれに独自のビジネス特性と異なるシステム アーキテクチャがあります。それにもかかわらず、これらのさまざまな Web サイトのコンテキスト間で共通のテクノロジーを見つけることもできます。

これらの技術と方法は、大規模な Web サイト システムのアーキテクチャで広く使用されています。以下では、大規模Webサイトのシステムの進化の過程を紹介しながら、これらの技術や手法について紹介します。

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

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

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

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

キャッシュでウェブサイトのパフォーマンスを向上させる

ハードウェアを通じてパフォーマンスを最適化すると同時に、ソフトウェアを通じてパフォーマンスも最適化します。ほとんどの Web サイト システムでは、システム パフォーマンスを向上させるためにキャッシュ テクノロジが使用されています。

キャッシュが使用される主な理由は、ホット データの存在です。ほとんどの Web サイト訪問は 28 の原則に従います (つまり、アクセス要求の 80% は最終的にデータの 20% に該当します)。そのため、ホット データをキャッシュしてこのデータへのアクセス パスを減らし、ユーザー エクスペリエンスを向上させることができます。

キャッシュを実装する一般的な方法は、ローカル キャッシュと分散キャッシュです。もちろんCDNやリバースプロキシなどもございます。

ローカル キャッシュは、その名前が示すように、アプリケーション サーバー上でデータをローカルにキャッシュします。メモリまたはファイルに保存できます。 OSCache はよく使用されるローカル キャッシュ コンポーネントです。

ローカルキャッシュの特徴は高速であることです。しかし、ローカルスペースが限られているため、キャッシュされるデータの量も限られています。

分散キャッシュの特徴は、膨大な量のデータをキャッシュでき、拡張が非常に簡単なことです。ポータルサイトでよく使われます。理論上、その速度はローカル キャッシュほど速くはありません。一般的に使用される分散キャッシュは Memcached と Redis です。

クラスタリングを使用したアプリケーション サーバーのパフォーマンスの向上

ウェブサイトへの入り口として、アプリケーション サーバーは大量のリクエストを処理します。多くの場合、アプリケーション サーバー クラスターを通じてリクエストの数を共有します。

負荷分散サーバーは、アプリケーション サーバーの前に配置され、ユーザー要求をスケジュールし、分散戦略に従って複数のアプリケーション サーバー ノードに要求を分散します。

一般的に使用される負荷分散技術のハードウェアには、比較的高価な F5 が含まれ、ソフトウェアには LVS、Nginx、HAProxy が含まれます。

LVS は 4 層の負荷分散であり、ターゲット アドレスとポートに基づいて内部サーバーを選択します。 Nginx と HAProxy は 7 層の負荷分散であり、メッセージの内容に基づいて内部サーバーを選択できます。

したがって、LVS 配布パスは Nginx や HAProxy よりも優れており、パフォーマンスも高くなります。一方、Nginx と HAProxy は、動的および静的な分離 (リクエスト メッセージの特性に基づいて静的リソース サーバーまたはアプリケーション サーバーを選択する) に使用されるなど、より構成可能です。

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

ユーザー数が増えると、データベースが最大のボトルネックになります。データベースのパフォーマンスを向上させる一般的な方法は、読み取りと書き込みの分離を実行し、データベースとテーブルを分割することです。読み取り書き込み分離は、その名の通り、データベースを読み取りデータベースと書き込みデータベースに分割し、マスタースレーブ機能を通じてデータの同期を実現します。

データベースとテーブルのシャーディングは、水平シャーディングと垂直シャーディングに分けられます。水平シャーディングは、ユーザー テーブルなどのデータベース内の特に大きなテーブルを分割するプロセスです。

垂直セグメンテーションは、ユーザービジネスと製品ビジネスに関連するテーブルを異なるデータベースに配置するなど、異なるビジネスに基づいています。

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

サーバーがすべて成都のコンピューター室に配備されている場合、四川省のユーザーのアクセスは速くなりますが、北京のユーザーのアクセスは遅くなります。

これは、四川省と北京市がそれぞれ中国電信と中国聯通の異なる開発地域に属しているためです。北京のユーザーは、成都のサーバーにアクセスするために相互接続ルーターを経由するより長い経路を経由する必要があり、戻り経路も同じであるため、データの転送時間は比較的長くなります。

この場合、問題を解決するために CDN がよく使用されます。 CDN はデータ コンテンツをオペレーターのコンピューター ルームにキャッシュします。ユーザーがデータにアクセスすると、まず最も近いオペレータからデータを取得するため、ネットワーク アクセス パスが大幅に短縮されます。よりプロフェッショナルな CDN オペレーターとしては、ChinaCache や Wangsu などがあります。

リバース プロキシは、Web サイトのコンピューター ルームに展開されます。ユーザー リクエストが到着すると、まずリバース プロキシ サーバーにアクセスし、キャッシュされたデータをユーザーに返します。

キャッシュされたデータがない場合、アプリケーション サーバーは引き続きデータを取得するためにアクセスされるため、データ取得のコストが削減されます。リバースプロキシには Squid や Nginx などがあります。

分散ファイルシステムの使用

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

NoSQLと検索エンジンの使用

膨大なデータのクエリと分析には、NoSQL データベースと検索エンジンを使用して、より優れたパフォーマンスを実現します。すべてのデータをリレーショナル データベースに保存する必要はありません。

一般的に使用される NoSQL には MongoDB、HBase、Redis などがあり、検索エンジンには Lucene、Solr、Elasticsearch などがあります。

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

ビジネスがさらに拡大するにつれて、アプリケーションは非常に肥大化します。このとき、Baidu がニュース、Web ページ、画像などのビジネスに分割されているように、アプリケーションをビジネスに分割する必要があります。

各ビジネス アプリケーションは、比較的独立したビジネス操作を担当します。企業はメッセージを通じて、またはデータベースを共有することでコミュニケーションをとります。

分散サービスの構築

この時点で、各ビジネス アプリケーションは、ユーザー サービス、注文サービス、支払いサービス、セキュリティ サービスなどのいくつかの基本的なビジネス サービスを使用することが分かりました。これらのサービスは、各ビジネス アプリケーションをサポートする基本要素です。

これらのサービスを抽出し、ステップバイステップのサービス フレームワークを使用して分散サービスを構築します。 AlibabaのDubboは良い選択です。

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

大規模電子商取引ウェブサイトのアーキテクチャ事例

電子商取引ケースを使用する理由

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

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

大規模なポータルには通常ニュース情報が含まれており、CDN、静的化、その他の方法を使用して最適化できます。 Kaixin.com やその他のポータルはよりインタラクティブであり、より多くの NoSQL や分散キャッシュを導入し、高性能な通信フレームワークを使用する可能性があります。

電子商取引ウェブサイトには、上記 2 つのカテゴリの特徴があります。たとえば、製品の詳細には CDN を使用できますが、静的であり、高いインタラクティブ性には NoSQL などのテクノロジの使用が必要です。そこで、私たちは分析のケースとして電子商取引のウェブサイトを使用します。

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

顧客のニーズ:

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

顧客は顧客です。彼らは具体的に何が欲しいのかは言わないけれど、欲しいものだけは伝えます。顧客のニーズを導き、探求しなければならないことがよくあります。幸いなことに、明確な参考ウェブサイトが提供されています。

したがって、次のステップは、業界と参考ウェブサイトを組み合わせて多くの分析を行い、顧客にソリューションを提供することです。

要件機能マトリックス

これは、ユースケース図またはモジュール図 (要件リスト) を使用して要件を記述する、要件管理に対する従来のアプローチです。

そうすると、非常に重要な要件（非機能要件）が見落とされてしまうことが多いため、要件を記述するには要件機能マトリックスを使用することをお勧めします。

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

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

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

これはここ数年間のより伝統的な慣習でした。会員数が 10 万人を超え、垂直的な衣服デザインポータルと大量の写真が掲載されている Web サイトを見たことがあります。

アプリケーション、データベース、およびイメージ ストレージを展開するためにサーバーが使用されました。次に示すように、パフォーマンスの問題が多数あります。

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

少なくとも次のようになります:

クラスターを使用してアプリケーション サーバーに冗長性を提供し、高可用性を実現します。 （負荷分散デバイスはアプリケーションと一緒に導入できます）

データのバックアップと高可用性を実現するには、データベース マスター/スレーブ モードを使用します。

システム容量の推定

推定手順:

• 登録ユーザー数 - 平均日次 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、ハードディスク、ネットワークなどはここでは評価されなくなりました。

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

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

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

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

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

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

事業分割

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

ビジネス サブシステムに応じて、レベル定義は次のように分けられます。

• コアシステム、製品サブシステム、ショッピングサブシステム、支払いサブシステム。
• 非コアシステム: コメントサブシステム、顧客サービスサブシステム、およびインターフェースサブシステム。

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

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

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

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

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

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

分散展開: ビジネスを分割した後にアプリケーションを個別に展開し、アプリケーションは RPC を介して直接リモートで通信します。

クラスターの展開: 電子商取引 Web サイトの高可用性要件を満たすには、クラスター展開のために各アプリケーションを少なくとも 2 台のサーバーに展開する必要があります。

負荷分散: 高可用性システムには必須です。一般的なアプリケーションは負荷分散によって高可用性を実現し、分散サービスは組み込みの負荷分散によって高可用性を実現し、リレーショナル データベースはマスター/スレーブ モードによって高可用性を実現します。

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

マルチレベルキャッシュ

キャッシュは一般に、保存場所に応じて、ローカル キャッシュと分散キャッシュの 2 つのカテゴリに分類されます。このケースでは、二次キャッシュ方式を使用してキャッシュを設計します。

第 1 レベル キャッシュはローカル キャッシュであり、第 2 レベル キャッシュは分散キャッシュです。 （ページキャッシュ、フラグメントキャッシュなど、より細かい区分もあります）

第 1 レベルのキャッシュは、データ ディクショナリ、よく使用されるホット データ、およびその他の基本的に不変/定期的に変更される情報をキャッシュし、第 2 レベルのキャッシュは必要なすべてのキャッシュをキャッシュします。

第 1 レベル キャッシュの有効期限が切れているか使用できない場合は、第 2 レベル キャッシュのデータにアクセスします。第 2 レベル キャッシュが利用できない場合は、データベースにアクセスします。

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

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

• 自動キャッシュ有効期限
• キャッシュトリガーの有効期限

シングル サインオン (分散セッション)

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

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

プロセスは上記のように説明されています:

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

Cache ミドルウェアと組み合わせると、分散セッションはセッションを非常にうまくシミュレートできます。

データベース クラスター (読み取りと書き込みの分離、データベースとテーブルの分離)

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

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

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

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

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

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

サービス指向

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

メッセージキュー

メッセージ キューは、サブシステム/モジュール間の結合を解決し、非同期、高可用性、高性能のシステムを実現します。これは分散システムの標準機能です。

この場合、メッセージキューは主にショッピングと配信で使用されます。

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

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

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

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

アーキテクチャの概要

大規模なWebサイトのアーキテクチャは、ビジネスのニーズに応じて常に改善されており、さまざまなビジネス特性に基づいて特定の設計と考慮事項が行われます。

この記事では、通常の大規模なWebサイトに関係するテクノロジーと方法の一部のみについて説明しています。すべての人にインスピレーションを与えることができることを願っています。

著者：Rotten Pigskin

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