適切なフレームワークの選び方 - 分散タスクスケジューリングフレームワークの選択

1. 背景

スケジュールされたタスクは、私たちの開発において不可欠な部分です。たとえば、一部の電子商取引システムでは、誕生日クーポンが定期的にユーザーに送信され、一部の調整システムでは、調整が定期的に実行される場合があります。昔は、各サービスには 1 台のマシンしかなく、このマシンにタイマー スケジュールを設定することで、基本的にビジネス ニーズを満たすことができました。しかし、時代の変化により、1 台のマシンでは私たちのニーズを満たすことは難しくなってきています。現時点では、ビジネスを運営し、トラフィックを受け入れるには、10 台、20 台、あるいはそれ以上のマシンが必要になる可能性があります。これを水平方向の拡張と呼びます。しかし、ここで問題があります。非常に多くのマシンが引き続き当社の Timerschedule を使用するとどうなるでしょうか?上記の電子商取引システムでは、誕生日クーポンが多数ユーザーに送信され、会社に多大な損失をもたらす可能性があるため、スケジュールされたタスクを複数のマシンで 1 回だけ実行する他の方法が必要です。

[[271156]]

ここでお聞きしたいのですが、分散タスク スケジューリング フレームワークについて学んだり使用したりする前は、スケジュールされたタスクをどのように実行していましたか? Spring プロジェクトでは、全員が Spring-Scheduler を知っておく必要があります。スケジュールされたタスクを完了するには、Spring の Bean の対応するメソッドに @Scheduler アノテーションを追加するだけです。ただし、この注釈だけでは、スケジュールされたタスクが複数回実行されることを保証するには不十分です。メソッドが一般的に次のようになっていることを確認するには、他の手段が必要です (すべて Spring プロジェクトに基づいています)。

• 専用のサービス デスクを使用して、重要度の低いスケジュールされたタスクを 1 台のマシンでホストし、それを単一のマシンとして実行することができます。たとえクラッシュしたとしても、許容時間内に復旧すれば、当社の業務に影響はありません。
• 複数のマシンと分散ロックでは、タスクを実行するときに最初に分散ロックを取得する限り、取得が長時間失敗する場合は、他のサービスがすでに実行されていることがわかります。取得が成功すると、スケジュールされたタスクを実行しているサービスがないことが確認され、タスクを実行できるようになります。
• 複数のマシンが ZooKeeper を使用して、リーダー マシン上でスケジュールされたタスクを実行します。すでに多くの企業がZKを使用しています。スケジュールされたタスクを実行するときに、自分がリーダーであるかどうかを判断できます。そうでない場合は実行しません。そうであれば、ビジネスロジックを実行します。これによっても私たちの目標は達成できます。

現在、当社でも上記3つの方法を使用してスケジュールされたタスクを実行しています。これらの方法は基本的にビジネスの初期段階のニーズを満たすことができます。しかし、時間が経つにつれて、私たちはますます多くの問題に直面します。ここで皆さんに共有します:

• まず、単一のマシンの問題があります。事業をどのように分割するかはそれほど重要ではありません。この領域は本質的に複雑です。誰もが自分のビジネスが重要だと言う可能性があります。次に、1 台のマシンがハングした場合、システム停止やその他の状況が発生する可能性があります。どうすれば許容範囲内で回復できるでしょうか?これらはすべて難しい点です。
• 現在、スケジュールされたタスクを使用する場合、それをすぐに実行したい場合は、追加の Rest インターフェースまたは別のジョブを記述する必要がある場合があります。
• もう 1 つは、スケジュールされたタスクの実行時間を変更する必要があることです。たとえば、実行時間を 12 時間ごとから 6 時間ごとに変更する必要が生じています。コードを修正し、PR を送信して、オンラインでパッケージ化する必要があります。時間を変更するだけでもかなりの時間がかかります。
• スケジュールされたタスクを一時停止することはできません。スケジュールされたアラームが必要な場合など、スケジュールされたタスクに問題がある場合、突然アラームが大量に発生する場合は、アラームの送信を停止するためにタスクを一時停止する必要があります。現時点では、いくつかの分散構成スイッチを使用してこれを実行し、ロジック内でスケジュールされたタスク スイッチがオンになっているかどうかを判断してから実行できる可能性があります。これは比較的単純ですが、タスクに関係のないロジックをいくつか追加する必要があります。
• スケジュールされたタスクの監視が不十分であり、開発者はタスクがいつ失敗したかを知る方法がありません。エラーログがあると言う人もいます。エラー ログによってアラームが 1 回トリガーされた場合、サービスはそれに耐えることができますか?一般的に、アラームをトリガーするには、連続した複数のエラーが必要ですが、スケジュールされたタスクの周期的な性質により、連続したエラーをトリガーすることは困難です。

