ついに誰かが分散システムアーキテクチャを明確に説明した

[[430108]]

この記事はWeChatの公開アカウント「Shucang Baobaoku」から転載したもので、著者はXiao YuとBingheです。この記事を転載する場合は、舒倉赤ちゃん図書館公式アカウントまでご連絡ください。

インターネットの継続的な発展に伴い、企業はますます多くのデータを蓄積しています。単一のデータベースに大量のデータを保存できなくなると、複数のサーバー上の複数のデータベースにデータを分散して保存する方法が模索され、徐々に分散データベースが形成されていきます。データが分散的に格納されると、データの追加、削除、変更、クエリなどの操作がより複雑になり、特に分散トランザクションと呼ばれるデータの一貫性を確保することが難しくなります。

この記事では、分散トランザクションの基本的な概念について、以下の内容で紹介します。

分散システム アーキテクチャの原則。

分散システムアーキテクチャの進化。

分散トランザクションのシナリオ。

1. 分散システムアーキテクチャ

インターネットの急速な発展により、従来のモノリシックなシステムアーキテクチャでは、大規模なユーザーのニーズを満たすことができなくなりました。その結果、より多くのインターネット企業が、元のシステムを改造・アップグレードし、ユーザーが生成した大規模なトラフィックを分解し、分割統治し、ユーザーのニーズを満たすために異なるサーバー上でユーザーにサービスを提供するようになりました。徐々に、元のモノリシック システム アーキテクチャは分散システム アーキテクチャへと進化しました。

1. 背景

インターネットの初期の頃は、インターネット企業のビジネスはそれほど複雑ではなく、ユーザーベースも大きくなかったため、一般的には単一のシステム アーキテクチャを使用してビジネスを迅速に実装していました。このとき、システムによって処理されるトラフィック エントリは、主に PC 側から来ます。

ユーザー数の爆​​発的な増加に伴い、トラフィックの入り口は PC に限定されなくなり、モバイル アプリ、H5、WeChat アプレット、自律端末、さまざまな IoT デバイス、Web クローラーからもトラフィックが流入するようになりました。ユーザーや企業のニーズもますます複雑になっています。継続的な反復とアップグレードのプロセスにおいて、モノリシック システムはますます肥大化し、システムの業務はますます複雑になり、保守が困難になることもあります。小さな機能を変更するとシステム全体に変更が及ぶ可能性があるため、システムをオンラインにする前に厳密にテストする必要があります。小さな機能でもシステム全体のリリースが必要となり、システム内の他の業務の安定性と可用性に直接影響を及ぼします。

この時点では、開発効率は低く、システムのアップグレードとメンテナンスのコストは非常に高く、テストサイクルはますます長くなり、コードの競合率はますます高くなります。最も厄介なのは、開発者が退職すると、新しい従業員がシステム全体に慣れるまでに長い時間がかかることです。モノリシックなシステム アーキテクチャでは、高トラフィックおよび高同時実行のシナリオをサポートできなくなりました。

モノリシックなシステムアーキテクチャのさまざまな問題に直面した場合、その解決策は、複雑で肥大化したシステムを水平に分割し、共通業務を他の業務が呼び出すための独立したサービスにカプセル化し、関連業務をサブシステムにカプセル化して他のシステムまたは外部から呼び出すためのインターフェイスを提供することで、コードの結合を減らし、コードの再利用率を高めることです。現時点では、サブシステムは分離されているため、各サブシステムを変更しても他のサブシステムの安定性には影響しません。これにより、システムの保守およびリリースコストが削減され、テスト中にシステム全体を再テストする必要がなくなり、テスト効率が向上します。コードメンテナンスの面では、各サブシステムのコードが個別に管理されるため、コードの競合率が低減し、システムの研究開発効率が向上します。

2. アーキテクチャの目標とアーキテクチャの原則

