分散システムの基礎

1. 序章

このチュートリアルでは、分散システムの基本を理解します。 この記事では、それらの基本的な特性と、それらが提示する課題を一般的な解決策とともに説明します。

また、複数のカテゴリにまたがる人気のある分散システムのいくつかが採用しているアプローチについても簡単に説明します。

2. 基本概念

さまざまなシステムの分散アーキテクチャを理解する前に、まずいくつかの基本事項を明確にしましょう。

動機は分散アーキテクチャに大きく影響しますが、それらすべてに適用されるいくつかの基本的な原則と課題があります。

2.1. 分散システムとは

それでは、分散システムを正式に定義することから始めましょう。 分散システムは、メッセージパッシングを介して通信し、アクションを調整する、おそらく地理的な境界を越えた複数のコンポーネントで構成されます。 このシステムの外部のアクターには、単一のコヒーレントシステムのように見えます。

今では、分散システムについてよく耳にし、分散システムと混同することがあります。 したがって、いくつかの区別をすることが不可欠です。 分散システムは、特定のコンポーネントが意思決定を所有しない分散システムです。 すべてのコンポーネントが決定の一部を所有していますが、完全な情報を持っているコンポーネントはありません。 したがって、決定の結果は、すべてのコンポーネント間のある種のコンセンサスに依存します。

分散システムに非常に密接に関連するもう1つの用語は、並列システムです。 どちらの用語も計算能力のスケールアップを指しますが、それらを実現する方法は異なります。 並列コンピューティングでは、1台のマシンで複数のプロセッサを使用して複数のタスクを同時に実行します、場合によっては共有メモリを使用します。 ただし、分散コンピューティングでは、共有メモリがなく、メッセージパッシングと通信する複数の自律型マシンを使用します。

2.2. 分散システムの利点

分散システムは、設計と構築が明らかに複雑ですが、分散システムがもたらすメリットを実感できます。

主な利点のいくつかを簡単に見ていきましょう。

• スケーラビリティ：垂直スケーリングは、一般にハードウェアの制限によって制約されます。たとえば、プロセッサコアの数は非常に多くなります。 ただし、理論的には、比較的安価なコモディティマシンで無制限の水平スケーリングを実現できます。
• 信頼性：分散システムは複数のマシンで構成されており、データは複数のノードに複製されているため、一般的にシステムの一部の障害に対する耐性が高くなります。 したがって、容量が減少した場合でも、システム全体は引き続き機能します。
• パフォーマンス：分散コンピューティングの一般的なアプリケーションは、ワークロードを複数のマシンで同時に実行できる小さな部分に分割することで機能します。 したがって、このは、行列の乗算など、多くの複雑なワークロードのパフォーマンスを大幅に向上させます。

2.3. 分散システムにおける課題

分散システムのすべてのメリットを問題なく享受できると考えるなら、現実から遠く離れることはできません。

分散システムが私たちに提示する主要な課題のいくつかを理解しましょう。

• 一貫性vs。 可用性：分散システムは定義上パーティション許容度を提供するため、CAP定理によって制約されるように一貫性または可用性のいずれかを選択する必要があります。 これは、汎用コンピューティングプラットフォームを作成するための簡単なトレードオフではありません。
• データ分散：分散システムのデータまたはワークロードは、複数のノードに送信するためにパーティション化する必要があります。 これにより、複雑なアルゴリズムを効率的に分割し、後でそれらを結合するための要件が生じます。
• 調整：分散システムのデータまたはワークロードもフォールトトレランスのために複数のノードに複製されるため、それらを調整するのは非常に困難です。 参加ノードが決定に同意するには、複雑なプロトコルが必要です。

多くの場合、エンタープライズアプリケーションでは、トランザクションの下で複数の操作を実行する必要があります。 たとえば、単一の作業単位としてデータに複数の更新を行う必要がある場合があります。 これは、データが同じ場所に配置されている場合は簡単になりますが、ノードのクラスターにデータを分散する場合は非常に複雑になります。 多くのシステムは、PaxosやRaftなどの複雑なプロトコルを使用して、分散環境でセマンティクスのようなトランザクションを提供します。

3. アーキテクチャとカテゴリ

分散システムへの関心は最近復活していますが、基本的な基礎は新しいものではありません。 かなり長い間、分散システムは、データに関連する一般的なユースケースから特定のユースケースを解決するために多くのアーキテクチャパターンが出現するのを見てきました。

