Week 4: OS・シェル | プロジェクト・ミーミル

Transcript

1. Week 4: OS・シェル プロジェクト・ミーミル Phase 1 / 全15回 プロジェクト・ミーミル | Week 4 1
2. 今日のゴール 1. プロセス・スレッド・メモリの関係を候補者に語れる — 並行処理の基礎を言語化 できる 2. データ競合（レースコンディション）のメカニズムを説明できる — 「サイレント に壊れる」という怖さまで伝えられる 3. 排他制御の必要性と実装を判断できる — ミューテックスやセマフォを実務の文脈 で語れる プロジェクト・ミーミル | Week 4 2
3. 今日のアジェンダ 時間 パート 分 0:00 Week 3 振り返り 5分 0:05 面接問題①: プロセス・スレッド・メモリの関係性 10分 0:15 面接問題②: データ競合の発生原理 10分 0:25 面接問題③: 排他制御と実務経験 10分 0:35 シェル関連（さらっと） 5分 0:40 プチテスト 10分 0:50〜 質疑・まとめ（バッファ） 残り時間 プロジェクト・ミーミル | Week 4 3
4. Week 3 振り返り エラーのレイヤー切り分け: HTTP のエラーか TCP より下の問題か、 ping / telnet / curl で切り分け gRPC vs REST: 「速いから」じゃなく、誰が使うか・運用コストで判断。 ConnectRPC はブラウザ対応 + JSON DNS の TTL: 移転前に TTL を短くしておく。知らないとインフラ移行で障害を起 こす プロジェクト・ミーミル | Week 4 4
5. プロセス・スレッド・メモリ 並行処理とデータ競合を理解する。面接の最重要トピック プロジェクト・ミーミル | Week 4 5
6. なぜこのトピックが重要か バックエンドのパフォーマンス・安全性に直結 面接では 「並行処理と排他制御の実践的な理解度」 を深掘りする テックリードとして、競合状態のバグは 原因究明が極めて困難 なので事前に防げ る設計が必要 面接での深掘りの型: 1. 基本概念 → 2. 異常系（データ競合）→ 3. 解決策（排他制御）と実務経験 プロジェクト・ミーミル | Week 4 6
7. 面接問題①: プロセス・スレッド・メモリの関係性 「プロセス、スレッド、メモリの3つの関係性について説明してください。 」 皆さん、面接官として候補者からどんな回答を引き出したいですか？ いい回答と不十分な回答、違いは何でしょう？ プロジェクト・ミーミル | Week 4 7
8. 面接問題①: 良い回答 「プロセスは OS から割り当てられるプログラムの実行単位で、独立したメモリ 空間を持ちます。 」 「スレッドは、そのプロセス内で並行処理を行うための単位で、1つのプロセス内 の複数のスレッドは、同じメモリ領域を共有します。 」 評価ポイント: プロセスとスレッドの違いを 「メモリが共有されるか否か」 という最重要観点で 言語化 1対Nの関係性（1プロセスに複数スレッド）を理解している プロジェクト・ミーミル | Week 4 8
9. 面接問題①: 不十分な回答 「プロセスはプログラムの実行単位で、スレッドはその中で動くものです。 別々のプロセスからは別々のメモリ空間を取るため、基本的にメモリが共有され ることはなく安全に動きます。 」 なぜ不十分か: 「プロセス同士は独立」は合っているが、**「同じプロセス内のスレッド同士 はメモリを共有する」**という、並行処理で一番気をつけるポイントが抜け落ち ている この認識のままマルチスレッドを書くと、気づかないうちにデータが壊れるバ グを作りやすい → 面接問題②で詳しく プロジェクト・ミーミル | Week 4 9
10. プロセスとスレッドの関係 ┌─ プロセス ──────────────────────────┐ │ 独立したメモリ空間 │ │ ┌─ スレッド1 ─┐ ┌─ スレッド2 ─┐ │ │ │ スタック │ │ スタック │ │ │ │ (各自固有) │ │ (各自固有) │ │ │ └─────────────┘ └─────────────┘ │ │ │ │ ┌─ 共有メモリ（ヒープ・データ領域）─┐│ │ │ 全スレッドから同時アクセス可能 ││ │ └──────────────────────────────────┘│ └─────────────────────────────────────┘ 共有 = 高速・効率的、でも並行アクセスは危険 プロジェクト・ミーミル | Week 4 10
11. 面接問題② データ競合（レースコンディション）の発生原理 プロジェクト・ミーミル | Week 4 11
12. 面接問題②: 異常系を考える 「複数のスレッドから、共有メモリ領域にある同じ変数に同時にアクセス（読み書き） した場合、どのような問題が起こり得ますか？」 「エラーになる」で止まらない回答を引き出したい。 プロジェクト・ミーミル | Week 4 12
13. 面接問題②: Go のコードで見る var counter int var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() counter++ // ← データ競合 }() } wg.Wait() fmt.Println(counter) // 期待: 1000 // 実際: 毎回違う値（例: 973, 988, 1000...） go run -race で検出できる プロジェクト・ミーミル | Week 4 13
14. 面接問題②: 良い回答 処理の手順をちゃんと追って説明できるか counter = 10 のとき、2つのスレッドが同時に counter++ を実行: A: 10 を読み込む B: 10 を読み込む A: 11 を書き込む B: 11 を書き込む ← 期待値は 12、でも結果は 11。1つ消える 評価ポイント: 具体的な手順でメカニズムを語れるか（1つ目） エラーも出ない、クラッシュもしない、数字だけが間違っているという怖さに気 づいているか（2つ目） プロジェクト・ミーミル | Week 4 14
15. 面接問題②: 不十分な回答 「読み込むだけなら大丈夫でしょ。 」 「同時に書き込んだらエラーで落ちるんじゃ？」 実は逆: クラッシュしてくれるなら、ログを見てすぐ直せる 一番厄介なのは、エラーが出ないまま数字だけがちょっとずつズレていくこと カウンタが期待値と違う、集計が合わない、でもコードにバグの痕跡がない 本番で発覚するまで気づけない、原因究明に何日もかかる → 面接官として、この危機感を候補者が持っているか見たい プロジェクト・ミーミル | Week 4 15
16. TypeScript / Node.js ではどうか？ Node.js はシングルスレッドのイベントループ → Go みたいなデータ競合は基本的に起きにくい ただし同じ問題が起きるケース: 別スレッドを使う場面 — ブラウザの Web Worker / Node.js の Worker Threads など async/await や Promise.all で並行処理して共有状態を触るとき テックリードとして: Go のバックエンドを書くなら必ず遭遇する。TypeScript だけ書い てると気づきにくい罠 プロジェクト・ミーミル | Week 4 16
17. 面接問題③ 排他制御の解決策と実務経験 プロジェクト・ミーミル | Week 4 17
18. 面接問題③: 解決策 「その問題を防ぐためにはプログラム上でどう制御しますか？ また、実務でそういった排他制御を行った経験はありますか？」 知識 + 実務経験の両方を引き出したい。 プロジェクト・ミーミル | Week 4 18
19. 面接問題③: Go のコードで見る var mu sync.Mutex var counter int var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() mu.Lock() defer mu.Unlock() counter++ // ← ロックで保護 }() } wg.Wait() fmt.Println(counter) // → 必ず 1000 プロジェクト・ミーミル | Week 4 19
20. 面接問題③: 良い回答 「ミューテックスロックやセマフォ などの排他制御機構を使って、 1つのスレッドが処理中は他のアクセスを制限します。 」 「実務でも、API サーバーで DB のコネクションプールを複数スレッドで共有する 際にロックをかけた 経験があります。 」 「Go で goroutine からスライスや map を操作するときに sync.Mutex で保護し たこともあります。 」 評価ポイント: ロック機構の知識 + 実際のシステム設計の課題 として語れる 使用言語（Go / Rust / Java など）に紐づいた具体例が出てくる プロジェクト・ミーミル | Week 4 20
21. 排他制御の選択肢 手法 用途 Go の例 ミューテックス 基本の排他制御 sync.Mutex RWミューテックス 読み込みは並行可、書き込みは排他 sync.RWMutex アトミック操作 単一変数の軽量な更新 sync/atomic チャネル スレッド間のメッセージパッシング chan T （Go の哲学） Go の哲学: 「メモリを共有して通信するな、通信してメモリを共有しろ」 → チャネルを使うことで、そもそもロックが不要になるケースも多い プロジェクト・ミーミル | Week 4 21
22. テックリードとしての視点 共有状態を持つ設計を見つけたら、並行アクセスの可能性 を疑う レビューで goroutine や worker_threads を見たら、共有変数の保護 が必要か 確認 「エラーにならないから安全」ではなく、 「結果が保証されるか」 で判断 実務例: Redis のコネクションプール、DB接続プールの取り合い キャッシュの同時書き込み カウンタや集計処理の並行実行 プロジェクト・ミーミル | Week 4 22
23. シェル関連（さらっと） 実務の必須知識。スキルテストで確認する位置づけ プロジェクト・ミーミル | Week 4 23
24. シェル関連: 押さえておきたい3つ 1. リダイレクト・パイプ ログのエラー件数を数える cat → grep → wc の組み合わせが書けるレベルで十分 2. 変数・環境変数 export DATABASE_URL="postgres://..." # 子プロセスに渡る → 今日のプロセスの話そのもの（シェルが子プロセスに環境変数を渡す） 3. 基礎コマンド（深掘り: ps aux ） ps aux | grep node # 実行中の Node.js プロセスを探す → 今日話したプロセスが目に見える形になる。面接で「プロセスとは？」の後に「じ ゃあ実際どう確認？」と繋げられる プロジェクト・ミーミル | Week 4 24
25. プチテスト プロジェクト・ミーミル | Week 4 25
26. プチテスト 問題数: 7問（選択式5問 + 記述式2問） 制限時間: 10分 プロジェクト・ミーミル | Week 4 26
27. まとめ・次回予告 今日のポイント プロセス・スレッド・メモリ: スレッドは同じプロセス内でメモリを共有する データ競合: サイレントに壊れるのが一番怖い（ go run -race で検出可能） 排他制御: ミューテックス・セマフォ・チャネル。実務経験とセットで語れるか 次回: Week 5「仮想化 + セキュリティ」 コンテナ・Docker は今回の「プロセス」 「メモリ空間の隔離」の延長線上 「プロセスの隔離をもっと強力にしたもの」がコンテナ 自習課題: go run -race で実際にデータ競合を体験してみる Chrome DevTools の Performance タブでメインスレッドの様子を観察 プロジェクト・ミーミル | Week 4 27
28. 自習リソース リソース 内容 Linuxのしくみ 増補改訂版 プロセス・メモリ管理の基本 体系的なインプット > OS・シェル 社内カリキュラム Go by Example: Mutexes Go の排他制御の実例 Visualizing Concurrency in Go goroutine の並行処理を視覚的に プロジェクト・ミーミル | Week 4 28