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

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