見出し画像

Kaigi on Rails 2024 参加レポート

CAMPFIRE 開発チーム

こんにちは、okayuです。
2024年10月25日(金)、26日(土)に東京で開催されたKaigi on Rails 2024に参加してきました！
今年はKaigi on Railsのオフライン開催２度目でしたが、初開催のワークショップや本屋さんの設置という新しい取り組みもありました！
Kaigi on Rails 2024 にはスポンサーとして協賛しており（過去記事：Kaigi on Rails 2024 にCAMPFIREがスポンサーとして協賛します！）、当日はブースやセッションを通じて多くの方と交流する貴重な機会となりました。本記事では、特に印象に残ったセッションについて振り返ります。


印象に残ったセッション

cXML という電子商取引のトランザクションを支えるプロトコルと向きあっている話 (ogawa)

  • cXML(commerce eXtensible Markup Language)という電子商取引用のプロトコルについてのお話でした(私は初耳でした)。EC関連の様々な仕様が定義されており、仕様書は600ページ以上という膨大な量になるとのこと。

  • スライドにもある通り、理想は「実装すればどんなECサイトとも連携できる」なのですが、複雑膨大な仕様ゆえに現実はそう上手くいきません。

  • 各接続先で微妙に仕様が異なったり、膨大な仕様のため、連携先のシステム、はてはcXML用のgemまでもが対応できていないコーナーケースがあったり・・・。多かれ少なかれ、cXMLのような複雑な仕様に悩まされ、またそれを何とかするために色々試行錯誤したことがある方は多いのではないでしょうか？そんな方にはとても刺さる発表だったと思います。

Identifying User Identity (nakamatsu)

  • User モデルが大きくなりがち問題はRails あるあるだよなーと思いセッションタイトルに惹かれて聴きはじめました。

  • この発表を聴く前までは、users テーブルにはその「ユーザー固有の属性」(メールアドレス,パスワード,ニックネームなど) を列挙しがちで、それが普通のデータ設計だと思い込んでいました。

  • しかし、この発表にあるように users テーブルに id だけ持たせることで「identityそのものを表現する」という発想が本当に目からウロコが落ちる思いでした。

  • 将来、認証基盤を作るようなことがあるとしたら(あるのか?)、この考え方を参考にしたいと思っています。

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

  • 商品の販売において発生する「在庫の引き当て」問題についての発表でしたが、このセッションも「目からウロコ系」でした。

  • 「在庫の引き当て」においては、在庫以上の注文を受付けないように在庫レコードをロックして確実に注文の作成と在庫の更新(減算)を連動させることが肝になってきます。

  • そうした場合、大量の注文を捌くことになったときにロックの競合によってパフォーマンスが大きく落ちる、ということになりかねない。というのがよくある話です。

  • その問題に立ち向かうため、1レコード1在庫という設計にたどり着いた。というのがこの発表であり、確かにそれであればロックの競合が減るけど… RDBでどのように実装するの?という疑問もありました。

  • そこで出てきたのが `FOR UPDATE SKIP LOCKED` で、行ロックされている行をスキップした結果を返して `FOR UPDATE` でロック取得できる、というものでした。

  • 聞いたところ、Rails 8 で導入される Solid シリーズもこの仕組みを利用しているということで、プロダクトでも活用できそうなテクニックなので、今後活用方法を考えていきたいと思っています。

Data Migration on Rails (nakamatsu)

  • Rails アプリケーションを本番運用しているとどうしても向き合うことになる Data Migration についてのセッション。

  • 自分自身も数年前にRails における Data Migration について考えたこともあったりして、最近の Data Migration 事情に興味があり発表を聴いていました。

  • 想像していたとおり ruby script (いわゆるoneshot)を実行する方法が多数派で、実際 CAMPFIRE サービスの運用においてもその手法を採用していますが、発表でも触れられていたようにスクリプトの管理や実行方法に手間がかかるという点がデメリットとしてあり、そこをなんとかしたい気持ちがあります。

  • いくつか Data Migration を扱う gem の紹介がありましたが、その中でも maintenance_task が大きく運用・メンテナンスのコストを下げてくれそうな印象を受けました。

  • 今後本番環境で実行するスクリプトの運用を改善する機会のために、maintenance_task についてリサーチしておきたいと考えています。

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

技術的な深掘りだけでなく、実践的な知見が多く得られ、非常に有意義な時間でした。特に学びになったポイントは以下です。

  • 非推奨警告の徹底的な管理と即時対応：アップグレード作業中に出るデプリケーションワーニングを無視せず、Sentryなどのエラー通知システムで検知し、発生したらすぐに対処する習慣をつけることが重要だと感じました。これにより、将来的な大きな問題を未然に防ぐことができると思えました。

  • フレームワークの段階的移行：新しいRailsバージョンにアップグレードした後、すぐにデフォルト設定を変更するのではなく、一度現行の設定で安定稼働させ、その後段階的に新しいデフォルトに移行する手法は、リスクを最小限に抑える方法だと思いました。

  • gemの選定と保守戦略：更新が止まっているgemに依存している場合、フォークして自分たちで保守するか、別のgemに置き換える必要があります。その際、メタプログラミングが過度に使われていない、標準の動きを変えないgemを選ぶことがメンテナンス性向上の鍵だと実感しました。

  • 業務領域の深い理解によるコード品質向上：コードリーディングを通じて業務そのものの理解も深めることで、より適切で効率的なコードを書けるようになるという点は、自分自身も痛感しており、改めて大事だと感じました。

  • ビジネス側との信頼関係と説明責任：アップグレードは直接的な利益を生みにくいため、その必要性やリスク、リソースについて正確に説明し、理解と協力を得ることがプロジェクト成功の鍵だと強く感じました。

今回の講義を通じて、技術的なスキルだけでなく、戦略的な思考やコミュニケーションの重要性を再認識しました。これらの知見を活かして、これからもメンテナンス性と信頼性を高める開発に努めていきたいと思います。


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

基調講演のpalkanさんと島田さんが別角度ながら、一貫したストーリになっていて、Railsの開発体験の気持ち良さや、Railsが開発でなくサービスも良い方向に導いてくれていることを改めて感じました。
来年こそCFP出したい！

デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ～俺のやらかしを越えてゆけ～（okayu)

  • とにかくトークが面白く進行が上手かったので楽しんで聞くことができました。会場中で笑いが溢れるセッションでオフラインで参加することの良さを再確認できる時間だったと思います。

  • 原因を丁寧に深掘り、それを他の事業部にまで広げていく過程が素晴らしかったです。新卒1年目でこれを行うという驚きもありましたし、改めて当社でもデプロイ設定について理解を深める機会が必要だと感じました。

  • また彼らのエンジニア組織の姿勢というものを感じることが出来て刺激を受けました。スライドだけでも面白いのですがスピーカーの方のトーク力・会場の雰囲気を感じ取れるため、アーカイブ動画が公開されたら見ていただきたいです。

おわりに 

(nakamatsu)
今回、個人的には久しぶりのオフラインでのカンファレンス参加となり、現地で Rails や Ruby に関わる人たちの熱気やそれらに対する想いのようなものを感じることができ、とても良かったと感じました。
また、カンファレンス後の初日の懇親会や最終日の Drink Up にも参加できて、他社のエンジニアの方々と交流できたこともとても良い経験でした。
来年もまた参加したいですし、将来、CAMPFIREの開発メンバーから Kaigi on Rails に登壇する人が出てくるような開発組織になれるといいな、と考えています。

いいなと思ったら応援しよう！