Skip to content
Published on

アーキテクチャ事例研究 — Netflix・Stripe・Cloudflare・Shopify を 2025 年基準で深掘り

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 「理論 22 本終わった。現実はどう動く?」

Season 2 では原則とパターンを学んだ。Season 3 は現実の事例を扱う。

  • なぜ Netflix は 7,000 以上のマイクロサービスを運用するのか?
  • なぜ Stripe は今でも Ruby モノリスなのか?
  • Cloudflare はどうやって 1 日 32 兆リクエストを捌くのか?
  • Shopify は Black Friday に $10B の売上をどう受け止めるのか?

本稿は公開されたエンジニアリングブログ、カンファレンス発表、ポストモーテムから抽出した実アーキテクチャ。内部情報はなく、出典はすべて公開資料。

Season 3 Ep 1 — アーキテクチャ事例研究。

第 1 部 — Netflix — 7,000 マイクロサービスのオーケストラ

規模 (2024 公開資料)

- MAU: 2.7 億
- 同時ストリーミング: 数千万
- トラフィック: インターネット全体の 15%
- マイクロサービス: 7,000+ (推定)
- AWS EC2 インスタンス: 数百万
- Cassandra クラスタ: 数千
- Kafka メッセージ: 1 日数兆件

アーキテクチャスタック

Edge: Zuul (API Gateway) → Spring Cloud Gateway へ移行中
Service Mesh: 自社実装 (Ribbon, Eureka) → gRPC ベース
DB: Cassandra (primary), DynamoDB, EVCache (Memcached)
Caching: EVCache (自社開発), Moneta
Streaming: Kafka + Flink
Compute: AWS EC2 + Titus (自社コンテナ基盤)
Chaos Engineering: Chaos Monkey (発明)

Chaos Engineering — Netflix の発明

Chaos Monkey: 本番でランダムにサーバを落とす
Chaos Gorilla: AZ 全体を停止
Chaos Kong: リージョン全体を停止

哲学: 「障害は避けられない。予め練習して回復力を作る。」 効果: 10 年以上大規模な outage なし (2023 AWS us-east-1 障害でも生存)。

エンコーディング戦略

1 本の映画 → 120 以上のバリアント
(解像度 × ビットレート × オーディオ × HDR × 字幕)

Per-title encoding: 映画ごとに最適ビットレートを解析
Per-shot encoding: シーンごとに異なるビットレート → 帯域 20% 削減
AV1 codec: 2024 年有効化、H.264 比 20-30% 効率向上

Open Connect — 自社 CDN

理由: 商用 CDN ではスケール/コストを賄えない
構成: 世界中の ISP データセンターに自社サーバを設置
効果: バックボーン負荷最小化、レイテンシ低減
規模: 175 か国以上に 18,000+ サーバ

デプロイ — Spinnaker

2014 年 Netflix 開発 → オープンソース。GitOps 以前の CD。 2025 現実: Spinnaker は衰退、ArgoCD が主流。Netflix 内部も modernize 中。

教訓

  1. 規模がアーキテクチャを決める: 2.7 億ユーザにはマイクロサービスが必須。
  2. 障害を前提にする: Chaos Engineering は "if" ではなく "when"。
  3. 自社ツールを大胆に: CDN、コンテナ基盤を自社開発。
  4. データ駆動の細部: per-shot encoding のような細かな最適化。
  5. ただし 7,000 サービスはあなたの会社が真似すべきではない — Netflix だから必要。

第 2 部 — Stripe — モノリスが勝つ

規模 (2024 公開)

- 決済処理: 年 $1T+ (2023)
- 顧客: 数百万 (Uber, Amazon, Google, OpenAI 等)
- Ruby モノリス: 数千万行
- 従業員: 8,000+

「大企業なのに今もモノリス?」

Stripe は誇らしげに「我々はモノリスだ」と言う。

理由:

1. 決済ドメインは強整合が必要 (ACID)
2. マイクロサービス = 分散トランザクション = 複雑性
3. 開発者生産性: 1 つのレポジトリ、1 つのデプロイ
4. 強固なテスト → 自由にリファクタ

