最も重要な 5 つの分散システム設計パターン

分散アプリケーションは、現代のソフトウェア開発業界の定番です。これらはクラウド ストレージ サービスの鍵であり、大規模な Web アプリケーションの応答性を維持できるようにします。プログラマーがこれらのシステムを構築する際には、出発点として使用でき、共通の語彙で通信できる基本的な構成要素が必要です。

ここで、分散システムの設計パターンが非常に重要になります。これらは使いすぎられることもありますが、その使い方を理解することは、採用担当者が求める重要なスキルであり、高度なシステム設計の面接で目立つために不可欠です。

今日は、5 つの優れた分散システム設計パターンについて説明し、その長所と短所、そしていつ使用するかを理解できるようにします。

[[405312]]

分散システム設計パターンとは何ですか?

デザイン パターンは、特定のユース ケースに適合する各システムに対して実証およびテストされたアプローチです。これらは実装ではなく、抽象的に構造化されたシステムです。ほとんどのデザイン パターンは、長年にわたってさまざまな開発者によって開発および更新されているため、多くの場合、非常に効果的な出発点となります。

デザイン パターンは、プログラマーがシステムごとにゼロから始めるのではなく、既存の知識を活用できるようにするビルディング ブロックです。また、システム設計用の標準モデルのセットを作成し、他の開発者が自分のプロジェクトが特定のシステムとどのようにインターフェースするかを確認できるようにしました。

創造的デザイン パターンは、新しいオブジェクトを構築する際のベースラインを提供します。構造パターンはソリューションの全体的な構造を定義します。動作パターンは、オブジェクトとそれらが相互に通信する方法を説明します。

分散システムの設計パターンは、基本的にエンド ユーザーに対して単一のコンピューターとして機能するコンピューターとデータ センターの集合である分散システムを開発するときに使用される設計パターンです。これらの分散設計パターンは、異なるノードが相互に通信する方法、各ノードによって処理されるタスク、およびさまざまなタスクに使用されるプロセス フローを理解するソフトウェア アーキテクチャの概要を示します。

これらのパターンは、大規模なクラウド コンピューティングやスケーラブルなマイクロサービス ソフトウェア システム向けの分散システム アーキテクチャの設計に広く使用されています。

分散設計パターンの種類

ほとんどの分散設計パターンは、次の 3 つの機能カテゴリのいずれかに基づいています。

• オブジェクト通信: システムのさまざまなコンポーネントが通信するためのメッセージング プロトコルとアクセス許可について説明します。
• セキュリティ: 機密性、整合性、可用性の問題に対処し、システムが不正アクセスから安全であることを保証します。
• イベント駆動型: システム イベントを生成、検出、使用、および応答するためのパターンについて説明します。

1. コマンドとクエリの責任分離 (CQRS)

CQRS パターンは、スケーラビリティと安全性を向上させるために、分散システムの読み取り操作と書き込み操作を分離することに重点を置いています。このモデルでは、コマンドを使用して永続ストレージにデータを書き込み、クエリを使用してデータを検索および取得します。

これらは、ユーザーからのリクエストを受信するコマンド センターによって処理されます。その後、コマンド センターはデータを取得して必要な変更を加え、データを保存し、読み取りサービスに通知します。次に、読み取りサービスは読み取りモデルを更新して、変更をユーザーに表示します。

利点：

• タスクを委任することでシステムの複雑さを軽減します。
• ビジネス ロジックと検証を明確に分離します。
• 彼らの仕事を整理するのを手伝ってください。
• 共有データへの予期しない変更の数を減らします。
• データへの変更アクセス権を持つエンティティの数を減らします。

欠点:

• コマンドと読み取りモデルの間では、継続的な双方向通信が必要です。
• これにより、高スループットのクエリを送信するときにレイテンシが増加する可能性があります。
• サービスプロセス間の通信手段はありません。

使用例:

CQRS は、SQL や NoSQL データベース管理システムなどのデータ集約型アプリケーションに最適です。また、データ量の多いマイクロサービス アーキテクチャにも役立ちます。ライター/リーダーの区別は不変性に役立つため、これはステートフル アプリケーションを処理する上で非常に重要です。

2. 2フェーズコミット（2PC）

2PC は、トランザクション アプローチとコア コマンドへの依存において CQR に似ていますが、パーティション分割はコマンドの種類と完了段階によって処理されます。 2 つのフェーズは、準備フェーズ (中央制御がサービスにデータを準備するように指示する) とコミット フェーズ (準備されたデータをサービスに送信する) です。

デフォルトでは、2PC システム内のすべてのサービスはロックされており、データを送信できません。ロックする場合、サービスは準備フェーズに入力して、ロック解除を送信する準備を整えます。コーディネーターはサービスを 1 つずつロック解除し、そのデータを要求します。サービスがデータをコミットする準備ができていない場合、コーディネーターは別のサービスに進みます。準備されたすべてのデータが送信されると、すべてのサービスがブロック解除され、コーディネータからの新しいタスクを待機します。

2PC は基本的に、一度に 1 つのサービスのみが動作できるようにすることで、プロセスの耐性を高め、CQRS の一貫性を高めます。

