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
310
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
龍昌餃子で理解するWebサーバーの並行処理モデル - 東葛.dev #9
Koji NAKAMURA
November 06, 2025
More Decks by Koji NAKAMURA
See All by Koji NAKAMURA
Lightning近況報告
kozy4324
0
260
Rubyで作る論理回路シミュレータの設計の話 - Kashiwa.rb #12
kozy4324
1
600
Rubyで作る論理回路シミュレータ - Shinjuku.rb #99
kozy4324
0
120
Steep導入したいRTA - Kashiwa.rb #11
kozy4324
0
230
これまで細々と作成したGemの紹介をします - Kashiwa.rb #9
kozy4324
0
300
東京Ruby会議12のお手伝いしてきた話
kozy4324
0
140
個人開発発表 LT - Shinjuku.rb #97
kozy4324
0
570
Ruby界隈を中心に2024をふりかえる - Kashiwa.rb #6
kozy4324
0
250
「今までで一番学びになった瞬間」発表 LT - Shinjuku.rb #96
kozy4324
0
440
Other Decks in Technology
See All in Technology
事業成長とAI活用を止めないデータ基盤アーキテクチャの設計思想
hiracky16
0
550
CDKで書くECSのベストプラクティス、 改めて考え直す2026 #cdkconf2026
makies
3
940
reFACToring
moznion
0
200
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
データエンジニアリングとドメイン駆動設計
masuda220
PRO
14
2.5k
Amplify Gen2でbackend.tsにCDKを定義する/しない事によるCDKの挙動の違いとユースケース
smt7174
1
490
GoでCコンパイラを作った話
repunit
0
150
AI時代におけるエンジニアの新たな役割──FDEとクオリアの探求/登壇資料(戸井田 裕貴)
hacobu
PRO
0
330
探索・可視化・自動化を一本化 Amazon Quickでデータ活用スピードを上げる方法
koheiyoshikawa
0
170
StepFunctionsとGraphRAGを活用した暗黙知活用のためのRAG基盤
yakumo
0
140
AIエージェントがあれば技術書なんてすぐ書けるでしょ→無理でした
watany
2
290
2年前に削除したPHPクラスが、 ある日突然決済をエラーにした
ykagano
1
790
Featured
See All Featured
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
420
The SEO Collaboration Effect
kristinabergwall1
1
510
How to Ace a Technical Interview
jacobian
281
24k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Google's AI Overviews - The New Search
badams
0
1.1k
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
660
Deep Space Network (abreviated)
tonyrice
0
230
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
560
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
450
The Pragmatic Product Professional
lauravandoore
37
7.4k
Tell your own story through comics
letsgokoyo
1
1k
Navigating Weather and Climate Data
rabernat
0
400
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🍺