このセクションでは、分散システムのいくつかのアーキテクチャパターンと、それらが提供できるさまざまなカテゴリのユースケースについて説明します。

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

分散システムのシステムアーキテクチャは、ユースケースとそれからの期待に依存します。 ただし、ほとんどの場合に見られる一般的なパターンがいくつかあります。

実際、これらはアーキテクチャが採用するコア分散モデルです。

• マスタースレーブ：このモデルでは、分散システムの1つのノードがマスターの役割を果たします。 ここで、マスターノードはシステムに関する完全な情報を持ち、意思決定を制御します。 残りのノードは軟膏として機能し、マスターによってノードに割り当てられたタスクを実行します。 さらに、フォールトトレランスのために、マスターノードは冗長スタンバイを持つことができます。
• ピアツーピア：このモデルの分散システムのノード間に指定された単一のマスターはありません。 すべてのノードは、マスターの責任を等しく共有します。 したがって、これはマルチマスターモデルまたはマスターレスモデルとしても知られています。 複雑さと通信オーバーヘッドの増加を犠牲にして、このモデルはより優れたシステム回復力を提供します。

これらのアーキテクチャにはそれぞれ長所と短所がありますが、1つだけを選択する必要はありません。 分散システムの多くは、実際には両方のモデルの要素を組み合わせたアーキテクチャを作成します。

ピアツーピアモデルはデータ分散を提供できますが、マスタースレーブモデルは同じアーキテクチャでデータレプリケーションを提供できます。

3.2. 分散システムのカテゴリー

分散システムを設計する理由はいくつかあります。 たとえば、機械学習モデルでは、行列の乗算などの計算を大規模に実行する必要があります。 これらを1台のマシンに収容することは不可能です。

同様に、巨大なファイルを処理し、それらを単一のマシンで処理および保存するシステムは、不可能であるか、少なくとも非常に非効率的である可能性があります。

したがって、ユースケースに応じて、分散システムを次のカテゴリに大まかに分類できます。 ただし、これは分散システムで考えられるユースケースの完全なリストではありません。

• データストア
• メッセージング
• コンピューティング
• 元帳
• ファイルシステム
• アプリケーション

従来、リレーショナルデータベースは、かなり長い間、データストアのデフォルトの選択肢でした。 しかし、データの量、多様性、速度の点での最近の成長により、リレーショナルデータベースは期待を下回り始めました。 これは、分散アーキテクチャを備えたNoSQLデータベースがより有用であることが証明され始めた場所です。

同様に、従来のメッセージングシステムは、現代の規模のデータの課題に対して隔離されたままではありませんでした。 したがって、パフォーマンス、スケーラビリティ、および場合によっては耐久性を提供できる分散型メッセージングシステムの必要性が高まり始めました。 今日、この領域には、パブリッシュ/サブスクライブやポイントツーポイントなどの複数のセマンティクスを提供するいくつかのオプションがあります。

このチュートリアルでは、いくつかの一般的な分散データベースとメッセージングシステムについて説明します。 主に、一般的なアーキテクチャと、それらがパーティション分割や調整などの分散システムの主要な課題のいくつかにどのように対処するかに焦点を当てます。

4. Apache Cassandra

Cassandra は、パーティション化されたワイドカラムストレージモデルを採用したオープンソースの分散キーバリューシステムです。 完全なマルチマスターデータレプリケーションを備えており、低レイテンシで高可用性を提供します。 単一障害点がなく、線形にスケーラブルです。

Cassandra は高可用性とスケーラビリティを優先するため、結果整合性のあるデータベースになります。 これは基本的に、データに対するすべての更新が最終的にすべてのレプリカに到達することを意味します。 ただし、同じデータの異なるバージョンが一時的に存在する可能性があります。 ただし、Cassandraは、読み取り操作と書き込み操作の両方について、選択可能な整合性レベルのリストの形式で調整可能な整合性も提供します。

4.1. データ配信

Cassandraは、クラスター内のノード間ですべてのデータを均等に分割することにより、水平スケーリングを提供します。 クラスター全体にデータを分散する簡単な方法は、分散ハッシュテーブルを使用することです。 ただし、通常、クラスター内のノードの数が変更された場合に備えて、再ハッシュが発生します。 これは、コンシステントハッシュが優れていることが証明されているため、Cassandraによって使用される場所です。

