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

OS とシェルの基礎を、並行処理の落とし穴と面接での見極めに落とし込む勉強会の資料です。

プロセス・スレッド・メモリの関係から入り、データ競合（レースコンディション）が「サイレントに壊れる」メカニズム、それを防ぐ排他制御（ミューテックスやセマフォ）の必要性と実装判断を扱います。後半はリダイレクト・パイプ、環境変数、基礎的なコマンド操作までを実務の文脈で押さえます。

ねらいは、用語を覚えるのでなく「なぜ排他制御が要るか」「並行処理がどこで壊れるか」を自分の言葉で説明できる状態にすること。候補者が並行処理の怖さまで語れているかを見分ける観点も合わせて示します。

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

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