Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
龍昌餃子で理解するWebサーバーの並行処理モデル - 東葛.dev #9
Search
Koji NAKAMURA
November 06, 2025
Technology
1
210
龍昌餃子で理解する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
500
Rubyで作る論理回路シミュレータ - Shinjuku.rb #99
kozy4324
0
95
Steep導入したいRTA - Kashiwa.rb #11
kozy4324
0
150
これまで細々と作成したGemの紹介をします - Kashiwa.rb #9
kozy4324
0
230
東京Ruby会議12のお手伝いしてきた話
kozy4324
0
120
個人開発発表 LT - Shinjuku.rb #97
kozy4324
0
360
Ruby界隈を中心に2024をふりかえる - Kashiwa.rb #6
kozy4324
0
190
「今までで一番学びになった瞬間」発表 LT - Shinjuku.rb #96
kozy4324
0
380
脆弱性から学ぶシリーズ CVE-2024-34341 - Kashiwa.rb #5 LT
kozy4324
0
310
Other Decks in Technology
See All in Technology
Oracle Technology Night #95 GoldenGate 26ai の実装に迫る1
oracle4engineer
PRO
0
150
小さな判断で育つ、大きな意思決定力 / 20251204 Takahiro Kinjo
shift_evolve
PRO
1
580
安いGPUレンタルサービスについて
aratako
2
2.6k
GitHub Copilotを使いこなす 実例に学ぶAIコーディング活用術
74th
3
1.7k
チーリンについて
hirotomotaguchi
3
980
Security Diaries of an Open Source IAM
ahus1
0
130
【pmconf2025】PdMの「責任感」がチームを弱くする?「分業型」から全員がユーザー価値に本気で向き合う「共創型開発チーム」への変遷
toshimasa012345
0
270
生成AIでテスト設計はどこまでできる? 「テスト粒度」を操るテーラリング術
shota_kusaba
0
530
AWS CLIの新しい認証情報設定方法aws loginコマンドの実態
wkm2
5
560
AI 駆動開発勉強会 フロントエンド支部 #1 w/あずもば
1ftseabass
PRO
0
210
ML PM Talk #1 - ML PMの分類に関する考察
lycorptech_jp
PRO
1
730
Reinforcement Fine-tuning 基礎〜実践まで
ch6noota
0
160
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
PRO
55
12k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
970
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.8k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.8k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Testing 201, or: Great Expectations
jmmastey
46
7.8k
Code Review Best Practice
trishagee
74
19k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Documentation Writing (for coders)
carmenintech
76
5.2k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
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🍺