コンシステントハッシュ法は、クラスター内のノード数に依存しない分散ハッシュスキームです。 これには、トークンとも呼ばれるハッシュ値の全範囲を表す抽象リングの概念があります。

Cassandraは、クラスター内のすべてのノードをこのトークンリング上の1つ以上のトークンにマップして、トークンの範囲全体がクラスター全体に均等に分散されるようにします。 したがって、すべてのノードは、リング内のどこにトークンを配置するかに応じて、このリング内のトークンの範囲を所有します。

キーの所有権を判別するために、Cassandraは最初にキーをハッシュすることによってトークンを生成します。 ハッシュ関数としてパーティショナーを使用し、Murmur3Partitionerがデフォルトのパーティショナーです。 リング上でキーのトークンを見つけると、リングを時計回りに歩き、トークンを所有している最も近いノード、つまりキーを識別します。

現在、Cassandra は、フォールトトレランスを提供するために、複数の物理ノード間で各パーティションも複製します。 SipleStrategyやNetworkTopologyStrategyなどのプラグ可能なレプリケーション戦略をサポートして、特定のトークン範囲のレプリカとして機能するノードを決定します。 Simple Strategyの場合、レプリケーションファクター（RF）で定義された個別のノードの数が見つかるまで、リングを歩き続けます。

4.2. 調整

Cassandraクラスターはマルチマスターであるため、クラスター内のすべてのノードが独立して読み取りおよび書き込み操作を受け入れることができます。 リクエストを受信したノードは、アプリケーションのプロキシとして機能します。 プロキシノードをコーディネーターと呼び、パーティショナーを使用してキーを所有するノードを識別する責任があります。

したがって、すべてのノードは、操作を最適にルーティングするために、クラスター内でどのノードが稼働しているか停止しているかを知る必要があります。 Cassandraは、ゴシッププロトコルを使用して、基本的なクラスターブートストラップ情報をクラスター全体に伝播します。

Gossipは、すべてのノードが他のいくつかのノードと定期的に状態情報を交換するピアツーピア通信プロトコルです。 彼らは自分自身と彼らが知っている他のノードについての情報を交換します。 さらに、ゴシップが古いバージョンのクラスター状態を無視できるように、ベクタークロックで情報をバージョン管理します。

マルチマスターアーキテクチャのもう1つの問題は、複数のレプリカが同じキーミューテーション要求を同時に受け入れることができることです。 したがって、レプリカセット全体で同時更新を調整するメカニズムが必要です。

Cassandraは、Last-Write-Winsモデルを使用してこの問題を解決します。 簡単にするために、ここでは、すべてのミューテーションにタイムスタンプが付けられ、常に最新バージョンが優先されます。

5. MongoDB

MongoDB は、データをドキュメントのコレクションとして格納する、オープンソースの汎用ドキュメントベースの分散データベースです。 ドキュメントは、フィールドと値のペアで構成される単純なデータ構造です。 さらに、複雑なデータモデリング用の埋め込みドキュメントと配列も提供します。

MongoDBシャードをレプリカセットとしてデプロイできます。 レプリカセットのプライマリメンバーは、すべての要求を処理します。 シャードは通常、自動フェイルオーバー中に要求を処理するために使用できません。 これにより、MongoDBはデフォルトで強力な一貫性を保ちます。 ただし、高可用性を実現するために、クライアントは、データが結果整合性を持つセカンダリレプリカから読み取ることを選択できます。

5.1. データ配信

MongoDBは、シャードキーを使用して、コレクション内のドキュメントを複数のシャードに分散します。 は、ドキュメントの1つ以上のフィールドからシャードキーを作成できます。 明らかに、シャードキーの選択は、シャードクラスターのパフォーマンス、効率、およびスケーラビリティを意味します。

MongoDBは、シャードキーを使用してデータをチャンクに分割します。 クラスタ内のすべてのシャードにチャンクを均等に分散させようとします。

MongoDB は、ハッシュシャーディングとレンジシャーディングの2つのシャーディング戦略をサポートしています。 ハッシュシャーディングを使用すると、シャードキー値のハッシュを計算し、すべてのチャンクにハッシュ値の範囲を割り当てます。 範囲シャーディングを使用すると、MongoDBはデータをシャードキー値に基づいて範囲に分割し、すべてのチャンクに範囲を割り当てます。

