Dropboxが新開発した「非同期処理フレームワーク」はどのように構築されているのか？

複数のプログラムを順番に処理していく同期処理システムでは、どこかひとつの処理に時間がかかると後続の処理がまるごと遅れてしまいます。そんな同期処理に対し、ある処理の完了を待たずに次の処理を実行できるのが非同期処理。重たい処理によるボトルネックを回避できるため、ウェブサイトの応答速度改善などに役立てられています。クラウドストレージサービスのDropboxで開発が進められていた大規模な非同期処理フレームワークについて、同社のエンジニアであるArun Sai Krishnan氏が解説を行っています。

How we designed Dropbox’s ATF - an async task framework - Dropbox
https://dropbox.tech/infrastructure/asynchronous-task-scheduling-at-dropbox

これまでDropboxでは各チームでそれぞれ非同期処理機能を実装していたそうで、開発の効率化や各システムの互換性の向上、古いソフトウェアへの依存度を低減する目的から、単一の非同期タスクフレームワーク(ATF)で各チームの非同期処理機能を置き換えるプロジェクトが進められていました。Dropboxが独自開発したATFは、毎秒1万件もの非同期タスクを処理し、約30の異なるコードベースを持つチームで共通して利用できる強力なシステムで、さらにスケールできる余地があるとのこと。

ATFの全体像はこんな感じ。ぱっと見ただけでは何がどうなっているか理解しづらいですが、Krishnan氏がひとつずつ説明を加えています。

「Frontend」はATFユーザーからのRPCを受け取り、後述するTask Storeと連携しながらタスクを生成する部分。タスクとはユーザーから受け取ったコールバック関数の実行単位のことで、ATFでは処理をタスク単位で管理しています。

「Task Store」は断片的なタスクを関連付けて保存し入出力を行う部分で、Dropboxが開発したメタデータストア「Edgestore」が使用されているとのこと。

「Store Consumer」はTask Storeをポーリングし、実行可能なタスクを発見したらTask Storeからタスクを取り出してキューへとプッシュする部分。内製のTask Storeとは異なり、キューにはAmazon Simple Queue Service(SQS)が使われています。

「Controller」と「Executor」はタスク実行を担う部分で、単一の物理マシンにひとつのControllerと複数のExecutorが動作している構成。Executorが次のタスクをControllerに要求すると、ControllerはSQSからタスクを取得してローカルのキューに格納。その後Executorがローカルのキューからタスクを取得し実行します。Controllerは優先度別にローカルのキューを持っているため、タスクを実行する優先順位をコントロールすることができるとのこと。

「Heartbeat and Status Controller(HSC)」は、タスクの実行状態を監視してTask Storeの状態を更新する部分。Controllerは次のタスク要求をExecutorから受け取ったことを伝えるRPCを、Executorは実行環境の死活監視情報とタスクの実行結果を伝えるRPCをHSCに送信します。HSCはControllerやExecutorからの情報をもとにTask Store内のタスクの状態を更新していくとのこと。

タスクの状態遷移は以下のように行われます。新しいタスクは「NEW」状態で、キューに格納されることで「ENQUEUED」に変化。その後Controllerから取得されたタスクは「CLAIMED」状態に移り、Executorで処理中のタスクは「PROCESSING」、処理終了後は「SUCCESS」もしくは「FATAL_FAILURE」状態へと移行します。なお、「CLAIMED」や「PROCESSING」といった中間状態で異常が発生したタスクは「RETRIABLE_FAILURE」状態へ移行させ再処理対象のタスクとすることで、どのタスクも最低一回は処理の終了が保証されているとのこと。

以上がDropboxが開発したATFのアーキテクチャです。Krishnan氏は「この投稿が、他のエンジニアが良質な非同期タスクフレームワークを開発するための手助けとなることを願っています」とコメントしています。