実構成

Sorbet (Ruby 型チェッカ) — Stripe 開発
Rails ベースモノリス
数千のエンドポイント
Postgres (sharded) + MongoDB (一部レガシー)
Kafka でイベント
Spark で analytics

Sorbet は Ruby に静的型を追加する Stripe 製ツール。2019 オープンソース化。TypeScript が JS に対して果たす役割と同等。

API バージョニング

日付ベース: Stripe-Version: 2024-12-18
breaking change があるたびに新バージョン
各バージョンを永遠に維持 (2011 年の v1 も動く)

内部実装:
- Request → version translator → 現行内部スキーマ
- 現行内部 → version translator → Response
- 10 年分のバージョン維持コスト vs 顧客の信頼

Idempotency

全 POST API で Idempotency-Key をサポート。Redis + DB に 24 時間保持。同時リクエストはロックで 1 回のみ実行。Stripe が Idempotency の事実上の標準を作った。

データインフラ

Pervasive Caching: 各サービスが自前のキャッシュを持つ
Event sourcing: 決済履歴は不変
Double-entry bookkeeping: 会計スタイル (残高 = イベントの合計)
Strong consistency: Spanner 相当の自社実装

教訓

  1. モノリスでも $1T を捌ける。マイクロサービスは必須ではない。
  2. ツールを自社開発: Sorbet、Skycfg (Starlark config)。
  3. API は契約: 10 年維持する覚悟で設計。
  4. Idempotency は基本装備。
  5. 開発者体験こそ製品。

第 3 部 — Cloudflare — Edge の支配者

規模 (2024)

- ネットワーク: 300+ 都市、120+ か国
- トラフィック: 1 日 32 兆リクエスト
- DNS: 1 日 30+ quadrillion クエリ
- DDoS 防御: 209 Tbps 攻撃を防御 (2024)
- Workers: 毎日 7M+ デプロイ

コア製品スタック

Edge: 自社ハードウェア + ソフトウェアスタック
Network: Anycast (1.1.1.1 単一 IP、300 PoP)
DDoS: L3/L4/L7 多層防御
Workers: V8 isolate ベース serverless
Workers AI: Edge 推論 (LLM)
R2: S3 互換 object storage (egress 無料が差別化)
D1: SQLite ベース分散 DB
Durable Objects: ステートフル serverless
Hyperdrive: edge での DB コネクションプーラ
Tunnel: Zero Trust プライベートネットワーク

Workers — なぜ V8 isolate?

Lambda: コンテナ → 100ms+ cold start
Workers: V8 isolate → 5ms cold start

理由:
- V8 isolate は軽量 (数 MB メモリ)
- 同一プロセスに数千 isolate
- 各 isolate は分離 (同じ V8)

制約: Node API の一部のみ対応 (Web 標準優先)。ファイルシステムなし。CPU 時間 50ms 制限 (有料で 30 秒)。

ネットワークスタックの特徴

Quicksilver: 自社 KV store (設定の超高速配信)
Unimog: L4 ロードバランサ
BGP: 全世界アナウンス、Argo Smart Routing

2022 年 11 月障害ポストモーテム (有名)

何が: Cloudflare dashboard が世界中でダウン
原因: スイッチアップグレード中の BGP 経路伝播エラー
継続: 2 時間
教訓: 「Control plane は分散されるべき」 — Argo control plane を再設計

価値: ポストモーテムが公開 — 業界全体が学んだ。

教訓

  1. Edge が未来: 中央データセンターより世界分散。
  2. スタックを自社で所有: ネットワーク機器からランタイムまで。
  3. 透明なポストモーテムが信頼を築く。
  4. 無料 tier は戦略的: 開発者ロックイン。
  5. 他 CDN との差別化: 開発者プラットフォーム (Workers) がコア。

第 4 部 — Shopify — Black Friday の王

規模 (2023-2024)

- マーチャント: 500 万+
- Black Friday 2023: 売上 $9.3B (4 日間)
- Peak RPS: 70 万+ リクエスト/秒
- 注文: 1 分に数万件
- GMV: 年 $300B+

アーキテクチャスタック

