11 ポイント 投稿者 GN⁺ 2024-03-09 | 1件のコメント | WhatsAppで共有

分散・耐障害性タスクキュー

  • Hatchet は、管理が難しい既存のキューや pub/sub システムの代わりに、障害から回復し、並行性公平性レート制限といった問題を解決できる、耐久性のあるワークロードを設計できる。
  • 独自のタスクキューや pub/sub システムを管理する代わりに、Hatchet を使うことで、最小限の設定やインフラで関数を一連のワーカー間に分散できる。

Hatchet の利点

  • 超低レイテンシかつ高スループットのスケジューリング
    • Hatchet は平均開始時間 25ms の低レイテンシキューを基盤として構築されており、リアルタイムな対話性とミッションクリティカルな処理に必要な信頼性を高い水準で両立する。
  • 並行性、公平性、レート制限
    • FIFO、LIFO、Round Robin、Priority Queues のような戦略を Hatchet の組み込み機能として実装し、最小限の設定で一般的なスケーリング上の問題を回避する。
  • 設計上の復元力
    • カスタム再試行ポリシーと統合されたエラー処理により、Hatchet は一時的な障害からタスクを迅速に回復できることを保証する。

強化された可視性と制御

  • 可観測性
    • すべての実行は完全に検索可能で、問題を迅速に特定できる。
  • (実用的な)耐久性のある実行
    • イベントをリプレイし、ワークフローの特定の段階から手動で実行を再開できる。
  • Cron
    • 関数実行を繰り返しスケジューリングできる。
  • 単発スケジューリング
    • 特定の時刻と日付に関数実行をスケジューリングできる。
  • スパイク保護
    • トラフィックの急増を緩和し、システムが処理できる分だけを実行する。
  • 段階的ストリーミング
    • バックグラウンドワーカーの進行状況に応じて更新を購読できる。

使用例

  • Generative AI のための公平性
    • 一部の多忙なユーザーがシステムを圧迫しないよう、Hatchet を使ってワーカーへリクエストを公平に分配できる。
  • ドキュメント索引作成のためのバッチ処理
    • Hatchet はドキュメント、画像、その他のデータの大規模なバッチ処理に対応し、失敗時には途中から再開できる。
  • マルチモーダルシステムのためのワークフローオーケストレーション
    • Hatchet はマルチモーダルな入力と出力を調整でき、DAG スタイルの実行全体を処理できる。
  • イベント駆動処理のための正確性
    • 外部イベントやシステム内部イベントに反応し、自動的にイベントをリプレイできる。

クイックスタート

  • Hatchet は Python、Typescript、Go 向けのオープンソース SDK をサポートしている。
  • 始めるには Hatchet のドキュメントを参照するか、クイックスタート用リポジトリを確認できる。

SDK リポジトリ

  • Hatchet は標準で Go SDK を提供している。
  • Typescript SDK も利用できる。
  • SDK に関する問題が発生した場合は、該当リポジトリで issue を提出できる。

Hatchet にマネージドクラウド版はあるか?

  • はい。ベータ期間中は、製品の構築と改善に協力してくれる一部の企業にクラウド版を提供している。

Hatchet にセルフホスティング版はあるか?

  • はい。セルフホスティング向けのオープンソース Docker コンテナの手順はドキュメントで確認できる。

代替手段と比べてどうか?(Celery、BullMQ)

  • なぜまた別の管理キューを作ったのか?
    • 特に DAG スタイルの実行に依存する、トランザクション全体のキューイングの利点を備えたものを目指しており、Postgres がほとんどのキューイング用途を置き換えられると強く考えている。
    • 多くのキューは Redis ベースで、注意しないと OOM によるデータ損失が起こり得るが、PG を使えばこうした問題を避けられる。

問題点

  • 発見したバグは Github issue を通じて報告できる。
  • プロジェクトは初期段階のため、複雑な機能要望の前に、まず Discord で連絡を取るのが望ましい。

貢献したいなら

  • 貢献ドキュメントを参照し、Discord の #contributing チャンネルで取り組みたい内容を知らせれば、プロジェクトの方向性づくりやコラボレーションがしやすくなる。

