マルチスレッドはスケーラビリティを行き止まりに追い込みます

管理者 · 掲載地 2014/12/06 22:21:58

これはPythonの世界からの記事ですが、プログラミング分野全体に当てはまります。マルチスレッドはリクエスト処理を高速化させますが、上限もあり、グリーン(マイクロスレッド)スレッドが解決策です。

マルチスレッドソフトウェア開発は、特にユーザーへの迅速な対応に要求の高いパフォーマンスを必要とするネットワーク中心のアプリケーションにおいて、多くの問題を解決します。残念ながら、マルチスレッディングだけでは大規模な問題を解決するには不十分です並行処理性的な問題。

これらの問題に対処するには、非同期イベントやコールバックベースのメカニズムを用いたプログラミングモデルの変更が必要です。 Druvaでは、大規模な問題を解決するためにDhagaというPythonベースのライブラリを作成しました並行処理一方、プログラミングモデル自体は大きな変更を必要としません。

ソフトウェア開発者は一つの環境で生活しています並行処理世界。スレッドは今日、特に開発中、特にアプリケーションが集中的なネットワーク操作を行う場合、例えばDruvaのようなinSyncシステム(ネットワークセキュリティ同期製品)などにおいては、一流の市民です。マルチスレッドは、ネットワーク操作のためのプログラミングコードの流れをシンプルかつ秩序あるものにします。アプリケーションのパフォーマンス向上や改善が必要な場合は、改善が可能です弾性スレッド数を増やすことができます。

しかし、何千ものスケールに関しては並行処理リクエストやスレッドだけでは不十分です。

マルチスレッドには以下の欠点があることがわかりました:
1. inSyncシステムクライアントはネットワークRPCコールを通じて大量のファイルをサーバーにバックアップする必要があります。開発者が作業を高速化する典型的な方法はスレッドを使うことです。しかし、マルチスレッドによる性能はメモリとCPUのコストを増加させます。開発者は速度とスレッド数のバランスを保つ必要があります。

2. 私たちのサーバーはinSyncシステムと数千人の顧客間の対応を担当する必要があります並行処理接続と通知。効率的に接続を処理するために、リクエストを処理するためにスレッドを使用します。しかし、inSyncシステムの顧客数が増えるにつれて、スレッド数を増やし続ける必要があり、それが多くのサーバーメモリとCPUを消費します。

3. 私たちのウェブサーバーは数千の並列HTTPリクエストを処理する必要があります。ほとんどの作業は、データの受信と送受信を行い、それをinSyncシステムのバックエンドに渡すネットワークソケットに集中しています。ほとんどのスレッドがネットワーク操作を待つ原因になります。 C10Kの問題を引き起こしているのは、ウェブサーバーに対して数千件の同期リクエストがある場合、各リクエストごとにスレッドを生成するのはかなりスケーラブル(スケール)に欠けることです。

非同期フレームワークの限界
Twisted、Tornado Tornado、asyncoreなど多くの非同期フレームワークは、開発者が一般的なスレッド利用方法から離れる手助けをします。これらのフレームワークは、ノンブロッキングソケットやコールバック機構(Node.jsに似ています)に依存しています。これらのフレームワークをそのまま使うと、Druvaコードの主要な部分はリファクタリングしなければなりません。それは私たちがやりたいことではありません。コードをリファクタリングすると開発やテストのサイクルが長くなり、スケール要件の達成が妨げられます。製品の複数の部分が巨大である必要があるため、私たち一人ひとりがそれらをリファクタリングしなければならず、だからこそ倍増や三倍にする手間がかかるのです。

コードを大幅に変更しないため、既存のフレームワークを直接使うのをやめざるを得ませんでした。幸いにも、いくつかの便利なツールを見つけました。

ネットワークI/O上のコード実行を制御したいため、スレッドをマイクロスレッドに分割する方法が必要です。次のようになりますグリーンレット。これはコルーチンコルーチンと呼ばれる非暗黙のマイクロスレッドスケジューリングを提供します。要するにあの。コードの実行をコントロールしたいときに便利です。グリーンレットの収穫停止時間をコントロールできるため、カスタムスケジュール用のマイクロスレッドを作成できます。これは私たちにとって完璧で、コードのスケジューリングを完全にコントロールできるからです。

Tornadoは、数千件の非同期リクエストを処理するために設計された、Pythonで書かれたシンプルでブロッキングしないウェブサーバーフレームワークです。そのコアコンポーネントであるIOLoop IOStreamを使用しています。 IOLoopは非ブロッキングソケットI/Oイベントループです。 Linuxではepoll、BSDやMac OS Xではキューを利用し、Windowsでは利用可能な場合はselectを使用します。 IOStreamは読み書きのための便利なパッケージングなどのノンブロッキングソケットを提供しています。すべてのソケット操作をTornadoに委任し、コールバックを使ってコード操作を完了させます(banq注:Node.jsメカニズムに非常に似ています)。

良いスタートですが、もっと必要です。上記のモジュールをコードに直接使う場合、多くのRPCコードを変更しなければなりません。例えば、グリーンレットを通じたRPCのスケジューリング、グリーンレットがブロックされないように(グリーンレットが詰まるとスレッド全体や他のスレッドが詰まってしまう)、Tornadoからのコールバック関数の処理などです。

外部呼び出しでグリーンレットを管理・配置する抽象化が必要であり、この抽象化はスレッドを超えて大幅に拡張可能です。この抽象化がDhagaであり、アプリケーションコードの流れを従来の同期シーケンスのようにプログラムできますが、実行は非同期です。

Dhaga(ヒンディー語で「スレッド」を意味する)は、軽量スレッドの実行フレームワークで、抽象化しています。 Dhagaクラスはgreenletsから派生し、スタックスイッチングを用いて単一のOSスレッド内で複数のコードフローを実行します。 1つのオペレーティングシステムのスレッドは、協調スケジューリングを用いて複数のdhagasを実行します。ダガが待機する(主にRPC呼び出しの返りを待つ間)は、親レベル(すなわちそれを作成したOSレベルのスレッドの実行コンテキスト)に制御権を譲渡します。親レベルは次のダガを実行準備の準備をします。 RPC呼び出しはTornadoのウェブサーバーに非同期でSocketを書き込むために渡され、戻った際にコールバックを登録します。このRPCが戻ると、待機中のDHAGAは実行キューに追加され、親スレッドが引き継ぎます。 (バンク注:node.js原理に類似)

高遅延処理にはスレッドの代わりにDhagaを使うことができ、スレッド数がスループットの合理的な上限を超えた場合は1スレッドに512のdhagaを使用します。

試験 · 掲載地 2014/12/07 17:22:55

読んで返信することは美徳です

マルチスレッドはスケーラビリティを行き止まりに追い込みます

関連記事

閲覧したセクション