Overview
This video introduces the CAP theorem, a key principle of distributed systems that captures a hard design trade-off. A distributed system connects ordinary servers over a network so that users see one large system, mainly for scalability and fault tolerance. That matters even for services used only in Japan: they must survive traffic spikes such as ticket sales, or keep running from Osaka if an earthquake hits a Tokyo data center. But with many servers, keeping their data in sync becomes the problem.
Key Points
- C, A and P stand for consistency (always returning the latest data), availability (always responding without errors) and partition tolerance (continuing to work when communication between servers is cut). The theorem says a distributed system can satisfy only two of the three at once.
- In normal operation, C and A coexist. The practical reading is that when a partition occurs, the system must give up either consistency or availability.
- If isolated nodes keep accepting writes, their data diverges and conflicts when the partition heals. If they stop to protect consistency, they return errors.
- Google Bigtable and MongoDB favor CP, although Google’s very robust networks keep partitions rare. Amazon DynamoDB favors AP; it first offered only eventual consistency but now also offers strongly consistent reads as an option. Apache Cassandra is AP by default, but each request can set how many servers must confirm, moving it toward consistency.
- The video recommends Designing Data-Intensive Applications, especially Chapter 9 on consistency and consensus, for going deeper.
Chapters
- 0:00 Introduction
- 0:17 What is a distributed system?
- 0:39 Two reasons to distribute
- 0:57 Is it needed for domestic systems too?
- 1:34 A new problem: how to keep data in sync
- 1:49 Defining C, A and P
- 2:21 The essence of the CAP theorem
- 2:41 Normal operation vs. network partitions
- 4:19 How it applies to real databases
- 6:18 Summary
- 8:27 Book recommendation
概要
この動画では、分散システムの重要な原則であり、設計上の難しいトレードオフを示すCAPの定理を紹介します。分散システムとは、ネットワークでつないだ普通のサーバーを連携させ、ユーザーからは1つの大きなシステムに見せる仕組みで、主な目的は拡張性と耐障害性です。これは国内向けのサービスでも欠かせません。チケット予約のようなアクセス集中に耐えたり、地震で東京のデータセンターが被災しても大阪で運用を続けたりする必要があるからです。ただしサーバーが増えると、それぞれのデータをどう同期するかが問題になります。
ポイント
- C、A、Pは、整合性（常に最新のデータを返す）、可用性（エラーを出さずに応答し続ける）、分断耐性（サーバー間の通信が途切れても動き続ける）を表します。定理は、分散システムでは3つのうち同時に2つしか満たせないと主張します。
- 通常時はCとAが両立します。実務的には、ネットワーク分断が起きたときに整合性と可用性のどちらかを犠牲にしなければならない、と読むのが明確です。
- 孤立したノードが書き込みを受け付け続けると、データが食い違い、分断が解消したときに衝突します。整合性を守るために止まれば、エラーを返すことになります。
- Google BigtableとMongoDBはCPを重視しますが、Googleは非常に強固なネットワークで分断そのものを起きにくくしています。Amazon DynamoDBはAPを重視し、当初は結果整合性のみでしたが、現在はオプションで強い整合性の読み取りも選べます。Apache Cassandraは基本的にAPですが、何台のサーバーの確認を待つかをリクエストごとに決められ、整合性寄りの動きにもできます。
- さらに深く学ぶ本として『データ指向アプリケーションデザイン』、特に一貫性と合意を扱う第9章を勧めています。