$30 off During Our Annual Pro Sale. View Details »
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
230
龍昌餃子で理解する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
510
Rubyで作る論理回路シミュレータ - Shinjuku.rb #99
kozy4324
0
96
Steep導入したいRTA - Kashiwa.rb #11
kozy4324
0
160
これまで細々と作成したGemの紹介をします - Kashiwa.rb #9
kozy4324
0
230
東京Ruby会議12のお手伝いしてきた話
kozy4324
0
120
個人開発発表 LT - Shinjuku.rb #97
kozy4324
0
370
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
業務のトイルをバスターせよ 〜AI時代の生存戦略〜
staka121
PRO
2
220
20251219 OpenIDファウンデーション・ジャパン紹介 / OpenID Foundation Japan Intro
oidfj
0
190
Reinforcement Fine-tuning 基礎〜実践まで
ch6noota
0
190
ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素
sonoda_mj
5
490
Haskell を武器にして挑む競技プログラミング ─ 操作的思考から意味モデル思考へ
naoya
7
1.6k
学習データって増やせばいいんですか?
ftakahashi
2
510
1人1サービス開発しているチームでのClaudeCodeの使い方
noayaoshiro
2
440
Database イノベーショントークを振り返る/reinvent-2025-database-innovation-talk-recap
emiki
0
240
[デモです] NotebookLM で作ったスライドの例
kongmingstrap
0
160
Identity Management for Agentic AI 解説
fujie
0
110
AWS re:Invent 2025で見たGrafana最新機能の紹介
hamadakoji
0
430
Lookerで実現するセキュアな外部データ提供
zozotech
PRO
0
170
Featured
See All Featured
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
115
91k
The Spectacular Lies of Maps
axbom
PRO
1
390
Making Projects Easy
brettharned
120
6.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Designing for humans not robots
tammielis
254
26k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
1
110
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
0
25
Rails Girls Zürich Keynote
gr2m
95
14k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.8k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
190
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
170
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🍺