サーバー側における高並列分散アーキテクチャの進化

[[277797]]

1. 概要

この記事では、Taobao を例に、同時ユーザー数 100 人から 1,000 万人までのサーバー側アーキテクチャの進化を紹介します。また、各進化段階で遭遇する関連テクノロジもリストし、アーキテクチャの進化を誰もが総合的に理解できるようにします。最後に、この記事ではアーキテクチャ設計のいくつかの原則をまとめます。

2. 基本概念

アーキテクチャを紹介する前に、読者がアーキテクチャ設計の概念を理解できないことを避けるために、いくつかの基本的な概念を次に紹介します。

分散した

システム内の複数のモジュールが異なるサーバーに展開されており、これを分散システムと呼びます。たとえば、Tomcat とデータベースを別のサーバーにデプロイしたり、同じ機能を持つ 2 つの Tomcat を別のサーバーにデプロイしたりします。

高可用性

システム内の一部のノードに障害が発生した場合、他のノードが引き継いでサービスの提供を継続できるため、システムは高可用性を備えているとみなされます。

クラスタ

特定分野のソフトウェアを複数のサーバーに展開し、全体としてある種のサービスを提供します。この全体をクラスターと呼びます。たとえば、Zookeeper のマスターとスレーブはそれぞれ複数のサーバーに展開され、全体として集中化された構成サービスを提供します。一般的なクラスターでは、クライアントはサービスを取得するために任意のノードに接続できることが多く、クラスター内のノードがオフラインになった場合、他のノードが自動的に引き継いでサービスを提供し続けることができるため、クラスターの可用性が高くなります。

負荷分散

リクエストがシステムに送信されると、システム内の各ノードがリクエストの負荷を均等に処理できるように、リクエストは何らかの方法で複数のノードに均等に分散されます。システムは負荷分散されていると考えられます。

フォワードプロキシとリバースプロキシ

システムが外部ネットワークにアクセスする必要がある場合、要求はプロキシ サーバーを介して転送されます。外部ネットワークへのアクセスはプロキシ サーバーによって開始されます。このとき、プロキシ サーバーはフォワード プロキシを実装します。外部からのリクエストがシステムに入ると、プロキシ サーバーはそのリクエストをシステム内のサーバーに転送します。外部リクエストの場合、それと対話する唯一のサーバーはプロキシ サーバーです。このとき、プロキシ サーバーはリバース プロキシを実装します。簡単に言えば、フォワード プロキシとは、内部システムではなくプロキシ サーバーを使用して外部ネットワークにアクセスするプロセスであり、リバース プロキシとは、システムにアクセスするための外部要求をプロキシ サーバーを介して内部サーバーに転送するプロセスです。

3. アーキテクチャの進化

3.1 単一マシンアーキテクチャ

淘宝網を例に挙げてみましょう。ウェブサイトの初期段階では、アプリケーションとユーザーの数が少ないため、Tomcat とデータベースを同じサーバーに展開できます。ブラウザが www.taobao.com へのリクエストを開始すると、まずドメイン名が DNS サーバー (ドメイン ネーム システム) を通じて実際の IP アドレス 10.102.4.1 に変換され、ブラウザはその IP に対応する Tomcat にアクセスします。

ユーザー数が増えると、Tomcat とデータベースがリソースを競合し、単一のマシンのパフォーマンスではビジネスをサポートするのに不十分になります。

3.2 最初の進化: Tomcatとデータベースは別々に展開される

Tomcat とデータベースはそれぞれサーバー リソースを排他的に占有するため、それぞれのパフォーマンスが大幅に向上します。

ユーザー数が増えると、データベースの同時読み取りと書き込みがボトルネックになる

3.3 第2の進化: ローカルキャッシュと分散キャッシュの導入

Tomcat と同じサーバーまたは同じ JVM にローカル キャッシュを追加し、外部に分散キャッシュを追加して、人気商品の情報や人気商品の HTML ページなどをキャッシュします。キャッシュにより、ほとんどのリクエストはデータベースの読み取りと書き込みの前に傍受できるため、データベースの負荷が大幅に軽減されます。関連するテクノロジには、memcached をローカル キャッシュとして使用すること、Redis を分散キャッシュとして使用すること、さらにキャッシュの一貫性、キャッシュの侵入/破壊、キャッシュのなだれ、ホット データの集中障害などの問題が含まれます。

