2023年10月27日、28日の2日間、Kaigi on Rails 2023が開催されました。
Kaigi on RailsはRuby on RailsをメインテーマとするWeb系の技術カンファレンスです。2020年に始動し今回で4回目の開催ですが、前回まではコロナ禍の影響でオンラインのみでの開催だったため、オフラインとオンラインのハイブリッドでの開催は今回が初となります。
本記事では現地写真とともにイベントレポートをお届けします。
基調講演
今回の基調講演は初日と2日目に1つずつあり、どちらもRailsコントリビューターの方による発表でした。
1日目基調講演：準備中 (zzak)
1日目の基調講演はzzakさんさんでした。zzakさんはRuby/
英語でのトークでしたが、スライド全編に日本語字幕が用意されていました。
zzakさんはこの基調講演のゴールを次のように定めました。
- コントリビュートの動機づけにすること
- OSSの世界で自分自身の道を見つけられる手助けをすること
そして、どのようにしてコントリビューターになったのか、なぜRailsに熱心に取り組むのか、貢献を通して学んできたことを紹介しました。
その際、自身の貢献の例として大きく
- ドキュメンテーションの改善
-
APIドキュメントやRailsガイドの不整合や重複の修正などドキュメント自体の修正から、Markdownやドキュメント中のコードのLintツールの導入など、ドキュメントをよりメンテしやすくするための貢献を行いました。
- CIの改善
-
Rackの複数バージョンでテストできるようにし、7.
1で導入された新規RailsアプリケーションでDockerfileが生成される機能についてもリリース前の検証にCIの改善で貢献したそうです。 - THIS WEEK IN RAILSでの執筆
-
コントリビュートするためにも最新の情報をキャッチアップするために役に立つ以下の学習リソースを紹介しました。
- RailsConfのセッション動画の視聴
（zzakさん作プレイリスト） - THIS WEEK IN RAILS
- TechRacho
zzakさんはこのTHIS WEEK IN RAILSの執筆メンバーになっており、どのようにして記事を執筆しているのかを共有しました。
- RailsConfのセッション動画の視聴
トーク中にzzakさんは
2日目基調講演：A Decade of Rails Bug Fixes (byroot)
2日目の基調講演では、Rails Core Teamメンバーであるbyrootさんが
講演ではbyrootさんが関わった2つのバグ修正の話を通して、どのような流れでデバッグを行ったのかや、その中でどんな学びが得られたかを紹介しました。
1つめのバグ修正：Counter Cacheの並列性の問題
1つめのバグは10年前のもので、Counter Cacheの並列性の問題を修正したものです。これはCounter Cacheが本来ありえない負の数になることがある問題でした。
この問題の原因を調べるため、byrootさんはRailsのコードを参照し単純なコールバック処理を用いて処理が行われていることを確認しました。このコールバックがモデルの生成時か削除時のいずれかで余分に呼び出されているのではないかと仮説を立て、ローカル環境で並列に様々な操作を試み、問題の再現に成功します。
このように
また修正をPull Requestにした際にコミッターへ問題の原因や意図が正しく伝わらずトラブルになったことを反省点として挙げ、
2つめのバグ修正：Mastodonで発生したキャッシュに起因する問題
2つめのバグは今年5月と最近のもので、Mastodonで発生したキャッシュに起因する問題の話でした。こちらはコミュニティから報告された問題を調査したところ、MarshalでのシリアライズとRuby VM内での挙動変更が絡む非常に複雑な問題があったそうです。
このバグは1つめのものと違い自身が関わるサービスで発生していたものではないため、バグの情報をコミュニティとのやり取りからしか収集できず、原因特定が非常に難しかったそうです。この点において、OSSでは問題が発生した場合に他者を介さず自力でデバッグできることが主要な利点になる、としています。またこのバグのようにMarshalなど低レイヤーまで潜って調べるのを恐れないこと、また再現が難しくなる半決定的な振る舞いは実装しないことを勧めています。
全体を通して、Railsという巨大なプロジェクトでもデバッグの流れは一般的なものと変わらず、地道な調査をしていることがわかって面白かったです。
またRailsコントリビューターの方が
一般セッション
今回のKaigi on Railsは初の2トラック開催となり、計34本もの一般セッションがありました。ここではその中から3本のセッションをピックアップして紹介します。
Simplicity on Rails - RDB, REST and Ruby (moro)
このセッションの発表者はMOROHASHIさんで、
タイトルがSimplicity on Railsということで、Railsでアプリケーション開発をするうえでシンプルに実現するために考えるポイントが紹介されました。
まず、
Railsが得意とする設計はscaffoldで生成されるようなDBのテーブル構造、画面の構造を合せてCRUDできる状態ですが、それでは機能がたりないのでそのギャップをどう埋めるのかがポイントとし、3つの軸を挙げています。
- RDB
- ドメインに現われるイベントエンティティを見出して
has_関連のエンティティにするmay: through - REST
- コトをRESTリソースとして定義してサービスの機能をそのCRUDで表現し、コトの操作のための状態遷移もresourcesで定義したアクションへのリンクの遷移で表現する
- Ruby
-
- コトをCRUDするときにUIとイベントエンティティの構造が違う場合、その違いを吸収する
- その際にどういうインターフェイスにするとRailsの支援を得やすいかを考えてRubyの柔軟性を活かして継続的な変化に対応できるようにする
普段Railsでアプリケーション開発する上でなにげなく考えている設計について丁寧に言語化されており、Rails初学者にも普段開発しているエンジニアにも学びになるセッションでした。
また、トーク中の例題では、今回のKaigi on Railsのカンファレンスにあわせてユーザー、カンファレンス、参加登録といったイメージしやすいエンティティで説明されていたのもわかりやすかったです。
APMをちゃんと使おうとしたら、いつのまにか独自gemを作っていた話 (kokuyouwind)
このセッションの発表者は黒曜さんで、普段Railsアプリケーションの開発だけでなく、インフラやSREもしている方です。
講演では、APM
APMの使い方や活用方法
APMを導入しただけで終わらないようにアプリケーションの改善に繋げるための見方や運用についての話を、実際に社内で実践している方法を踏まえて説明していました。ポイントとしては次のとおりです。
- サイト全体の指標からエンドポイントごと、リクエストごとと大きい視点から細かい視点の順に見る
- チーム全員で週一
「APMを見る回」 を実施して傾向や問題のトリアージを行う
独自gemについて
標準のトレースだけでは困る場合があってその対処方とそのためのgemについての紹介もありました。
- SQLの発行場所の詳細がわからない
- Rubyの処理が重くて原因の箇所がわからない
これらの問題は手動インストゥルメンテーションで解決できますが、それでは使いづらいためAPM Traceableというgemを作成したそうです。このgemを使うとメソッド名を指定すればAPMでスパンとして表示されるようになります。
具体的なチューニング事例
実際の運用中のサービスで発生した問題についてどのように検知、改善したかについて次の2件の事例を紹介していました。
- MySQL 8.
0の更新で特定エンドポイントの処理が遲くなっていた問題 -
- トレースから重いクエリを特定
- EXPLAINして復号インデックスを追加
- 該当しそうなMySQL 8.
0のIssue調査 - クエリの改善でパフォーマンス改善
- 外部API呼び出しのトレースによる問題の特定
-
- 外部APIを並列で呼び出す箇所で時間がかかっていたがトレースが取れていなかった
- 並列処理をする際にスパンの親子関係が切れていたのを修正
- レスポンスのパース処理に原因があると特定
- コードの改善でパフォーマンス改善
事例も含めた使い方の紹介で実際にAPMを活用するためにどう運用すると良いのかの参考になります。また、APM活用に際して困ったことを解決しそれをgemにして再利用しやすくするという開発者としての姿勢も真似したいと思いました。
管理機能アーキテクチャパターンの考察と実践（ohbarye）
このセッションの発表者はohbaryeさんで、Kaigi on Rails 2021から3年連続で登壇されているそうです。すごい！
管理機能はエンドユーザー向けのアプリケーションが作られた後で、社内の運用管理者向けに向けて後付で開発されることが多くなります。そのときにどういったアーキテクチャを取り得るか考察し、具体的な事例を紹介するという内容でした。
発表の中では特にPresentation Domain Separation
また発表の中で
余談ですが、ohbaryeさんの名字はオオバさんで、時間帯が被る裏のセッションで発表していた方もオオバさんでした。そんな偶然があるのか、と思っていたところ、このセッションの前座で大暴露が行われました。
前夜祭で発表者の方が聞いた話によると、運営が意図的にオオバさんのセッションの時間帯を被せて
こんな運営許せますか!? ……個人的には面白いので許します！ 発表者の前座トーク力もさることながら、運営のユーモアも感じて面白い一幕でした。
会場の様子
ここからは、今回会場となった浅草橋ヒューリックホール&カンファレンス内の様子などを紹介します。
ホワイエ・企業ブース
受付やノベルティ置き場に加えて、10社の企業ブースがホワイエに出展していました。休憩時間には各ブースとも大きく賑わっていたようです。
なかでも、入り口一番近くに巨大ガラポンを設置していたTechouseさんのブースは存在感があり人も多く集まっていました。一等景品がHHKBやRealforceといった高級キーボードなのもエンジニアの心をくすぐります。
またmybestさんのブースでは
発表ホール
基調講演やAトラックのセッションが行われるヒューリックホールは、座席が400席ほど用意され広々としています。メインスクリーンに加えて左右にサブスクリーンがあるため、発表がとても見やすい作りになっていました。
Bトラックのセッションが行われるカンファレンスルーム1は広めの会議室といった作りです。席数が限られているため、人気のあるセッションでは座席がほぼ埋まっていたようです。
代わりに隣のルーム2がサテライト会場となっており、基調講演やBトラックのセッションがこちらに中継されていました。
他にも休憩スペースやハックルームなどが設けられており、休憩時間の交流や作業に活用されていたようです。
ホワイエは参加人数に対してやや狭めの印象でしたが、これらの目的別スペースが多く用意されていたおかげで人が滞留せず快適に過ごせました。オフライン開催が初とは思えない心配りですね。
パーティー
1日目の夜には複数のスポンサー主催パーティーが開催されました。
私がお邪魔したのはマイベスト・
初日の夜には他にもRIZAPテクノロジーズ主催のRIZAP DrinkUP、STORES主催のSTORES CAFEが開催されており、どの会場も賑わっていたようです。
2日目の夜にはヒューリックホールをそのまま使って公式主催のアフターパーティーが行われました。オフラインチケットを持っている人が全員参加可能で、たくさんの人と交流することができました。
ちなみに、ドリンクカウンターにはビールやカクテルの他に日本酒も多く用意されていました。Rubyistといえばやはり日本酒ですね。
まとめ
初のオフライン開催となったKaigi on Railsでしたが、大きなトラブルもなく快適に楽しませていただきました。交流やブースを巡れるよう休憩時間が長めに取られていたり、立ち話で人が滞留しないよう休憩スペースが別途設けられていたりなど、随所に運営の気配りが行き届いていたのが印象的です。
クロージングトークで触れられていましたが、会場は未定であるものの来年も開催自体は決定しているそうです。いまから次回の開催が楽しみです。
なお、YouTubeのKaigi on Rails公式チャンネルでは今回の基調講演や一般セッションの動画が公開されています。今回紹介できなかったセッションも面白いものばかりだったので、ぜひ確認してみてください！
最後に、素晴らしいイベントを開いてくださったスタッフの皆様、ありがとうございました！ 来年のイベントも楽しみにしています！
