Quantcast
Channel: kariaの日記 @ Alice::Diary
Viewing all articles
Browse latest Browse all 130

Kaigi on Rails 2024に参加してきた

$
0
0

Kaigi on Rails 2024のフォトパネル

SRE NEXT 2024に引き続き、Kaigi on Rails 2024にもオフラインで参加してきました。今年はオフラインの技術系カンファレンスへの参加を増やそうと思っておりまして、業務プロダクトでRailsに接しているだけにタイトルが気になるセッションが多く、実際収穫も多かったです。

セッション数がかなり多くて全部触れると無限に時間を消費していきそうなので、特に気になったセッションのみ感想を書いていきます。

DAY 1

RailsのPull requestsのレビューの時に私が考えていること

speakerdeck.com

RailsのcommiterによるPull Requestにマージされやすくなるコツの解説。他のあらゆるプロジェクトに適用できるわけではないでしょうが、「少なくともRailsはこうだ」という参考になるかと思って聞きに行きました。

特に強調されていたのが Real world use case?という部分。自分のユースケースとしてこのPRが活用できるのか、それが多くのユーザーに役に立つのか、という点が重要で、「技術的にできるからマージしてくれ」ではない、というのはなるほどと思った。あとは、絵文字が多すぎると組織票の可能性があるのでむしろ逆効果というのも「なるほど」ポイント。そんなに実現してほしければコメントを書きましょうと。

『Actual behaviorのところは否定文ではなく肯定文で書こう』というのもRailsに限らず文章書くときに意識しておきたいですね。「動きません!」では相手に何も伝わらない。

リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果

speakerdeck.com

ViewComponentへの移行をサブプロジェクトでやり切ったという話。自動生成にして20万行の変更やりきったのものすごいし、そこからの段階的リリースがすごく丁寧なのが更に素晴らしいと思いました。

現実のRuby/Railsアップグレード

zenn.dev

Rails5.0からのアップグレード事例の紹介。アップグレードのやり方そのものはRailsアップグレードガイドに書いてあるので、そうではなくノウハウ的な部分が中心。テストがないとアップグレードしたとき壊れたかどうかわからないのでテストを書く文化を根付かせましょうとか、ビジネス側との良い関係構築を心がけましょうとか、かなり文化面での言及が多かった印象でした。確かに周囲の理解がないとアップグレードは難しい。

あとはこれね。

エンジニアの説明責任。「アップグレードの工数の許可がなぜ下りないの!?」とか現場の人は言いがちだが、そのための必要な説明と理解を得るというプロセスを、きちんと上の人がやってくれていますか?という話。文句を言うなという話じゃなくて、誰に対しても丁寧な説明が大事だよね、そういう動きをする人が必要だよねと思います。

DAY 2

都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」

(資料未公開のようなので公開されたら埋め込みます)

朝イチから「RubyよりもGoのほうがISUCONにも勝ってるしベンチマークはいいよね」というなかなかロックな発表。とはいえ現実のWebアプリではDBのクエリ時間が支配的だし、スレッド数も絡んでくるし、N+1問題もあるし、適切なベンチマーカーを使ってパフォーマンスチューニングやっていこうぜという良い話でした。

Railsガイドにパフォーマンスチューニングの記事あるの知りませんでした。Railsガイド読むのマジで大事。

guides.rubyonrails.org

このIssueも読んでおきたい。pumaデフォルトの1プロセス5スレッドは多いよねという話。

github.com

推し活のハイトラフィックに立ち向かう Railsアーキテクチャ

speakerdeck.com

DAY2はとにかくパフォーマンスチューニングの話が印象強かったのですが、こちらの発表もそうでした。

このブログを読んでいる皆さんなら、チケット販売サイトがクソ重くなることを見越して販売開始時刻の数秒前ぐらいを狙ってリロードした経験とか、グッズ販売のサイトが重すぎてクレジットカードの決済が三回走ってあとから取り消してもらったりした経験とか、きっとあると思います(どちらも筆者の実体験です)。そういったエンタメ分野のトラフィックに対して真面目に立ち向かっているよというお話。

一体どんな凝った構成なんだろうとワクワクしながら見たのですが、意外なことにめっちゃシンプルな構成でした。

インフラアーキテクチャ

