正しいクラウドはある意味で遅い - Software Transactional Memo

TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは

[hatest]

過負荷(カフカ)のシステムにサムザという名前を付けると、ある朝突然、蟲(バグ)に変わる

[rulir]

確かに柔軟に設計を変更できるようになったんだから、利益最大化する方向に常に設計を最適化してないのは変。そうはいっても予算を下回っても怒られが発生する不思議な文化と常に戦いがありそうだけど…

[koba789]

とてもそう思う。みんなでステートをディスクに書き、限界の速度で状態遷移を回していきましょう

[programmablekinoko]

めちゃくちゃ含蓄がある話であった…

[isrc]

正しく設計されたクラウドは本業のサービス表面以外では基本的に過負荷状態かつ落ちまくりこそが常態でありそれを目指すのが経済的に正しく、そのために分散システムとトランザクションをやっていきましょう

[gfx]

"プロダクション環境のCPU使用率は常に100%であって、時々自分にも微かなCPU割当がスケジュールされているに過ぎないつもりで設計される必要がある"

[sonots]

全体が常に過負荷なのが最適、わかります

[inductor]

自分がもっと次元の低いレベルで考えてるのと似たようなことが言語化されてて面白い。ステートレスとステートフルは表裏一体だし、ユーザーの裏にいる仕組みは常に泥臭いのである

[yarumato]

“クラウドを支える仮想ネットワークと仮想マシンも、全体をトランザクションであると定義すればその上で実施すべきundo/redoの整理や冪等化や物理論理ログやリカバリの設計は単体テストもしやすい形で整理できる。”

[maninthemiddle]

「ステートをワークロードから切り離す」のはコンピューターを安く使うための大定石よね。記憶階層が頂点に近いほど更新が早く多く、すなわち冗長性を確保するコストが高いと言うことなので。

[yosuke_furukawa]

非常に考えさせられた。そうすると、Node.jsのとりあえず何かdiskやnetworkに書いてる間はCPU回して良いという設計は筋が悪い訳では無いが、常態的に落ちることには向いてないのかもとは思った。

[tmatsuu]

アパート経営の話、もっと聞きたい（そこじゃない

[igrep]

“正しく設計されたクラウドは本業のサービス表面以外では基本的に過負荷状態かつ落ちまくりこそが常態でありそれを目指すのが経済的に正しく...”