1 つの記事で詳細に説明しています: 可用性の高い分散アーキテクチャを設計するにはどうすればよいでしょうか?

この記事の著者は、現在主流となっている分散アーキテクチャ、分散アーキテクチャにおける一般的な理論、および可用性の高い分散アーキテクチャの設計方法について説明します。

[[236104]]

分散アーキテクチャでは、SOA とマイクロサービス アーキテクチャが 2 つの最も一般的な分散アーキテクチャであり、サービス メッシュの概念がますます普及しています。まずはこれらの一般的なアーキテクチャから始めましょう。

SOAアーキテクチャの分析

SOA の正式名称は Service Oriented Architecture で、中国語で「サービス指向アーキテクチャ」を意味します。

これは、相互に依存する複数のサービスが含まれ、最終的に完全な機能セットを提供する設計コンセプトです。

通常、各サービスは独立して展開および実行され、サービスはネットワーク経由で呼び出されます。アーキテクチャ図は次のとおりです。

SOA と同等なのが ESB (エンタープライズ サービス バス) です。簡単に言えば、ESB はさまざまなサービス ノードを接続するために使用されるパイプラインです。

ESB の目的は、異なるプロトコルに基づいてさまざまなサービスを統合することです。 ESB はメッセージを変換、解釈、ルーティングし、さまざまなサービスが相互接続できるようにします。

ビジネスが複雑になるにつれて、より多くのサービスが見つかるでしょう。 SOA アーキテクチャでは、呼び出し関係は次のようになります。

明らかに、これは私たちが望んでいることではありません。 ESB の概念を導入すると、プロジェクトの呼び出しは次のように非常に明確になります。

SOA が解決することを目指す主な問題は次のとおりです。

• システム間の統合: システムの観点から、まずシステム間の通信問題を解決する必要があります。目標は、システム間の元々の分散した計画外のネットワーク構造を、規則的で管理しやすいスター構造に変換することです。このステップの実装には、多くの場合、いくつかの概念と仕様の導入が必要になります。

たとえば、ESB、技術仕様、サービス管理仕様など。このステップで解決する中心的な問題は[順序]です。

• サービス指向システム: 機能的な観点から、サービス オーケストレーションを通じてビジネスの迅速な再生を実現するために、ビジネス ロジックを再利用可能かつ組み立て可能なサービスに抽象化する必要があります。

本来の固有の業務機能を汎用的な業務サービスに抽象化し、ビジネスロジックの迅速な再利用を実現することを目的としています。このステップで解決すべき中心的な問題は[再利用]です。

• サービス指向ビジネス: 企業の観点から、企業機能を再利用可能かつ組み立て可能なサービスに抽象化したい場合、企業の外部サービス機能をさらに強化するために、元の機能的なエンタープライズ アーキテクチャをサービス指向のエンタープライズ アーキテクチャに変換する必要があります。

「最初の 2 つのステップは、システム コールとシステム関数の再利用の問題を技術的な観点から解決することです。」このステップでは、ビジネス ドライバーに基づいてビジネス ユニットをサービスにカプセル化します。解決すべき中心的な問題は[効率性]です。

マイクロサービスアーキテクチャ分析

マイクロサービス アーキテクチャは SOA アーキテクチャと非常によく似ています。マイクロサービスは SOA の昇華ですが、マイクロサービス アーキテクチャでは、「ビジネスは完全にコンポーネント化され、サービス指向である必要がある」ということを強調しています。元の単一のビジネス システムは、独立して開発、設計、展開、実行できる複数の小さなアプリケーションに分割されます。

これらの小さなアプリケーションは、サービス指向のアプローチを通じて相互に対話し、統合されます。コンポーネントとは、PC の CPU、メモリ、グラフィック カード、ハード ドライブのように独立しており、他のユニットに影響を与えることなく交換やアップグレードが可能なユニットを指します。

PC 内の各コンポーネントをサービスとして構築すると、この PC ではマザーボード (ESB として理解できます) といくつかの必要な外部デバイスのみを維持する必要があります。