シャード全体でチャンクの分散のバランスを取ることも重要です。 MongoDBのデフォルトのチャンクサイズは64メガバイトです。 チャンクが指定されたサイズ制限を超えた場合、または構成された制限を超えたドキュメント数を超えた場合、MongoDBはシャードキー値に基づいてチャンクを分割します。 さらに、MongoDB は、シャード間でチャンクを自動的に移行するバランサープロセスを実行して、均等な分散を実現します。

データの局所性を向上させるために、MongoDBはゾーンの概念を提供します。 これは、シャードが複数のデータセンターにまたがる場合に特に便利です。 シャードクラスターでは、シャードキーに基づいてゾーンを作成できます。 さらに、各ゾーンをクラスター内の1つ以上のシャードに関連付けることができます。 したがって、MongoDBは、ゾーンによってカバーされるチャンクを、このゾーンに関連付けられているシャードにのみ移行します。

5.2. 調整

MongoDBは、複数のマシンにデータを分散する方法としてシャーディングを使用します。 したがって、MongoDBのシャーディングされたクラスターは水平方向にスケーラブルです。 シャードにはデータのサブセットが含まれており、各シャードはレプリカセットとして展開できます。 クラスターは、メタデータと構成設定を格納するためのmongos、クエリルーター、および構成サーバーでも構成されます。

レプリカセットは、MongoDBで自動フェイルオーバーとデータ冗長性を提供します。 上記のように、レプリカセットは、同じデータセットを維持するmongodインスタンスのグループです。 プライマリは、oplogと呼ばれる操作ログに記録することにより、すべての書き込み操作を処理します。 次に、セカンダリはプライマリのoplogを非同期的に複製します。

プライマリが設定された期間セカンダリと通信しない場合、適格なセカンダリは、選挙を要求することにより、新しいプライマリとして自分自身を指名することができます。 一次および二次とは別に、選挙に参加するがデータを保持しないアービターとして知られるmongodの追加のインスタンスを持つことができます。 クラスタは、新しいプライマリの選出を完了しようとします。

これにより、MongoDBでデータ損失の余地が残されますが、適切な書き込みの懸念事項を選択することで、データ損失を最小限に抑えることができます。 書き込みの懸念は、MongoDBにを要求する確認のレベルです。 「過半数」の書き込みに関する懸念は、データを保持する投票メンバーの計算された過半数に書き込み操作が伝播したことの確認を要求することを意味します。

6. Redis

Redis は、データベース、キャッシュ、さらにはメッセージブローカーとしても使用できるオープンソースのデータ構造ストアです。 いくつか例を挙げると、文字列、リスト、マップなどのさまざまな種類のデータ構造をサポートしています。 これは主に、オプションの耐久性を備えたメモリ内のKey-Valueストアです。

Redisは、スレーブがマスターの正確なコピーであるマスタースレーブアーキテクチャを使用して高可用性を提供します。 マスターノードは、クライアントからの書き込み要求を受け入れます。 さらに、スレーブノードへの書き込みを非同期で複製します。 ただし、クライアントはWAITコマンドを使用して同期レプリケーションを要求できます。 したがって、Redis は、強一貫性よりも可用性とパフォーマンスを優先します。

6.1. データ配信

水平スケーリングの恩恵を受けるために、パーティションデータを複数のインスタンスに再分割します。 範囲分割やハッシュ分割など、データを分割するためのいくつかの代替メカニズムを提供します。 現在、範囲の分割は単純ですが、使用するのはあまり効率的ではありません。 それどころか、ハッシュ分割ははるかに効率的であることが証明されています。

ハッシュ分割の基本的な前提は単純です。 キーを取得し、CRC32などの標準のハッシュ関数を使用して、キーのハッシュを生成できます。これは数値にすぎません。 次に、ハッシュに対してモジュロ演算を実行して、このキーをマップできるインスタンスを取得します。 明らかに、これにはコンシステントハッシュのパフォーマンスが向上するという特定の制限があります。

これで、Redisのソフトウェアスタックのさまざまな部分でパーティション分割を実行できます。 クライアント側から始めて、一部のRedisクライアントはクライアント側のパーティショニングを実装します。 次に、Twemproxyのようなプロキシがパーティショニングを処理するプロキシベースのパーティショニングを行いました。