キャッシュはほとんどのアクセス要求に耐えます。ユーザー数が増えると、同時実行の圧力は主に単一マシンの Tomcat にかかり、応答が徐々に遅くなります。

3.4 第3の進化: 負荷分散を実現するためのリバースプロキシの導入

Tomcat を複数のサーバーに展開し、リバース プロキシ ソフトウェア (Nginx) を使用して各 Tomcat にリクエストを均等に分散します。ここでは、Tomcat が最大 100 件の同時リクエストをサポートし、Nginx が最大 50,000 件の同時リクエストをサポートしていると想定します。理論上、Nginx がリクエストを 500 台の Tomcat に分散すると、50,000 件の同時リクエストを処理できます。関連するテクノロジには、Nginx と HAProxy が含まれます。これらはどちらも、ネットワークの第 7 層で動作するリバース プロキシ ソフトウェアであり、主に http プロトコルをサポートし、セッション共有やファイルのアップロードとダウンロードの問題にも関係します。

リバース プロキシにより、アプリケーション サーバーがサポートできる同時実行性が大幅に向上しますが、同時実行性が向上するということは、より多くの要求がデータベースに侵入することを意味し、最終的には単一マシンのデータベースがボトルネックになります。

3.5 第4の進化: データベースの読み書き分離

データベースは読み取りデータベースと書き込みデータベースに分かれています。読み取りデータベースは複数存在する場合があります。書き込みデータベース内のデータは、同期メカニズムを通じて読み取りデータベースに同期されます。最新の書き込まれたデータを照会する必要があるシナリオでは、追加のコピーをキャッシュに書き込むことができ、最新のデータはキャッシュを通じて取得できます。関連するテクノロジには、データベースの個別の読み取りと書き込み、およびサブライブラリとテーブルの分割を整理するために使用できるデータベース ミドルウェアである Mycat が含まれます。クライアントはこれを使用して基盤となるデータベースにアクセスしますが、データの同期とデータの一貫性の問題も発生します。

事業所の数が増えると、事業所間の訪問回数は大きく変わります。さまざまなビジネスがデータベースと直接競合し、お互いのパフォーマンスに影響を与えます。

3.6 第5の進化: 業務別のデータベース分割

異なる企業のデータを異なるデータベースに保存すると、企業間のリソースの競争を軽減できます。トラフィック量の多い企業の場合は、サポートのためにさらに多くのサーバーを導入できます。これにより、クロスビジネステーブルで直接関連分析を実行することも不可能になり、他のソリューションが必要になります。しかし、これはこの記事の焦点では​​ありません。興味のある人は自分で解決策を探すことができます。

ユーザー数が増えると、単一マシンのデータベース書き込みは徐々にパフォーマンスのボトルネックに達します。

3.7 第 6 の進化: 大きなテーブルを小さなテーブルに分割する

たとえば、コメント データの場合は、製品 ID に従ってハッシュし、対応するテーブルにルーティングして保存できます。支払い記録の場合、時間ごとにテーブルを作成し、各時間ごとのテーブルをさらに小さなテーブルに分割し、ユーザー ID またはレコード番号を使用してデータをルーティングできます。リアルタイムで操作されるテーブル内のデータ量が十分に小さく、リクエストが複数のサーバー上の小さなテーブルに十分に均等に分散される限り、データベースは水平拡張によってパフォーマンスを向上させることができます。前述の Mycat は、大きなテーブルを小さなテーブルに分割する場合のアクセス制御もサポートしています。

このアプローチにより、データベースの運用と保守の難易度が大幅に高まり、DBA に高い要求が課せられます。データベースがこの構造に設計されている場合、分散データベースと呼ぶことができますが、これは全体として論理的なデータベースにすぎません。データベース内のさまざまなコンポーネントは、さまざまなコンポーネントによって個別に実装されます。たとえば、サブライブラリとサブテーブルの管理、およびリクエストの分散は Mycat によって実装され、SQL 解析はスタンドアロン データベースによって実装されます。読み取りと書き込みの分離はゲートウェイとメッセージ キューによって実装され、クエリ結果の集約はデータベース インターフェイス層などによって実装される場合があります。このアーキテクチャは、実際には MPP (大規模並列処理) アーキテクチャの実装の一種です。