Rails モノリス: "Shopify Core"
Ruby: 主力言語 (YJIT を積極活用)
MySQL: sharded、Vitess ライクな自社実装
Kafka: イベントストリーミング
Go, Elixir, Rust: 特殊サービス
Kubernetes (一部)、GCP + 自社データセンター

Pods — Shopify のシャーディング

Pod: マーチャントをグループ化した隔離単位
各 Pod: MySQL shard + Redis + 他リソース
1 Pod の障害 → 他 Pod に影響なし (blast radius 制限)
世界で数十の Pod

効果: 1 顧客が DB を飽和させても他顧客に影響なし。

Black Friday 準備

1. 想定トラフィック 4-10 倍
2. 6 か月前からリハーサル
3. Game day: 意図的な障害シミュレーション
4. Capacity planning: 単なる増設ではなく効率改善
5. Feature freeze: 2 週間前から主要デプロイ停止
6. On-call 体制の大規模準備

YJIT — Ruby JIT の転換点

2022: YJIT を Rust で書き直し
2023+: Shopify Core が採用
効果: サーバ全体 CPU 15% 削減 → サーバコスト削減
YJIT 開発を Shopify がリード (Maxime Chevalier-Boisvert)

Storefront — 新 FE スタック

Hydrogen: Shopify 製 Remix ベース SSR フレームワーク
Oxygen: Shopify のデプロイ基盤
以前: Liquid テンプレートエンジン (自社製)
以後: React + TypeScript

教訓

  1. Pod でシャーディング: 顧客隔離はスケーリングの友。
  2. Black Friday は普段の実力の倍。毎日少しずつ積み重ねる。
  3. モノリス + 周辺 micro: Rails + Go/Elixir で特殊部分。
  4. YJIT のように言語/ランタイムに投資: 複利効果。
  5. Game day 文化: 障害を練習する。

第 5 部 — Discord — 数千万同時接続のチャット

規模

- 登録ユーザ: 3 億+
- DAU: 1.5 億+
- メッセージ: 1 日 400 億+
- 音声分: 月数百億

面白い言語選択

Elixir (Erlang VM): チャットサービス (大規模同時実行)
Rust: 性能クリティカル (voice server など)
Python: ML、一部バックエンド
Go, TypeScript: その他

ScyllaDB で Cassandra を置換 (2023)

問題: Cassandra 177 ノード、運用が地獄
解決: ScyllaDB へ移行 (C++ で書き直した Cassandra)
結果: 177 → 72 ノード、レイテンシ 50% 削減、$$$ 節約

教訓: 言語/ランタイム変更でインフラ半減。エンジニアリング時間を投じる価値あり。

教訓

  1. BEAM (Erlang) の力: WhatsApp と Discord が証明。
  2. 言語を混ぜよ: ドメインごとに最適な言語。
  3. DB 置換は可能: 事前にインタフェース抽象化。
  4. Rust は段階導入: 性能クリティカルから。

第 6 部 — GitHub — 最大のコードリポジトリ

規模

- Repo: 5 億+
- 開発者: 1.5 億+
- Git データ: 数 PB
- Actions: 毎分数百万ジョブ

アーキテクチャ進化

2008: Rails モノリス (創業)
~2016: MySQL + Redis + memcached
2020+: Spokes (Git storage)、Kafka、Kubernetes を段階導入
2022-: Microsoft 買収後、Azure へ移行中

興味深いエンジニアリング

Monolith-first: 巨大な Rails アプリを今も維持
Spokes: Git の分散保存 (自社)
Codespaces: VS Code Server のための Kubernetes オーケストレーション
Copilot: OpenAI との協業

教訓

  1. Rails は今も有効: 正しく使えば。
  2. Git の保存は難しい: ファイルシステム問題。
  3. 開発者プラットフォーム = 自社コード: Codespaces は GitHub 自身の開発環境。

第 7 部 — Figma — リアルタイム協調編集の革命

技術的課題

数十人が同じキャンバスを同時編集
遅延 50ms 以下で感じさせる
オフライン編集後にマージ
Undo/Redo を混乱なく

CRDT ベースの同時編集

