Gearman-タスク分散フレームワーク、紹介

この記事では、アプリケーションを最適化する異常な方法の1つ、つまり、タスクの分散にGearmanプロジェクトを使用することを検討したいと思います。 Gearmanは、このようなシステムを構築するためのフレームワークです。 記事にはコード例はありません。記事はより入門的ですが、実用的な情報は十分に含まれています。



機能と負荷の点で非常に複雑なプロジェクトでは、遅かれ早かれ最適化とスケーラビリティの問題が生じます。 この複雑な問題を解決するための多くのアプローチがあります。システム全体またはその特にロードされた部分の計算能力の通常の増加から、特殊なソフトウェアおよびハードウェアシステムの形での複雑なソリューションまで。 これらのソリューションを組み合わせることは、目標であるだけでなく、より速く、より高く、より強く、それらを解決するためのアプローチでもあり、弱点の検索と特定です。 多くの場合、ボトルネックは、グラフィック情報の処理、暗号化、アーカイブ、大量の情報を処理および/または返す大量のデータベースクエリに関連するリソース集約型のタスクです。



Gearmanは、Danga Interactiveのスタッフによって開発されたオープンソースプロジェクトです。 この名前は、マネージャーという言葉のアナグラムに過ぎず、このアプリケーションの機能（さまざまなタスクの管理、制御、配布）の簡単な説明はマネージャーの役​​割です。 当初、GearmanはPerlで実装されましたが、時間の経過とともに、 libeventライブラリを使用してCで書き直されました。libeventライブラリの存在は、主要部分（タスクサーバー）の機能に必要です。 * nixシステムへのインストールは大した問題ではなく、ほとんどのLinuxディストリビューションでは、gearmanパッケージが標準リポジトリに含まれています。



著者がこの記事のタイトルで「フレームワーク」という言葉を使用した理由を説明する価値があります。 実際、ギアマンの使用は比較的簡単ですが、同時にタスクの効果的なソリューションには非常に深刻な開発が必要です-これは既成のソリューションではありません。



作業でGearmanを使用するアプリケーションは、3つの主要コンポーネントで動作します。

• タスクサーバー-Gearmanの中心部分です。ここでは、タスクと結果はクライアントとパフォーマーから送られ、ここからタスクと結果はパフォーマーとクライアントにそれぞれ送信されます。
• 請負業者-機能の実装が必要な主要部分です。 請負業者はサーバーからのタスクを受け入れて完了しようとします。
• クライアントも個別に実装され、タスクを作成してサーバーに送信し、場合によっては（後で詳しく説明します）結果を取得します。

クライアントと請負業者はGearman APIを使用して、必要な機能を呼び出して実装します。 上記のアーキテクチャを示す図は、メインプロジェクトサイトに表示されます。







そのようなシステムの操作の古典的な例を考えてみましょう-ユーザーが写真をサイトにアップロードし、それをすべての友達に見せたいと思っています。 サイト全体で使用するには、この写真のさまざまなサイズをすばやく準備する必要があります。 はい、ある時点までは、グラフィックスの生成に関するすべての作業をシステムのメインコードで実行できます。すると、habraeffectが発生し、システム全体が流入します。 次に、Gearmanを使用してこの問題を解決する方法を見ていきます。写真を受け取ったら、写真に関する必要な情報を含むGearmanサーバーのタスクを作成します（原則として、写真自体をタスクに含めることもできますが、私にとっては、それは利益がなく、より良いでしょうアドレスを使用して）実行するために送信します。 タスクサーバーは、無料のエグゼキューター（ラウンドロビン）を選択し（おそらく既に推測されているように、複数のエグゼキューターが存在する可能性があります）、完了させるタスクを送信します。 請負業者は必要なすべての情報を受け取り、必要に応じて処理し、正常に完了したタスク、およびタスクが同期されている場合は作業の結果に関する回答を送信します。 はい。2種類のタスクがあります。クライアントがタスクの完了を待機している場合は同期であり、それに応じて結果が発生します。クライアントがタスクのイニシエーターとしてのみ動作する場合は非同期です。 ここで、gearmanアプリケーションの各部分間の通信プロトコルがTCP / IPであるという事実を追加します。つまり、各部分（サーバー、クライアント、エグゼキューター）は別々のマシン上にあることが理解されます。 複数のサーバーとクライアントが存在する場合があります。 クライアントとエグゼキュータの実装は互いに独立しています（gearmanを操作するためのAPIが実装されている利用可能な言語には、perl、php、python、java、C、MySQL UDFなどがあります）。 このプロジェクトは活発に開発されています-バグ修正と改善を伴う新しいバージョンが毎月リリースされます。 出力では、開発者の想像力と経験によってのみ解決されるタスクの範囲が制限される、かなりバラ色の画像が得られます。 たとえば、正常に解決され、ギアマンを使用して解決されるいくつかの一般的なタスク：

