[セッションレポート]How Dropbox Scales Massive Workloads Using Amazon SQS #reinvent

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

re:InventにてDropboxがSQSをどのように大規模に使っているのか、というセッションを聴講してきました。以下に内容を箇条書きで残しておきます。

内容まとめ

  • Dropboxにとって「同期」というものが最もコアな競争力
    • 共有
    • コラボレーション
  • 「同期」を実現するための課題: いかにして巨大なワークロードを、アップロードされたその瞬間に実施するか。
  • アップロードされた後、ファイルの種類によって様々な処理を実施し、メタデータを取得する必要がある。
    • 画像ファイル: EXIFの取得、サムネイル取得
    • 動画ファイル: エンコード
    • などなど
  • 同期時の処理は以下の制約を満たす必要がある
    • 低レイテンシ
    • 高スループット
    • 様々な処理への柔軟な対応
  • Dropboxではこれまでに様々なアーキテクチャを試してきた
  • 最初に、オンプレのDropbox環境でファイル処理しS3へと保存する構成
    • 問題点: オンプレとAWS間の通信コストが高過ぎる
  • EC2のアプリケーションサーバで処理を実施、コンテンツをS3にアップロードしメタデータをオンプレ環境に送信するアーキテクチャに変更。
    • ネットワークの問題は解消できたが、負荷分散に難がある。新しいロジックを追加するための柔軟性が低い。

      photo

  • 最終的に、内部的に「Livefill」と呼ばれるアーキテクチャを作成
  • SQSをInput、Intermediate、Outputとして利用する構成
  • 何万というファイルを秒間で処理することができるようになった
  • 設定はYAMLで記載する。柔軟な変更・調整が可能になった。
  • EC2はSQSのQueue lengthに応じて台数を柔軟に変更するようにしている
  • SQSを利用することでキュー自体の管理は不要。この巨大システムをたった2名のエンジニアでメンテナンスしている。
  • SQSにPublishする際にはQueue Lengthに気を使うようにする。あまりにも貯まりすぎている場合にはPublish側で制御する必要がある。SQSは時系列のQueueではないので。
  • 失敗したJobは再度キューに入れなおすような処理を別途作っている。
  • 現在、平常時で20,000QPS、バースト時で300,000 QPSのワークロード。
  • 秒間450,000のジョブが実行される。
  • 今後はこのシステムをマルチリージョン化、リージョン間フェイルオーバーなど、さらに柔軟に、AWSの特性を活かしきったシステム構成にしていきたい。

まとめ

DropboxではSQSを利用することで、高速かつ大量の処理を実施することを可能にしています。このアーキテクチャとSQS利用法は非常に有用だと感じました。