Phase 1 | Week 6: 設計論と分散システムとAPI | プロジェクト・ミーミル

設計判断の軸を、アーキテクチャ・分散システム・API の3段で扱う勉強会の資料です。

アーキテクチャのレイヤー分けと DI（依存性の注入）の目的から入り、マイクロサービスのメリット・デメリットとデータ整合性の担保方法、そして API のエラー設計・リトライ戦略・冪等性までを、抽象度の高い順に積み上げます。

ねらいは、用語を覚えるのでなく「なぜ層を分けるか」「なぜ冪等性が要るか」を自分の言葉で説明できる状態にすること。いずれもシニア候補者の設計判断を見極めるための観点として、良い回答と不十分な回答の違いも合わせて示します。

▼ プロジェクト・ミーミルとは
TLE（テックリードエンジニア）および技術面接官の育成を目的としたプログラムです。コンピュータ・ネットワーク・Web の基礎を体系的に学び直し、暗記ではなく「なぜそうなっているか」を自分の言葉で説明できる状態を目指します。週1回の勉強会で基礎から専門領域までを順番に扱い、技術面接で候補者の力を原理から正しく評価できる面接官を育てます。

Transcript

1. Week 6: 設計論 + 分散システム + API プロジェクト・ミーミル Phase 1 / 全15回（2 週分まとめ） プロジェクト・ミーミル | Week 6 1
2. 今日のゴール 1. アーキテクチャのレイヤー分け と DI（依存性の注入） の目的を語れる 2. マイクロサービス のメリット・デメリットとデータ整合性の担保方法を語れる 3. API のエラー設計 とリトライ戦略・冪等性 を語れる → いずれもシニア候補者を見極めるための 設計判断軸 プロジェクト・ミーミル | Week 6 2
3. 今日のアジェンダ 時間 パート 分 0:00 Week 5 振り返り 5分 0:05 設計論（アーキテクチャ + DI） 15分 0:20 分散システム（マイクロサービス + データ整合性） 15分 0:35 API（エラーハンドリング + 冪等性） 20分 0:55 まとめ・次回予告 5分 プチテストは時間外（Notion フォームで次回までに各自） プロジェクト・ミーミル | Week 6 3
4. Week 5 振り返り コンテナ: ホスト OS のカーネルを共有しつつ namespaces / cgroups でプロセス隔 離 OWASP Top 10 2025: サプライチェーン攻撃が A03 に格上げ。Axios npm 乗っ取 り 認証と認可: JWT は発行後取り消せない（ログアウト設計に工夫） 2026 トレンド: Passkey / ReBAC / AI エージェントへの委任認可 → 今日はその上に乗る 設計判断レイヤー: アーキテクチャ → 分散システム → API プロジェクト・ミーミル | Week 6 4
5. 復習: コンテナはなぜ軽い？ 前提: Linux 環境で Docker のようなコンテナ を VM と比較したとき、本質的な違い は？ VM は何を立てる？ コンテナは何を 共有 している？ Linux カーネルの どの機能 で隔離している？ プロジェクト・ミーミル | Week 6 5
6. 設計論 アーキテクチャのレイヤー分けと DI プロジェクト・ミーミル | Week 6 6
7. アプリケーションのレイヤー分け（骨格） コア: [Entity] ← ビジネスロジック（ドメインルール） 調整層（薄く保つ）: [UseCase] ← Entity と 出力アダプター を呼び出すだけ アダプター（差し替え可能）: [入力アダプター] ← API・GraphQL・バッチの受け口 （例: Controller / Resolver） [出力アダプター] ← DB・外部 API・キャッシュ （例: Repository） 3 原則: (1) 責務で分ける / (2) 依存方向は内向き / (3) ドメイン（Entity）は外側を知 らない Controller も Repository も「アダプター」 ── どちらもコアの外側、差し替え可 能 プロジェクト・ミーミル | Week 6 7
8. アンチパターンと派生パターン UseCase は薄く保つ — ロジックを溜めない 溜まる → 同じ業務ルールが複数 UseCase でバラバラ実装 = 貧血ドメインモデル / トランザクションスクリプト 例: 在庫減算ルールが OrderUseCase と CancelOrderUseCase で別実装 → 仕様矛 盾 派生パターン — 骨格は同じ、図解が違うだけ BE: ヘキサゴナル（ポート&アダプター） （クリーン / オニオンも同系） FE: Feature-Sliced Design など、機能ごとに feature を切る 面接の見どころ: 「クリーンアーキテクチャです」と名前だけの候補者は要注意 → 「な ぜそうするのか」を根本動機から語れるか プロジェクト・ミーミル | Week 6 8
9. DI（依存性の注入）の目的 ハードコード（具象型に依存）: type UserService struct { repo *PostgresUserRepository } func NewUserService() *UserService { return &UserService{repo: NewPostgresUserRepository()} } → テスト時に Postgres 実体が必要、別 DB に切り替えにくい DI（インターフェース経由）: type UserRepository interface { /* ポート */ } type UserService struct { repo UserRepository } func NewUserService(repo UserRepository) *UserService { ... } → テスト時はモック / 本番は実装 と差し替え自由 プロジェクト・ミーミル | Week 6 9
10. 設計論の最新の動向 ヘキサゴナル / クリーンアーキテクチャ が主流寄りに ── ドメインを中心に置 き、外部入力・出力をアダプター経由で配置する 設計思想 AI コード生成時代の設計: AI に読み込ませるドキュメントで 「各レイヤーが何を 実現するのか」を明示的に指示 してから書かせる モジュラーモノリス: いきなりマイクロサービスにせず、モジュール境界を保った モノリスから始める。ゆくゆくマイクロサービス化するか、現状維持か を判断す る選択肢式の設計 プロジェクト・ミーミル | Week 6 10
11. 面接問題①: 設計論（3 段階で聞く） 導入（実体験で答えやすい）: 「過去に関わったプロジェクトのフォルダ構成と、もしレイヤー分けをしていた ら、それぞれの役割を教えてください」 深掘り①（実装経験）: 「ビジネスロジックやバリデーションは、どのレイヤーに配置すべきだと考えて いますか？なぜですか？」 深掘り②（設計判断 / 最新動向）: 「DI を使う目的は何ですか？使わない設計と比べてどう違いますか？」 プロジェクト・ミーミル | Week 6 11
12. 面接問題①: 不十分な回答とその理由 深掘り① ロジック・バリデーション配置: 「Controller で受けて、そのまま DB から取って返してます」 → レイヤー意識な し 「MVC で Model に全部書いてます」 → 入力・業務・データの境界なし △「ロジックは全部 Service、Entity は struct でフィールドだけ」 → ドメインが薄 い（貧血ドメインモデル） 深掘り② DI の目的: 「テストで mock を使えるから」 → 変更への強さが抜ける 「疎結合になるから」 → 何のための疎結合か が曖昧 「Wire / fx を使うと便利だから」 → 手段の話で止まる プロジェクト・ミーミル | Week 6 12
13. 分散システム マイクロサービスとデータ整合性 プロジェクト・ミーミル | Week 6 13
14. マイクロサービスのメリット・デメリット メリット: デプロイの独立性: サービスごとに別々にリリースできる 障害の隔離: 1 つが落ちても他は動く、高負荷も分けられる スケールの個別最適: 重い処理だけ水平スケール デメリット: DB が分散 → JOIN ができない、データ取得の効率悪化 ネットワーク経由の通信: レイテンシ・障害点が増える 運用の複雑化: ログ・監視・トレースを全サービスで揃える必要 分散トランザクション の難しさ（次のスライド） プロジェクト・ミーミル | Week 6 14
15. サービス間のデータ整合性 サービスごとに DB / テーブルが分かれていると、1 トランザクションで複数を更新で きない 対策 1: 集約単位で切る（設計で回避） トランザクション範囲内にサービス境界を引く（DDD の集約設計） 対策 2: 非同期 + イベント駆動 メッセージバス（Pub/Sub / Cloud Tasks 等）にイベント発行 → 他サービスが購読 → 結果整合性（Eventual Consistency） 対策 3: 補償トランザクション（Saga パターン） 複数ステップに分割、失敗時は 逆順で取り消し操作 を発行 例: 「在庫減らした → 決済失敗 → 在庫を戻す」 プロジェクト・ミーミル | Week 6 15
16. 分散システムの最新の動向 OpenTelemetry: ログ・メトリクス・トレースを統一仕様で出力 → 1 リクエストが 何サービス跨いでも追える / ベンダーを乗り換えても観測コードを書き換えずに済 む サービスメッシュ（Istio / Linkerd / Cilium）: サービス間通信を インフラ層で制御 ── mTLS 強制、トラフィックポリシー、リトライ、観測性を アプリコード変更 なし で実現。eBPF ベースのサイドカーレス（Cilium / Istio Ambient）が新潮流 プラットフォームエンジニアリング: 内部開発者プラットフォーム（IDP・ Backstage 等）で マイクロサービス運用の標準化をプラットフォーム側に寄せる 動き、Golden Path を整備 採用判断のポイント: 少人数チームでマイクロサービスにすると スケールメリットが得 られず複雑になるだけ プロジェクト・ミーミル | Week 6 16
17. 面接問題②: 分散システム（3 段階で聞く） 導入（実体験で答えやすい）: 「マイクロサービスのメリットとデメリットを教えてください」 深掘り①: 「マイクロサービスは、どんな組織規模・状況のときに採用すべきですか？」 深掘り②（実装経験）: 「サービスごとに DB が分かれている場合、複数のサービスにまたがるデータの 整合性をどうやって担保しますか？」 プロジェクト・ミーミル | Week 6 17
18. 面接問題②: 不十分な回答とその理由 深掘り① 採用基準: 「とにかく分けた方がスケールする」 → 少人数だとコストの方が上回る 視点欠 落 「モダンでベストプラクティスだから」 → 流行で採用する危険サイン 「将来のスケールを見越して最初から細かく」 → 早期最適化 深掘り② データ整合性: 「2 フェーズコミット（2PC）を使う」 → マイクロサービスでは現実的でない: パフォーマンス: 全サービスのロック完了まで処理が止まる 可用性: コーディネータが SPOF（単一障害点）になり、独立性を相殺 プロジェクト・ミーミル | Week 6 18
19. API エラーハンドリングと冪等性 プロジェクト・ミーミル | Week 6 19
20. エラーの種類と HTTP ステータス API 通信で 遭遇しうるエラー を網羅的に挙げられるか: 種類 例 HTTP ステータス クライアント起因 残高不足、権限なし、入力不正 400, 401, 403, 422 競合 同時更新の衝突、リソース既存 409 サーバー側エラー 想定外の例外 500 過負荷 / 一時障害 DB 接続エラー、レート制限 503, 429 タイムアウト サーバー応答なし 504 ネットワーク瞬断 HTTP より下のレイヤー （HTTP で表現できない） → 「全部 500 で返します」では設計力が足りない プロジェクト・ミーミル | Week 6 20
21. リトライ戦略 自動リトライ OK: 500 サーバー側エラー / タイムアウト / ネットワーク瞬断 → サーバー側の一過性の問題、タイミングをずらせば成功する可能性 自動リトライ NG: 400 番台: クライアント側の問題、リトライしても結果は変わらない 503 の即時リトライ: 過負荷を悪化させる 実装の定石: 指数バックオフ: 間隔をだんだん長くする（1s → 2s → 4s → 8s） ランダムに時間をばらつかせる: 全クライアントが同じ瞬間に叩かないようにずら す リトライ回数の上限は 3〜5 回 プロジェクト・ミーミル | Week 6 21
22. 冪等性（べきとうせい）と冪等性キー（Idempotency-Key） 冪等性: 同じリクエストを 何度送っても結果が同じ という性質 メソッド 冪等? 例 GET / PUT / DELETE 何回叩いても結果は同じ POST 新規作成なので叩くたびに増える 現実の課題: 振込 API（POST）でレスポンスが返ってこないと、リトライしていいか分 からない → 二重振込のリスク 冪等性キーパターン（Stripe 発、RFC ドラフト化進行中）: 1. クライアントが UUID を生成してヘッダで送る 2. サーバーは 同じキーは 1 回しか処理しない よう記録 3. 同じキーが再送されたら、保存した結果を返す プロジェクト・ミーミル | Week 6 22
23. API 設計の最新の動向 MCP（Model Context Protocol）: Anthropic が 2024-11 発表 → OpenAI（2025- 3）/ Google（2026-Q1）が対応、2025-12 に Linux Foundation 傘下に移管。AI エージェントとツール間の 事実上の業界標準 に 冪等性キーの IETF 標準化: draft-ietf-httpapi-idempotency-key-header-07 が IETF HTTPAPI WG で進行中（2026-5 時点） 、RFC として標準化される直前。 Stripe 発祥のパターンが HTTP の正式仕様の一部に Standard Webhooks の標準化: Svix / Twilio / Kong / Supabase 共同策定、OpenAI / Anthropic / Google も採用。HMAC-SHA256 署名・タイムスタンプによる replay 保護・メッセージ ID による冪等性を業界で統一 プロジェクト・ミーミル | Week 6 23
24. 面接問題③: API（3 段階で聞く） 導入（実体験で答えやすい）: 「銀行アプリで振込 API を叩く際、遭遇しうるエラーの種類と HTTP ステータス を広く挙げてください」 深掘り①（実装経験）: 「通信エラー（タイムアウト等）で自動リトライさせたい場合、二重振込を防ぐ ため にはどう設計しますか？」 深掘り②（設計判断 / 最新動向）: 「リトライしていいエラーといけないエラーを、どう判定しますか？」 プロジェクト・ミーミル | Week 6 24
25. 面接問題③: 不十分な回答とその理由 導入 エラー網羅の不十分な回答: 「サーバーエラー（500）だけ考えます」 → 網羅性不足（400 番台・タイムア ウト・HTTP で表現できない TCP レベル瞬断 が抜ける） 深掘り① 二重振込防止の不十分な回答: 「フロントでボタンを disable」 → ネットワーク再送には無力 深掘り② リトライ判定の不十分な回答: 「全部リトライする」 「全部リトライしない」 → メリハリ不足、エラー種類で 判定軸を分けられていない プロジェクト・ミーミル | Week 6 25
26. プチテスト 時間外で各自取り組み（次回まで） プロジェクト・ミーミル | Week 6 26
27. まとめ・次回予告 今日のポイント: 設計論: レイヤーを責務で分ける + DI でテスト性・変更容易性 分散システム: マイクロサービスは「組織規模が必要になってから」 、データ整合性 は 集約単位で切る / 非同期イベント / 補償トランザクション API: エラーは網羅的に、リトライは種類で判断、冪等性キーで二重処理を防ぐ 次回 Week 7: Phase 1 総復習 ← Phase 1 完了マイルストーン Week 1〜6 の全項目を通しで確認、弱点特定 総合プチテスト（20〜30 問） プロジェクト・ミーミル | Week 6 27
28. 自習リソース リソース 内容 Stripe API Idempotency 冪等性キーの業界標準実装 Microservices Patterns マイクロサービスのパターン集（Saga 等） OpenTelemetry 分散トレース・構造化ログの標準 12 Factor App クラウド時代の Web アプリ設計原則 Clean Architecture（書籍） レイヤー分けと DI の古典 Feature-Sliced Design 入門（Zenn / akfm） FE の機能ベースレイヤー設計、 src/features/ 構造の根拠 プロジェクト・ミーミル | Week 6 28