エンジニアのshirakurakとkoboriです。2023/10/27(金)-28(土)で開催された、 Kaigi on Rails 2023 に、2名で現地参加してきました。
Kaigi on Rails は、Railsの話題を中心としつつ、アーキテクチャ、パフォーマンス改善、技術的負債など、アプリケーション開発において多くの方が悩むような話題について、幅広く扱われるカンファレンスです。 今年は初のオフライン開催ということで、浅草橋ヒューリックホール&カンファレンス で開催されました。会場はメイン会場、サブ会場、フリースペース、ハックスペースなどが用意されており、全国から集まってきた参加者で賑わう大きいイベントでした。 各社工夫の凝らされたブースや協賛品ばかりで、発表以外でも2日間非常に楽しむことができました。
発表について
聴講した発表のうち、我々の中で特に印象に残ったものを紹介していきます。
Rails アプリの 5,000 件の N+1 問題と戦っている話
N+1 問題の内容やその一般的な対策方法から入り、Bulletで検知した N+1 問題（約5000箇所）とどのように戦っているかということをお話されていました。メインテーマは、普段の思考回路をもとにした、自動修正のために自作したgem（BulletmarkRepairer）の設計方法です。 自動で N+1 問題を直すためには、適切な場所に、適切な対象を includes すれば良さそうだけれど、N+1 問題が起きる場所やその対象っていろいろな種類あるし、考えること多いよねと。
トークの後半では、N+1 問題との現実的な向き合い方のお話もありました。個々人が直すことに頼りすぎず、検知を見張って適切な人に修正を振る係（N+1 退治番長）を決めることを勧められていました。
全体を通して非常にわかりやすく、理想だけでなく、現実問題（我々は忙しい、そうとても忙しい、やりたいことが全てできるわけではない）という主張に、涙を禁じ得ませんでした。
TracePointを活用してモデル名変更の負債解消をした話
Ruby標準ライブラリである TracePoint を用いて、アプリケーションのすべてのモデル名を変更することを完遂した話でした。 手作業でやることは難しく、かといって単純な一括置換では危険なため、TracePointを用いて、メソッドを呼び出しているファイルやソースコードの位置を特定しながら、ファイルを修正していったとのことでした。
直近のプロジェクトで影響調査になかなか時間かかったこともあり、うまく使えないかなとぼんやり考えていました。簡単に使えるならばデバッグでも役立つかもしれません。メタ的な視点や抽象構文木が出てきたりなど、技術的にも面白い発表でした。
以下の記事でも、発表内容について書かれてます：
Fat Modelを解消するためのCQRSアーキテクチャ
採用しているCQRS（Comman Query Responsibility Segretion = コマンド・クエリ責務分離パターン）アーキテクチャを用いて、Fat Model および Fat Controller 問題を解決している話でした。そのままCQRSではなく、独自に UseCase と呼ばれるレイヤを Client と Command の間に加えることで、より読みやすく、テスタビリティの向上にも繋がると言うお話でした。
発表の中での例をみたところ、各レイヤで記載する処理も明確で、わかりやすいだろうなと思いました。新規ジョイン者も、認知負荷低く済みそう。読む気が失せるようなテストコードがなくなっていくと話されており、specが適切に仕様理解の役にも立っているかもなぁと想像していました。あとはみんな責務の分離で悩んでいるんだなとも思いました。
数十億のレコードを持つ5年目サービスの設計と障害解決
負荷問題により発生した障害を例に、どのようにサービス設計することで解決していったかについて話されていました。特定の時間に、特定の種類の人がアクセス集中するアプリのため、負荷に耐えるために、スペックを上げるやチューニングを行うといった基本的な方法だけでなく、そのアプリの特性やユーザの利用データを生かした対応内容が紹介されていました。
メイントピックとしては、以下の3つ：
- キャッシュを使う
- 不要なデータは使わない
- テーブルを適切な形に変更する
Railsアップデートにより発生したエラーやアクセスが少ない開発環境では見逃したなど、どこかで聞いたような話もあり胸が痛くなりつつ、よく考えたらインシデントって登壇の材料になるな〜とポジティブなことも考えていました。
やさしいActiveRecordのDB接続のしくみ
ActiveRecordとMySQLの接続についての発表で、RailsとMySQLの接続確立までの全体像を掴み、Railsのソースコードと照らしあわせながら詳細を理解するという内容でした。
mysql2クライアントインスタンスを接続と見做し、ConnectionPoolが接続を使い回すか、新規作成するかを管理し、ConnectionHandlerがコネクションプールどの接続を使うかを管理する。ボトムアップなアプローチでの説明は個人的に非常に理解やすかったです。
今後Databaseとの接続でトラブルに見舞われた時、ライブラリのソースコードを知りたくなった時、自力での理解を後押ししてくれるロードマップのような発表でした。
Simplicity on Rails -- RDB, REST and Ruby
この発表では、イベントエンティティを見つけ、Rubyの持つ特性に合わせたシンプルな設計について話されていました。 イベントエンティティを見つけ、発見したイベントエンティティをリソースと捉え、RESTに乗せていく。しかし、エンティティの粒度はUIの粒度と一致しないこともよくある。ので、RubyとRailsの豊かな表現力を利用し、ActiveModelやPureなRuby Objectを使って対応するという内容だと理解しました。
Railsでは、FatModelとどう戦うかがよく議論されます。本来あるべき概念が見出せていないために、特定のModelの責務が多くなってしまう。そこでよく見落とされがちなのがイベントエンティティという背景を想像しながら発表を聴いていました。
利用している言語やフレームワークが解決したい課題とコンテキストを理解し、特性を活かした設計をしていく考え方に、強い賛同を覚えました。
その点で、Railsの持つの美しさが表現された発表だったと感じました。
今後何度もこの発表を見直すだろうと思います。
事業の試行錯誤を支える コードを捨てやすくして システムをシンプルに保つ設計と工夫
方針転換や試行錯誤を柔軟にするために、まだ固まり切っていないコードはコアドメインから切り離し、コードや機能を捨てやすくしようという話でした。新規事業で重要なソフトウェアの特性（簡単にやめられる・劇的に変えられる）のために、削除を前提に設計することの重要性が語られていました。具体的には、目的の混ざったサマリテーブル、種別用のカラム、コードの分岐でどうにかするといったことを避けるなど。ある機能を削除するために、特定の用語が入ったファイルをがさっと消去すれば良い、という状況にしておくと良いと話されていました。
発表の最後には、人間には損失回避バイアスがあるので、（削除しやすい設計をしたとしても）削除するという意思決定をすることの難しさについても触れていました。対策として、思った通りに行かなかった場合の仕様案（minispec）をあらかじめ定めるなど、開発者側から機能削除に対するアプローチをすることの重要性も話されていました。
仮説検証を行なっているフェーズのチームも多い現在の自社と重ねながら、興味を持って聞けました。
余談ですが、スピーカーの方が運営されている、Podcastをよく聴いており、私がこの業界を志したきっかけでもあります。発表の感想に加え、Podcastへの感謝もスピーカーの方へ伝えられたことも含め、個人的には最も思い出に残る発表でした。
さいごに
「初学者から上級者までが楽しめるWeb系の技術カンファレンス」 というコアコンセプトの通り、完全には理解しきれないまでも新たな学びを得ることができた発表や、日頃の業務と照らし合わせて強い共感を覚える発表など、とても楽しい2日間でした。運営の皆様、本当にありがとうございました。
