Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary

先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの

[sue445]

最初から最後まで「札束を積め」で一貫性があってよかった。（そうなりますよね...）

[threetea0407]

ゲームでDB分割バリバリやってるが、バリバリやりすぎて感覚が麻痺しとるかもしれん...

[dominion525]

リアルイベントに行くとこういう話がアドホックに発生するのでむちゃくちゃいい価値なんだよなーと思ってる。フリートーク重要。

[non_117]

かなりの負荷があって本当にトランザクションが必須だったので、RailsでRDB分割を実装したことある

[matarillo]

本文にある通りRailsは本質ではないので、Rails選択してない場合も参考になる

[bluerabbit]

以前、Aurora MySQL検証した感じだとdb.r6g.largeは300tps程度、db.r6g.xlargeは800tps程度までは大丈夫そうという感覚です。

[inose660]

"エンプラの世界だったらOracle" OCI ADPのチュートリアルによると4oCPUで自動スケーリングON(最大3倍増)すると1インスタンス(DB分割なし)で 6000tpsを軽く超えられる https://oracle-japan.github.io/ocitutorials/database/adb205-swingbench/#anchor2-3

[threetreeslight]

“そういう時のための選択肢を常に調査して、手遅れになる前に対処することが大事”

[celeron1ghz]

“Hazelcast”

[mas-higa]

金で解決する

[jacoyutorius]

“現実的な開発に合わせて仕様をコントロールするのも重要な仕事です。”

[Magicant]

「手遅れになる前に対処することが大事」それな。

[sora_h]

まあそうだよね…

[tettekete37564]

SQSってなんだっけ。AWSの各イベントをSlackに流す仕組み作った時に使ったような。

[razokulover]

金 is パワー

[Eiichiro]

費用対効果が高いのは、トランザクションに必要なほんとにコアなとこだけに絞るのが、良さそうと認識した。 それ以外は札束で殴るのが正解と。

[nicht-sein]

ほへー。そこまでハードな環境触ったことないけれど、AuroraとかSpannerとかすごいんだな。いつかつかってみたくはある

[k-tanaka99]

なるほどなあ、複数DBもやはり茨の道なんだな。

[als_uz]

echo "hoge" >> README.md; git add README.md; git commit -m "update README" が頭の中でループした / SQSに逃がすのは忘れがち、偶に思い出しておきたい

[ledsun]

いい話だ

[YusukeIwaki]

これはすごいKaigi Effectだ.....

[iga_k]

jokerさんの現場の知見