GN⁺ の意見

  • Hatchet は分散システムにおけるタスクキュー管理の複雑さを減らし、高可用性と耐障害性を提供するソリューションであり、特に大規模データ処理やリアルタイムサービスで有用と思われる。
  • 現在市場で使われている他のキューシステムと比べ、Postgres を使うことで得られる安定性と拡張性は注目すべき利点である。
  • Hatchet 導入時の検討事項としては、既存インフラとの互換性、データ移行、そしてチームの技術力がある。
  • Hatchet が提供する高度な可視性と制御機能は、システム性能の監視や問題解決を容易にし、開発者や運用チームの負担を減らせる。
  • Hatchet はまだベータ段階のため、安定性と機能性の面で十分な検証が必要であり、大規模システムへ適用する前に十分なテストが必要である.

1件のコメント

 
GN⁺ 2024-03-09
Hacker Newsのコメント
  • あるユーザーは、Postgresベースのジョブキューと、さまざまな言語で動作するワーカー(worker)、そして適切な組み込みの可観測性機能を備えた製品を3年間探していたと述べている。このユーザーは6か月ごとに市場を確認して代替案を評価していたが、いつも失望していたという。しかし、RabbitMQのような追加依存は避けたかったため、Postgresベースのキューを好むとも述べている。現在はgraphile-workerを使っているが、依然として満たされていない要件があるという。
  • 別のユーザーは、この製品がY Combinatorの支援を受けていることを指摘し、この会社が「オープンコア」モデルを採用するのか、それとも別の収益化手段を模索するのか気にしている。
  • また別のユーザーは、pub/subシステムのプッシュサブスクリプション機能を気に入っていると述べており、たとえばGCP pub/subでは、イベントをキューから引き出す代わりにHTTPエンドポイントへプッシュするサブスクライバーを持てると説明している。この方式には、Cloud RunやLambdaのようなランタイムを使ってHTTPリクエストに基づいてスケールし、ゼロまでスケールできる利点があるという。ワーカーのオートスケーリング設定はより複雑になる可能性があり、RabbitMQではキュー深度メトリクスに基づいてKEDAオートスケーリングを設定することもできるが、それは複雑さを増すとしている。HTTP接続を維持するデーモンがジョブをプッシュできるモデルをサポートする予定があるのかと、このユーザーは尋ねている。
  • あるユーザーは、なぜすべての関数がコンテキストを引数として受け取るのか説明してほしいと求めている。関数を書くたびに多くのボイラープレートコードを書かなければならないように感じるという。
  • 別のユーザーは、分散DAG処理システムを実装していたときにこのアイデアがあればよかったのにと述べ、試してみたいとしている。
  • あるユーザーは、クラウド提供サービスの価格を公開しているのか、自前ホスティング向けオプションとしてKubernetes Operatorを作る計画があるのかを尋ねている。また、MITライセンスを採用していることで、将来的にAmazonがAmazon Hatchetサービスを作れるのではないかという懸念も示している。
  • 別のユーザーは、DAGベースのジョブランナー向けにジョブキューを書いており、PostgreSQL、SQLite、インメモリなどを使って、リトライ、タイムアウト、直列化されたリソースなどを考慮せずにジョブグラフが実行されるようにしたいと述べている。このユーザーはこのアプローチに関心を示している。
  • あるユーザーは、クライアント(Webブラウザ)がジョブの進行状況を完了まで監視できるジョブキューが必要だと述べている。Deno Queueのシンプルさと使いやすさを気に入っているが、クライアント側でジョブ状態を購読する方法は自分で実装しなければならないという。Postgresベースで可能なのか気になっていたが、ドキュメントのリンクを通じて可能だと確認したとしている。
  • 別のユーザーは、以前の職場で無制限にジョブをスケジュールしなければならない問題に直面したと述べている。たとえば、患者が6か月後の予約を取ると、その期間中に予約を思い出させる一連の通知をスケジュールする必要がある。このユーザーは、データベースキューにレコードを入れて数秒ごとにポーリングする方法から始めたが、ポーリングによるI/Oコストが理想的ではなかったため、分散システムを使わずにこれを解決したいと考えていた。Redisに切り替えたものの、複数のディスパッチャーを扱う複雑さ、OOM問題、即時キューへジョブを移動するための補助ジョブを走らせる必要があることなどの問題があった。PGに切り替えてSKIP LOCKEDなどを使う方法も検討したが、その前に転職したという。Hatchetがこのようなユースケースに適しているのか気にしている。
  • 最後に別のユーザーは、HatchetがTemporal/Cadence/Conductorと比べてどうなのか、またHatchetも耐久性のある実行をサポートしているのかを尋ねている.