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
Koji NAKAMURA
November 06, 2025
Technology
1
110
龍昌餃子で理解する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
480
Rubyで作る論理回路シミュレータ - Shinjuku.rb #99
kozy4324
0
91
Steep導入したいRTA - Kashiwa.rb #11
kozy4324
0
140
これまで細々と作成したGemの紹介をします - Kashiwa.rb #9
kozy4324
0
220
東京Ruby会議12のお手伝いしてきた話
kozy4324
0
100
個人開発発表 LT - Shinjuku.rb #97
kozy4324
0
340
Ruby界隈を中心に2024をふりかえる - Kashiwa.rb #6
kozy4324
0
180
「今までで一番学びになった瞬間」発表 LT - Shinjuku.rb #96
kozy4324
0
370
脆弱性から学ぶシリーズ CVE-2024-34341 - Kashiwa.rb #5 LT
kozy4324
0
290
Other Decks in Technology
See All in Technology
GTC 2025 : 가속되고 있는 미래
inureyes
PRO
0
150
QAEが生成AIと越える、ソフトウェア開発の境界線
rinchsan
0
300
SREのキャリアから経営に近づく - Enterprise Risk Managementを基に -
shonansurvivors
1
740
触れるけど壊れないWordPressの作り方
masakawai
0
680
어떤 개발자가 되고 싶은가?
arawn
1
440
LLM APIを2年間本番運用して苦労した話
ivry_presentationmaterials
10
8.4k
今日から使える AWS Step Functions 小技集 / AWS Step Functions Tips
kinunori
2
140
今から間に合う re:Invent 準備グッズと現地の地図、その他ラスベガスを周る際の Tips/reinvent-preparation-guide
emiki
1
290
データエンジニアとして生存するために 〜界隈を盛り上げる「お祭り」が必要な理由〜 / data_summit_findy_Session_1
sansan_randd
1
970
The Twin Mandate of Observability
charity
1
390
[AWS 秋のオブザーバビリティ祭り 2025 〜最新アップデートと生成 AI × オブザーバビリティ〜] Amazon Bedrock AgentCore で実現!お手軽 AI エージェントオブザーバビリティ
0nihajim
2
360
プロダクト開発と社内データ活用での、BI×AIの現在地 / Data_Findy
sansan_randd
1
830
Featured
See All Featured
It's Worth the Effort
3n
187
28k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
The World Runs on Bad Software
bkeepers
PRO
72
11k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.8k
The Language of Interfaces
destraynor
162
25k
Into the Great Unknown - MozCon
thekraken
40
2.1k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.7k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
2
270
Thoughts on Productivity
jonyablonski
72
4.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
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🍺