system-architecture

システムアーキテクチャの専門知識

このスキルを使用するタイミング

次の場合にこのスキルを使用します。

• 分散システムを設計するとき
• システム設計ドキュメントを作成するとき
• システム設計の面接に備えるとき
• アーキテクチャ図を作成するとき
• 設計上の選択肢の間でトレードオフを分析するとき
• 既存のシステム設計をレビューまたは改善するとき

システム設計のフレームワーク

1. 要件の収集（5～10 分）

機能要件：

• 中核となる機能は何ですか？
• ユーザーはどのような操作を行えますか？
• 入力と出力は何ですか？

非機能要件：

• 規模：ユーザー数はどれくらいですか？データ量はどれくらいですか？
• パフォーマンス：レイテンシの要件は何ですか？（p50、p95、p99）
• 可用性：必要な稼働率はどれくらいですか？（99.9%、99.99%）
• 一貫性：強い一貫性ですか、それとも結果整合性ですか？

制約：

• 予算上の制限
• 技術スタックの制約
• チームの専門知識
• スケジュール

質問の例：

- How many daily active users?
- What's the read:write ratio?
- What's the average data size?
- What's the peak load vs average load?
- Do we need real-time updates?
- Can we have data loss?

2. 容量の見積もり（概算）

計算項目：

Traffic:
- DAU = 100M users
- Each user makes 10 requests/day
- QPS = 100M * 10 / 86400 ≈ 11,574 QPS
- Peak QPS = 2-3x average ≈ 30,000 QPS

Storage:
- 100M users * 1KB per user = 100GB
- With 3x replication = 300GB
- Growth: 300GB * 365 days = 109.5TB/year

Bandwidth:
- QPS * average request size
- 11,574 * 10KB = 115.74MB/s

メモリ／キャッシュ：

• 80 対 20 の法則：データの 20% がトラフィックの 80% を占めます
• キャッシュ：頻繁に使われるデータ用に、全データの 20% を確保します

3. 高レベル設計

中核コンポーネント：

1. クライアント層（Web、モバイル、デスクトップ）
2. API ゲートウェイ／ロードバランサー
3. アプリケーションサーバー（ビジネスロジック）
4. キャッシュ層（Redis、Memcached）
5. データベース（SQL、NoSQL、または両方）
6. メッセージキュー（Kafka、RabbitMQ）
7. オブジェクトストレージ（S3、GCS）
8. CDN（CloudFront、Akamai）

アーキテクチャを図示する：

[Clients] → [CDN]
            ↓
        [Load Balancer]
            ↓
    [Application Servers]
        ↙     ↓     ↘
   [Cache] [DB] [Queue] → [Workers]
                            ↓
                      [Object Storage]

4. データベース設計

SQL と NoSQL の選択：

SQL を使用する場合：

• ACID トランザクションが必要
• JOIN を伴う複雑なクエリ
• 関係性のある構造化データ
• 例：PostgreSQL、MySQL

NoSQL を使用する場合：

• 大規模なスケール（水平スケーリング）
• 柔軟なスキーマ
• 高い書き込みスループット
• 例：Cassandra、DynamoDB、MongoDB

シャーディング戦略：

• ハッシュベース：user_id % num_shards
• 範囲ベース：ユーザー 1～100M をシャード 1 に配置
• 地理ベース：米国のユーザーを米国のシャードに配置
• コンシステントハッシュ：均等に分散するために使用

スキーマ設計：

-- Example: URL Shortener
CREATE TABLE urls (
    id BIGSERIAL PRIMARY KEY,
    short_url VARCHAR(10) UNIQUE NOT NULL,
    long_url TEXT NOT NULL,
    user_id BIGINT,
    created_at TIMESTAMP DEFAULT NOW(),
    expires_at TIMESTAMP,
    click_count INT DEFAULT 0,
    INDEX (short_url),
    INDEX (user_id)
);

5. コンポーネントの詳細

キャッシュ戦略：

• キャッシュアサイド：アプリはキャッシュを読み取り、キャッシュミス時に DB から読み込みます
• ライトスルー：キャッシュと DB に同時に書き込みます
• ライトビハインド：キャッシュに書き込み、非同期で DB に書き込みます

退避ポリシー：

• LRU（最も最近使われていない項目）— 最も一般的
• LFU（最も使用頻度の低い項目）
• TTL（有効期間）

ロードバランシング：

• ラウンドロビン：シンプルで均等に分散
• 最小接続数：最も負荷の低いサーバーにルーティング
• コンシステントハッシュ：再分散を最小限に抑制
• 重み付け：サーバーの容量に基づく

メッセージキューのパターン：

• パブリッシュ／サブスクライブ：1 対多（通知）
• ワークキュー：タスクの分散（ジョブ処理）
• ファンアウト：複数のキューにブロードキャスト

