インターネット分散アーキテクチャの進化に関する簡単な説明

[[437209]]

インターネット システムは多くの場合、膨大なユーザー ベースに直面しており、これはシステムが大量の同時実行リクエストや大量のデータ ストレージなどの課題に常に直面する必要があることを意味します。これらの問題を解決しながら、システムの高可用性を確保することも必要です。同時に、インターネット業界は急速に更新と反復を行っています。開発の初期段階では、多くのインターネット大手は、製品をオンラインで迅速にリリースしてユーザートラフィックを占有するために、最も単純なアプリケーションアーキテクチャ形式でシステムを展開し、アプリケーションアーキテクチャの将来の開発についてはあまり考慮しません。そのため、多くのインターネット企業は、ある程度の規模に成長すると、ビジネスの発展に適応するために、それに応じたアーキテクチャの再構築と改善を実施することになります。

私は過去数年間、数人の開発者がいる小さな会社から 10 億人以上のユーザーを抱える会社まで、さまざまな会社で働いてきました。そのため、私はインターネット企業のシステムアプリケーションアーキテクチャの進化について深い洞察を持っています。

シングルポイントアプリケーション

企業の開発の初期段階では、ユーザー数が少なく、システムに対する同時要求が少なく、データ量も少なかったため、ビジネス ニーズを満たすにはアプリケーションを 1 か所に展開するだけで十分であることがよくありました。

上記は、初期のインターネット アプリケーションの典型的なアーキテクチャ モデルです。アプリケーションは単一のサーバーにデプロイするだけでよく、データベースも同じサーバーに配置されます。交通はまっすぐ上下に流れます。

アプリケーションとデータベースが一体型になっているため、フェイルオーバーができないという明らかなデメリットがあります。アプリケーションまたはデータベースのいずれかに障害が発生すると、システム全体が使用できなくなります。

アプリケーションSOA

1. 水平分割

モノリシック アプリケーションにはフェイルオーバーがありません。リクエストの数が増えると、モノリシック アプリケーションの展開ではすべてのリクエストを処理できなくなります。よくある問題としては、アプリケーション接続数がいっぱいになる、ユーザー要求がタイムアウトになる、応答に時間がかかる、などが挙げられます。

上図に示すように、システムは水平に分割され、複数のアプリケーション インスタンスが展開されます。同時に、ゲートウェイはトラフィックを均等に分散し、単一のアプリケーションの要求圧力を効果的に軽減します。同時に、アプリケーション サービスにはフェイルオーバーが存在します。サービスに障害が発生した場合でも、複数のアプリケーション インスタンスが維持されている限り、システムは動作可能です (ダウングレード処理も考慮する必要があります)。

これはアプリケーション SOA の初期段階です。

2. 垂直分割

当社の事業は急速に発展しており、事業規模もますます大きくなっています。 1 つのアプリケーションですべてのビジネスが実行され、すべてのビジネス コードが同じコード リポジトリに配置されます。これは導入が簡単で、運用および保守コストも低いですが、欠点は非常に明白です。事業規模が大きくなるにつれて、プロジェクトのコードは飛躍的に増加し、事業はますます複雑になり、結合度はますます高くなります。さらに、コード量が増えるにつれてスケーラビリティがどんどん悪化し、リリース サイクル ウィンドウがどんどん長くなり、迅速な反復と迅速なリリースを実現できなくなります。

上記の問題を解決するために、ビジネス次元に応じてシステムを垂直に分割することができます。例えば、モールシステムは、上図に示すように、ユーザーサービス、トランザクションサービス、注文サービスなどに分割できます。

この時点で、システムは水平方向と垂直方向に分割され、アプリケーション層は基本的に SOA が完成しています。

ストレージ分割

1. ストレージの読み取りと書き込みの分離

ビジネスが発展するにつれて、アプリケーション サービスはもはや負担ではなくなり、データ層がシステム全体の唯一の単一ポイントになっていることがわかります。このとき、システム TPS の増加に伴い、デプロイされるアプリケーション インスタンスの数が増え、単一のデータベースへの接続数が増加し、データの書き込み効率が低下し、単一のマスター データベースではシステム全体のデータの読み取りと書き込みを維持できなくなります。