CPU、メモリ、ハードディスクなどはすべてコンポーネントの形でサービスを提供します。たとえば、PC が計算を行うために CPU を呼び出す必要がある場合、CPU コンポーネントのアドレスのみを知っていれば十分です。

マイクロサービスの特徴:

• サービスによるコンポーネント化
• サービスチームと開発チームをビジネス能力別に分ける
• 分散化
• インフラストラクチャ自動化（DevOps、自動デプロイメント）

SOAとマイクロサービスアーキテクチャの違い

マイクロサービスは、従来の SOA アーキテクチャにおける重い ESB エンタープライズ サービス バスを重視する必要がなく、同時に SOA の概念を使用して単一のビジネス システムに参入し、真のコンポーネント化を実現します。

Docker コンテナ テクノロジーの登場により、より小さなデプロイメント ユニットなど、マイクロサービスにとって非常に便利な条件が提供され、各サービスは Spring Boot や Node などのテクノロジーを通じて独立して実行できるようになりました。

誰もが分析できるはずのもう一つのポイントがあります。 SOA はシステム統合に重点を置いていますが、マイクロサービスは完全な分離に重点を置いています。

サービスメッシュアーキテクチャの分析

2017 年末までに、非侵入型サービス メッシュ テクノロジーは徐々に成熟しました。中国語で「サービス メッシュ」を意味するサービス メッシュは、サービス間の通信のためのインフラストラクチャ層としてシステム内に存在します。

サービス メッシュとは何かを一言で説明すると、サービス間のネットワーク呼び出し、回路遮断、電流制限、監視を担うアプリケーション間またはマイクロサービス間の TCP/IP に例えることができます。

プログラマーは一般に、アプリケーション (HTTP プロトコルを提供する RESTful アプリケーションなど) を作成するときに TCP/IP 層を気にする必要がないことは誰もが知っています。

同様に、サービス メッシュを使用すると、元々アプリケーションや他のフレームワークによって実装されていたサービス間の事柄 (回路遮断、電流制限、監視など) を心配する必要がなくなります。後は、サービス メッシュに任せるだけです。

サービス グリッド アーキテクチャ図は次のとおりです。

現在人気のあるサービス メッシュ オープン ソース ソフトウェアには、Linkerd、Envoy、Istio などがあります。最近、Buoyant (オープンソースの Linkerd を開発した会社) が、Kubernetes ベースのサービス メッシュ オープンソース プロジェクト Conduit をリリースしました。

マイクロサービスとサービス メッシュの違いについては、次のように理解しています。マイクロサービスはサービス間のエコロジーに重点を置き、サービス ガバナンスなどの側面に重点を置いていますが、サービス メッシュはサービス間の通信と DevOps とのより優れた統合に重点を置いています。

サービス メッシュの特徴:

• アプリケーション間通信ミドルウェア
• 軽量ネットワークプロキシ
• アプリケーションは認識しない
• アプリケーションの再試行/タイムアウト、監視、トレース、サービス検出を分離する

分散アーキテクチャの基礎理論

CAP 理論と BASE 理論について話す前に、まず分散一貫性の問題を理解する必要があります。異なるビジネスのサービスでは、データの一貫性に対する要件が異なります。

たとえば、12306 では厳密なデータ一貫性が求められます。チケットをユーザーに販売した後で、残席がないことが判明した場合、チケットは販売できません。

たとえば、銀行を通じて送金する場合、通常は「送金申請は 24 時間以内に届きます」というメッセージが表示されます。

実際、このシナリオは、最終的に資金を正常に送金できるという要件を満たしており、同時に、資金が送金されない場合、資金が失われないようにする必要があります。

したがって、ユーザーはさまざまなサービスを使用する場合、データの一貫性に関してさまざまな要件を持ちます。

分散一貫性問題について

分散システムで解決すべき非常に重要な問題は、データの複製です。

日常の開発経験では、ほとんどの開発者が次のような問題に遭遇したことがあると思います。データベースの読み取りと書き込みを分離するシナリオで、クライアント A がシステム内の値 V を V1 から V2 に変更するとします。

