【読書メモ／System Design on AWS 第1章】堅牢なシステムを支える「土台」：システム設計の基本概念とトレードオフ

「システム設計」と聞くと、難解な図解や複雑な数式を思い浮かべるかもしれません。しかし、その本質は非常にシンプルです。それは「あちらを立てれば、こちらが立たず」というトレードオフの中で、最良のバランスを見つけることです。

本記事では、AWSで大規模システムを構築するためのバイブル『System Design on AWS』の第1章をもとに、プログラミング初心者の方でも「なるほど！」と思えるように各用語を噛み砕いて解説します。

この記事の背景
1. 通信：サーバー同士の「おしゃべり」
- 同期通信 (Synchronous)
- 非同期通信 (Asynchronous)
2. 一貫性：データの「正しさ」
- なぜ重要か？
- 一貫性のグラデーション（スペクトル）
3. 可用性：システムが「起きている」時間
- 「ナイン」の魔法
- 直列と並列のルール
4. 信頼性：どれくらい「頼りになる」か
5. スケーラビリティ：リソースの「伸ばし方」
- 垂直スケーリング (スケールアップ)
- 水平スケーリング (スケールアウト)
6. 保守性：未来の自分への「優しさ」
7. 耐障害性：ピンチからの「復旧力」
分散システムの「8つの罠（誤謬）」
究極の選択：トレードオフの正体
まとめ：大切なのは「It Depends（状況による）」
- 学んだことの整理
- 次にやること
参考リンク

この記事の背景

プログラミングを始めたばかりの頃は、「動くものを作る」ことに必死です。しかし、ユーザーが100人、1万人、100万人と増えていくと、ただ動くだけでは足りなくなります。

「急にアクセスが増えて止まった」「データが消えた」「更新したはずなのに古い情報が表示される」……。こうしたトラブルを防ぐために必要なのがシステム設計の知識です。第1章で語られる「土台」の部分を、丁寧に紐解いていきましょう。

1. 通信：サーバー同士の「おしゃべり」

システムは複数のサーバーが協力して動きます。その協力の方法には大きく分けて2種類あります。

同期通信 (Synchronous)

電話のようなものです。相手が返事をするまで、自分は受話器を持ったまま待機（ブロック）します。

メリット：すぐに結果がわかるので確実。
デメリット：相手の処理が遅いと、自分もずっと待たされる。

非同期通信 (Asynchronous)

メールやLINEのようなものです。メッセージを投げたら、返信を待たずに自分の作業に戻ります。

メリット：相手を待たなくていいので、自分の処理がスムーズ。
デメリット：いつ返事が来るかわからない。返事が来なかった時の対応（リトライなど）を考えておく必要がある。

2. 一貫性：データの「正しさ」

一貫性とは、どこから見てもデータが同じであることを指します。

なぜ重要か？

例えば、銀行で1万円おろしたのに、別のATMで見たらまだ残高が減っていない（古いデータが見える）としたら大問題ですよね。これが「一貫性がない」状態です。

一貫性のグラデーション（スペクトル）

強い一貫性：更新したら、0.1秒後でも全員が最新版を見れる。最高だけど、実現にはコストがかかり、システムの速度が落ちることもあります。
結果整合性：「そのうち全員に伝わるから、ちょっとの間だけ古いデータが見えても許してね」という考え。SNSの「いいね」数などは、一瞬のズレが命取りにならないので、これで十分なことが多いです。

3. 可用性：システムが「起きている」時間

可用性は、システムがどれだけ元気に動いているかを示す割合です。

「ナイン」の魔法

可用性は「99.9%（3ナイン）」のように「9」の数で数えます。

99%：年間3.6日も止まる。意外と多いですよね。
99.999%：年間わずか5分！これを目指すには、相当な工夫が必要です。

直列と並列のルール

直列：10台のサーバーが順番に並んでいると、どこか1台でも壊れたらアウト。全体の故障率は上がります。
並列：予備のサーバーを横に並べておけば、1台壊れても他がカバーします。「予備を持つ（冗長化）」だけで、可用性は爆発的に上がります。