このとき、データ層は読み取りと書き込みに分離され、データベースはマスター データベースと複数のスレーブ データベースに分割されます。マスター データベースは引き続きデータの書き込みを担当し、スレーブ データベースはデータの読み取りを担当します。これにより、データ書き込みの負担が大幅に軽減されます。ただし、読み取りと書き込みの分離は、読み取りと書き込みが厳密に同期されないことを意味します。マスター データベースがスレーブ データベースとデータを同期するには一定の時間がかかりますが、ほとんどのデータ遅延は許容範囲内です。

2. ストレージ垂直分割

データの読み取りと書き込みが分離されると、データ書き込みの負担がある程度軽減されます。しかし、システム全体でマスターデータベースは 1 つしか存在せず、各業務ドメインのデータ書き込みはこのマスターデータベースに大きく依存していることがわかりました。トラフィックが増加すると、単一のマスター データベースではまったく処理できなくなります。

アプリケーションの垂直分割と同様に、ストレージ層の垂直分割もビジネスディメンションに応じて分割され、複数のライブラリに分割されます。たとえば、モールシステムは、ユーザーライブラリ、注文ライブラリなどに分割できます。上の図からわかるように、データ書き込みトラフィックについては、各ビジネスドメインが独自のデータの読み取りと書き込みを担当します。

この時点で、基本的に完全な分散アプリケーション アーキテクチャが形成されており、次にデータベース分割に関連する分散トランザクションの問題を解決します。

3. ストレージ水平分割

ビジネスが一定規模にまで発展すると、単一のデータベースと単一のテーブルでは、各ビジネスドメインのデータの読み取りと書き込みに耐えられなくなります。では私たちは何をすべきでしょうか?

このとき、ユーザーディメンションに応じてデータを水平に分割できます。たとえば、ユーザー ID の最後の 2 桁に応じて大きなテーブルを 100 個の小さなテーブルに分割し、100 個の新しいデータベースを作成できます (もちろん、データベースの数はテーブルの数より少なくなる場合があります)。データベースとテーブルを分割するこのルールを、100 データベース - 100 テーブル モデルと呼ぶことができます。

サブライブラリとテーブルを使用すると、単一のテーブル内のデータ量を効果的に削減できるほか、ユーザーのディメンションに応じてさまざまなライブラリとテーブルにトラフィックを分散できるため、総合的にパフォーマンスが向上します。

この時点で、完全な分散アーキテクチャが形成されました。実際、これは多くの大手インターネット企業の現在の展開アーキテクチャの状態です。

ユニット化された展開

ビジネスのさらなる発展に伴い、10億人を超えるユーザーを抱える一部の巨大企業では、アプリケーションインスタンスの展開規模が非常に大きくなり、データベース接続数が不足するという問題が発生します。上の図から、アプリケーション インスタンスの数が増えると、データベース リンクの数も増えることがわかります。

なぜ？

各データベース インスタンスはアプリケーション インスタンスによって共有されるため、なぜ共有する必要があるのか​​疑問に思うかもしれません。これは、ゲートウェイ トラフィックが均等に分散されるためです。各リクエストは、任意のアプリケーション インスタンスに該当する可能性があります。この場合、アプリケーション インスタンスは、ユーザー ID に基づいて指定されたテーブルにデータを配置する必要があります。現時点では、これを実行するには、アプリケーション インスタンスがすべてのデータベースに接続している必要があります。

10 億人を超えるユーザーがいるシステムの場合、トラフィックはすでに非常に高くなっています。サービスを水平方向に拡張することは非常に困難です。サービスはデータベース接続の上限に達し、それ以上水平方向に拡張できなくなる可能性があります。

それで何をすべきでしょうか?

データはユーザーディメンションに従ってデータベースとテーブルに分割できるのに、要求されたトラフィックをユーザーディメンションに従って水平に分割できないのはなぜでしょうか?

アプリケーション インスタンスをユーザー ディメンションに応じてユニットに分離します。すべてのシステム サービスは各ユニットに展開され、次の図に示すように、ユーザーはユニット内ですべてのビジネス プロセスを完了できます。

ユニット分離後、データベース接続数が指数関数的に減少していることがわかります。ユニットの粒度が小さい場合、データベース接続の数はさらに少なくなります。

データの分割