もちろん、ここでは一つ一つ挙げない程度の些細な問題もいくつかあります。この経験があれば、自分でゆっくりと体験し発見することができます。

2. 研究の基本原則

上記の第 1 章では、フレームワークの理由について説明しました。何を導入または改善したい場合でも、何かを行うにはコストがかかるため、理由が必要です。非常に小規模なプロジェクトがメッセージ キューや分散トランザクションなどを導入し始めているのをよく目にします。これは本末転倒です。たとえば、一部のブログ システムでは、ピーク時のトラフィックを減らすためにメッセージ キューを使用することがありますが、これは同期呼び出しよりも高速ではない可能性があります。

理由がわかれば、調査や技術的な解決策の設計を始めることができます。ここでは、私の研究フレームワークの基本原則についていくつかお話しします。将来、同様の研究フレームワークが必要になった場合は、これを使用できます。

• シンプル - 開発者にとってアクセスしやすく、ユーザーにとって使いやすい。
• 豊富なドキュメント。ドキュメントがほとんどないオープンソース プロジェクトは数多くあります。もちろん、英語のドキュメントしかないオープンソース プロジェクトもいくつかあります。英語があまり得意でない場合は、主に中国語で書かれた文書を検討する必要があるかもしれません。
• 管理インターフェースがあり、操作や統計を実行するのに非常に便利です。
• 主流のフレームワークをサポートします: Spring、Springboot など。もちろん、少なくともビジネスの主流のフレームワークをサポートする必要があります。
• フレームワークは軽量で、ニーズに応じて簡単にカスタマイズできます。
• 高性能、高信頼性、高可用性: フレームワークがビジネスのボトルネックになってはなりません。
• コードの更新頻度とコミュニティの使用状況: 使用する企業が増えるほど、人気が高まります。コードの更新頻度が高ければ高いほど、問題が発生する可能性は低くなります。オープンソースであり、大企業によってメンテナンスされているのが最適です。
• 多言語要件: たとえば、会社で多くの開発言語を使用していて、スケジュール フレームワークが必要な場合など、ビジネスに多言語要件がある場合は、多言語サポートを使用する必要があります。たとえば、Thrift は Rpc の複数言語サポートの代表例です。
• 現在の問題点を解決できますか?これが最も重要なことです。問題を解決できないのであれば、それを使う意味は何でしょうか?

上記の原則がわかったら、研究に進むことができます。

3. 研究の枠組み

3.1 TBSchedule

一般的に、Java フレームワークを調査する場合、まず Alibaba がそれらをオープンソース化しているかどうかを確認します。結局のところ、アリババは近年オープンソースで非常に良い仕事をしてきました。その後、オンラインで検索すると、Alibaba が 2012 年に TBSchedule というスケジュール フレームワークをオープン ソース化したことがわかります。現在、コードを検索すると、このフレームワークは放棄され、コードがクリーンアップされていることがわかります。もちろん、それをフォークしてメンテナンスを続ける個人プロジェクトもありますが、ユーザーが非常に少ないためここでは説明しません。 GitHub アドレス: github.com/taobao/TBSc…

3.2 エラスティックジョブ

Elastic-Job は、Dangdang のオープンソースの分散スケジューリング ソリューションであり、Elastic-Job-Lite と Elastic-Job-Cloud という 2 つの独立したサブプロジェクトで構成されています。これは軽量の分散型ソリューションとして位置付けられており、jar パッケージの形式で分散タスクの調整サービスを提供します。分散スケジューリング調整、弾力的な拡張と縮小、フェイルオーバー、失敗したジョブ実行の再トリガー、並列スケジューリング、自己診断と修復などの機能をサポートします。

このフレームワークは約 2 年前に非常に人気がありました。当時は多くの企業が利用しており、聞いたことがある人も多いと思います。しかし残念なことに、現在はメンテナンスされておらず、コードは 2 年間更新されていません。これは更新頻度の原則に違反します。問題が発生した場合、助けてくれる人がいない可能性があるため、使用はお勧めしません。 GitHub アドレス: github.com/elasticjob/…

3.3 比較的ニッチな

Uncode-Schedule、LTS、openCron など、スターが少なく、更新頻度も低い、比較的ニッチな github プロジェクトがいくつかあります。これらは当社の原則に準拠していないため、考慮されません。

3.4 XXLジョブ