現在、オープンソースと商用の両方で多くの MPP データベースが存在します。より人気のあるオープンソースのものには、Greenplum、TiDB、Postgresql XC、HAWQ などがあります。商用のものには、南京大学総合研究所の GBase、Ruifan Technology の Snowball DB、Huawei の Libra などがあります。異なる MPP データベースには異なる重点があります。たとえば、TiDB は分散 OLTP シナリオに重点を置いており、Greenplum は分散 OLAP シナリオに重点を置いています。これらの MPP データベースは基本的に、Postgresql、Oracle、MySQL と同様の SQL 標準サポート機能を提供します。クエリを分散実行プランに解析し、各マシンに配布して並列実行することができます。最後に、データベース自体がデータを要約して返します。また、権限管理、サブライブラリとテーブルのシャーディング、トランザクション、データのコピーなどの機能も提供しており、そのほとんどは 100 ノードを超えるクラスターをサポートできるため、データベースの運用と保守のコストを大幅に削減し、データベースを水平に拡張できます。

データベースと Tomcat の両方を水平方向に拡張でき、サポートされる同時実行性が大幅に向上します。ユーザー数が増えると、単一マシンの Nginx は最終的にボトルネックになります。

3.8 第7の進化: LVSまたはF5を使用して複数のNginxサーバーの負荷を分散する

ボトルネックとなっているのはNginxなので、2層のNginxを介して複数のNginxの負荷分散を実現することは不可能です。図の LVS と F5 は、ネットワークの第 4 層で動作する負荷分散ソリューションです。 LVS は、オペレーティング システムのカーネル状態で実行され、TCP 要求または上位レベルのネットワーク プロトコルを転送できるソフトウェアです。したがって、Nginx よりも多くのプロトコルをサポートし、パフォーマンスがはるかに高くなります。単一マシンの LVS は数十万の同時リクエスト転送をサポートできると考えられます。 F5 は、LVS と同様の機能を備え、LVS よりも高いパフォーマンスを備えた負荷分散ハードウェアですが、高価です。 LVS はスタンドアロン ソフトウェアであるため、LVS が配置されているサーバーがダウンすると、バックエンド システム全体にアクセスできなくなるため、バックアップ ノードが必要になります。 keepalived ソフトウェアを使用して仮想 IP をシミュレートし、その仮想 IP を複数の LVS サーバーにバインドすることができます。ブラウザが仮想 IP にアクセスすると、ルータによって実際の LVS サーバーにリダイレクトされます。メインの LVS サーバーがダウンすると、keepalived ソフトウェアはルーターのルーティング テーブルを自動的に更新し、仮想 IP を別の通常の LVS サーバーにリダイレクトして、LVS サーバーの高可用性を実現します。

ここで注意すべき点は、上図の Nginx 層から Tomcat 層への描画は、すべての Nginx がすべての Tomcat にリクエストを転送することを意味するわけではないということです。実際の使用では、いくつかの Tomcat に複数の Nginx が接続される場合があります。これらの Nginx は keepalived を通じて高可用性を実現し、他の Nginx は他の Tomcat に接続します。この方法では、アクセス可能な Tomcat の数を 2 倍に増やすことができます。

LVS もスタンドアロン サーバーであるため、同時ユーザー数が数十万に増加すると、LVS サーバーは最終的にボトルネックに達します。この時点で、ユーザー数は数千万、あるいは数億に達します。ユーザーはさまざまな地域に分散しており、サーバールームからの距離も異なるため、アクセス遅延が大きく異なります。

3.9 第8の進化: DNSポーリングによるコンピュータルームの負荷分散

DNS サーバーでは、1 つのドメイン名を複数の IP アドレスに対応するように構成でき、各 IP アドレスは異なるコンピューター ルームの仮想 IP に対応します。ユーザーが www.taobao.com にアクセスすると、DNS サーバーはポーリング戦略またはその他の戦略を使用して、ユーザーがアクセスする IP を選択します。この方法により、コンピュータ室内の負荷分散を実現できます。この時点で、システムはコンピュータ ルーム レベルで水平拡張を実現できます。数千万から数億の同時実行はコンピュータ室を追加することで解決でき、システム入口でのリクエストの同時実行は問題になりません。