ここで、Redis Sentinelは、インスタンスまたはシャード内で自動フェイルオーバーを提供することにより、高可用性を提供します。 最後に、クエリルーティングを使用することもできます。この場合、クラスター内の任意のランダムインスタンスは、リクエストを適切なノードにルーティングすることでリクエストを処理できます。

Redis Clusterは、自動パーティショニングと高可用性を可能にするため、同じことを実現するための推奨される方法です。 クエリルーティングとクライアント側のパーティショニングを組み合わせて使用します。 Redisクラスターは、すべてのキーがハッシュスロットの一部であるシャーディングの形式を使用します。 Redisクラスターには16384個のハッシュスロットがあり、すべてのノードがこのサブセットを担当します。

6.2. 調整

Redis Clusterは、Redisの分散実装であり、高性能の目標、線形のスケーラビリティ、高可用性、および許容可能な程度の書き込みの安全性を備えています。 これは、複数のマスターとスレーブで構成されるアクティブ-パッシブアーキテクチャに従います。

Redisクラスター内のノードは、データの保持、キーの適切なノードへのマッピング、クラスター内の他のノードの検出、および必要に応じてスレーブノードのマスターへの昇格を担当します。 これらすべてのタスクを実行するために、Redisクラスター内のすべてのノードはTCPバスとRedisクラスターバスと呼ばれるバイナリプロトコルによって接続されます。 さらに、ノードはゴシッププロトコルを使用してクラスターに関する情報を伝達します。

Redisクラスターは非同期レプリケーションを使用するため、障害に対する適切な書き込みの安全性を提供する必要があります。 Redis Clusterは、最後のフェイルオーバー勝ちの暗黙的なマージ機能を使用します。 これが意味するのは、最後に選択されたマスターデータセットが最終的に他のすべてのレプリカを置き換えるということです。 これにより、パーティション化中に書き込みが失われる可能性がある小さな時間枠が残ります。 ただし、 Redisは、ほとんどのマスターに接続しているときにクライアントが実行する書き込みを保持するために最善を尽くします。

Redis Clusterは、コマンドを適切なノードにプロキシしません。 代わりに、キースペースの特定の部分にサービスを提供する適切なノードにクライアントをリダイレクトします。 クライアントはすべてのクラスターノードに自由にリクエストを送信し、必要に応じてリダイレクトされます。 ただし、最終的に、クライアントはクラスターに関する最新情報を受け取り、適切なノードに直接接続できます。

7. Apache Kafka

Kafka は、リアルタイムデータフィードを処理するための統合された高スループット、低レイテンシのシステムを提供するために構築されたオープンソースプラットフォームです。 これにより、イベントのストリームをパブリッシュおよびサブスクライブし、イベントのストリームを永続的かつ確実に格納し、発生したイベントまたは遡及的にイベントのストリームを処理できます。

耐久性と可用性を強化するために、Kafkaは自動フェイルオーバーを使用して複数のノード間でデータを複製します。 イベントは、すべての同期レプリカがイベントを消費した場合にのみコミットされたと見なされます。 さらに、コミットされたコンシューマーのみがメッセージを受信できます。 したがって、 Kafkaは一貫性が高く、利用できるように設計されており、で遊ぶための多くの構成があります。

7.1. データ配信

Kafkaは、トピック内のイベントを整理し、永続的に保存します。 プロデューサーはトピックにイベントを公開するアプリケーションであり、コンシューマーはトピックからのイベントをサブスクライブするアプリケーションです。 すべてのトピックを1つ以上のパーティションに分割し、スケーラビリティーのためにそれらを異なるノードに分散させることができます。 これにより、複数のコンシューマーがトピックからデータを並行して読み取ることもできます。

ここでのパーティションは簡単に言えば、プロデューサーの観点からはコミットログが追加モードで機能します。 パーティション内の各イベントには、オフセットと呼ばれる識別子があり、コミットログ内のイベントの位置を一意に識別します。  さらに、Kafkaは、トピック内のイベントを構成可能な期間保持します。