大規模なインターネット企業では、物理的なコンピューター室が複数あることがよくあります。複数のコンピュータ ルームでは、展開モードは主に 2 つのタイプに分けられます。

垂直展開 (拡張モード): システム サービスとデータベースは複数の部分に分割され、各コンピューター ルームにはいくつかのサービスとデータベースがあります。これにより、コンピューター室の容量の問題を解決できます。ただし、ビジネスを完了するには、複数のコンピュータ ルームの連携が必要になる場合があります。コンピュータ室に障害が発生すると、システム全体が使用できなくなり、災害復旧機能が失われます。

水平展開 (ミラー モード): 各コンピュータ ルームにすべてのサービスが備わっており、つまり、各コンピュータ ルームで業務フローを完了でき、災害復旧機能も備えています。

一般的に、ほとんどの企業は 2 番目の水平展開モードを採用します。ただし、このモードでは、データのパーティション分割の問題を解決する必要があります。アプリケーションはステートレスであることはわかっています。各コンピュータ ルームにトラフィックをランダムに分散し、各コンピュータ ルームに一定量のトラフィックを流すことも簡単にできます。しかし、データについては同じことが言えません。各コンピューター室に独立したデータベースがあることを保証するのは非常に困難です。

では、データパーティションの問題をどのように解決すればよいのでしょうか?

ユニットの配置についてはすでに説明しました。ユニットにはシステムのすべてのサービスが含まれているため、論理データセンター (Logical Data Center)、略して LDC と呼ぶことができます。

同様に、水平展開モードでは、物理的なコンピュータ ルームにすべてのサービスが備わり、これを略してインターネット データ センター (IDC) と呼ぶことができます。

つまり、それらの関係は次のようになります。

LDC は IDC の論理的な部門です。

簡単に言うと:

LDC は IDC に基づく論理区分です。 LDC 論理データセンターは「ユニット」と呼ばれます。各ユニットには、展開されたすべてのアプリケーションがあります。各ユニットは、任意の物理的なコンピューター ルームに割り当てることができます。次の図に示すように、各物理コンピューター ルームには複数のユニットを配置できます。

上図に示すように、物理的なコンピュータ ルームの水平展開モードでは、ユニット化によってデータ パーティションの問題がどのように解決されるのでしょうか。

先ほど、ユーザー ディメンションに応じてユニット分離を展開し、データをパーティション分割できることを説明しました。ユーザーの最後の 2 桁でデータを分割するなど、ユーザー ディメンションに従ってデータを分割し、合計 100 個の部分にデータを分割できます。各ユニットはデータの複数のコピーを担当します。たとえば、システムに合計 10 個のユニットがある場合、各ユニットは 10 個のパーティションのデータを担当します。

これにより、各ユニットに独立したデータ パーティションが確保され、データの完全な分離が実現します。

容量を拡張する方法

ユニット化された展開アーキテクチャで容量を拡張するにはどうすればよいですか?

アプリケーションの拡張

システムがユニット化された分離状態で展開されると、通常、データベース接続はボトルネックではなくなります。これは、ユニット化された展開の利点の 1 つです。このとき、ユニット内の各サービスに複数のアプリケーション インスタンスを追加することで、簡単に容量拡張を実現できます。

ユニット拡張

ユニット数を増やし、増加後に各ユニットのトラフィックを再分配します。ただし、単位データを増やすことは、データパーティションが増加することを意味するわけではないことに注意してください。データ層とアプリケーション層の拡張は互いに関係がありません。ただし、ユニット拡張によってデータベース接続の数を効果的に削減できることは注目に値します。各ユニットに接続されたデータ パーティションは、次の図に示すように、ユニットが担当するユーザー ディメンションのトラフィックに応じて区別されます。

ストレージ拡張

ユニットを追加するのは簡単ですが、テーブル ルーティング ルールの変更やデータ移行が必要になるため、元のデータ パーティションの下で容量を拡張するのは簡単ではありません。一般的に、データベースやテーブルをシャーディングする場合は、将来のビジネスの容量要件を事前に見積もって、各ユーザーディメンションを事前にシャーディングしておきます。したがって、データを拡張する必要がある場合は、再度シャーディングする必要があります。これにはデータの移行が関係するため、詳細については説明しません。

この記事はWeChatの公開アカウント「Backend Advanced」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、Backend Advanced Public Account にお問い合わせください。