CNCF、Apache などの分散スケジュールタスクの基盤がないため、決定はそれほど難しくないかもしれません。メッセージキューとは異なり、Apache には Kafka、rocketmq、plusar など、いくつかあります。各コミュニティは非常に大きいため、選択が難しい場合があります。そうすると、基本的に 2 つの選択肢が残ります。一つは自分たちで開発することです。この種のタスク スケジューリング フレームワークの開発の難しさは、メッセージ キューの開発の難しさよりもはるかに低いため、Meituan の Crane など、多くの企業が独自に開発することを選択しています。ただし、メッセージ キューなどの複雑なミドルウェアの場合は、二次開発が選択される場合があります。たとえば、Meituan の Mafka は Kafka の二次開発に基づいており、Didi の DDMQ も Rocketmq に基づいています。しかし、現時点で自社製品の開発を選択した場合、リソースが明らかに不足しています。ここでは、二次開発フレームワークの戦略を引き続き使用します。

もちろん、XXL-Job:www.xuxueli.com/xxl-job という選択肢が 1 つ残っていますが、これは基本的に当社の原則を満たしています。コードは継続的に更新されており、問題作成者も積極的に対応しており、以前のコメントも含め200社以上が使用しており、その他の原則も満たされています。一般的に言えば、フレームワークを選択する際には、他の人が納得できるように、その利点を詳細に列挙する必要があります。

XXL-job には以下の機能があります。

• シンプル: Web ページを通じてタスクの CRUD 操作をサポートします。操作は簡単で、1分で始めることができます。
• 動的: タスク ステータスの動的な変更、タスクの開始/停止、実行中のタスクの終了を即時にサポートします。
• ディスパッチセンター HA (集中型): ディスパッチは集中型設計を採用しています。 「ディスパッチセンター」は自社開発のディスパッチコンポーネントを備え、クラスター展開をサポートしており、ディスパッチセンターのHAを確保できます。
• Executor HA (分散): タスクは分散方式で実行され、タスク「executor」はクラスター展開をサポートし、タスク実行の HA を保証できます。
• 登録センター: 実行者は定期的にタスクを自動的に登録し、スケジュール センターは登録されたタスクを自動的に検出して実行をトリガーします。同時に、アクチュエータ アドレスの手動入力もサポートされています。
• 弾力的な拡張と縮小: 新しい実行マシンがオンラインまたはオフラインになると、タスクは次のスケジュール時に再割り当てされます。
• ルーティング戦略: エグゼキュータ クラスターがデプロイされると、最初、最後、ポーリング、ランダム、一貫性のある HASH、最も使用頻度の低い、最近最も使用されていない、フェイルオーバー、ビジー転送など、さまざまなルーティング戦略が提供されます。
• フェイルオーバー: タスク ルーティング戦略が「フェイルオーバー」に設定されている場合、エグゼキュータ クラスター内のマシンに障害が発生すると、通常のエグゼキュータに自動的にフェイルオーバーされ、スケジュール要求が送信されます。
• ブロッキング処理戦略: スケジュールが密集しすぎて、エグゼキュータがそれを処理する時間がない場合の処理​​戦略。戦略には、単一マシン シリアル (デフォルト)、後続のスケジュールの破棄、以前のスケジュールの上書きなどがあります。
• イベントトリガー: タスク実行をトリガーする「Cron 方式」と「タスク依存方式」に加えて、イベントベースのタスクトリガーもサポートします。スケジューリング センターは、ビジネス イベントに応じて柔軟にトリガーできるタスクの単一実行をトリガーするための API サービスを提供します。
• タスクの進捗状況の監視: タスクの進捗状況のリアルタイム監視をサポートします。
• ローリングリアルタイムログ: スケジュール結果のオンライン表示をサポートし、ローリングモードで実行者によって出力される完全な実行ログのリアルタイム表示をサポートします。

基本的に、上記の機能が私たちのビジネスに必要な機能であるため、最終的にXXL-JOBを選択しました。

4. まとめ

諺にもあるように、「魚を与えるよりも魚の釣り方を教える方が良い」。これまでの記事では、常に特定のフレームワークを紹介してきました。今回は、今後の研究でこの考え方を踏襲できるように、私がこのフレームワークをどのように選択したかを紹介したいと思います。優れた、また違った研究アイデアをお持ちの場合は、ぜひメッセージを残したり、グループに参加してコミュニケーションをとってください。もちろん、調査が完了した後、研究者として、このフレームワークのソースコードと実装原理を理解していなければ、あなたは不適格な研究者ですので、次の記事では、XXL-Jobの実装原理を詳しく紹介します。