優れた分散システム アーキテクチャは一夜にして実現されるものではなく、企業やユーザーのニーズに合わせて継続的に反復され、進化していきます。現在の分散システムにおける最も重要な矛盾を解決し、将来の基本的な予測を立てることができるため、システム アーキテクチャは、高い同時実行性、高い可用性、高いスケーラビリティ、高い保守性などの非機能要件を備え、変化するニーズに適応するために迅速に反復することができます。

分散システム アーキテクチャの設計は比較的複雑ですが、業界で従われている原則がいくつかあります。これらの典型的なアーキテクチャ原則のいくつかは、それぞれ eBay と PayPal の CTO である Martin L. Abbott と Michael T. Fisher が書いた「The Art of Scalability」という書籍から引用されています。彼らは、以下のように 15 の建築原則を本の中でまとめています。

• N+1デザイン。
• ロールバック設計。
• デザインを無効にします。
• 監視設計。
• アクティブ/アクティブ データ センターを設計します。
• 実績のあるテクノロジーを使用します。
• 非同期設計。
• ステートレスなシステム。
• 垂直方向ではなく水平方向に拡大縮小します。
• 少なくとも 2 つのステップを念頭に置いて設計します。
• コアではないものを購入してください。
• 市販のハードウェアを使用します。
• 小さく構築し、小さくリリースし、早く失敗しましょう。
• 障害を特定します。
• オートメーション。

2. 分散システムアーキテクチャの進化

インターネット企業のビジネスの急速な発展により、システムアーキテクチャは絶えず変化しています。一般的に、システム アーキテクチャは、モノリシック アプリケーション アーキテクチャから垂直アプリケーション アーキテクチャ、分散アーキテクチャ、SOA アーキテクチャ、マイクロサービス アーキテクチャへと大まかに進化してきました。多くのインターネット企業のシステム アーキテクチャは、サービス メッシュへと進化しています。次に、システムアーキテクチャの開発履歴について簡単に紹介します。

1. モノリシックアプリケーションアーキテクチャ

ビジネス開発の初期段階では、会社の Web サイトのトラフィックは一般的に小さく、会社のビジネス ニーズをサポートするために、すべての機能コードを 1 つのサービスにパッケージ化し、サーバーに展開するために必要なアプリケーションは 1 つだけです。このアプローチにより、開発、展開、保守のコストを削減できます。例えば、皆さんがよくご存知の電子商取引システムには、ユーザー管理、商品管理、注文管理、支払管理、在庫管理、物流管理などの業務モジュールが主に含まれています。エンタープライズ開発の初期段階では、すべてのモジュールを Web プロジェクトに記述し、それらを Web サーバーにデプロイしました。これはモノリシック アプリケーション アーキテクチャです。システムアーキテクチャを図 1 に示します。

図1 モノリシックアプリケーションシステムアーキテクチャ

このアーキテクチャの利点は次のとおりです。

1) アーキテクチャがシンプルで、プロジェクトの開発および保守コストが低くなります。

2) すべてのプロジェクト モジュールが一緒にデプロイされるため、小規模プロジェクトのメンテナンスに便利です。

しかし、その欠点も非常に明白です。

1) すべてのモジュールが結合されているため、大規模なプロジェクトの開発と保守が困難になります。

2) プロジェクトのモジュールが結合しすぎています。 1 つのモジュールで問題が発生すると、プロジェクト全体が利用できなくなります。

3) 特定のモジュールのパフォーマンスを向上させることはできません。

4) プロジェクトを水平展開することができない。

モノリシック アプリケーション アーキテクチャには多くの欠点があるため、徐々に垂直アプリケーション アーキテクチャへと進化してきました。

2. 垂直アプリケーションアーキテクチャ

エンタープライズ ビジネスの継続的な発展により、単一ノードのモノリシック アプリケーションではビジネス ニーズを満たすことができなくなります。そのため、企業は単一のアプリケーションの複数のコピーを展開し、それらを異なるサーバーに配置します。ただし、すべてのモジュールの訪問回数が多いわけではありません。プロジェクト内の特定のモジュールのパフォーマンスを最適化および向上させたい場合、単一のアプリケーションでは不可能です。こうして、垂直アプリケーション アーキテクチャが誕生しました。