• 写真を処理する上記のタスク。さまざまなサイズの生成のみに限定されない
• クライアント側でクラウンと遅延を使用しない、キャッシュ内のデータの非同期無効化/更新
• 大量のデータをアーカイブする
• executor側で暗号化を使用して、形式（key => value）のデータを操作します

今、いくつかの実用的な情報。 gearmanの主な仕事のオブジェクトは、タスク（タイプ（同期、非同期）、タスクの名前（サイズ変更など）、およびパラメーター）で構成されるタスクです。 各タスクは、名前とパラメーターのペアで識別されます。 つまり、同じパラメーターを持つ2つの同一のタスクがサーバーに到着した場合、最初のタスクのみが完了し、2番目のサーバーはスローバックされます。 このニュアンスにより、多くの興味深いことが起こります。常に覚えておく価値があります。特定のタスクを完了する必要がありますか？ -パラメータに一意の値を追加します。



サーバーはデーモンプロセスです。 このようなアプリケーションのユーザーポートインターフェイス設定標準とともに、多くの構成パラメーターがあり、いくつかの特定のオプションもあります。 タスクを完了するための試行回数は、-jパラメーター--job-retries =で構成されます。 複数のスレッドを使用するには、-tオプション、-threads =が存在します。 サーバーにはタスクキューを何らかの種類のストレージに保存する機能があるため、再起動時にデータを失うことなくプロセス全体を復元できます。 リポジトリは、MySQL / drizzle、memcached、PostgreSQL、またはsqlliteです。 興味深いのは、通信プロセスクライアント->タスクサーバーでサードパーティのプロトコルを使用するオプションです。 現在実装されているこのようなプロトコルはHTTPのみです。 このオプションを使用すると、HTTP要求を介して特定のポートでタスクを受信するようにGearmanサーバーを構成できます（要求されたuriはタスク名、http本体からワークロード、httpヘッダーにそれぞれタスクタイプに変換されます）。つまり、クライアント実装は単純なHTTPクライアントを呼び出し元。 これにより、タスクのタイプ/サイズに制限が課されることはありません。 ギアマンでの HTTPの使用については、 こちらをご覧ください 。 HTTPプロトコルとGearmanを使用すると、効率的にバランスの取れたRESTサービスを簡単に構築できます。 API関数を呼び出すためのラッパーはほとんどの環境向けに作成されているため、ほぼすべてのプログラミング言語からgearmanのタスクを作成できます。



実行部分は、それぞれいわゆるエグゼキューターにあります。 ここでは、標準のphp、python、javaからmysqlのユーザー定義関数に至るまで、実装ツールの選択も非常に広範囲です。 唯一の条件は、gearmanライブラリのサポートが利用可能であることです。これには、モジュールの追加コンパイルが必要になる場合があります。 いわゆるエグゼキュータ（ワーカー）は、実行可能なすべてのタスクを登録した後、メモリ内でサーバーからのタスクの到着を待機するバックグラウンドプロセスです。 特定のベンダーが通信するサーバーの数に制限はありません。



欠点について話しましょう。それらのいくつかがあり、それらはさまざまな程度の重大度です。 executorは長期間有効なプロセスであるため、その機能の変更はexecutor自体を再起動するプロセスを意味し、このexecutorが実行できるタスクの追加/削除にも同じことが当てはまります。 つまり、新しい機能を追加したり、既存の機能を変更したりする必要がある場合、このタスクに関連付けられている実行者のすべてのプロセスを再起動する必要があります。 実行者が異なるサーバーに異なる数で散在している場合、このプロセスは簡単ではありません。 また、すべての言語が効率的なデーモンプロセスを記述するように設計されているわけではありません。



サーバーによるタスクの分散は、単一のアルゴリズム（ラウンドロビン）に従ってのみ行われます。 はい、2つの優先度レベル（高および低）のタスクがあります。 ただし、タスクの実行をより正確に制御することはできません。 さらに、どのエクゼキューターがタスクを実行するかを正確に知ることは不可能であり、どのノードに送信するべきかを直接示すことも不可能であり、デバッグプロセスを非常に複雑にします。



上記の欠点から、主なものは次のとおりです-実装されたシステムを管理するための健全な手段の欠如。 すべてを手動で行う必要があり、ギアマンアプリケーションの構造に留意してください。



もちろん、説明されているすべての問題には解決策があります。その実装については、次の記事で説明します。



Gearmanの情報ソースやその他の興味深い情報へのリンクが少しあります。

• 実際のメインサイト： gearman.org
• ランチパッドプロジェクトページ： launchpad.net/gearmand
• Googleグループでのディスカッション： groups.google.com/group/gearman/topics
• PHPでの使用例： http : //highload.com.ua/
• Gearmanサーバーの起動 ： gearmanhq.com