データが豊かになり、ビジネスが発展するにつれて、検索と分析に対する要求はますます多様化します。データベースだけでは、このような多様な要求を満たすことはできません。

3.10 第9の進化: NoSQLデータベースや検索エンジンなどの技術の導入

データベース内のデータが一定の規模に達すると、データベースは複雑なクエリには適さなくなり、通常のクエリのニーズしか満たせなくなります。統計レポートのシナリオでは、データ量が多いと結果を生成できない可能性があり、複雑なクエリを実行すると他のクエリの速度が低下します。全文検索や可変データ構造などのシナリオでは、データベースは本質的に適していません。したがって、特定のシナリオに適切なソリューションを導入する必要があります。たとえば、大規模なファイルストレージの場合は、分散ファイルシステム HDFS によって解決できます。キーバリュー型データの場合は、HBase や Redis などのソリューションで解決できます。全文検索のシナリオでは、ElasticSearch などの検索エンジンによって解決できます。多次元分析シナリオの場合、Kylin や Druid などのソリューションで解決できます。

もちろん、コンポーネントを増やすとシステムの複雑さも増します。異なるコンポーネントによって保存されたデータを同期する必要があり、一貫性の問題を考慮する必要があり、これらのコンポーネントを管理するには、より多くの操作および保守方法が必要です。

より多くのコンポーネントを導入することで、さまざまなニーズが解決され、ビジネスの次元が大幅に拡大します。ただし、アプリケーションに含まれるビジネス コードが多すぎるため、ビジネスのアップグレードや反復が困難になります。

3.11 第10の進化: 大きなアプリケーションを小さなアプリケーションに分割する

アプリケーション コードをビジネス セグメントごとに分割して、個々のアプリケーションの責任を明確にし、アプリケーション間で独立したアップグレードと反復処理を可能にします。現時点では、アプリケーション間で共通の構成がいくつか関係している可能性がありますが、これは分散構成センター Zookeeper を通じて解決できます。

異なるアプリケーション間で共有されるモジュールがあります。アプリケーションごとに個別に管理すると、同じコードのコピーが複数存在することになります。つまり、パブリック関数をアップグレードするときに、すべてのアプリケーション コードをアップグレードする必要があります。

3.12 第11の進化: 再利用可能な機能をマイクロサービスに抽出する

例えば、ユーザー管理、注文、支払い、認証などの機能が複数のアプリケーションに存在する場合、これらの機能のコードを個別に抽出して、管理用の別のサービスを形成できます。このようなサービスは、いわゆるマイクロサービスです。アプリケーションとサービスは、HTTP、TCP、RPC リクエストなどのさまざまな方法を通じてパブリック サービスにアクセスします。それぞれのサービスは個別のチームによって管理できます。さらに、Dubbo や SpringCloud などのフレームワークを通じて、サービス ガバナンス、電流制限、回路遮断、ダウングレードなどの機能を実装し、サービスの安定性と可用性を向上させることができます。

サービスによってインターフェース アクセス方法が異なります。サービスを使用するには、アプリケーション コードを複数のアクセス方法に適応させる必要があります。さらに、アプリケーションがサービスにアクセスすると、サービスも相互にアクセスする場合があります。呼び出しチェーンが非常に複雑になり、ロジックがわかりにくくなります。

3.13 第12の進化: サービスインターフェースのアクセスの違いを保護するエンタープライズサービスバス (ESB) の導入

アクセス プロトコルの変換は ESB を通じて一律に実行され、アプリケーションは ESB を通じて一律にバックエンド サービスにアクセスし、サービスは ESB を通じて相互に呼び出すため、システムの結合度が低下します。単一のアプリケーションを複数のアプリケーションに分割し、公開サービスを個別に抽出して管理し、エンタープライズ メッセージ バスを使用してサービス間の結合問題を解決するこのようなアーキテクチャは、いわゆる SOA (サービス指向) アーキテクチャです。このアーキテクチャは、表現が非常に似ているため、マイクロサービス アーキテクチャと混同されやすいです。私の考えでは、マイクロサービス アーキテクチャは、システムからパブリック サービスを抽出して個別に管理するというアイデアを指し、SOA アーキテクチャは、サービスを分割してサービス インターフェイス アクセスを統一するというアーキテクチャのアイデアを指します。 SOA アーキテクチャにはマイクロサービスという考え方が含まれています。

