分散システムとは、存在すら知らなかったコンピューターの障害によって、自分のコンピューターが使用できなくなる可能性があるシステムです。 AM チューリング賞受賞者のレスリー・ランポートのこの有名な言葉は、分散システムの構築と維持における課題を要約しています。しかし、なぜこのような複雑なシステムが必要なのでしょうか? インターネットとよりスマートなデバイスの出現により、処理する必要のあるデータの量は爆発的に増加しました。Uber の注文、Netflix での番組の視聴、簡単な Google 検索、オンライン ショッピング、ソーシャル メディアでのやり取りなど、私たちが当たり前だと思っている日常の些細な行動はすべて、数百の分散サービスによって実現されています。これらのサービスはすべて、分散システムに関するいくつかの基礎論文を基盤として構築されています。 このリストは決して包括的なものではありませんが、分散システムの世界に大きな影響を与えた私のお気に入りの論文をいくつか紹介します。 CAP定理 伝統的な論文ではありませんが、エリック・ブリューワーは2000年のACMシンポジウム「分散コンピューティングの原理（PODC）」の基調講演でこの仮説を初めて発表しました。この論文は後にナンシー・リンチとセス・ギルバートによって で形式化され、証明されました。 「ブリューワーの仮説と一貫性があり、利用可能で、パーティション耐性のあるWebサービスの実現可能性」という論文 Eric Brewer の CAP 定理は分散システム理論の基本概念であり、分散データ ストアが一貫性、可用性、パーティション耐性の 3 つの保証のうち 2 つ以上を同時に提供することは不可能であると述べています。ここで言及されている他のすべての論文は、上記の原則を適用し、システム内で必要なトレードオフを行っています。 CAP 定理は、論文に対する読者の理解に基づいて、常に多くの議論を引き起こします。Martin Kleppmann の「 」は、トレードオフについて議論するためのより優れたフレームワークを提供します。 CAP 定理の批判 Paxos をシンプルに 2001 年のこの独創的な で、Leslie Lamport は、分散システムで簡単かつアクセスしやすい方法で合意を達成するための Paxos アルゴリズムを紹介しています。Paxos ベースの合意プロトコルは、多くのテクノロジー企業が使用する多くの分散データベース、ストレージ システム、メッセージング プラットフォーム、調整サービスのバックボーンを形成しています。これは、Google の Chubby、Google の Spanner、Apache ZooKeeper、Apache BookKeeper などの他のテクノロジーに大きな影響を与えました。 論文 Google ファイル システム では、コモディティ ハードウェア上の大規模な分散データ集約型アプリケーション向けのスケーラブルな分散ファイル システムを紹介しており、これがその後の多くの分散ファイル システムの基礎となっています。GFS は、Apache Hadoop フレームワークで使用される分散ファイル システムである HDFS や、最終的には Amazon S3 (ただし、s3 は根本的に異なります) に大きな影響を与えました。 Google File System (GFS) の論文 MapReduce: 大規模クラスタでの簡素化されたデータ処理 この 、分散コンピューティング インフラストラクチャを使用して大規模なデータセットを処理するためのスケーラブルなアプローチを示す MapReduce プログラミング モデルを紹介します。MapReduce は「ビッグ データ」革命において極めて重要な役割を果たし、組織が分散コンピューティングのパワーを活用して大量のデータセットを分析し、そこから洞察を引き出すことを可能にしました。GFS と MapReduce を組み合わせることで、Google がペタバイト単位のデータを処理し、「インターネット」のデータを整理できるようになったことがわかります。 ホワイト ペーパーでは MapReduce の論文 (GFS とともに) は、Apache Hive (Hadoop 上に構築されたデータ ウェアハウス インフラストラクチャ)、Apache Pig (Hadoop 用の高レベル データ フロー言語)、Apache Spark (メモリ内データ処理エンジン)、Apache HBase (分散型 NoSQL データベース) など、Apache Hadoop を中心に構築されたツールとライブラリのエコシステム全体の開発に影響を与えました。 Bigtable: 構造化データ用の分散ストレージ システム Google で構造化データを管理するための分散ストレージ システムを表しています。MapReduce と GFS によって Google がコスト効率の高い方法で大規模なデータを処理できるようになった後、次のステップは信頼性が高く可用性の高い方法でデータにアクセスできるようにすることでした。Bigtable は、Web インデックス作成、Google Earth、Google Finance などのアプリケーションに柔軟で高性能なソリューションを提供できました。 Bigtable の論文は、 MapReduce が「ビッグデータ」時代に革命をもたらしたのと同様に、BigTable 論文は「NoSQL」時代の原動力となりました。Bigtable 論文で紹介された設計原則やアーキテクチャ概念の多くは、「Apache HBase」、「Cassandra」、「MongoD」などのテクノロジーで使用されました。これらのアプリケーションの一部は異なるデータ モデル (MongoDB など) を使用する場合もありますが、水平スケーラビリティ、フォールト トレランス、自動シャーディングなどの共通原則を共有しています。 Dynamo: Amazon の高可用性キーバリューストア では、Amazon が開発した可用性の高いキーバリュー ストアの設計と実装について紹介されています。Dynamo は、ショッピング カート内のアイテムなど、非常に動的なデータへのリアルタイム アクセスのニーズに対処しました。この論文では、分散システム設計のコア原則として「最終的な一貫性」の概念を紹介し、緩やかな一貫性保証によって高い可用性とパフォーマンスを実現できるようにしています (CAP 定理のようなものです)。 Dynamo の論文 論文自体には、「Bigtable と比較して、Dynamo は、ネットワークの分割やサーバーの障害が発生しても更新が拒否されない高可用性に主眼を置き、キー/値アクセスのみを必要とするアプリケーションを対象としています。」と書かれています。 BigTable と同様に、Dynamo の論文は、Riak、Voldemort、Cassandra などの後続のテクノロジー、さらには Apache Kafka などのイベント ストリーミング テクノロジーに大きな影響を与えました。 Cassandra - 分散型構造化ストレージ システム Facebook の急速な成長には、膨大な量のデータを処理し、多数の同時ユーザーをサポートできるデータベース ソリューションが必要でした。BigTable と Dynamo はそれぞれ大きな影響力を持っていましたが、Cassandra は他のテクノロジよりも一歩先を行く最初のテクノロジでした。Facebook は、Apache ライセンスの下で Cassandra をオープンソース コントリビューションとしてリリースし、 も公開することで、業界全体がこのようなテクノロジにアクセスできるようにすることに尽力しました。 論文 Cassandra は、調整可能な一貫性モデルを提供することで、前の 2 つとの差別化を図り、ユーザーがアプリケーションの要件に基づいて、強力な一貫性 (BigTable など) と最終的な一貫性 (Dynamo など) を選択できるようにしました。 ZooKeeper: インターネット規模のシステムのための待機なしの調整 この では、Apache ZooKeeper を紹介し、分散システムで信頼性が高くスケーラブルな調整サービスを提供するための設計原則とアルゴリズムについて説明します。ZooKeeper が導入される前は、ソフトウェア開発者は分散システムでの分散調整とコンセンサスのために独自のアドホック ソリューションを実装する必要がありました。 ホワイト ペーパー ZooKeeper は、分散調整のための集中型サービスを提案し、分散ロック、リーダー選出、構成管理などのプリミティブを提供しました。これにより、複雑な調整ロジックを ZooKeeper にオフロードすることで、分散アプリケーションの開発を簡素化できました。Zookeeper を使用する最も一般的なユースケースの 1 つは、サービス検出です。 Apache Kafka: ログ処理のための分散メッセージング システム この 、イベント ストリームの高スループットでフォールト トレラントな処理向けに設計された分散メッセージング システムである Apache Kafka を紹介します。Kafka は、研究論文として公開され、Apache プロジェクトとしてオープン ソースとしてリリースされたことで、高度にスケーラブルでフォールト トレラントなリアルタイム データ処理とイベント駆動型アーキテクチャの標準メッセージング システムとして確立されました。 論文では Kafka は、大量のデータ ストリームをリアルタイムで処理するために設計された、スケーラビリティとフォールト トレラント性に優れたメッセージング システムを導入しました。Kafka は、バッチ処理とストリーム処理を組み合わせて低レイテンシと高スループットで大量のデータを処理する Lambda アーキテクチャの開発を可能にする上で大きな影響力を持っていました。 回復力のある分散データセット: インメモリ クラスタ コンピューティングのためのフォールト トレラントな抽象化 このホワイト ペーパーでは、分散クラスター全体でフォールト トレラント インメモリ データ処理を可能にする、Apache Spark のコア抽象化である Resilient Distributed Datasets (RDD) を紹介します。Spark のインメモリ実行エンジンは、特に反復アルゴリズム、機械学習、インタラクティブ分析において、ディスクベースの実行モデルを持つ MapReduce と比較して大幅に高速なパフォーマンスを提供します。 な これらの論文は、ストレージ システム、コンセンサス アルゴリズム、フォールト トレランス、スケーラビリティなど、分散システムの幅広いトピックをカバーしています。これらの論文を読むことで、分散システムの構築と管理の原則と実践に関する強固な基礎が得られます。 分散システムの勉強を始めてもっと学びたい場合、またはすでに専門家で基礎を復習したい場合、分散システムに関する基礎論文を読むことほど良い学習方法はありません。