垂直アプリケーション アーキテクチャは、元のプロジェクト アプリケーションを複数の無関係なアプリケーションに分割して、システム全体のパフォーマンスを向上させることです。

電子商取引システムを例にとると、垂直アプリケーションアーキテクチャでは、電子商取引プロジェクト全体を電子商取引トランザクションシステム、バックエンド管理システム、データ分析システムに分割できます。システムアーキテクチャを図 2 に示します。

図2 垂直アプリケーションシステムアーキテクチャ

モノリシック アプリケーション アーキテクチャを垂直アプリケーション アーキテクチャに分割すると、トラフィックが増加したときに、プロジェクト全体にサーバー ノードを追加せずに、トラフィックの多いビジネスにのみサーバー ノードを追加する必要があります。

このアーキテクチャの利点は次のとおりです。

1) システムを分割し、さまざまなシステムのアクセス条件に応じてターゲットを絞って最適化します。

2) アプリケーションの水平展開を実現できます。

3) 各システムは全体的なアクセストラフィックを共有できるため、同時実行の問題が解決されます。

4) サブシステムに障害が発生しても、他のサブシステムの動作には影響がないため、全体的なフォールトトレランスが向上します。

このアーキテクチャの欠点は次のとおりです。

1) 分割されたシステムは比較的独立しており、相互に呼び出すことはできません。

2) 各システムで業務が重複することは避けられず、業務展開が重複し、その後の保守が困難になります。

3. 分散アーキテクチャ

システムが垂直アプリケーション アーキテクチャに進化すると、垂直アプリケーションがどんどん追加され、ビジネス コードが繰り返し記述されるようになります。この時点で、重複したコードを抽象化し、他のシステムやビジネス モジュールが呼び出すための統合サービスを形成する必要があります。これは分散アーキテクチャです。

分散アーキテクチャでは、システム全体をサービス層とプレゼンテーション層に分割します。サービス層は、プレゼンテーション層が呼び出す特定のビジネス ロジックをカプセル化し、プレゼンテーション層はページとの対話型操作を処理する役割を担います。分散システムアーキテクチャを図 3 に示します。

図3 分散システムアーキテクチャ

このアーキテクチャの利点は次のとおりです。

1) 重複するビジネス コードを抽象化してパブリック アクセス サービスを形成し、コードの再利用性を向上させます。

2) システムとサービスのパフォーマンスをターゲットを絞って最適化し、全体的なアクセスパフォーマンスを向上させることができます。

このアーキテクチャの欠点は次のとおりです。

1) システム間の呼び出し関係が複雑になる。

2) システム間の依存関係が複雑になります。

3) システム維持コストが高い。

4. SOAアーキテクチャ

分散アーキテクチャでは、展開されるサービスが増えるにつれて、重複するコードも増え、コードの再利用やシステムのメンテナンスに支障をきたします。このため、クラスターをリアルタイムで管理するための統合スケジューリング センターを追加する必要があります。これが SOA (サービス指向) アーキテクチャです。 SOA システム アーキテクチャを図 4 に示します。

図4 SOAシステムアーキテクチャ

このアーキテクチャの利点は、登録センターを通じて、サービス間のサービス依存関係と呼び出し関係の自動登録と検出を解決することです。

このアーキテクチャの欠点は次のとおりです。

1) サービス間に依存関係があります。サービスに障害が発生すると、サーバーがクラッシュする可能性があります。

2) サービス間の依存関係や呼び出し関係が複雑になり、テストや運用・保守のコストが増加します。

5. マイクロサービスアーキテクチャ

マイクロサービス アーキテクチャは、SOA アーキテクチャに基づいてさらに拡張および分割されたものです。マイクロサービス アーキテクチャでは、大規模なプロジェクトが、それぞれ独自のデータベースを持つ、独立してデプロイ可能な小さなマイクロサービスに分割されます。マイクロサービス システムのアーキテクチャを図 5 に示します。

