Kaigi on Rails2024参加体験記
はじめに
株式会社マイベストでバックエンドエンジニアをしています、片田恭平(@katakyo_51)です!
昨年に引き続き今年もKaigii on Rails 2024(2024年10月25日〜26日開催)に参加したので参加レポートを残そうと思います!!
聞いたセッションなど
いくつかセッションを聞いたのですが、その中で興味を持った内容をまとめてみました!
聞けなかったセッションや理解が足りていないセッションもいくつかあるので資料を読み返しながら復習しようと思います!
Rails Way, or the highway (基調講演)
基調講演は、AnyCableをはじめとするオープンソースの開発に取り組むPalkan氏のKeynoteでした!
Rails wayとはRailsアプリケーションを構築する上での哲学であり、従うことで下記のメリットが享受できること
生産性と幸福のための最適化
意思決定からの解放
スケーラビリティを考慮した設計
Rails 8では下記のような0→1の環境をrails new時点で提供しており、より開発者はよりスピーディーにアプリケーションを構築できるようになっているそうです!
Rails 8.0は rails newコマンドで試すことができますね
gem install rails --pre
初期設定時点で下記を用意されています
認証基盤
SOLIDなインフラ基盤
デプロイシステム
ここで、初期のRailsアプリではMVCのRails wayに沿ったアーキテクチャがありますが、サービスが複雑になってくると徐々にRails wayから外れてくることとRails wayから外れると最終的に辛くなることの話から
Railsを他のものと混ぜ合わせるのではなく、拡張する形でRails wayに沿った形でアプリケーションを拡張していこうという話がされていました!
次のセッションでigaigaさんがfatになりやすいモデルを分割する方法やMVCからサービス層を増やした時のデメリットやモデルをうまく活用されている方法も紹介されているのでセットで見てみると良さそうです!
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング
こちらの書籍の紹介もあったので購入しました!(kindle版だとPDFとしてもダウンロードできそうです)
そのカラム追加、ちょっと待って!カラム追加で増えるActiveRecordのメモリサイズ、イメージできますか?
DBにinterger型のカラムを追加したときに増えるActiveRecordのメモリサイズの話をCRubyの実装のコードと照らし合わせて辿るといった内容のセッションでした。
メモリ関連でエラーが出たりDBのカラム追加で障害を起こした事例が最近あったのでActiveRecordの中身の仕組みやObjectのメモリ量の測定方法などがあるのですが、Railsの内部実装の仕組みがよくわからないこともあり、辿り方などの方法が実践ベースで試されていて面白いセッションでした!
セッションの後半の方にRuby 3.2のパフォーマンスを向上させるため、Variable Width Allocation(VWA)という新しいメモリ割り当て方法が導入されたそうで、このようなRubyのオブジェクトのメモリ管理の話など仕組みとして面白そうだったのでこちらの記事もぜひ読んでみようと思いました!
Sidekiqで実現する長時間非同期処理の中断と再開
マイベストも非同期ジョブにSidekiqを採用しているのですが、最近長時間のジョブが増えており、実際の業務と照らし合わせてためになるような内容でした!
特に再開処理の部分で進捗管理の方式やその実装例などがわかりやすく説明されてためになりました
また非同期処理などは中断再開などのテストケースを用意するのが難しそうでしたが、and_wrap_originalは、元のメソッドを呼び出しつつ追加処理を行うためのメソッドを使って書く工夫などされていて勉強になりました!
またセッションの最後の方では、Sidekiq Iterationという機能で進捗状況を保存し、中断の検知や中断した箇所からの再開などを自動的に行なってくる機能が追加されたそうですので試したいところですね!
約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり
実例ベースでRspecのCIの高速化やFlakyテスト(不安定なテスト)を減らした取り組みに関して話されていました!
弊社でもFlakyテスト撲滅デーのようなものを用意したり、test-profを入れたりしていますが、VRCを入れたりまだまだ改善点があるなと思いました
Allure Reportとcapybara-playwright-driver などは知らなかったのですが、CIでのテスト失敗時の調査を容易にして、Flakyテスト発生時のログやスクリーンショット、動画記録の確認ができるような運用になっているところを聞いてすごいなと思いました(vercelにデプロイしてURLを飛べば確認できるようなところも)
Sidekiq vs Solid Queue
Rails8.0のデフォルトとなるSolid QueueとデファクトスタンダートであるSidekiqの比較と移行するべき判断基準がわかりやすく解説されていました!
過去にはBackgrounDRb、Delayed::Job、Resqueなどが主流であり、現在はSidekiqが広く使われているような歴史から、Rails 8.0では、Solid Queueがデフォルトとして導入され、PostgreSQLやMySQLでのロック管理機能(SKIP LOCKED)を活用して大量のジョブを処理できるといった前提の話から、
Solid QueueがdefaultになるけどSidekiqから乗り換えるメリットはあるのかどういった時にSolid Queueを使うべきなのかといった話がまとめられていました!
すでにSidekiqを導入している場合Solid Queueへの移行メリット自体はそこまでなく、これから作成される小規模プロジェクトの場合はSolid Queueから始めてみて大量のジョブを捌く必要があればSidekiqに乗り換えたほうが良いという話をされていました!
Data Migration on Rails
Railsにおけるdata migrationは、データベースのスキーマ変更(schema migration)とは異なり、データ自体の修正・移行(DML操作)を指しているが、こちらの手法はRails8.0になってもデファクトスタンダート的な方法は決まっていなさそうで、サービスよって色々手法は分かれていそうですが、代表的なアプローチとして下記の5つにカテゴライズできるそうです!
直接SQL操作(コストが低く明示的だが、権限管理やテストが難しい)
Rails ConsoleやRunnerを使用(Railsの設定やコールバックが適用され、緊急時に便利だが権限管理やログ管理が課題)
db:migrationとして実行
schema migrationと合わせて実行でき、ログも残りやすいが、ライフサイクルの違いがありミスマッチが生じやすいrakeタスクやRubyスクリプト
柔軟でテストも容易だが、運用の追跡が難しい専用gemの使用
管理が容易で信頼性が高いが、学習コストや緊急対応での難点あり)
gemがいっぱいある……
弊社は4のrakeタスクを書くことが多いですが、3と5はあまり経験がなかったのでデータ投入の手法として手法が丁寧にまとめられていてとても勉強になりました!
またmaintenance_taskというgemの紹介もしており共通のGUI管理画面で実行・監視できるようにするものだそうです!sciptの雛形の生成やGUIでの実行などもできるため試してみるのも面白そうだなと思いました!
スポンサーブース
いくつかブースを回らせていただいたのですが、GMOさんのクイズが印象に残った+難しかったですね(1問だけ正解できてガチャポン引けました)
1問目はodenが正解だと思いませんでした(他よりありそうだったので)
感想
今年は始めてプロポーザルを出してみたのですが、残念ながら落ちてしまったのですが、現地に行ってみて、beta版のRailsの話をされているなど技術感度の高い人が多くとても刺激になりました!昨年と比べて自社のサービスで導入できるかといった目線でセッションをみるようなケースが増えましたが、それと関係なく個人でサービスを作りつつ参加して聞いてみるのもまた違った見方ができるのかなとも思いました。
Rails8.0ではkamal 2.0などのデプロイの仕組みやデフォルトでSQLiteを組み込んだ0→1の仕組みは整いつつあるなと話を聞いて持って帰れましたし、成長していく中で、アークテクチャをいかにシンプルにするか考え続けるのも大事だなと学びました!
色々試して来年またプロポーザル提出して今度は登壇できるようにしたいですね!
最後に
YOUTRUSTさん、スマートバンクさんと弊社マイベストでAfter Kaigi on Railsというアフターパーティーを行います!あと10名ほど空きがありそうなので是非ご参加ください!
(自分はLTもしますので登壇できなかった部分はここで供養もしたいと思います)