この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
re:InventにてDropboxがSQSをどのように大規模に使っているのか、というセッションを聴講してきました。以下に内容を箇条書きで残しておきます。
内容まとめ
- Dropboxにとって「同期」というものが最もコアな競争力
- 共有
- コラボレーション
- 「同期」を実現するための課題: いかにして巨大なワークロードを、アップロードされたその瞬間に実施するか。
- アップロードされた後、ファイルの種類によって様々な処理を実施し、メタデータを取得する必要がある。
- 画像ファイル: EXIFの取得、サムネイル取得
- 動画ファイル: エンコード
- などなど
- 同期時の処理は以下の制約を満たす必要がある
- 低レイテンシ
- 高スループット
- 様々な処理への柔軟な対応
- Dropboxではこれまでに様々なアーキテクチャを試してきた
- 最初に、オンプレのDropbox環境でファイル処理しS3へと保存する構成
- 問題点: オンプレとAWS間の通信コストが高過ぎる
- EC2のアプリケーションサーバで処理を実施、コンテンツをS3にアップロードしメタデータをオンプレ環境に送信するアーキテクチャに変更。
- ネットワークの問題は解消できたが、負荷分散に難がある。新しいロジックを追加するための柔軟性が低い。
- ネットワークの問題は解消できたが、負荷分散に難がある。新しいロジックを追加するための柔軟性が低い。
- 最終的に、内部的に「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利用法は非常に有用だと感じました。
1
