ノンブロッキング・フレームワークでのスレッドプールの使い方

Table of Contents

同期処理と非同期処理 スレッドの枯渇 bulkhead-pattern circuit-breaker little’s law

同期処理と非同期処理 同期処理

処理の呼び出し元が処理結果の取得を待つ必要がある 非同期処理

処理の呼び出し元が処理結果の取得を待つことなく次の処理を行うことができる

同期処理と非同期処理 同期処理

同期処理と非同期処理 非同期処理

同期処理と非同期処理 非同期処理を行うメリット

スレッドを効率的に使うことができる 計算が独立している場合は応答時間を早められる

非同期処理のデメリット 複雑性

スレッドプール エラーハンドリング 合成 / メッセージ駆動

スレッドの枯渇

スレッドの枯渇 同期 API にしてしまうとその部分は Request-Response になってしまう

スレッドの枯渇 同期 API にしてしまうとその部分は Request-Response になってしまう

スレッドの枯渇

スレッドの枯渇

遅延の伝播 共通のスレッドプールだけだと、特定のサブシステムや処理の遅延がシステム全体に波及してしまう

遅延の伝播 共通のスレッドプールだけだと、特定のサブシステムや処理の遅延がシステム全体に波及してしまう

ここでやりたいこと サブシステムの障害をシステム全体に波及させないようにする

例えば、配送システムが応答を返せなくなった場合に商品を参照しているだけの機能にまで影響を与えないようにする 障害が発生してもなるべく早く応答を返す

bulkhead-pattern

道路が一つしかないと事故によって全ての車両が待たされる

bulkhead-pattern

道路を複数用意しておくと事故の起きている経路を通らない車両は待たされない

bulkhead-pattern

スレッドプールは障害ドメインによって分ける データベースや外部サービスとの接続

スレッドの枯渇による影響を最小限に留められるようにする

bulkhead-pattern

どうしても暗黙的にしたい場合 (Scala) ファントム参照を使うとよいかも？

Little’s Law

L = λW L: スレッド数 λ: 到着率 (= 単位時間当たりのリクエスト数 ) W: 1 リクエスト当たりの処理時間

処理時間が安定している処理では、リトルの法則を適用することで効率的にスレッドを利用できる 処理時間が安定していない場合は平均時間だけでは考えないようにする

CPU バウンドな処理でも core 数以上のスレッドを割り当てないとスループットが出ないこともある

circuit-breaker

スレッドプールを分割してそれぞれのプールサイズを適切に設定しても、障害の起きている経路を通る処理は遅延してしまう こういった経路はフェイルオーバーさせることで応答性を保つことができる。

circuit-breaker

スレッドプールを分割してそれぞれのプールサイズを適切に設定しても、障害の起きている経路を通る処理は遅延してしまう こういった経路はフェイルオーバーさせることで応答性を保つことができる。

http://doc.akka.io/docs/akka/snapshot/common/circuitbreaker.html

まとめ bullhead-pattern

障害・遅延がシステム全体に波及しないように複数のスレッドプールを使い分ける 非同期処理のライブラリを適切に扱えているかどうかをチェックしよう

little’s raw スレッドを効率的に使えるように適切なプールサイズを見積もる

circuit-breaker 障害が起きた経路はフェイルオーバーさせる