Week 3: ネットワーク | プロジェクト・ミーミル

Transcript

1. Week 3: ネットワーク プロジェクト・ミーミル Phase 1 / 全15回 プロジェクト・ミーミル | Week 3 1
2. 今日のゴール 1. エラーのレイヤーを切り分けられる — 「API繋がらない」がHTTPの問題かTCPの 問題か判断できる 2. gRPC / ConnectRPC と REST の使い分けを判断できる — トレードオフを理解して 技術選定の理由を語れる 3. DNS の TTL を理解して安全にインフラ移行できる — テックリードとして障害を未 然に防げる プロジェクト・ミーミル | Week 3 2
3. 今日のアジェンダ 時間 パート 分 0:00 Week 2 振り返り 5分 0:05 レイヤーとエラーの切り分け 10分 0:15 gRPC vs REST 15分 0:30 DNS + mTLS 10分 0:40 プチテスト 10分 0:50〜 質疑・まとめ（バッファ） 残り時間 プロジェクト・ミーミル | Week 3 3
4. Week 2 振り返り 構造化: 影響範囲の局所化、テスト容易性、単一責務 データ構造: 配列は一発、連結リストは挿入が速い（トレードオフ） 計算量: O(n) vs O(n²)。n=100万で100万回 vs 1兆回 空間計算量: メモリの箱がデータに応じて増えるかどうか プロジェクト・ミーミル | Week 3 4
5. レイヤーの考え方（さらっと） Week 2 の構造化と同じ考え方 = 各層が自分の責務だけに集中 レイヤー やること 例 アプリケーション層 何を送るか HTTP, gRPC, DNS トランスポート層 確実に届けるか / 速く届けるか TCP / UDP ネットワーク層 どこに届けるか IP アドレス 物理層 どうやって届けるか Wi-Fi, 有線 Wi-Fi → 有線に変えても HTTP の通信内容は変わらない = レイヤーが分離している プロジェクト・ミーミル | Week 3 5
6. エラーのレイヤー切り分け テックリードとして障害対応で必要な視点 プロジェクト・ミーミル | Week 3 6
7. 面接問題①: API が繋がらない 「API通信が失敗しました。考えられるエラーを広く挙げてください。 」 さらに深掘り: 「スマホのネットワーク接続が切れていた（オフライン）場合、 HTTPステータスコードは何番になりますか？」 皆さん、考えてみてください。 プロジェクト・ミーミル | Week 3 7
8. 面接問題①: 回答例 良い回答: 「ネットワーク接続がない場合は、HTTPプロトコルより下の層（TCP）のエラー です。 サーバーからHTTPレスポンス自体が返ってこないので、 HTTPステータスコードでは表現できません。 」 不十分な回答: 「400 Bad Request か 404 Not Found だと思います」 → TCP/IP とHTTPのレイヤーの区別がついていない プロジェクト・ミーミル | Week 3 8
9. テックリードとしてのエラー切り分け 「繋がらない」と言われたとき、どのレイヤーの問題か？ レイヤー エラーの例 確認方法 アプリケーション層 HTTPエラー、ビジネスロジック ステータスコード確認 トランスポート層 ポート閉塞、FW telnet host port ネットワーク層 IP到達不能 traceroute 物理層 Wi-Fi切断、ケーブル抜け ping HTTPのエラーログが出ない → そもそも接続が確立していない → トランスポート層よ り下を疑う プロジェクト・ミーミル | Week 3 9
10. gRPC vs REST カナリーでも使っている。技術選定の判断基準を持つ プロジェクト・ミーミル | Week 3 10
11. 面接問題②: gRPC を採用した理由 「過去のプロジェクトで gRPC を採用した理由は？ REST と比較してどんなメリット がありましたか？」 カナリーでも gRPC / ConnectRPC を使ってますよね。 なぜ gRPC なのか、説明できますか？ プロジェクト・ミーミル | Week 3 11
12. 面接問題②: 良い回答 「複数言語（Go, TypeScript 等）での実装が必要な環境で、 Protocol Buffers の定義ファイルから各言語のコードを正確に自動生成できる点が 最大のメリット。 また REST よりエラーの種類を細かく指定できるため、 複雑なエラー原因の特定がしやすい。 」 「一方で、外部パートナーなど多様な関係者がアクセスするインターフェースは あえて REST を採用。Protobuf の定義ファイルの配布・更新の手間を 外部に強いるのは運用上煩わしいため。 」 プロジェクト・ミーミル | Week 3 12
13. 面接問題②: 悪い回答 「gRPC は HTTP/2 ベースでバイナリ通信だから REST より速い。 マイクロサービスのトレンドなので採用した。 」 なぜ悪いか: 「速いから」 「トレンドだから」= 自社の課題との紐づきがない デメリットへの言及がない（ブラウザから直接叩けない、スキーマ管理の複雑 化） トレードオフの判断基準が見えない プロジェクト・ミーミル | Week 3 13
14. gRPC vs REST: 使い分けの判断基準 判断軸 gRPC REST 利用者 社内サービス間 外部パートナー、ブラウザ 型安全性 .proto で厳密に定義 OpenAPI 等で後付け コード生成 多言語で自動生成 手動 or 生成ツール データ形式 Protobuf（バイナリ、速い） JSON（テキスト、読める） ブラウザ対応 gRPC-Web が必要 そのまま使える ConnectRPC: gRPC 互換だがブラウザから直接叩ける + JSON も使える（カナリーで も採用） テックリードとしての判断: 「速いから gRPC」ではなく、誰が使うか・運用コストは どうか で選ぶ プロジェクト・ミーミル | Week 3 14
15. シリアライズ / デシリアライズ データを送信可能な形式に変換すること シリアライズ: Go の構造体 → JSON or Protobuf → ネットワークで送信 デシリアライズ: 受信 → JSON or Protobuf → Go の構造体に復元 JSON: テキスト。人間が読める。デバッグしやすい Protobuf: バイナリ。人間が読めない。速い・小さい ※ 圧縮ではなく、効率的なバイナリエンコーディング gRPC が速い理由 = Protobuf（バイナリエンコーディング）+ HTTP/2（多重化） プロジェクト・ミーミル | Week 3 15
16. DNS + mTLS テックリードとして安全にインフラ移行するために プロジェクト・ミーミル | Week 3 16
17. 面接問題③: DNS とサーバー移行 「サーバー移転して DNS レコードを新しい IP に書き換えました。 しかし一部ユーザーから『古いサイトが表示される』と問い合わせ。 何が原因？事前にどうすべきだった？」 テックリードとしてこのシナリオ、対応できますか？ プロジェクト・ミーミル | Week 3 17
18. 面接問題③: 回答例 良い回答: 「DNS は分散システムで、TTL（キャッシュの有効期限）がある。 ユーザーの PC やプロバイダの DNS サーバーに古い IP のキャッシュが残ってい る。 移転の数日前に TTL を短く（例: 300秒）しておくべきだった。 」 悪い回答: 「DNS の設定画面で書き換えれば、すぐに全ユーザーが新サーバーにアクセスで きる」 → TTL を知らずにインフラ移行すると障害を起こす プロジェクト・ミーミル | Week 3 18
19. DNS レコードの種類 レコード 用途 例 A ドメイン → IPv4 canary-app.com → 35.200.x.x CNAME ドメインの別名 www → canary-app.com NS 権威 DNS サーバー ns-cloud-x.googledomains.com 実際に確認: dig canary-app.com A # IP アドレスの確認 dig canary-app.com +short # 簡易表示 自習課題: Cloud DNS Troubleshooting ラボで DNS 障害の切り分けを実践 プロジェクト・ミーミル | Week 3 19
20. mTLS: サービス間通信のセキュリティ 通常の TLS: ブラウザ → 「このサーバー本物？」 → サーバー証明書で確認（一方向） mTLS: サービスA ←→ サービスB （お互い「あなた本物？」= 双方向） なぜ必要か: マイクロサービス間で不正なサービスからのアクセスを防ぐ 「社内ネットワークだから安全」はゼロトラストの考え方では通用しない テックリードとして: サービス間通信の設計時に mTLS を検討できるかどうか プロジェクト・ミーミル | Week 3 20
21. プチテスト プロジェクト・ミーミル | Week 3 21
22. プチテスト 問題数: 7問（選択式5問 + 記述式2問） 制限時間: 10分 プロジェクト・ミーミル | Week 3 22
23. まとめ・次回予告 今日のポイント エラーの切り分け: HTTP のエラーか TCP のエラーか判断できるか gRPC vs REST: 「速いから」ではなく、誰が使うか・運用コストで判断 DNS: TTL を知らずにインフラ移行すると障害を起こす 次回: Week 4「OS・シェル」 プロセス・スレッド・メモリ（Week 1 のコンテキストスイッチが深掘りされる） 自習課題: Cloud DNS Troubleshooting ラボ — DNS障害の原因をレイヤーで切り分ける実践 dig コマンドで自分のドメインの DNS を確認してみる プロジェクト・ミーミル | Week 3 23
24. 自習リソース リソース 内容 マスタリングTCP/IP 入門編 TCP/IP の基本 体系的なインプット > ネットワーク 社内カリキュラム dig コマンド dig canary-app.com A で DNS 確認 Cloud DNS Troubleshooting ラボ DNS障害のレイヤー切り分け実践 プロジェクト・ミーミル | Week 3 24