ただし、クライアント B は V の最新の値をすぐに読み取ることはできず、読み取る前にしばらく待つ必要があります。データベースのレプリケーション間に遅延があるため、これは正常です。

いわゆる分散一貫性問題とは、分散環境でデータ複製メカニズムを導入した後に異なるデータノード間で発生する可能性があり、コンピュータアプリケーション自体では解決できないデータの不整合を指します。

簡単に言えば、データの一貫性とは、1 つのコピーのデータに変更を加えたときに、他のコピーも更新できることを確認する必要があることを意味します。そうしないと、異なるコピー間のデータの一貫性が失われます。

では、この問題をどう解決すればよいのでしょうか?通常の考え方では、問題はネットワークの遅延によって発生するため、同期アクションをブロックする必要があると考えるかもしれません。ユーザー 2 は、クエリを実行する前に、データの同期が完了するまで待機する必要があります。

しかし、この解決策はパフォーマンスに大きな影響を与えます。同期されるデータが大きい場合や頻繁に同期される場合、操作をブロックすると新しいシステム全体が使用できなくなる可能性があります。

したがって、システムのパフォーマンスに影響を与えずにデータの一貫性を満たすソリューションを見つける方法はなく、一貫性レベルが生まれました。

• 強力な一貫性: この一貫性レベルは、ユーザーにとって最も直感的です。システムが書き込んだ内容を読み取ることが要求され、優れたユーザー エクスペリエンスが提供されます。ただし、その実装はシステムのパフォーマンスに大きな影響を与えることがよくあります。
• 弱い一貫性: この一貫性レベルはシステムを制約します。書き込みが成功した後、書き込まれた値がすぐに読み取れる保証はなく、データが整合するまでにどれくらいの時間がかかるかも保証されません。ただし、一定の時間レベル (秒数など) が経過すると、データの一貫性が確保されるようになります。
• 結果的一貫性: 結果的一貫性は、実際には弱い一貫性の特殊なケースです。システムは、一定期間内にデータの一貫性が確保されることを保証します。

ここで結果的整合性について言及する理由は、それが弱い整合性の中でも最も推奨される整合性モデルであり、また、大規模分散システムにおけるデータ整合性のために業界でより頻繁に使用される整合性モデルでもあるためです。

CAP理論

CAP 理論は古典的な分散システム理論です。これは、分散システムが一貫性 (C: Consistency)、可用性 (A: Availability)、分断耐性 (P: Partition Tolerance) という 3 つの基本要件を同時に満たすことはできず、最大でそのうちの 2 つしか満たせないことを示しています。

CAP 理論はインターネット コミュニティで広く知られており、「ハット理論」としても知られています。これは、2000 年に ACM セミナーで Eric Brewer 教授によって提案された有名な予想です。

分散システムでは、一貫性、可用性、およびパーティション耐性を同時に満たすことはできず、最大でそのうちの 2 つを満たすことができます。

• 一貫性: すべてのノード上のデータは常に同期された状態に保たれます。
• 可用性: 成​​功したか失敗したかに関係なく、すべてのリクエストは応答を受け取ります。
• パーティション耐性: システム内でメッセージが失われた場合でも (ノード パーティションにより)、システムは引き続きサービスを提供する必要があります。

たとえば、スイッチに障害が発生したり、URL ネットワークが複数のサブネットに分割されてスプリット ブレインが発生したり、サーバーでネットワークの遅延やクラッシュが発生して、一部のサーバーがクラスター内の他のマシンとの接続を失ったりすることがあります。

パーティショニングは、分散システムにおいて信頼性の問題を引き起こす固有の特性です。本質的に、CAP 理論の正確な説明は、3 つの特性のうち 2 つを選択することではなく、適応を余儀なくされ、まったく選択の余地がないということになります。

CAP は普遍的な原則や指導理念ではありません。これは、アトミック読み取りと書き込みを伴う NoSQL シナリオにのみ適用され、データベース システムには適用されません。

ベース理論