トラフィックを捌くときに下手にマイクロサービス化されていると、どこがボトルネックなのかを特定するだけでも一苦労になってしまうので、合理性はありそうです。きちんとCDNやRedisのキャッシュは入れているのでそのあたりで吸収はしつつ、AuroraやRails Appは事前に大きめにスケールしとくみたいな感じの戦略でしょうか。これで秒間8000リクエスト捌けるんだなあ。

参考になった部分としては、最近のMySQL/PostgreSQLで導入されている FOR UPDATE SKIP LOCKEDでしょうか。これを使うことで「行ロックされている行をスキップする」というSELECT文が簡単に書けるということで、後述するSolid Queueでも使われているんだとか。これで数百RPS捌けるんだ!良いですね。

でも最後はRate limitを導入したという話で、やっぱそうなるか~というオチでした。外部APIはどうしようもない。

Data Migration on Rails

speakerdeck.com

Schema MigrationについてはActiveRecordに仕組みがあるけれど、Dataに関してはどうだ?というのがこのセッション。たとえばテーブルにカラムを追加したら初期値を埋める必要があるとか、別のテーブルをSchema Migrationで作成したので元々あったテーブルのレコードを移行するとか、そういうやつです。

感想としては、「代表的なアプローチ」の項目に5個も例が挙げられている時点で「やっぱり『これがベスト!』って言えるメソッドは無いよな~」と思いつつ、ruby-jp slackでアンケートを取ったりRedditで海外事情を調べたりと幅広く調査しているのがグッドでした。生SQLRails Consoleでの変更、やっぱよくないよね!!

Data Migrationを実現するgemの一覧

あとこのgemの一覧のスライドめちゃくちゃ笑った。皆さんgemのネーミングには苦労されている……。

ちなみにmaintenance_tasks gemのことをこのセッションで初めて知りました。これはData Migrationで利用できるかはともかく、管理ツールとして入れてみて良さそう。

github.com

Sidekiq vs Solid Queue

speakerdeck.com

Rails 8.0からデフォルトのバックグラウンドワーカーになるというSolid Queueが気になったので見に行きました。特にSidekiqから無理に移行する必要はなさそう(スループットや機能面ではSidekiqの方が優位)、ただ今から新規でrails newするときにRedis立てなくてよくなるというのがSolid Queueの便利な点だなといったところ。ありがたいまとめでした。

約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話

speakerdeck.com

自動テスト長いしよく落ちるし困る、なんとなく再実行したら通ったのでそのまま……というシチュエーションはまあよくある話で、それを地道に改善していったのは素直に拍手。改善を行った結果GitHub Actionsのコスト削減に繋がったという点も好印象ですね。

「これだけやればオッケー!」みたいな銀の弾丸はないけれど、改善したポイントを丁寧に解説して下さっているのは非常に参考になります。

WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

speakerdeck.com

システムコンポーネントと設計のパターンを知るの、マジで大事!!などなど、頷くことが多かったです。なにかの設計をするときに、立ち戻って毎回読むようにしたいスライドでした。

一番共感したのはここ。

「楽しさにはビジネス価値があります」

「楽しく仕事をする」というのを最近かなり意識するようにしてて、同一の仕事のクオリティなら楽しくやれる方が絶対いい。全ての発表の最後の締めが「楽しさ」だったのが、本当にここに来てよかったなと思えた瞬間でした。

おまけ

最後にTwitter……じゃなかったXに上げた写真を何枚か置いときます。

今回の会場が有明セントラルタワーホール & カンファレンスという、東京ビッグサイト有明ワシントンホテルの間にあるビルの会場で、コミケ以外で有明に来るのがなんか不思議な感覚でした。

今回カンファレンス専用のWebアプリが提供されていて、PWAとしてiPhoneのホーム画面に置いておけば運営からのアナウンスがpush通知で飛んでくるというなかなか便利なアプリだったのですが、オープニングトーク直前のあたりでこんな感じに。 イベント時のハイトラフィック対応は本当に大変。

追記:トラフィックの問題じゃなくて「deploy後に放置しているとrequestがtimeoutするという現象が発生」していたそうです。ひい。

2日目終了後にRubyMusicMixin on Rails 2024というイベントに参加したときの一枚。楽しそうすぎる。


Viewing all articles
Browse latest Browse all 130

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>