利点：

• 同時リクエストがないため、永続的でエラーに強い。
• スケーラブル - 単一のマシンからデータを処理できるため、大規模なデータ プールを簡単に処理できます。
• 同時分離とデータ共有を可能にします。

欠点:

• 同期的な性質のため、ボトルネックやブロッキングが発生しにくくなります。
• 他のデザイン パターンよりも多くのリソースが必要です。

使用例:

2PC は、リソース効率よりも精度が優先される、リスクの高いトランザクション操作を処理する分散システムに最適です。エラーに強く、大規模でも追跡が容易です。

3. サガ

SAGA は、中央コントローラーを使用せず、代わりにサービス間で完全に通信する非同期パターンです。これにより、これまでに説明した同期モードの欠点の一部が克服されます。

SAGA はアクティビティ バスを使用して、マイクロサービス システム内でサービスが相互に通信できるようにします。バスはサービス間でリクエストを送受信し、参加している各サービスはローカル トランザクションを作成します。参加しているサービスは、その都度、他のサービスのアクティビティを発行します。他のサービスはすべてイベントをリッスンします。アクティビティを最初に受信したサービスが必要なアクションを実行します。サービスが操作を完了できない場合は、他のサービスに送信されます。

この構造は、1 人がタスクを完了できない場合にサービスが循環するという点で 2PC 設計に似ています。ただし、Saga では中央制御要素を削除してトラフィックをより適切に管理し、必要な前後の通信の量を削減します。

利点：

• 個々のサービスでは、より長いトランザクションを処理できます。
• 分散システムは、分散化されているので優れています。
• サービス間のピアツーピア通信によりボトルネックが軽減されるためです。

欠点:

• 非同期の自律性により、どのサービスが個々のタスクを実行しているかを追跡することが困難になります。
• 複雑な振り付けのためデバッグが困難です。
• 以前のモデルよりもサービスの分離が少なくなります。

使用例:

SAGA の分散型アプローチは、一度に多数の並列リクエストを処理できるスケーラブルなサーバーレス機能に最適です。 AWS は、STEPS や LAMBDA 関数などの多くの機能で SAGA ベースの設計を使用しています。

4. レプリケーション負荷分散サービス (RLB)

RLBS パターンは、最も単純で最も一般的に使用される設計パターンです。最も基本的なレベルでは、中央のロード バランサーにレポートする複数の同一サービスで構成されます。各サービスはタスクを処理することができ、失敗した場合には複製することができます。ロード バランサは、エンド ユーザーからのリクエストを受信し、ラウンドロビン方式で、または場合によってはより複雑なルーティング アルゴリズムを使用して、リクエストをサービスに配布します。

重複したサービスにより、アプリケーションはユーザー要求に対して高い可用性を維持し、サービスの 1 つのインスタンスに障害が発生した場合でも作業を再配布できるようになります。

RLBS は、ワークフロー ベースの自動サービス スケーリングを提供する Microsoft のオープン ソース コンテナー オーケストレーション テクノロジである Azure Kubernetes でよく使用されます。

利点：

• エンドユーザーからの視点の一貫性。
• 障害が発生したサービスから迅速に回復できます。
• より多くのサービスを提供できるよう、高いスケーラビリティを備えています。
• 同時実行に非常に適しています。

欠点:

• ロード バランサ アルゴリズムに基づく一貫性のないパフォーマンス。
• リソース集約型管理サービス。

使用例:

RLBS は、Netflix や Amazon Prime などのエンターテイメント Web アプリケーションなど、全体的に一貫性がないものの、低レイテンシを維持する必要があるワークロードに適しています。

5. シャーディングサービス

レプリカベースの設計の代替案としては、それぞれが特定のタイプの要求のみを完了できるさまざまなサービスを作成することです。これは、リクエスト ストリームを複数の不均等な部分に分割するため、「シャーディング」と呼ばれます。たとえば、すべてのキャッシュ要求を受け入れるシャード サービスと、優先度の高い要求のみを処理するシャード サービスが 1 つある場合があります。ロード バランサは、各リクエストが到着するとそれを評価し、適切なシャードに分散します。

状態のサイズが単一のステートレス コンテナーには大きすぎることが多いため、フォークされたサービスはステートフル サービスの構築によく使用されます。シャーディングを使用すると、単一のシャードを国の規模に合わせて拡張できます。

サービスをフォークすると、優先度の高いリクエストをより速く処理することもできます。優先度の高いリクエスト専用のシャードは、リクエストをキューに入れるのではなく、リクエストが届いた瞬間に処理するために常に利用可能です。

利点：

• パブリック リクエストの階層的な断片化を可能にします。
• リクエストの優先順位付けが簡単。
• 自然な順序付けによりデバッグが容易になります。

欠点:

• 多くのシャードを維持するには多くのリソースが必要になる場合があります。
• シャードが不均衡に使用されると、パフォーマンスが低下します。

使用例:

シャード サービングは、システムが予測可能なリクエスト タイプの不均衡を受信し、一部のリクエストが優先される場合に最適に機能します。