[Day 2: B-14] Introduction of scalable microservice for video editing/transcoding


yhirano55
yhirano55 commented 4 months

登壇者: 株式会社ミクシィ 酒井 篤

家族アルバム「みてね」(https://mitene.us) というサービスの内部には、ユーザーがアップロードした数億件にも及ぶ大量で様々なファイルサイズ・形式の動画ファイルに対して、高速にトランスコード、また、高度な編集を行うことに特化した「Transcoder」と呼ばれるマイクロサービスが存在します。このセッションでは「Transcoder」の設計・実装の内部をできる限り詳細にご紹介します。

■ 予定しているアジェンダ

・なぜマネージドサービスではなくこのようなサービスを自作したのか?

各種クラウドサービスには同様の目的で開発されたマネージドサービスが多数存在しています。しかし、なぜ我々はそういったサービスを利用せず自作する必要があったのかについて説明したいと思います。

・数億件もの大量の動画ファイルをどのように高速に編集・トランスコードしているか?

大量でしかも動画ファイルを対象にした独特の課題や要件がある中で、コンピュートリソースをどのように扱い、スケールさせ、高速な編集・トランスコードを実現しているかをご紹介したいと思います。

キーワード: Ruby on Rails, Sidekiq, AWS, Microservices, ffmpeg, RSpec


  • このセッションに関する質問を募集中です
  • 事前に聞きたいことがあれば、何でも書き込んでください。
  • 質問への回答はお約束できません。あらかじめご了承ください

Like(0)

Questions and feedbacks (10)

radioboo
radioboo commented 4 months

@kokuyouwind さん

パイプラインのために粒度を小さくするとWorker数がかなり増えそうですが、ディレクトリ構成を工夫されていたりしますか?

たしかに、Worker数は多くなっています。 ただ、基本的には

  • リサイズ
  • 切り出し
  • 結合

など、よく使う共通化されたものを適切な粒度で作っているので、現在のところ混乱するほど多くなっているような感じではありません。 app/workers/ の下にごっそり入れています。 確かに、いずれ、何か考えた方が良いかもしれません。

Like(0)

radioboo
radioboo commented 4 months

@nobuhikosawai さん

AWSを使って、lambda + step functionsのような構成でもできそうな気がしたんですが、比較検討されたりしましたでしょうか?

Lambda + StepFunctionsは大好きで、いまから新しいものを作ろう!となったら多分この構成になる気がしています。 ただ、これを作った当時はLambdaは実行時間制限が300秒と厳しく、ffmpegの実行を依頼するには少し制限が強すぎて採用を見送りました。

Like(1)

radioboo
radioboo commented 4 months

@hoshinotsuyoshi さん

監視・workerの管理画面(?)で工夫していることはありますか?

Sidekiq Batch用のUIが公式で提供されているので、それを利用しています。 https://www.youtube.com/watch?v=b2fI0vGf3Bo

失敗の状況やログ出力など、モニタリングしやすくできているので、一旦はこれで十分そうです。 あとは、New Relicなどのシステムモニタリングツールでリソースの状況などは監視しています。

Like(1)

radioboo
radioboo commented 4 months

@misogi さん

パイプラインの一部の処理だけキューが詰まることはありますか?オートスケールなどで対応可能でしょうか。

実際、運用していてそういったことがあったように思います。 その場合、どこで詰まっているか、なぜ詰まっているか、CPUの問題?ネットワークの問題?I/Oの問題?など分析していって、最終的には原因に合わせたリソースが提供できる環境を作り、そちらにQueueを分けて対応するなどしています。 そうやっていくと、適切にオートスケールは可能です。

Like(2)

radioboo
radioboo commented 4 months

@kyanny さん

パイプライン処理にはジョブワークフローエンジンが有用、という話と理解しましたが、 Airflow や Luigi は検討しなかったのでしょうか?

Luigiはログの分析処理で導入しています。 Sidekiq Batchは普段Railsを書いているエンジニアでも理解しやすいので、適材適所でやっている、といった感じですね。

Like(0)

kokuyouwind
kokuyouwind commented 4 months

パイプラインのために粒度を小さくするとWorker数がかなり増えそうですが、ディレクトリ構成を工夫されていたりしますか?

Like(0)

nobuhikosawai

AWSを使って、lambda + step functionsのような構成でもできそうな気がしたんですが、比較検討されたりしましたでしょうか?

Like(2)

hoshinotsuyoshi

監視・workerの管理画面(?)で工夫していることはありますか?

Like(1)

misogi
misogi commented 4 months

パイプラインの一部の処理だけキューが詰まることはありますか?オートスケールなどで対応可能でしょうか。

Like(0)

kyanny
kyanny commented 4 months

パイプライン処理にはジョブワークフローエンジンが有用、という話と理解しましたが、 Airflow や Luigi は検討しなかったのでしょうか?

Like(3)

Create Comment

Please sign in to comment.

Sign in with GitHub
This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano