龍昌餃子で理解するWebサーバーの並行処理モデル - 東葛.dev #9
by
Koji NAKAMURA
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
龍昌餃子で理解する Webサーバーの並行処理モデル 2025.11.07 東葛.dev #9 Koji NAKAMURA (@kozy4324)
Slide 2
Slide 2 text
Koji NAKAMURA ● 𝕏: @kozy4324 ● GitHub:@kozy4324 ● Classi株式会社所属 ● Kashiwa.rb 自己紹介
Slide 3
Slide 3 text
龍昌餃子とは???
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
龍昌餃子🍜🥟🍺 ● kozy4324が大好きな柏駅前すぐの中華屋さん ○ 南口から東側に出て徒歩1分! ● JR常磐線ホーム(南柏側)から見えている ● 早い、安い、美味い!を体現している ○ ???「家賃を払っていない味がする」
Slide 6
Slide 6 text
龍昌餃子のココが好き!(1) ● お疲れセットが好き! ● オーダーできるの1人1回だと思うじゃん? ● なんと無限にできる ○ バグでは? ○ 脆弱性では?
Slide 7
Slide 7 text
● お疲れセットで生ビールと麻婆豆腐を注文します ● 麻婆豆腐が30秒ぐらいで提供されます ○ ビールを追い抜いてきた! ○ そんなことある?! ○ ???「キャッシュでは?!?!」 ● 料理の提供時間が早すぎてバグっている 龍昌餃子のココが好き!(2)
Slide 8
Slide 8 text
提供時間が早すぎるので ある「説」が浮かびました
Slide 9
Slide 9 text
龍昌餃子 お客さんが C10K 来ても捌ける説
Slide 10
Slide 10 text
C10K問題とは C10K問題(英語: C10K problem)とは、Apache HTTP ServerなどのWebサーバソフトウェアとクライアントの通信に おいて、クライアントが約1万台に達すると、Webサーバーの ハードウェア性能に余裕があるにもかかわらず、レスポンス性 能が大きく下がる問題である。 引用元: https://ja.wikipedia.org/wiki/C10K問題
Slide 11
Slide 11 text
表題に戻ります
Slide 12
Slide 12 text
龍昌餃子で理解する Webサーバーの並行処理モデル 2025.11.07 東葛.dev #9 Koji NAKAMURA (@kozy4324)
Slide 13
Slide 13 text
● 中華料理屋(龍昌餃子)をメタファーにすると、Webサーバー の並行処理モデルがうまく説明できるのでは? 本発表のモチベーション
Slide 14
Slide 14 text
● クライアント → お客さん ● Webサーバー → お店&従業員 Webサーバーの中華屋メタファー リクエスト レスポンス
Slide 15
Slide 15 text
お客さんは同時にたくさんやって来る リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス
Slide 16
Slide 16 text
● プロセスベース ● スレッドベース ● ノンブロッキングI/O + イベント駆動 大量リクエストを捌くための並行処理モデル
Slide 17
Slide 17 text
プロセスベースのイメージ リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス
Slide 18
Slide 18 text
● プロセスとは実行中のプログラムの単位 ○ OSが独立したメモリ空間とリソースを割り当てる ● 各プロセスは独立して動作し、直接メモリを共有しない ● 1リクエストごとに1プロセスを割り当てる ○ メリット: 1つのプロセスが落ちても他に影響しない ○ デメリット: メモリ消費、プロセス生成コストが高い プロセスベース
Slide 19
Slide 19 text
● OSは fork() システムコールでプロセスを複製できる ○ 親プロセスの状態を引き継いだ子プロセスを生成する ● Webサーバーでは、リクエストを捌くための複数の子プロセス (ワーカープロセス)を立ち上げて待機させる方式が多い forkによるプロセス生成
Slide 20
Slide 20 text
● 独立性や生成コストを考えると「従業員ごとお店を丸々複製し ている」みたいなもの ● 当然お店の数だけ固定費もかかる ○ アプリケーションならプロセス数だけメモリを消費 ● 言うなればチェーン店やフランチャイズでは? ○ なお龍昌餃子は独立店である 中華料理屋で例えると...
Slide 21
Slide 21 text
スレッドベースのイメージ リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス
Slide 22
Slide 22 text
● スレッドはプロセス内で動作する軽量な実行単位 ● プロセス内スレッドはメモリ空間やリソースを共有する ● 1リクエストごとに1スレッドを割り当てる ○ メリット: メモリ効率が良く、生成コストが低い ○ デメリット: スレッド間の干渉やバグが発生しうる スレッドベース
Slide 23
Slide 23 text
● 「従業員がたくさん働いている」みたいなイメージ ● 店舗内の資源は共有されるため、同時に△人以上で扱っては ダメ!という資源があると色々と大変 ○ アプリケーションならスレッドセーフが要求される ● 従業員の数だけ人件費はかかる ○ 複数店舗ほどではないが従業員の数だけコスト発生 ● なお龍昌餃子の厨房はいつみても1〜2人で回している ○ なんでそんなに提供スピード早いん??? 中華料理屋で例えると...
Slide 24
Slide 24 text
C10K問題
Slide 25
Slide 25 text
● 1万同時接続を扱おうとするとスケールできない ● なぜか? ○ メモリの枯渇 ○ コンテキストスイッチ切り替えによるCPU飽和 ○ I/O待ちによるブロック ○ etc… C10K問題 vs プロセスベース, スレッドベース
Slide 26
Slide 26 text
● C10K問題への解決策として発生した設計 ● これまではブロッキングI/Oが前提だった ○ 各I/O操作でブロックされる ○ そもそもWebサーバーはI/Oが多い ○ プロセスやスレッドによる多重化が必須だった ● ノンブロッキングI/O + 準備完了でイベント通知されるOSの機 構が実用的になったのが2000年代以降(らしい) ○ 代表的なアプリケーション: nginx, Node.js ノンブロッキングI/O + イベント駆動
Slide 27
Slide 27 text
イベント駆動・ノンブロッキングI/O → ワンオペ!? リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス リクエスト レスポンス
Slide 28
Slide 28 text
● ブロッキングI/O + プロセスベース or スレッドベース ○ I/O完了待ちまでCPUが待ち状態で無駄が多い ○ メモリ消費やコンテキストスイッチ切り替えもある ● ノンブロッキングI/O + イベント駆動 ○ I/O完了待ちによるCPUの待ち状態が無くなる ○ 1プロセス(1スレッド)で多くのリクエストが捌ける つまりどういうことだってばよ
Slide 29
Slide 29 text
● 従業員が常に無駄なく休みなく働いている ○ 少数精鋭 ○ 休みがないのはブラック企業では... ● 龍昌餃子の厨房はいつみても1〜2人で回している ○ ノンブロッキングI/O + イベント駆動じゃん ○ お客さんが C10K 来てもイケる 中華料理屋で例えると...
Slide 30
Slide 30 text
● プロセスベース + スレッドベース ○ 安全性と分離性を保ちつつ並列性を高める ● スレッドベース + ノンブロッキングI/O + イベント駆動 ○ nginx, Node.js がそう ○ マルチプロセッサ(複数CPUコア)を活用するには、プロセ スかスレッドを多重化する必要がある 補足: 処理モデルは組み合わせて利用可能
Slide 31
Slide 31 text
まとめ
Slide 32
Slide 32 text
龍昌餃子 お客さんが C10K 来ても捌ける説
Slide 33
Slide 33 text
説の検証 ● 龍昌餃子はノンブロッキングI/O + イベント駆動 ● つまりお客さんが C10K 来ても捌ける ● ホンマか...!?
Slide 34
Slide 34 text
「推測するな、計測せよ」
Slide 35
Slide 35 text
● つまり龍昌餃子に飲みに行こう! ● 龍昌餃子に少しでも興味を持ってもらえたらヨシ 計測 is …
Slide 36
Slide 36 text
🥟EOF🍺