6. スケーラビリティのパターン

水平スケーリング：

• サーバーを追加する
• ロードバランサーを使用する
• アプリケーションサーバーをステートレスにする
• セッションをキャッシュ／DB に保存する

垂直スケーリング：

• サーバーの CPU／RAM を増やす
• ハードウェアによる制限がある
• シンプルだが限界がある

マイクロサービス：

Monolith:
[Single App] → [DB]

Microservices:
[User Service] → [User DB]
[Post Service] → [Post DB]
[Feed Service] → [Feed DB]

利点：

• 独立してスケーリングできる
• 技術を柔軟に選択できる
• 障害を分離できる

欠点：

• 複雑さが増す
• ネットワークレイテンシが発生する
• 分散トランザクションが必要になる

7. 信頼性と可用性

レプリケーション：

• マスター／スレーブ：書き込み用ノードが 1 つ、読み取り用ノードが複数
• マスター／マスター：書き込み用ノードが複数（競合の解決が必要）
• マルチリージョン：地理的な冗長性

フェイルオーバー：

• アクティブ／パッシブ：スタンバイサーバーが引き継ぐ
• アクティブ／アクティブ：両方のサーバーがトラフィックを処理する

レート制限：

• トークンバケットアルゴリズム
• リーキーバケットアルゴリズム
• 固定ウィンドウカウンター
• スライディングウィンドウログ

サーキットブレーカー：

States:
Closed → Normal operation
Open → Reject requests immediately
Half-Open → Test if service recovered

8. 一般的なシステム設計パターン

コンテンツ配信：

• 静的アセットに CDN を使用する
• 地理的に分散したエッジサーバー
• エッジロケーションでキャッシュする

データの一貫性：

• 強い一貫性：読み取り結果に最新の書き込みが反映されます（ACID）
• 結果整合性：読み取り結果に最終的に書き込みが反映されます（BASE）
• CAP 定理：一貫性、可用性、分断耐性の 3 つから 2 つを選択します

API 設計：

RESTful:
GET    /api/users/{id}
POST   /api/users
PUT    /api/users/{id}
DELETE /api/users/{id}

GraphQL:
query {
  user(id: "123") {
    name
    posts {
      title
    }
  }
}

9. システム設計テンプレート

system_design/00_template.md に基づき、次の構成を使用してください。

# {System Name}

## 1. Requirements
### Functional
- [List core features]

### Non-Functional
- Scale: [Users, QPS, Data]
- Performance: [Latency requirements]
- Availability: [Uptime target]

## 2. Capacity Estimation
- Traffic: [QPS calculations]
- Storage: [Data size, growth]
- Bandwidth: [Network requirements]

## 3. API Design

[endpoint] - [description]

## 4. High-Level Architecture
[Diagram]

## 5. Database Schema
[Tables and relationships]

## 6. Detailed Design
### Component 1
[Deep dive]

### Component 2
[Deep dive]

## 7. Scalability
[How to scale each component]

## 8. Trade-offs
[Decisions and alternatives]

10. 実例

system_design/ の参考ケーススタディ：

• Netflix：動画ストリーミング、レコメンデーション
• Twitter：タイムライン、ツイートの保存、トレンド
• Uber：リアルタイムのマッチング、位置情報の追跡
• Instagram：画像の保存、フィードの生成
• WhatsApp：メッセージの配信、プレゼンス

一般的なパターン：

• ニュースフィード：書き込み時のファンアウトと読み取り時のファンアウト
• レートリミッター：Redis を使用したトークンバケット
• URL 短縮サービス：Base62 エンコーディング、ハッシュの衝突
• チャットシステム：WebSocket、メッセージキュー
• 通知：プッシュ通知サービス、APNs/FCM

面接のヒント

時間管理：

• 要件：10%
• 高レベル設計：25%
• 詳細な掘り下げ：50%
• まとめ：15%

コミュニケーション：

• 考えを声に出して説明する
• 不明点を確認する質問をする
• トレードオフについて話し合う
• 制限事項を認識する

面接官が評価する点：

• 問題解決への取り組み方
• 技術的な深さ
• トレードオフの分析
• スケールへの理解
• コミュニケーションスキル

避けるべきよくあるミス

• 要件を確認せずに解決策に飛びつく
• 単純な問題を過剰に設計する
• スケール要件を過小評価する
• 単一障害点を無視する
• 監視やアラートを考慮しない
• データの一貫性を忘れる
• セキュリティ上の考慮事項を見落とす

プロジェクトのコンテキスト

• テンプレートは system_design/00_template.md
• ケーススタディは system_design/*.md
• 確立されたドキュメントのパターンに従ってください