GitHub radioboo
Comment5
Like
Created atMarch 19, 2019 10:06
Updated atMarch 19, 2019 10:06

Questions and feedbacks (5)

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)

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