ビジネスが成長し続けると、アプリケーションとサービスが増加し続け、アプリケーションとサービスの展開が複雑になります。同じサーバーに複数のサービスを展開する場合は、オペレーティング環境の競合の問題も解決する必要があります。また、大規模なプロモーションなど動的なスケーリングが必要なシナリオでは、サービスのパフォーマンスを水平展開する必要があり、新しく追加されたサービス上に動作環境を準備してサービスを展開する必要があり、運用と保守が非常に困難になります。

3.14 第13の進化: 運用環境の分離と動的サービス管理を実装するためのコンテナ化技術の導入

現在、最も人気のあるコンテナ化技術はDockerであり、最も人気のあるコンテナ管理サービスはKubernetes（K8S）です。アプリケーション/サービスは Docker イメージとしてパッケージ化でき、そのイメージは K8S を通じて動的に配布およびデプロイできます。 Docker イメージは、アプリケーション/サービスを実行できる最小限のオペレーティング システムとして理解できます。アプリケーション/サービスの実行コードが含まれており、実行環境は実際のニーズに応じて設定されます。 「オペレーティング システム」全体をイメージにパッケージ化した後、関連するサービスを展開する必要があるマシンに配布できます。 Docker イメージを起動するだけで直接サービスを開始できるため、サービスの導入や運用・保守が簡単になります。

大規模なプロモーションの前に、既存のマシン クラスター上のサーバーを分割して Docker イメージを起動し、サービスのパフォーマンスを向上させることができます。大規模なプロモーションの後、マシン上の他のサービスに影響を与えずにイメージをシャットダウンできます (セクション 3.14 より前は、新しく追加されたマシンで実行されているサービスは、サービスに適応するためにシステム構成を変更する必要があり、その結果、マシン上の他のサービスに必要な動作環境が破壊されます)。

コンテナ化技術の活用により、サービスの動的な拡張と縮小の問題は解決されましたが、マシンは依然として企業自身が管理する必要があります。プロモーション期間以外でも、プロモーションに対応するために大量のマシン リソースをアイドル状態にしておく必要があります。機械自体のコストや運用・保守コストが非常に高く、リソースの利用率が低い。

3.15 第14の進化: ホストシステムとしてのクラウドプラットフォーム

このシステムはパブリック クラウド上に展開でき、パブリック クラウドの膨大なマシン リソースを活用して、動的なハードウェア リソースの問題を解決できます。プロモーション期間中は、クラウドプラットフォームに一時的にさらに多くのリソースを申請することができ、DockerとK8Sを組み合わせることで迅速にサービスを展開することができます。プロモーション終了後はリソースを解放できるため、真のオンデマンド支払いが可能になり、リソースの利用率が大幅に向上し、運用および保守コストが削減されます。

いわゆるクラウド プラットフォームは、統合リソース管理を通じて大量のマシン リソースをリソース エンティティに抽象化し、その上でハードウェア リソース (CPU、メモリ、ネットワークなど) をオンデマンドで動的に適用し、汎用オペレーティング システムと共通技術コンポーネント (Hadoop テクノロジー スタック、MPP データベースなど) をユーザーに提供します。開発されたアプリケーションも提供します。ユーザーは、自分のニーズを満たすためにアプリケーション内でどのようなテクノロジが使用されているか（オーディオおよびビデオのトランスコーディング サービス、電子メール サービス、個人のブログなど）を気にする必要がありません。クラウド プラットフォームには次の概念が関係しています。

IaaS: サービスとしてのインフラストラクチャ。上記のマシンリソースがリソース全体として統合されているため、ハードウェアリソースのレベルを動的に適用できます。

PaaS: サービスとしてのプラットフォーム。上記に対応して、システムの開発と保守を容易にするための共通の技術コンポーネントが提供されます。

SaaS: サービスとしてのソフトウェア。上記の開発されたアプリケーションまたはサービスの提供に応じて、機能またはパフォーマンスの要件に基づいて支払いが行われます。

これまでのところ、上記の高同時アクセス問題、サービス アーキテクチャ、およびシステム実装にはそれぞれ独自の解決策がありますが、上記の紹介では、コンピューター ルーム間のデータ同期や分散トランザクションの実装などの実際的な問題を意図的に無視していることにも注意する必要があります。これらの問題については今後別途議論される予定です。