Conflict-free Replicated Data Types
各編集は可換 (順序無関)
サーバは仲裁役、最終状態は収束

Figma のデータモデル:
- Node tree (DOM 風)
- 各 edit は operation タイプ
- WebSocket でリアルタイム sync

Rust ベースのコア

Rust で書かれた co-editor コア
WASM でブラウザ実行
ネイティブ相当の性能

教訓

  1. リアルタイム協調編集 = CRDT: Google Docs も Figma も。
  2. Web アプリがネイティブを置換: WASM の恩恵。
  3. 会社 === プロダクト: Figma はプロダクトへの執着。

第 8 部 — Notion — ブロックベース文書のデータモデル

データモデル

すべてが block
Page = block の block
Text, heading, list, code, ... すべて block

Block データ構造:
{
  id: "block_123",
  type: "paragraph",
  content: [...],
  parent: "block_456",
  children: ["block_789", ...],
  properties: {...}
}

特徴: 再帰的ツリー。世界中の Notion ユーザのデータがすべて同一構造。

Postgres + キャッシング

Primary: Postgres (全 block)
Cache: Redis, Memcached
Search: Elasticsearch
AI: OpenAI embedding

2024 growth: AI 機能拡大で Postgres 負荷急増。シャーディングを進化。

教訓

  1. データモデルが全て: 優れたスキーマは拡張できる。
  2. ブロック = 柔軟性: 「ページ」中心ではなく「ブロック」中心。
  3. Postgres の力: NoSQL を使わずとも Notion 規模に到達可能。

第 9 部 — Spotify — チーム構造とアーキテクチャ

Spotify Model (議論あり)

Squad: チーム (product area)
Tribe: 複数 Squad の束
Chapter: 同じ役割 (例: バックエンドエンジニア)
Guild: 関心ベースのコミュニティ

2024 現実: Spotify 自身が「我々はこのモデル通りに動いていない」と公言。 教訓: 組織構造は会社ごとに異なる。テンプレートをコピーしない。

Backstage — 内部開発者ポータル

2020 OSS 化: 内部ツールを外部公開
機能: サービスカタログ、ドキュメント、TechDocs、テンプレート
CNCF: Incubating プロジェクト

2025 現実: Platform Engineering の標準ツール。

Event-driven

Kafka 中心のアーキテクチャ
Play event → 数十サービスにブロードキャスト
Recommendation はイベント集約ベース

教訓

  1. 「Spotify Model」神話: 組織構造の一般化は難しい。
  2. Internal platform → OSS: Backstage 方式。
  3. Event streaming = 柔軟性: 新サービスを簡単に追加。

第 10 部 — Airbnb — Monolith → Services → Monolith?

旅路

2008-2017: Rails モノリス
2017-2022: マイクロサービス化 (複雑性爆発)
2022+: 一部再統合 ("macroservices")

教訓: 失敗を公言。「マイクロサービスに分割しすぎた、一部を統合している。」

発明物

  • Airflow: データパイプラインスケジューラ (2015、現在の標準)
  • Lottie: ベクタアニメーション (フロント)
  • Knowledge Graph: 検索/推薦

教訓

  1. 過度な分割の危険: MSA は無料ではない。
  2. Retrospective 文化: 失敗を認め、修正する。
  3. 周辺ツールがブランド: Airflow が会社イメージを作る。

第 11 部 — 共通パターン 10

事例から抽出したパターン:

  1. モノリスでも OK: Stripe、Shopify、GitHub — 規模があっても monolith。
  2. シャーディング/Pod で隔離: Shopify Pod、Netflix region。
  3. Event-driven: Kafka 中心 (Spotify、Shopify、Netflix)。
  4. 自社 CDN/インフラ: Netflix Open Connect、Cloudflare の自社スタック。
  5. Chaos Engineering: Netflix 発、業界拡散。
  6. 言語を混ぜる: Rust (性能)、Elixir/Erlang (同時実行)、Go (インフラ)。
  7. GitHub flow: PR レビュー + CI + 自動デプロイ。
  8. OSS → 標準: Airflow、Kubernetes、Backstage、Sorbet。
  9. ポストモーテム公開: Cloudflare、GitLab の透明性。
  10. 自社ツールを大胆に: 規模があるなら必ず。

