Kaigi on Rails 2023 イベントレポート

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/Railsコントリビューターです。なお発表タイトルについてはタイムテーブル上もYouTubeでの動画タイトルも「準備中」となっていますが、スライド上はタイトルスライドがないため単に無題というほうが正しいかもしれません。

英語でのトークでしたが、スライド全編に日本語字幕が用意されていました。

zzakさんはこの基調講演のゴールを次のように定めました。

  • コントリビュートの動機づけにすること
  • OSSの世界で自分自身の道を見つけられる手助けをすること

そして、どのようにしてコントリビューターになったのか、なぜRailsに熱心に取り組むのか、貢献を通して学んできたことを紹介しました。

その際、自身の貢献の例として大きく「ドキュメンテーションの改善」⁠CIの改善」⁠THIS WEEK IN RAILSでの執筆」を挙げて、それぞれ取り上げました。

ドキュメンテーションの改善

APIドキュメントやRailsガイドの不整合や重複の修正などドキュメント自体の修正から、Markdownやドキュメント中のコードのLintツールの導入など、ドキュメントをよりメンテしやすくするための貢献を行いました。

CIの改善

Rackの複数バージョンでテストできるようにし、7.1で導入された新規RailsアプリケーションでDockerfileが生成される機能についてもリリース前の検証にCIの改善で貢献したそうです。

THIS WEEK IN RAILSでの執筆

コントリビュートするためにも最新の情報をキャッチアップするために役に立つ以下の学習リソースを紹介しました。

zzakさんはこのTHIS WEEK IN RAILSの執筆メンバーになっており、どのようにして記事を執筆しているのかを共有しました。

トーク中にzzakさんは「華やかなRailsの新機能実装ではないが、ツールやプロセスを改善して他の貢献者が開発しやすいようにサポートしている」と述べていて、貢献にもいろんな方法があるんだなと考えかたの幅が広がりました。

2日目基調講演⁠A Decade of Rails Bug Fixes (byroot)

2日目の基調講演では、Rails Core Teamメンバーであるbyrootさんが「A Decade of Rails Bug Fixes」というタイトルで発表を行いました。なお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コントリビューターの方が「技術的な正しさよりコミュニケーションの礼儀正しさのほうが重要」と語るのは重みがありました。当然ながらOSSのメンテナは人間であり、たとえ技術的に正しかろうともメンテナにそれが伝わらず取り込んでもらえなければコントリビュートには繋がらない以上、言われてみれば当然です。自分もOSSへプルリクエストを出す際は肝に命じたいと思います。

一般セッション

今回のKaigi on Railsは初の2トラック開催となり、計34本もの一般セッションがありました。ここではその中から3本のセッションをピックアップして紹介します。

Simplicity on Rails - RDB, REST and Ruby (moro)

このセッションの発表者はMOROHASHIさんで、⁠Rails 3レシピブック』⁠共著)⁠はじめる! Cucumber』などを執筆されている方です。

タイトルがSimplicity on Railsということで、Railsでアプリケーション開発をするうえでシンプルに実現するために考えるポイントが紹介されました。

まず、⁠サービスでやりたいことと、記述するコードの差が少ない状態がシンプル」と定義しました。Railsが得意とするような設計にすることで、Railsの「Webアプリの偶発的な複雑さを減らす」恩恵を受けられるという話です。

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(Application Performance Monitoring)の使い方、活用方法を解説し、より使いやすくするために作成したgemや具体的なチューニング事例を紹介しました。

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(PDS)に繰り返し触れているのが印象的でした。⁠アーキテクチャに正解はなく、選択肢ごとのトレードオフを理解して目的に応じた選択をするのが大事」ということでしたが、PDSを破るようなアーキテクチャを選択するのはよほど限られた状況になりそうです。

また発表の中で「管理機能と呼ぶと誰がなんのために使うか曖昧になりがちなので、責務を表現する名前にしたほうがよい」という話に触れれていました。この話についてはTwitterで同意している人が多く、個人的にも頷ける話でした。

