分散システムの基礎

多くのシステムは、構築と管理が簡単なため、単一サーバーから始まります。小規模であれば、1台のマシンでリクエストの処理、ロジックの実行、データの保存を複雑さをあまり伴わずに行えます。

利用が増えると、このモデルは限界に達します。トラフィックの増加はレイテンシの上昇とリソース枯渇を招き、データセットの肥大化はクエリを遅くし、ストレージシステムに負荷をかけます。

信頼性も大きな問題になります。その1台のサーバーが故障すると、システム全体が停止します。継続的な可用性が必要なシステムでは、これは受け入れられません。

これらの制約を克服するために、システムは複数のマシンに処理を分散します。1台のサーバーに依存するのではなく、ワークロードを共有することでスケーラビリティとフォールトトレランスを実現しますが、その代わりに調整と整合性という新たな課題が生まれます。

分散システムでは、複数のサーバーが協力してリクエストを処理し、データを保存し、ロジックを実行します。各サーバーは別々のマシンであり、しばしば異なる場所で動作していますが、ユーザーの視点ではまとめて1つのシステムを構成しています。

単一マシンのシステムとは異なり、これらのノードはメモリを共有しません。その代わりに、ネットワーク越しにメッセージを送って通信するため、遅延や障害の可能性が生じます。

そのため、調整が非常に重要になります。ノードは、データ値やシステムの判断などの共有状態について合意しなければなりません。たとえ物理的には離れていてもです。

重要な課題は、遅延、障害、ネットワーク越しの部分的な可視性がある中で、この独立したマシンの集まりを、1つのシステムとして一貫性と信頼性を持って動作させることです。

レプリケーションは、同じデータを複数のマシンに保存する分散システムの中核的な技術です。通常、1つのノードがプライマリとして書き込みを担当し、他のノードはデータのコピーを受け取るレプリカとして動作します。

この構成により信頼性が向上します。プライマリまたは任意のレプリカが故障しても、システムは残りのノードを使って動作を継続でき、ダウンタイムを減らせます。

レプリケーションは、特に読み取りが多いシステムで性能も向上させます。すべての読み取りリクエストを1台のマシンに送る代わりに、リクエストを複数のレプリカに分散できます。

ただし、レプリケーションには複雑さも伴います。更新を各ノードへ伝播させる必要があり、同期の遅延によってレプリカ間に一時的な不整合が生じることがあります。

分散システムでは、マシンはネットワーク越しに通信しますが、ネットワークは本質的に信頼性が低いものです。接続が切れたり、メッセージが遅延したり、システム全体の一部に到達できなくなったりすることがあります。

ネットワークパーティションは、ノードが互いに通信できないグループに分断されるときに発生します。たとえば、Server A はネットワーク障害のために Server B に到達できないことがありますが、両方ともまだ稼働しています。

これにより、根本的な課題が生まれます。パーティションの各側は独立してリクエストを処理し続ける可能性があり、その結果、状態の不整合が発生することがあります。

パーティション耐性とは、ノード間の調整が一時的に不可能になることを受け入れつつ、こうした障害があっても動作を継続できるようにシステムを設計することを意味します。

分散システムでは、データは複数のマシンに複製されることが多く、そのデータを同期し続けるという問題が生じます。一貫性は、それらのレプリカがある時点でどれだけ揃っているかを定義します。

強い一貫性では、一度書き込みが発生すると、その後のすべての読み取りは、どのノードにアクセスしても、更新された値を即座に返します。これにはノード間の緊密な調整が必要です。

結果整合性では、更新は時間をかけて伝播します。書き込みの後、一部のノードは一時的に古いデータを返すことがありますが、最終的にはすべてのノードが同じ状態に収束します。

このトレードオフは避けられません。厳密な一貫性を強制するシステムは、特にネットワーク遅延や障害がある場合、パフォーマンスや可用性を犠牲にすることがよくあります。

CAP定理は、分散システムにおける厳しい制約を表しています。ネットワーク分断が発生したとき、完全な一貫性と完全な可用性を同時に維持することはできません。

一貫性を保つには、ノード間の調整が必要です。すべての読み取りで最新の書き込みを返すには、ノードが現在の状態について合意する必要があり、そのためにネットワーク越しの通信を待つ必要がある場合があります。

一方で、可用性は応答性を優先します。いくつかのノードに到達できなくてもシステムはリクエストを処理し続けますが、その結果、古いデータや不整合なデータを返すことがあります。

分断耐性は、実際のシステムでは避けられません。どんな現実のシステムでもネットワーク障害は起こるためです。そのため、システムはトレードオフを迫られます。分断中は、一貫性を保つために応答を遅らせるか、すぐに応答して一時的な不整合を受け入れるかのどちらかを選ばなければなりません。

分散システムでは、複数のノードが独立して動作しますが、多くの操作では協調して動くことが必要です。協調がないと、ノード同士が矛盾する決定を行い、不整合なデータやシステム障害につながる可能性があります。

リーダー選出は、1つのノードを選んで意思決定や重要なタスクを担当させる一般的なパターンです。これにより、複数のノードが同じ操作を同時に実行することを防げます。

分散ロックは、単一マシンの並行処理におけるロックと同様に、1つのノードだけが共有リソースに同時にアクセスまたは変更できるようにしますが、ネットワーク全体にわたって実装されます。

コンセンサスアルゴリズムはさらに進んで、障害が存在してもノードがある値や決定について合意できるようにします。ZooKeeper、etcd、Consul のようなツールは、これらの協調メカニズムを提供するため、エンジニアはゼロから実装する必要がありません。

システムが分散されると、ネットワーク上で動作しなければならず、ネットワークは本質的に信頼性が低いものです。メッセージは遅延したり、失われたり、順不同で届いたりするため、単純な操作でも推論がずっと難しくなります。

データの一貫性も課題になります。複製があると、特に負荷が高い場合やネットワーク遅延がある場合に、異なるノードが同じデータの異なるバージョンを持つことがあります。

ノード間の調整は、さらに別の難しさを加えます。複数のマシンが共有状態について合意したり、タスクを正しい順序で実行したりするには、複雑なプロトコルと慎重な設計が必要です。

これらの課題は例外的なケースではなく、本質的なものです。こうした問題があっても正しく信頼性の高いシステムを設計することが、分散システム工学が解決しようとする中心的な問題です。