このアーキテクチャの利点は次のとおりです。

1) サービスは完全に分割されており、各サービスは個別にパッケージ化、展開、アップグレードされます。

2) 各マイクロサービスが担当する業務が比較的明確であるため、その後の拡張やメンテナンスが容易になります。

3) マイクロサービスは REST および RPC プロトコルを使用して通信できます。

図5 マイクロサービスシステムアーキテクチャ図

このアーキテクチャの欠点は次のとおりです。

1) 開発コストが比較的高い。

2) 各サービスに関連するフォールト トレランスの問題。

3) データの一貫性に関する問題。

4) 分散トランザクションの問題が含まれます。

3. 分散トランザクションのシナリオ

大規模なアプリケーション システムを複数の独立して展開可能なアプリケーション サービスに分割するには、特定のトランザクション操作を完了するためにサービス間のリモート コラボレーションが必要であり、分散トランザクションの問題が伴います。一般的に、分散トランザクションは、JVM 間プロセス、データベース間インスタンス、および単一のデータベースにアクセスする複数のサービスという 3 つのシナリオで発生します。

1. クロスJVMプロセス

モノリシック プロジェクトを分散型のマイクロサービス プロジェクトに分割した後、各サービスは連携して、リモート REST または RPC 呼び出しを通じてビジネス操作を完了します。典型的なシナリオは、ショッピングモール システムの注文マイクロサービスと在庫マイクロサービスです。ユーザーは注文を行う際に注文マイクロサービスにアクセスします。注文マイクロサービスが注文レコードを生成すると、在庫マイクロサービスを呼び出して在庫を差し引きます。各マイクロサービスは異なる JVM プロセスにデプロイされるため、JVM 間プロセスが原因で分散トランザクションの問題が発生する可能性があります。モール システム内の JVM プロセス間で分散トランザクションを生成するシナリオを図 6 に示します。

図6: モールシステム内のJVMプロセス間の分散トランザクションシナリオ

2. クロスデータベースインスタンス

単一のシステムが複数のデータベースインスタンスにアクセスする場合、つまりデータソース間にアクセスする場合、分散トランザクションが生成されます。たとえば、システム内の注文データベースとトランザクション データベースは、異なるデータベース インスタンスに配置されます。ユーザーが払い戻しを開始すると、ユーザーの注文データベースとトランザクション データベースが同時に操作されます (トランザクション データベースで払い戻し操作が実行され、注文データベースで注文ステータスが払い戻し済みに変更されます)。データは異なるデータベース インスタンスに分散されるため、データベース内のデータを操作するには異なるデータベース接続セッションが必要になり、分散トランザクションが発生します。モール システム内のデータベース インスタンス間での分散トランザクションのシナリオを図 7 に示します。

図7: ショッピングモールシステム内のデータベースインスタンス間の分散トランザクションシナリオ

3. 複数のサービスが単一のデータベースにアクセスする

複数のマイクロサービスが同じデータベースにアクセスする場合、たとえば、注文マイクロサービスとトランザクション マイクロサービスが同じデータベースにアクセスすると、分散トランザクションが生成されます。これは、複数のマイクロサービスが同じデータベースにアクセスする場合、基本的には異なるデータベース セッションを通じてデータベースを操作するため、分散トランザクションが生成されるからです。モール システム内の複数のサービスが単一のデータベースにアクセスして分散トランザクションを生成するシナリオを図 8 に示します。

図8: ショッピングモールシステム内の単一のデータベースにアクセスする複数のサービスによって生成される分散トランザクションのシナリオ

データベース インスタンス間のシナリオや、複数のサービスが単一のデータベースにアクセスするシナリオでは、データベース内のデータを操作するために基本的に異なるデータベース セッションが生成され、分散トランザクションが生成されます。これら 2 つのシナリオは見落とされがちです。

この本は『分散トランザクションの詳細な理解: 原則と実践』から抜粋したもので、出版社の許可を得て出版されています。