スケールアウト再考

DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。

[kawasin73]

性能の分散の小ささも品質の高さに繋がる。確かに。いい知見だ。

[aroma_black]

“リトルの公式(Little’s formula) 平均の待ち行列の数 ”

[tmatsuu]

素晴らしい。最近このあたりを意識しながらApache preforkの(Min|Max)SpareServersを調整してる。workerやnginxにすればいい？そうなんだけどね…

[BigFatCat]

リトルの公式

[halfrack]

25ページ目が良かった

[naopontan]

ATM で行列待ちの話

[kgrock]

スケールアウト再考

[Hash]

むつかしくない！すごい！

[nntsugu]

scaleout

[hush_in]

分散

[muddydixon]

ニュートン算だ！

[matsumoto_r]

良い解説。スケールアウトは基本可用性が前提になっている、あたりはもはや言うまでもない前提なのかな

[nandemoOKdato]

スケールアウト再考

[harry0000]

"普通をきちんと積み重ねるだけで数1000億のアクセスは十分対応可能"

[wordi]

スケールアウト再考

[vinzentvladimir]

スケールアウト再考

[letitride]

ATM端末を増やすことによって入出金処理をするトランザクションサーバがどうなるかも知りたい

[t-wada]

"リトルの公式(Little’s formula)" "性能の分散が小さい ＝制御しやすい" "やかんは壊れない"

[yoshikidz]

なんでブックマーク増えてるんだろ。MM1モデル的な話ってことじゃないのか。

[Nobeee]

なるほどー 解りやすい‼︎

[vanbraam]

"数千億アクセス"って余り一般的じゃない状況だなと思って読んだら, 数値は余り関係ない割と普遍的なbest practiceだった

[Songmu]

"性能の分散が小さい=制御しやすい" の腑に落ちた感

[miya-jan]

ATMの話は怪しい。行列を見て帰ってた人が列に加わる可能性がある。アクセス数でも同じ話。

[dominion525]

現場で聞いてたけど大変に良いセッションでした。パネルディスカッションも。

[lizy]

ATMのたとえが分かりやすい

[lejay4405]

わかりやすかった…

[michiomochi]

めっちゃわかりやすい

[azumaon]

スケールアウト再考 お仕事のために…φ(..)メモメモ

[katzchang]

「あらゆるところが100倍になっても大丈夫か確認」検討はするけど、実際に対処するのは後の話だよね。

[sonots]

この話すごい良かった