Kaigi on Rails 2024 Day1 参加レポート
こんにちは。
GMOビューティーで主にキレイパスコネクトというサービス開発を担当している千葉です。
今回は2024年10月25日〜26日に開催されたKaigi on Rails 2024に参加してきたので、Day1のセッションに関するレポートをまとめたいと思います。
Kaigi on Rails 2024 概要
Kaigi on Railsは主にRailsに関する技術カンファレンスになります。
Kaigi on Rails 2024では、10月25日〜26日に＠有明セントラルタワーホール & カンファレンス（東京）で開催されました。
Kaigi on Railsのコアコンセプトは 「初学者から上級者までが楽しめるWeb系の技術カンファレンス」 です。Kaigi on Railsは技術カンファレンスへの参加の敷居を下げることを意図して企画されています。
上記に記載の通り、Kaigi on Railsでは初学者から上級者まで幅広く楽しめるレベルのセッションが設けれられているため、初学者でも比較的参加しやすい技術カンファレンスとなっています。
セッションレポート
1. そのカラム追加、ちょっと待って！カラム追加で増えるActiveRecordのメモリサイズ、イメージできますか?
いつもお世話になっているGMOビューティー取締役エンジニアの浅山さんによるセッションです。
こちらはカラム追加ではなくテーブル分割を選んだ方が良いのか、許容できる変更なのかを設計ではなくメモリ使用量の観点から考えたセッションになります。
まず初知りだったことは、Integerの1カラム増やした場合のメモリサイズ。
1カラム増えた場合のメモリサイズは224バイトだそう。
（個人的な感想ですが、224バイトは自分が思っていたよりも少ない数値だと感じました）
1カラム増やすと224バイト増えるんだなあで終わりではなく、増えたオブジェクトの詳細（クラス名とそのバイト数の内訳）まで深掘りしてくれています。下記の黄色ブロックのバイト数合計が224バイトになっています。
増えたオブジェクトの構成を図にまとめると以下のような画像になります。
ここで以下のような疑問生まれます。
- @value = 1の部分のバイト数は増えないのか？
- 40バイトと72バイトの数値の違いは？
こちらについてはCRubyのメモリレイアウトについて深掘り解説してくださり、先ほどの疑問点を解消することができました。
- @value = 1の部分のバイト数は増えないのか？
- CRubyではオブジェクトごとにRVALUEと呼ばれる固定長を割り当てるが、Value埋め込み表現と呼ばれる例外のケースがある
- 40バイトと72バイトの数値の違いは？
- RString構造体・RStruct構造体の構成から短めの文字列とレンジは40バイト
- RObject構造体（ユーザー定義クラス）の構成から72バイト
今回のセッションを通して、メモリサイズの観点から、このカラム追加は本当に大丈夫なのか？テーブルに切り出した方が効率が良いのでは？などと考えるきっかけを改めて与えてくれるものだと感じました。（メモリ効率や使用量は普段の開発でも意識しなければならない項目ですしね）
2. ActionCableなら簡単? 生成 AIの応答をタイピングアニメーションで表示。実装、コスト削減、テスト、運用まで。
このセッションでは、ChatGPTといったLLM APIとActionCableを用いた実装、テスト、インフラ構成のポイントと各フェーズでの課題解決方法について解説してくださっています。
ChatGPTの出力結果をタイピングアニメーションで実装するまでの過程について、実装方法とその際に発生した問題点を見ていきます。
まず最初は単純にAPIとして組み込んでいます。
この構成で出力処理に時間がかかった場合、ローディングインジケータが回り続け、最悪タイムアウトしてしまうという問題点があります。
| 構成図 | 結果例 |
|---|---|
 |
 |
しかしActionCableを用いてSubscribeしておくことで、解決することができます。
| 構成図 | 結果例 |
|---|---|
 |
 |
しかし、まだ以下のような問題点があります。
- subscribeが多発する場合、コネクションを占有してしまい他のAPIが繋がらなく恐れがある
- プロンプトの生成処理が重い場合の処理をどうするか
- 非同期で実装した場合、WorkerからActionCableに送れるのか
これらは以下のような対策で解消したそうです。
- subscribeが多発する場合、コネクションを占有してしまい他のAPIが繋がらなく恐れがある
- ActionCable専用のサーバを用意し、そこにsubscribeするようにする
- プロンプトの生成処理が重い場合の処理をどうするか
- 非同期処理に移す
- 非同期で実装した場合、WorkerからActionCableに送れるのか
- Redisアダプタを設定し、WorkerからBroadcastする
構成図としては以下のようなイメージになります。
しかしまだ問題点が。
Redisのqueueが順序を保証しないため、正しい出力結果が得られない場合があります。
その解決策として、バックエンド側ではindex番号をActionCableに割り当て、フロント側でその割り当てられたindex番号を元に出力結果を組み立てることをしたそうです。
ActionCableは個人開発では触ったことがありますが、実際にサービスとして本番運用している事例をあまり聞いたことがなかったため、どのような構成でどういった運用をしているかなど、とても参考になったセッションでした。
「バックエンド側ではindex番号をActionCableに割り当て、フロント側でその割り当てられたindex番号を元に出力結果を組み立てる」処理には開発者の気合を感じました。
3. Capybara+生成AIでどこまで本当に自然言語のテストを書けるか？
個人的にRailsのE2EテストといえばCapybara×Selenium。
(「RailsのE2EテストといえばCapybara×Selenium」← 発表者に怒られそうですが。)
E2Eはある程度の実装コストがかかってしまうのが欠点ですが、生成AIの登場によってテストコードを書くこと自体は比較的容易になった印象です。しかしE2Eテストは作っておしまいではなく、Webサイトを改修するたびにメンテナンスをしなくてはいけないというデメリットは残ったままになります。
このセッションでは、Railsサーバーを起動してAIにWebサイトを読み取らせて自然言語でテスト内容を入力して結果を得るという方法について解説してくださっています。
自然言語での自動テスト実行はフォーム操作に関しては大枠期待通りの挙動をしてくれるみたいです。
しかしリストのような一覧画面の場合は、正しい位置をクリックできなかったり、Capybaraの選択ミスに気付けずそのままテストが落ちたりとまだまだ発展途上の部分はあるようです。
このセッションを通して、生成AI×E2Eによって簡単にテストできる未来がそう遠くない所まで来ていることを感じました。
最後に
全体的なセッションの内容としては、実際のプロダクト開発に関連するものが多くあり、今の開発現場でも役立てられるものがたくさんあるなという印象を受けました。今後のキレイパスコネクトの開発で取り入れられそうなものは積極的に入れていこうと思います！
Discussion