これまでの分析から、CAP 理論は分散を前提としたデータベース トランザクション (データベース シャーディングまたはシャードされたデータベースの複数のインスタンス) には適していないことがわかります。

誤ったデータの更新によって障害が発生すると、データに修正不可能なエラーが含まれるため、高可用性ソリューションは役に立たなくなります。

さらに、XA トランザクションは分散システム内のデータベースの ACID (原子性、一貫性、独立性、永続性) 特性を保証しますが、同時にパフォーマンス コストも発生し、同時実行性と応答時間に対する要件が高い e コマース プラットフォームでは受け入れが困難です。

eBay はまったく異なるアプローチを試み、データベース トランザクションの ACID 要件を緩和し、BASE と呼ばれる新しいガイドライン セットを提案しました。

BASE は、Basically Available (基本的に利用可能)、Soft state (ソフト状態)、Eventually Consistent (最終的に一貫性がある) という 3 つのフレーズの略語です。 CAP と比較すると、システムに対する要件が大幅に削減されます。

基本的に利用可能

分散システムで予期しない障害が発生した場合に、一時的な部分的な可用性が許可されることを示します。

• たとえば、Taobao で商品を検索すると、通常 0.5 秒以内にクエリ結果が返されます。ただし、バックエンドのシステム障害により、クエリ応答時間は 2 秒になります。
• たとえば、データベースがシャーディング モードを採用している場合、100 万のユーザー データが 5 つのデータベース インスタンスに分割されます。 1 つのインスタンスが破損した場合でも、可用性は 80% のままです。つまり、80% のユーザーがログインでき、システムは引き続き利用可能です。
• 大規模な電子商取引のプロモーション中は、トラフィックの急増に対処するために、一部のユーザーがダウングレードされたページに誘導され、サービス層ではダウングレードされたサービスのみが提供される場合があります。ここで、可用性の一部が失われることになります。

ソフトステート

これは、システム内にデータの中間状態が存在し、この中間状態の存在がシステム全体の可用性に影響を与えないことを意味します。つまり、システムでは、異なるノード上のデータ コピー間のデータ同期のプロセスに遅延が生じる可能性があります。

たとえば、注文ステータスには、支払い保留中、支払い中、支払い成功、支払い失敗が含まれます。支払いは中間状態です。支払いが成功した後、支払いテーブルのステータスが注文ステータスに同期されるまで、この中間ステータスに時間の不整合が生じます。

最終的に一貫性がある（データの最終的な一貫性）

これは、一定期間の同期の後、すべてのデータ コピーが最終的に一貫した状態になることを意味します。したがって、最終的な一貫性の本質は、システム データの強力な一貫性をリアルタイムで保証する必要なく、データが最終的に一貫していることを保証することです。

BASE 理論の核となる考え方は、強い一貫性を実現できない場合でも、各アプリケーションが独自のビジネス特性に基づいて適切な方法を採用し、システムが最終的な一貫性を実現できるようにするというものです。

分散アーキテクチャにおける高可用性設計

単一障害点を回避する:

• 負荷分散技術（フェイルオーバー/サイト選択/ハードウェア負荷/ソフトウェア負荷/分散ソフトウェア負荷（ゴシップ（redis-cluster）））
• ホットスタンバイ (Linux HA)
• 複数のコンピュータ ルーム (同じ都市での災害復旧、異なる場所での災害復旧)

アプリケーションの高可用性:

• 障害監視（システム監視（CPU、メモリ）/リンク監視/ログ監視）自動警告
• アプリケーションのフォールトトレラント設計と自己保護機能（サービス低下、電流制限）
• データ量（データシャーディング、読み取りと書き込みの分離）

分散アーキテクチャにおけるスケーラブルな設計:

• 垂直拡張
• ハードウェア機能の向上
• 水平スケーリング
• サーバーの追加

静的コンテンツへのアクセスを高速化するCDN

CDN の正式名称は Content Delivery Network で、中国語の意味はコンテンツ配信ネットワークです。