第 12 部 — 真似すべきこと vs しないこと

真似すべき

  • 強固なテスト + CI/CD
  • ポストモーテム文化
  • Idempotency (Stripe 方式)
  • Feature Flag
  • 可観測性 (logs/metrics/traces)
  • DORA 指標測定

真似すべきでない

  • 7,000 マイクロサービス (Netflix) — あなたの規模ではない
  • 自社 CDN 作成 (Netflix) — ホスティングコストが十分大きくない限り無駄
  • Spotify Model をそのままコピー — 組織コンテキストが違う
  • Rust で全体書き換え — 性能ボトルネックがなければ意味なし
  • Kubernetes everything — 小規模スタートアップには過剰

第 13 部 — 小規模企業の事例

Plausible Analytics (10 名):

  • Elixir モノリス
  • 解析に ClickHouse
  • 本番サーバ数台
  • オープンソース、ブートストラップ
  • $2M+ ARR

Gumroad (数十名):

  • Rails モノリス
  • Postgres、Redis
  • Heroku → AWS へ移行
  • シンプル。そこがポイント。

Bytebase (数十名):

  • Go + React
  • SQLite (組み込み) + Postgres オプション
  • CNCF 志向

教訓: 小さなチームほど「シンプルさ」が武器。モノリス + 1 つの DB でも $100M+ は可能。

第 14 部 — チェックリスト 12

  • 事例研究で自社を比較する
  • Netflix の Chaos Engineering を一部導入 (簡単なものから)
  • Stripe の Idempotency Key を実装
  • Cloudflare のポストモーテムを読む (公開)
  • Shopify の Pod 隔離概念を適用
  • Discord の Rust for hot path
  • Figma の CRDT (リアルタイム協調が必要な場合)
  • Notion のデータモデルを学ぶ
  • Spotify の Backstage (Platform)
  • Airbnb の "Macroservices" を検討
  • 会社サイズに合ったツール選択
  • Postmortem テンプレートを自社にも導入

第 15 部 — アンチパターン 10

  1. Netflix の真似 (大企業方式) → あなたの規模ではない
  2. 100 人に 100 サービス → 運用不可能
  3. 自社 DB/言語を作る → 1 万人規模でなければ無駄
  4. トレンド追従 → 安定性を犠牲
  5. ポストモーテム秘密 → 同じ失敗を繰り返す
  6. 準備なしの Chaos Engineering → ただの障害
  7. Kubernetes 強制 → シンプルさ喪失
  8. Microservices + 強整合 → 分散トランザクション地獄
  9. Rust everywhere → 採用が困難
  10. Spotify Model 盲信 → コンテキストを無視

まとめ — 「巨人の肩の上で」

Netflix、Stripe、Cloudflare は天才だけの集まりではない。

  • 数年にわたる反復される失敗と学習
  • 透明なポストモーテム (公開資料が豊富)
  • 巨大な規模で発見された原則

あなたの会社が小さいなら、むしろ「シンプルさの武器」を持っている。 大企業は「小さいときから Microservices を始めたことを後悔している。」

次回は Season 3 Ep 2 — 有名ポストモーテム解剖。 Cloudflare 2022、Fastly 2021、AWS 2017、Heroku DNS 問題、Knight Capital $440M 8 分 など。

失敗から学ぶのが最速の成長。

次回予告 — 「有名ポストモーテム解剖: Cloudflare・Fastly・AWS・Knight Capital の失敗から学ぶ」

Season 3 Ep 2 は:

  • Cloudflare 2022-06 (BGP)、2019-07 (Regex)
  • Fastly 2021-06 (1 顧客設定 → インターネットの半分がダウン)
  • AWS S3 2017-02 (タイポ 1 つで us-east-1 ダウン)
  • Knight Capital 2012 (8 分で $440M 損失)
  • GitLab 2017 (DB wipe)
  • Common patterns

失敗からの方が速く学べる。次の記事で。

Discuss on Twitter • View on GitHub