Questions and feedbacks

geeknees
geeknees commented 4 months

ガンガン技術力で課題を解決していてすごいなと感じたのですが、新しい技術スタックを導入する際に、特に意識しているポイントがありますか?

Like(1)

kirikak2
kirikak2 commented 4 months

作られるテーブルや検索されるデータによってはIndexの作り方に悩むシーンが多々あるんじゃないかと思うのですが、開発チーム内で統一されたルールとかはありますか?

Like(0)

asayamakk
asayamakk commented 4 months

もしアプリケーションがGCPで動いていたらBigQueryだけで粘っていましたか?

Like(0)

ujihisa
ujihisa commented 4 months

~Bi-Temporal Data Modelのつらみについて、実際に体験した具体例を聞きたいです!~

ユニーク制約・primary keyの話があったので解決

Like(1)

cobafan
cobafan commented 4 months

「時間によって変わっていくデータ」をDBで管理する際に、 Railsのバリデーションをすり抜けてデータが重複することはありますか? もしありましたらどういう工夫をされてますでしょうか。

Like(0)

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
nobuhikosawai commented 4 months

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

Like(2)

hoshinotsuyoshi
hoshinotsuyoshi commented 4 months

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

Like(1)

misogi
misogi commented 4 months

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

Like(0)

kyanny
kyanny commented 4 months

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

Like(3)

taogawa
taogawa commented 4 months

@pokotyamu 社内wikiや自社のテックブログを読んでもらっています。 記事にまとめると、背景含めて説明しやすいのでおすすめです!

Like(1)

moro
moro commented 4 months

住まう人がフレームワークを作ってしまっている場合も多々あると思います。 こんなとき、「いい感じにする」ためにどんなことをしていますか? また、気をつけていることはありますか?

ありますね。 そこは、フレームワークにするか、制御の方向を手放すかについて、一緒に相談するかなあとおもいます。 「フレームワークになってるための不自由さ」は、エンジニアはよく知ってると思うので、同じようなことが業務にも起こるかも? っていうところを共有した上で、じゃあどこのコントロールを手放せるかを一緒に設計すると思います。

Like(0)

moro
moro commented 4 months

@anonymous

専門家がそんなに知識が堪能ではなかったみたいなケースによく出会うんですが、そういうところを調整するのも「合流する場」の人が調整する責務があると思いますか?

その場でも回答しましたが、義務/duty としての「調整する責務」というと強すぎるかなあと思います。損した気持ちになりますよね。

いっぽうで、「完璧な専門家がいて上手に回る」みたいな状況はなかなかないので、ある種の不足のある者同士のチームとして、その人達とみんなでうまくやる方法を考えるといいんじゃないかなあと思います。

Like(0)

taogawa
taogawa commented 4 months

@expajp いまのところ、そんなに切り分けているわけではなく、関連ドメインで切り分けているような感じです。このあたりはキッチハイクでも試行錯誤中です。

Like(0)

moro
moro commented 4 months

@yuriko1211

「全体をいい感じにする」志向に目覚めたきっかけはありますか?

受託からサービス企業で働き出したときに、運営をしている人たちの業務知識がスゴイなーと思って、いっぽう管理画面がなかなか改修できずに(技術的だったり、優先度が上がらなかったり)で苦労している様子を見た影響は大きいです。

彼ら彼女らの業務知識と課題間をうまくサービスに反映できるといいのにねって思ったのでした。

Like(0)

hshimoyama
hshimoyama commented 4 months

Rails 併用することで Roda 側が実効的に得られる利点は何かあったでしょうか? (reload 機能などが効くようになるなど?)

Like(0)

ledsun
ledsun commented 4 months

エンジニアリングマネージメントに費やす時間が増えて、自分が直接開発のために手を動かす時間が減ると、現場の技術の変化に取り残されていくのではないか?老害化するのではないかという恐怖を感じます。とはいえ、エンジニアリングマネージメントのスキルが不足しているので、エンジニアリングマネージメントに時間を費やす必要はあると思っています。恐怖を克服しながら、エンジニアリングマネージメントに向き合うための秘訣があったら教えてください。

Like(1)

moro
moro commented 4 months

@colorbox

これまでの経験の中で管理画面で要求されたCRUD以外の機能にはどういったものが多かったですか?

そうですね。承認フローとか権限管理とか、あるいは行動や操作の履歴ですね。 こういったのを、たとえばActiveRecordコールバックで実現した上でCRUDに落とし込む、という作戦もありますが、それが立て込んでくるとだんだん辛くなるなあ。と。

なので、はじめから運営業務として設計すると結果として楽なことが多いと感じています。

Like(1)

kirikak2
kirikak2 commented 4 months

大場さんはマネジメント自体に価値はないとおっしゃっておられましたが、大場さん自身はCTO・VPoEとしてうまくキャリア形成を行って転進されているように感じます。大葉さん自身はこれまでのご経験からご自身の価値をどの部分にあると感じているのかをお聞きしたいです。

Like(2)

ledsun
ledsun commented 4 months

エンジニアリングマネージメントの成果はどのようにアピール or 評価されているのでしょうか?良かったら教えてください。

Like(0)

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