Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
龍昌餃子で理解するWebサーバーの並行処理モデル - 東葛.dev #9
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Koji NAKAMURA
November 06, 2025
Technology
1
270
龍昌餃子で理解するWebサーバーの並行処理モデル - 東葛.dev #9
Koji NAKAMURA
November 06, 2025
Tweet
Share
More Decks by Koji NAKAMURA
See All by Koji NAKAMURA
Rubyで作る論理回路シミュレータの設計の話 - Kashiwa.rb #12
kozy4324
1
530
Rubyで作る論理回路シミュレータ - Shinjuku.rb #99
kozy4324
0
100
Steep導入したいRTA - Kashiwa.rb #11
kozy4324
0
170
これまで細々と作成したGemの紹介をします - Kashiwa.rb #9
kozy4324
0
250
東京Ruby会議12のお手伝いしてきた話
kozy4324
0
120
個人開発発表 LT - Shinjuku.rb #97
kozy4324
0
440
Ruby界隈を中心に2024をふりかえる - Kashiwa.rb #6
kozy4324
0
200
「今までで一番学びになった瞬間」発表 LT - Shinjuku.rb #96
kozy4324
0
390
脆弱性から学ぶシリーズ CVE-2024-34341 - Kashiwa.rb #5 LT
kozy4324
0
330
Other Decks in Technology
See All in Technology
Claude Code for NOT Programming
kawaguti
PRO
1
110
AIエージェントに必要なのはデータではなく文脈だった/ai-agent-context-graph-mybest
jonnojun
1
250
Oracle Cloud Observability and Management Platform - OCI 運用監視サービス概要 -
oracle4engineer
PRO
2
14k
SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル / SRE Kaigi 2026
aeonpeople
6
2.6k
OCI Database Management サービス詳細
oracle4engineer
PRO
1
7.4k
SREが向き合う大規模リアーキテクチャ 〜信頼性とアジリティの両立〜
zepprix
0
480
モダンUIでフルサーバーレスなAIエージェントをAmplifyとCDKでサクッとデプロイしよう
minorun365
4
230
Context Engineeringが企業で不可欠になる理由
hirosatogamo
PRO
3
680
Kiro IDEのドキュメントを全部読んだので地味だけどちょっと嬉しい機能を紹介する
khmoryz
0
210
Codex 5.3 と Opus 4.6 にコーポレートサイトを作らせてみた / Codex 5.3 vs Opus 4.6
ama_ch
0
220
Tebiki Engineering Team Deck
tebiki
0
24k
Greatest Disaster Hits in Web Performance
guaca
0
300
Featured
See All Featured
Done Done
chrislema
186
16k
Paper Plane (Part 1)
katiecoart
PRO
0
4.3k
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
70
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
3.6k
Speed Design
sergeychernyshev
33
1.5k
New Earth Scene 8
popppiees
1
1.5k
Crafting Experiences
bethany
1
54
Practical Orchestrator
shlominoach
191
11k
The Language of Interfaces
destraynor
162
26k
Git: the NoSQL Database
bkeepers
PRO
432
66k
Transcript
龍昌餃子で理解する Webサーバーの並行処理モデル 2025.11.07 東葛.dev #9 Koji NAKAMURA (@kozy4324)
Koji NAKAMURA • 𝕏: @kozy4324 • GitHub:@kozy4324 • Classi株式会社所属 •
Kashiwa.rb 自己紹介
龍昌餃子とは???
None
龍昌餃子🍜🥟🍺 • kozy4324が大好きな柏駅前すぐの中華屋さん ◦ 南口から東側に出て徒歩1分! • JR常磐線ホーム(南柏側)から見えている • 早い、安い、美味い!を体現している ◦
???「家賃を払っていない味がする」
龍昌餃子のココが好き!(1) • お疲れセットが好き! • オーダーできるの1人1回だと思うじゃん? • なんと無限にできる ◦ バグでは? ◦
脆弱性では?
• お疲れセットで生ビールと麻婆豆腐を注文します • 麻婆豆腐が30秒ぐらいで提供されます ◦ ビールを追い抜いてきた! ◦ そんなことある?! ◦ ???「キャッシュでは?!?!」
• 料理の提供時間が早すぎてバグっている 龍昌餃子のココが好き!(2)
提供時間が早すぎるので ある「説」が浮かびました
龍昌餃子 お客さんが C10K 来ても捌ける説
C10K問題とは C10K問題(英語: C10K problem)とは、Apache HTTP ServerなどのWebサーバソフトウェアとクライアントの通信に おいて、クライアントが約1万台に達すると、Webサーバーの ハードウェア性能に余裕があるにもかかわらず、レスポンス性 能が大きく下がる問題である。 引用元:
https://ja.wikipedia.org/wiki/C10K問題
表題に戻ります
龍昌餃子で理解する Webサーバーの並行処理モデル 2025.11.07 東葛.dev #9 Koji NAKAMURA (@kozy4324)
• 中華料理屋(龍昌餃子)をメタファーにすると、Webサーバー の並行処理モデルがうまく説明できるのでは? 本発表のモチベーション
• クライアント → お客さん • Webサーバー → お店&従業員 Webサーバーの中華屋メタファー リクエスト
レスポンス
お客さんは同時にたくさんやって来る リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト
レスポンス
• プロセスベース • スレッドベース • ノンブロッキングI/O + イベント駆動 大量リクエストを捌くための並行処理モデル
プロセスベースのイメージ リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト
レスポンス
• プロセスとは実行中のプログラムの単位 ◦ OSが独立したメモリ空間とリソースを割り当てる • 各プロセスは独立して動作し、直接メモリを共有しない • 1リクエストごとに1プロセスを割り当てる ◦ メリット:
1つのプロセスが落ちても他に影響しない ◦ デメリット: メモリ消費、プロセス生成コストが高い プロセスベース
• OSは fork() システムコールでプロセスを複製できる ◦ 親プロセスの状態を引き継いだ子プロセスを生成する • Webサーバーでは、リクエストを捌くための複数の子プロセス (ワーカープロセス)を立ち上げて待機させる方式が多い forkによるプロセス生成
• 独立性や生成コストを考えると「従業員ごとお店を丸々複製し ている」みたいなもの • 当然お店の数だけ固定費もかかる ◦ アプリケーションならプロセス数だけメモリを消費 • 言うなればチェーン店やフランチャイズでは? ◦
なお龍昌餃子は独立店である 中華料理屋で例えると...
スレッドベースのイメージ リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト
レスポンス
• スレッドはプロセス内で動作する軽量な実行単位 • プロセス内スレッドはメモリ空間やリソースを共有する • 1リクエストごとに1スレッドを割り当てる ◦ メリット: メモリ効率が良く、生成コストが低い ◦
デメリット: スレッド間の干渉やバグが発生しうる スレッドベース
• 「従業員がたくさん働いている」みたいなイメージ • 店舗内の資源は共有されるため、同時に△人以上で扱っては ダメ!という資源があると色々と大変 ◦ アプリケーションならスレッドセーフが要求される • 従業員の数だけ人件費はかかる ◦
複数店舗ほどではないが従業員の数だけコスト発生 • なお龍昌餃子の厨房はいつみても1〜2人で回している ◦ なんでそんなに提供スピード早いん??? 中華料理屋で例えると...
C10K問題
• 1万同時接続を扱おうとするとスケールできない • なぜか? ◦ メモリの枯渇 ◦ コンテキストスイッチ切り替えによるCPU飽和 ◦ I/O待ちによるブロック
◦ etc… C10K問題 vs プロセスベース, スレッドベース
• C10K問題への解決策として発生した設計 • これまではブロッキングI/Oが前提だった ◦ 各I/O操作でブロックされる ◦ そもそもWebサーバーはI/Oが多い ◦ プロセスやスレッドによる多重化が必須だった
• ノンブロッキングI/O + 準備完了でイベント通知されるOSの機 構が実用的になったのが2000年代以降(らしい) ◦ 代表的なアプリケーション: nginx, Node.js ノンブロッキングI/O + イベント駆動
イベント駆動・ノンブロッキングI/O → ワンオペ!? リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト
レスポンス リクエスト レスポンス
• ブロッキングI/O + プロセスベース or スレッドベース ◦ I/O完了待ちまでCPUが待ち状態で無駄が多い ◦ メモリ消費やコンテキストスイッチ切り替えもある
• ノンブロッキングI/O + イベント駆動 ◦ I/O完了待ちによるCPUの待ち状態が無くなる ◦ 1プロセス(1スレッド)で多くのリクエストが捌ける つまりどういうことだってばよ
• 従業員が常に無駄なく休みなく働いている ◦ 少数精鋭 ◦ 休みがないのはブラック企業では... • 龍昌餃子の厨房はいつみても1〜2人で回している ◦ ノンブロッキングI/O
+ イベント駆動じゃん ◦ お客さんが C10K 来てもイケる 中華料理屋で例えると...
• プロセスベース + スレッドベース ◦ 安全性と分離性を保ちつつ並列性を高める • スレッドベース + ノンブロッキングI/O
+ イベント駆動 ◦ nginx, Node.js がそう ◦ マルチプロセッサ(複数CPUコア)を活用するには、プロセ スかスレッドを多重化する必要がある 補足: 処理モデルは組み合わせて利用可能
まとめ
龍昌餃子 お客さんが C10K 来ても捌ける説
説の検証 • 龍昌餃子はノンブロッキングI/O + イベント駆動 • つまりお客さんが C10K 来ても捌ける •
ホンマか...!?
「推測するな、計測せよ」
• つまり龍昌餃子に飲みに行こう! • 龍昌餃子に少しでも興味を持ってもらえたらヨシ 計測 is …
🥟EOF🍺