CDNの役割は、ユーザーが必要とするコンテンツを、ユーザーに最も近い場所に配信して応答し、ユーザーが必要なコンテンツを素早く取得できるようにすることです。

CDN は本質的に、比較的安定したリソースをエンドユーザーの近くに配置できるネットワーク キャッシュ テクノロジです。一方では、広域ネットワーク全体の帯域幅消費を節約でき、他方では、ユーザーのアクセス速度を向上させ、ユーザーエクスペリエンスを向上させることもできます。

実際のシステムでは、通常、静的ファイル (画像、スクリプト、静的ページなど) を CDN に配置します。

• ユーザーがウェブサイトのページのコンテンツ URL にアクセスすると、ローカル DNS システムによって解決された後、DNS システムは最終的に、CNAME によって指定された CDN 専用 DNS サーバーにドメイン名解決権限を引き渡します。
• CDN の DNS サーバーは、CDN のグローバル ロード バランシング デバイスの IP アドレスをユーザーに返します。
• ユーザーは、CDN のグローバル ロード バランシング デバイスに対してコンテンツ URL アクセス要求を開始します。
• CDN グローバル ロード バランシング デバイスは、ユーザーの IP アドレスとユーザーが要求したコンテンツ URL に基づいて、ユーザーが属するエリア内の地域ロード バランシング デバイスを選択し、このデバイスへの要求を開始するようにユーザーに指示します。
• 地域負荷分散デバイスは、ユーザーにサービスを提供するために適切なキャッシュ サーバーを選択します。選択の基準には、ユーザーの IP アドレスに基づいて、どのサーバーがユーザーに最も近いかを判断することが含まれます。

ユーザーが要求した URL に含まれるコンテンツ名に基づいて、ユーザーが必要とするコンテンツがどのサーバーにあるかを判断します。各サーバーの現在の負荷を照会して、どのサーバーにサービス容量があるかを判断します。

• 上記の条件を総合的に分析した後、地域負荷分散デバイスはキャッシュ サーバーの IP アドレスをグローバル負荷分散デバイスに返します。
• グローバル ロード バランシング デバイスは、サーバーの IP アドレスをユーザーに返します。ユーザーはキャッシュ サーバーにリクエストを送信し、キャッシュ サーバーはユーザーのリクエストに応答して、ユーザーが要求したコンテンツをユーザー端末に返します。

キャッシュ サーバーにユーザーが必要とするコンテンツがないにもかかわらず、地域バランシング デバイスがそれをユーザーに割り当てている場合、サーバーは、コンテンツを含むソース サーバーまで遡ってコンテンツをローカルに取得するまで、上位レベルのキャッシュ サーバーにコンテンツを要求します。

CDN はいつ使用すればよいですか?

最も適しているのは、画像、JS ファイル、CSS ファイルなど、頻繁に変更されないコンテンツです。画像ファイルには、プログラム テンプレートの CSS ファイルで使用される背景画像や、Web サイトのコンテンツの一部となる画像などが含まれます。

グレースケールリリース

アプリケーションがテスト部門によってテストされたとしても、ユーザーの使用シナリオを完全にカバーすることは依然として困難です。

すべてがスムーズに進むように、通常、リリース時にグレースケール リリースを採用します。つまり、新しいアプリケーションをバッチでリリースし、*** が完了するまで、クラスター全体での新しいアプリケーションの割合を徐々に増やしていきます。グレースケール リリースは、新しいアプリケーションのユーザー エクスペリエンスが認識されないことを意味します。

グレースケールリリースシステムの役割は、独自の構成に従って新しく起動されたシステムにユーザートラフィックを誘導し、新しい機能を迅速に検証することです。

問題が発生した場合、リリースをすぐにロールバックできます。簡単に言えば、これは A/B テスト システムです。

要約する

この記事では、主流の SOA アーキテクチャ、マイクロサービス アーキテクチャ、サービス メッシュ アーキテクチャを分析し、分散アーキテクチャにおけるいくつかの基本的な理論を学習し、可用性の高い分散アーキテクチャを設計する方法を分析しました。