4. 信頼性：どれくらい「頼りになる」か

可用性と似ていますが、少し違います。

可用性：「今、使える状態か？」
信頼性：「一定期間、壊れずに動いてくれるか？」

例えば、たまにエンジントラブルで止まるけどすぐ直る車は「可用性は高い（すぐ使えるようになる）」かもしれませんが、「信頼性は低い（いつ止まるか不安）」と言えます。MTBF（平均故障間隔）を伸ばすことが、信頼性向上のカギです。

5. スケーラビリティ：リソースの「伸ばし方」

アクセスが増えたときに、どう対応するか？

垂直スケーリング (スケールアップ)

1台のサーバーを「最強のサーバー」に改造することです。

イメージ：今あるキッチンのコンロを増やす。
限界：1台のスペックには物理的な上限があり、改造費用も高くなります。

水平スケーリング (スケールアウト)

安いサーバーを「たくさん並べる」ことです。

イメージ：同じようなキッチンを3つ作る。
強み：1台がダメになっても他でカバーでき、理論上は無限に増やせます。現代のクラウド設計の主流はこちらです。

6. 保守性：未来の自分への「優しさ」

システムは作って終わりではありません。

運用性：異常があったらすぐ気づけるか？
明快さ：コードを読んだときに「何これ？」とならないか？
修正しやすさ：一部を直したときに、全然関係ないところが壊れないか？

これらを意識することが、長く愛されるシステムを作る秘訣です。

7. 耐障害性：ピンチからの「復旧力」

壊れることを前提に、「壊れてもデータを守る」仕組みです。

レプリケーション：あらかじめコピーを作っておく。
チェックポイント：「ここまでのデータはセーブしたよ」という記録をこまめに取る。

ここで出てくるRPO（目標復旧時点）とRTO（目標復旧時間）という言葉は覚えておいて損はありません。「どれくらい前のデータまでなら消えても許せるか？」と「何分以内に復旧させるか？」という約束事のことです。

分散システムの「8つの罠（誤謬）」

システムを設計するとき、つい「ネットワークは常に完璧だ」と思い込んでしまいがちですが、それは誤謬（間違い）です。

1. ネットワークは信頼できる（→ いいえ、時々切れます）
2. 遅延はゼロである（→ いいえ、通信には時間がかかります）
3. 帯域幅は無限である（→ いいえ、道は混みます）
4. ネットワークは安全である（→ いいえ、ハッカーが狙っています）
5. トポロジーは変化しない（→ いいえ、サーバーは増減します）
6. 管理者は1人である（→ いいえ、たくさんの人が関わります）
7. 輸送コストはゼロである（→ いいえ、お金がかかります）
8. ネットワークは均質である（→ いいえ、色んな機器が混ざっています）

これらを「当たり前」だと思わずに設計することが、プロへの第一歩です。

究極の選択：トレードオフの正体

システム設計で最も有名なのがCAP定理です。「一貫性」「可用性」「分断耐性」の3つのうち、2つまでしか同時に満たせないというルールです。

しかし、現実はもっと複雑です。そこで出てくるのがPACELC（パセルク）定理です。

トラブル時：可用性と一貫性、どっちを取る？
正常な時でも：速さ（レイテンシ）と一貫性、どっちを優先する？

「100%完璧」は存在しません。「今回は速さを優先して、データの正しさは少しだけ待ってもらおう」といった判断をすることが、設計そのものなのです。

まとめ：大切なのは「It Depends（状況による）」

最後に、迷ったときのガイドラインを一つだけ紹介します。

「It Depends（状況による）」

「どの設計が最強ですか？」という質問に、唯一の答えはありません。

銀行なら、一貫性が命。
Twitterなら、一貫性より可用性（すぐに見れること）。

それぞれのユースケース（使い道）に合わせて、これまで紹介した概念のバランスを調整していきましょう。

学んだことの整理

テーマ	初心者がまず覚えること
通信	電話（待つ）か、メール（待たない）か
スケーリング	最強の1台を作るか、そこそこの10台を並べるか
トレードオフ	100点満点のシステムはない。バランスが大事。