4. アーキテクチャ設計の概要

アーキテクチャの調整は上記の進化の道筋に従う必要がありますか?

いいえ、上記のアーキテクチャの進化シーケンスは、特定の側面に対する個別の改善にすぎません。実際のシナリオでは、同時に解決する必要がある問題が複数存在する場合や、別の側面が最初にボトルネックになる場合もあります。このとき、実際の状況に応じて問題を解決する必要があります。たとえば、政府のシナリオでは、同時実行性は大きくないかもしれませんが、ビジネスは非常に豊富である可能性があります。この場合、高い同時実行性は解決すべき重要な問題ではありません。現時点では、富裕層のニーズへの解決策を優先することになるかもしれません。

実装するシステムに合わせてアーキテクチャをどの程度設計する必要がありますか?

明確なパフォーマンス指標を持つ単一の実装の場合、システムのパフォーマンス指標要件をサポートするようにアーキテクチャを設計するだけで十分ですが、必要に応じてアーキテクチャを拡張するためのインターフェイスを残しておく必要があります。電子商取引プラットフォームなどの継続的に進化するシステムの場合、次の段階のユーザー数とパフォーマンス インデックスの要件を満たすように設計する必要があり、ビジネスの成長に応じてアーキテクチャを継続的に反復およびアップグレードして、より高い同時実行性とより豊富なビジネスをサポートする必要があります。

サーバー側アーキテクチャとビッグデータアーキテクチャの違いは何ですか?

いわゆる「ビッグデータ」は、実際には、大量のデータの収集、クリーニング、変換、データの保存、データ分析、データサービスなどのシナリオソリューションの総称です。各シナリオには、データ収集用の Flume、Sqoop、Kettle など、データ保存用の分散ファイルシステム HDFS、FastDFS、NoSQL データベース HBase、MongoDB など、データ分析用の Spark テクノロジー スタック、機械学習アルゴリズムなど、さまざまなオプション テクノロジーが含まれています。一般的に、ビッグデータ アーキテクチャとは、ビジネス ニーズに応じてさまざまなビッグデータ コンポーネントを統合するアーキテクチャです。一般的には、分散ストレージ、分散コンピューティング、多次元分析、データ ウェアハウス、機械学習アルゴリズムなどの機能を提供します。サーバー側アーキテクチャは、アプリケーション組織レベルのアーキテクチャを指し、基盤となる機能はビッグデータ アーキテクチャによって提供されることがよくあります。

建築設計には原則があるのでしょうか?

N+1デザイン。システム内の各コンポーネントには単一障害点が存在しない必要があります。

ロールバック設計。システムに前方互換性があり、システムがアップグレードされたときにバージョンをロールバックする方法があることを確認します。

デザインを無効にします。特定の機能が使用可能かどうかを制御する構成を提供し、システム障害が発生したときに機能を迅速にシャットダウンできるようにする必要があります。

監視設計。監視手段は設計段階で検討する必要があります。

マルチアクティブデータセンター設計。システムに極めて高い可用性が必要な場合は、少なくとも 1 つのコンピュータ ルームで電源が失われた場合でもシステムが引き続き利用できるように、複数の場所にデータ センターを実装することを検討してください。

実績のあるテクノロジーを使用します。新しく開発された技術やオープンソース技術には多くの隠れたバグが存在することが多く、問題が発生しても商用サポートがなければ大惨事になる可能性があります。

リソース分離設計。単一の事業体がすべてのリソースを占有することを避けます。

アーキテクチャは水平方向に拡張できる必要があります。システムを水平方向に拡張できる場合にのみ、ボトルネックの問題を効果的に回避できます。

コアではないものを購入してください。非コア機能の解決に多くの研究開発リソースが必要な場合は、成熟した製品の購入を検討してください。

市販のハードウェアを使用します。市販のハードウェアはハードウェア障害の可能性を効果的に低減できます。

素早く繰り返します。システムは、小さな機能モジュールを迅速に開発し、できるだけ早く検証のためにオンラインにする必要があります。問題を早期に検出することで、システム提供のリスクを大幅に軽減できます。

ステートレスなデザイン。サービス インターフェイスはステートレスにする必要があり、インターフェイスへの現在のアクセスは、最後にアクセスされたときのインターフェイスの状態に依存しません。