余談ですが、ohbaryeさんの名字はオオバさんで、時間帯が被る裏のセッションで発表していた方もオオバさんでした。そんな偶然があるのか、と思っていたところ、このセッションの前座で大暴露が行われました。

写真

前夜祭で発表者の方が聞いた話によると、運営が意図的にオオバさんのセッションの時間帯を被せて「どっちのオオバさん行く?」という会話をさせたかったとのこと。

写真

こんな運営許せますか!? ……個人的には面白いので許します! 発表者の前座トーク力もさることながら、運営のユーモアも感じて面白い一幕でした。

会場の様子

ここからは、今回会場となった浅草橋ヒューリックホール&カンファレンス内の様子などを紹介します。

ホワイエ⁠企業ブース

受付やノベルティ置き場に加えて、10社の企業ブースがホワイエに出展していました。休憩時間には各ブースとも大きく賑わっていたようです。

写真

なかでも、入り口一番近くに巨大ガラポンを設置していたTechouseさんのブースは存在感があり人も多く集まっていました。一等景品がHHKBやRealforceといった高級キーボードなのもエンジニアの心をくすぐります。

写真

またmybestさんのブースでは「同じコーヒー豆を複数のコーヒーメーカーで淹れた飲み比べ」を開催していました。評価1位のコーヒーメーカーで淹れたコーヒーがどれかを当てると、ガラポンが回せるシステムです。自分も試してみたところ、思った以上に味の違いがあってびっくりでした。

写真

発表ホール

基調講演やAトラックのセッションが行われるヒューリックホールは、座席が400席ほど用意され広々としています。メインスクリーンに加えて左右にサブスクリーンがあるため、発表がとても見やすい作りになっていました。

写真

Bトラックのセッションが行われるカンファレンスルーム1は広めの会議室といった作りです。席数が限られているため、人気のあるセッションでは座席がほぼ埋まっていたようです。

写真

代わりに隣のルーム2がサテライト会場となっており、基調講演やBトラックのセッションがこちらに中継されていました。

写真

他にも休憩スペースやハックルームなどが設けられており、休憩時間の交流や作業に活用されていたようです。

ホワイエは参加人数に対してやや狭めの印象でしたが、これらの目的別スペースが多く用意されていたおかげで人が滞留せず快適に過ごせました。オフライン開催が初とは思えない心配りですね。

パーティー

1日目の夜には複数のスポンサー主催パーティーが開催されました。

私がお邪魔したのはマイベスト・ROUTE6・YOUTRUSTの3社で共催されたStartup Drinkupで、会場近くのダーツバーが会場になっていました。会場奥にはダーツマシンが設置されており、そちらでダーツをしながら談笑している人たちもいて見ているだけでも楽しめました。

写真

初日の夜には他にもRIZAPテクノロジーズ主催のRIZAP DrinkUP、STORES主催のSTORES CAFEが開催されており、どの会場も賑わっていたようです。

2日目の夜にはヒューリックホールをそのまま使って公式主催のアフターパーティーが行われました。オフラインチケットを持っている人が全員参加可能で、たくさんの人と交流することができました。

写真

ちなみに、ドリンクカウンターにはビールやカクテルの他に日本酒も多く用意されていました。Rubyistといえばやはり日本酒ですね。

写真

まとめ

初のオフライン開催となったKaigi on Railsでしたが、大きなトラブルもなく快適に楽しませていただきました。交流やブースを巡れるよう休憩時間が長めに取られていたり、立ち話で人が滞留しないよう休憩スペースが別途設けられていたりなど、随所に運営の気配りが行き届いていたのが印象的です。

クロージングトークで触れられていましたが、会場は未定であるものの来年も開催自体は決定しているそうです。いまから次回の開催が楽しみです。

なお、YouTubeのKaigi on Rails公式チャンネルでは今回の基調講演や一般セッションの動画が公開されています。今回紹介できなかったセッションも面白いものばかりだったので、ぜひ確認してみてください!

最後に、素晴らしいイベントを開いてくださったスタッフの皆様、ありがとうございました! 来年のイベントも楽しみにしています!

写真

おすすめ記事

記事・ニュース一覧