Airbnbのエンジニアリングチームでは、大量のリソースと処理時間を要するタスクを非同期バックグラウンドジョブとして実行することによって、Webアプリケーションのスケーラビリティ改善を実現している。さらに、バックグラウンドジョブによって発生する可能性のある処理上の問題が、ユーザ要求を処理するWebサーバに影響することが少なくなるため、パフォーマンス上の問題も同時に回避可能になる。このシステムでは、ジョブスケジュールシステムが非常に重要なコンポーネントである。そのため同チームでは、高度にスケーラブルなスケジューラを備えた分散型遅延ジョブキューサービスのDyneinを開発した。クラウドインフラストラクチャを担当するAndy Fang氏がブログ記事で、Dyneinの設計と開発に関する背景と課題について説明している。
Airbnbでは、集中化されたResqueワーカのクラスタをResque Scheduler上で運用している。Fang氏の記事によると、このクラスタは同社のモノリシックアプリケーション用に構築されたものであり、使用が容易な反面、同社のサービス指向アーキテクチャへの移行に対しては十分なものではなかった。問題のひとつは信頼性である — "たかだか1回(at-most-once)"配信保証のジョブがロストする場合があるのだ。その他にもスケーリングや、スケジュール機能の制限といった問題がある。
Airbnb社内の他チームと要件について議論し、Resqueのエクスペリエンス上の問題に対処する方法を確認した後、同チームは、新たなジョブスケジューリングシステムが提供すべき機能の一覧をまとめ上げた。すべてのジョブで"たかだか1回"デリバリの保証、障害後あるいは再起動後の全データの確保、ビジネス拡大をサポートするための水平スケーリング能力などがその内容だ。同社のスケジュール時間である10秒以内に大部分のジョブ起動が可能であるというタイミング保証のサポートや、指定したジョブのスケジュール解除といった機能も必要となる。
要求機能をサポートするため、同チームは、分散遅延ジョブキューイングサービスのDyneinを開発した。高レベルの観点から見たシステムは、サービスキューと実際のジョブを実行するワーカという、2つのコアコンポーネントで構成されている。
キューにはAWS Simple Queue Service(SQS)を使用することにした。Fang氏はこれを、さまざまなトレードオフの観点から、ジョブキューとしては最適な選択だと考えている。このシステムは、概念的には比較的単純で、ジョブキューのユースケースに関するさまざまな特性を提供する。SQSでは"たかだか1回"デリバリが提供されている。これはすなわち、Dynein側でメッセージ配信を保証する機能を追加する必要がない、ということだ。デッドレターキューや個々のメッセージ確認などの機能も備えており、Dyneinで使用されている。
Dyneinサービスでは、即時(immediate)ジョブと遅延(delayed)ジョブという、2つのカテゴリのジョブを処理する。即時ジョブはDyneinへ送信されると、直接サービスキューに転送される。このラッピングを行うおもな理由は、ジョブのタイプに関わらず、エンジニアが同じAPIを使用できるようにすることだ。遅延ジョブはインバウンドキューに転送される。このキューは、スケジューラへの書き込みバッファとして機能するものだ。その後、Dyneinサービスが自身のレートでインバウンドキューからジョブを読み出し、ジョブのトリガを生成して、ジョブスケジューラにそれを格納する。
Dyneinには最初からジョブスケジューラが用意されているが、スケジューリングの方法は一定ではないというチームの考えから、機能的には限定的で、スケーラビリティの高いスケジューラとして開発されている。同社のクエリモデルは極めてシンプルなものだ、とang氏は言う — 期限を過ぎたジョブを検索してサービスキューのトップにディスパッチすることで、DynamoDBの使用が可能になる、というものだ。ジョブの重複デリバリを回避するためには、データベースの状態更新を使用して、成功した場合にのみ先へ進めるという、基本的に楽観的ロック(optimistic locking)手法を採用している。現在使用しているプロセスは、シンプルであると同時に効率が高く、結果としてサービズの運用コストの大幅な削減が可能になっている、とFang氏は指摘する。
Dyneinはオープンソースで、GitHubでコードが公開されている。