プロデューサーは、にイベントを公開するパーティションを制御できます。 これは、使用可能なパーティション間でランダムな負荷分散を行うことも、セマンティックパーティショニング機能を使用することもできます。 Kafkaがイベントを固定パーティションにハッシュするために使用できるパーティションキーを定義できます。 これにより、消費者にとって重要になる可能性のあるパーティション内のイベントの局所性が生じます。

コンシューマーは、任意のオフセットポイントからイベントを読み取ることを選択できます。 Kafkaのコンシューマーグループは、複数のコンシューマーを論理的にグループ化して、トピックのパーティションの消費を負荷分散します。 Kafkaは、コンシューマーグループ内の1つのコンシューマーにのみトピックパーティションを割り当てます。 グループ内のコンシューマーの数が変更されると、Kafkaは自動的にコンシューマー間のパーティション割り当てのバランスを取り直そうとします。

7.2. 調整

Kafkaクラスターは通常、複数のデータセンターまたはクラウドリージョンにまたがることができる複数のサーバーで構成されます。 それらは高性能TCPネットワークプロトコルを使用して相互におよびクライアントと通信します。 データを保持するサーバーをブローカーとしてのトピックパーティションと呼びます。 各ブローカーはいくつかのパーティションを保持します。

さらに、KafkaはZooKeeperを使用して、パーティションの場所やトピックの構成などのメタデータを保存します。

ご覧のとおり、Kafkaは、構成可能な数のブローカー間で各トピックのパーティションのログも複製します。 トピックへのすべての書き込みと読み取りは、パーティションのリーダーを通過します。 リーダーは、レプリカを新しいデータで更新するように調整します。 リーダーに障害が発生した場合、レプリカの1つが自動フェイルオーバーを通じてリーダーの役割を引き継ぎます。

Kafkaは、ZooKeeperとのセッションを維持でき、リーダーに大きく遅れをとらない場合、レプリカを同期レプリカ（ISR）として定義します。 Kafkaへの書き込みは、すべての同期レプリカが書き込みを受信するまでコミットされたとは見なされません。 さらに、一連の同期レプリカのメンバーのみがリーダーとして選出される資格があります。 したがって、Kafkaは、コミットされたデータを失うことなく、1つを除くすべての同期レプリカの失敗を許容できます。

Kafkaクライアントの構成と使用方法に応じて、さまざまなメッセージ配信セマンティクスを実現できます。 たとえば、多くても1回、少なくとも1回、または正確に1回です。 プロデューサー側では、プロデューサーの acksプロパティとブローカーのmin.insync.replicaプロパティを構成することで、異なる配信セマンティクスを実現できます。 同様に、コンシューマー側では、 enable.auto.commit などの構成を使用して、配信セマンティクスを制御できます。

8. CAP定理のメモ

Eric Brewerは、CAP定理を保証できる属性の観点から分散システムの制約を定義すると仮定しました。 基本的に、分散システムは次の3つの保証のうち2つ以上を同時に提供できないことを意味します。

• 一貫性：すべての読み取りは、最新の書き込みまたはエラーを受け取ります
• 可用性：最新の書き込みでなくても、すべての読み取りはエラー以外の応答を受け取ります
• パーティショントレランス：ネットワークの一部に障害が発生した場合でも、システムは機能し続けます

上記では、CAP定理が分散システムを分類するためのガイドスターとしてどのように使用されているかを確認できます。 しかし、この分類はしばしば過度に単純化されており、誤った方向に進んでいる可能性があり、ある程度不必要でもあります。

現在、分散システムでは、ネットワークパーティションの可能性を完全に排除することはほとんど不可能です。 したがって、基本的に、CAP定理の意味は一貫性または可用性の間のトレードオフを行うことになります。 したがって、分散型であると主張するシステムとCAは、それらが動作するネットワークをしっかりと信頼している必要があります。

しかし、前に説明したいくつかの分散システムのコンテキストで見たように、それは本当に簡単な選択ではありません。 したがって、これらのシステムのほとんどは、標準要件として動作を選択できるように、構成で多くの制御を提供します。 したがって、これらのシステムを単にCPまたはAPとして分類することは、ほとんど公平ではなく、正しくさえありません。

9. 結論

このチュートリアルでは、分散システムの基本を理解し、主な利点と課題を理解しました。 さらに、データストアやメッセージングシステム全体で人気のある分散システムのいくつかを幅広く評価しました。

分散アーキテクチャでデータの分散と調整をどのように実現するかを強調しました。