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

ネットワークの仕組みを、エラーの切り分けと技術選定の判断に落とし込む勉強会の資料です。

OSI 参照モデルの各レイヤーの役割から入り、「API が繋がらない」が HTTP の問題か TCP の問題かを切り分ける見方を扱います。後半は gRPC / ConnectRPC と REST の使い分け、DNS の仕組みと TTL を理解して安全にインフラ移行する勘所、mTLS までを順番に押さえます。

ねらいは、用語を覚えるのでなく「なぜそのプロトコルを選ぶか」「障害をどのレイヤーで切り分けるか」を自分の言葉で説明できる状態にすること。テックリードとして障害を未然に防ぐ視点と、候補者の回答の良し悪しを見分ける観点も合わせて示します。

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

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