こんにちは！コインチェック株式会社（以下、コインチェック）の牟田です。
10/25~10/26の2日間開催された「Kaigi on Rails 2024」に参加するため有明セントラルタワー ホール＆カンファレンスに行ってきました。
ということで、今回は「Kaigi on Rails 2024」の参加レポートをお届けします。
どのセッションも内容が濃く大変興味深かったのですが、個人的に印象的だったものをいくつかピックアップしてみます。
Day1
基調講演（[Kaigi on Rails 2024] Rails Way, or the highway）
「Rails Way」はRailsアプリケーションを構築する哲学であり、「Rails Way」から外れないように拡張していきましょうという内容でした。
Railsには埋めるべき隙間（認可、複雑なUI、ワークフローなど）があり、その隙間を埋めるためにフレームを歪ませると「怪獣 on Rails」になってしまうので
Railsを習得して「他のものと混ぜ合わせるのではなく、拡張しよう」というものです。
そして、拡張するためには担当分野を分離して各ユニットをプロセスの一部に集中させる必要があり、分離には抽象化が必要となるとのことで、
その際のルールとして以下4つが挙げられています。
-
Railsらしい開発者体験とコアコンポーネントとの互換性を提供する
-
抽象化レイヤーの間に明確な境界を引く
-
介入より抽出: コード内で既存の抽象化を見つけよう
-
関心事と複雑さのレベルを分離する
かなり濃い内容なので30分のセッションだけでは把握仕切れない部分も多かったです。
なので以下の書籍を購入して読んでみようと思っています。
https://www.packtpub.com/en-jp/product/layered-design-for-ruby-on-rails-applications-9781801813785
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
弊社コインチェックでエンジニアメンバーの育成を通じた開発力の向上を目的にペアプロをしてくださっているigaigaさんの講演です。
基調講演とも通づるのですが、安易にサービス層を入れたりせずにイベント型モデルを探したり、POROやフォームオブジェクトをつくることを検討してみて欲しいという内容です。
イベント型モデルとは
-
名詞であるモデル名に「〜する」をつけると行為になるもの
です。
例えば、
-
在庫（Stock）モデル
-
銀行口座（BankAccount）モデル
の2つのモデルがあるとします。
ある時、入荷処理（在庫（Stock）を増やす & 支払った代金を銀行口座（BankAccount）から減らす）を実装したくなった際にどちらに書くか迷うかと思います。
そんな時に登場するのがイベント型モデルで、この場合は「入荷（Arrival）モデル」を作成します。
入荷（Arrival）モデルには、「在庫（Stock）を増やす」「支払った代金を銀行口座（BankAccount）から減らす」といったメソッドを実装します。
メリットとして以下が挙げられています。
-
適切なイベント型モデルを探し出せると、責務が適切なモデルに処理を書ける
-
Rails Wayに乗った設計になっている
資料でも紹介されていますが、「Railsの練習帳」を読んでいただくとさらに理解が深まると思いますので是非読んでみてください！
https://zenn.dev/igaiga/books/rails-practice-note/viewer/ar_processing_across_multiple_models
ActionCableなら簡単? 生成 AIの応答をタイピングアニメーションで表示。実装、コスト削減、テスト、運用まで。
chatGPTなどを利用した際に返答が書き出されていくアニメーション（タイピングアニメーション）をAction Cableで実装した時のお話です。
websocketで簡単にできると思いきやリリースを考慮すると、
-
多くのユーザーが接続した場合
-
→ 専用サーバーを用意する
-
-
重たいプロンプト生成処理だった場合（非同期で実装したが、別マシンからActionCableに送れるのか？）
-
→ Redisアダプタを設定する
-
といった懸念と対策をした上で実際に動かしてみると、「一部のテキストで順番がおかしくなっている」という問題が発覚。
Redisのqueueは順序を保証しないので、
-
index番号をActionCableに伝えてフロントエンドで組み直す(バックエンド)
-
順序をActionCableに伝えてフロントエンドで組み直す(フロントエンド)
でやっと意図通りに動作するものができました というものでした。
また、テスト時の工夫や手法についても記載してくれています。
実際にやったことある人は「わかるわ〜」といった反応で、
自分は「あーはいはいWebSocketね」と思っていた人なので先達に学んで慢心せず開発していこうと思います。
Day2
サイロ化した金融システムを、packwerk を利用して無事故でリファクタリングした話
弊社からの登壇者である草間さんのセッションです。
コインチェックのサービスは巨大なモノリシックなコードでできており、全てのサービスで利用されている「ユーザーステータスに応じた取引可否の判定」をpackwerkを用いてモジュラーモノリス化してリファクタリングしたという内容です。
前提として、
-
インシデントは金融庁報告へつながる
-
多くのドメインが存在し影響範囲が広い
といった難しさがありました。
その中で、モジュラーモノリスを選択した理由として以下を挙げています。
-
インフラ部分に影響することなく構成を試すことができる
-
関心の分離を行いつつ、一定の視認性を維持することができる
また、packwerkを選定した理由として以下も挙げています。
-
実態は静的解析なので本番に影響を与えない
-
依存関係の検知ができる
-
パブリックアクセス領域の設定
-
コード移動のみでモジュール化が実現できて認知負荷が低め
※詳しいイメージが資料に載っているのでぜひ見てください。
ただ、packwerkでは「モノリス側で再び同じようなロジックが作成されることを機械的に防げない」ため、
-
全体認知として各チームへの説明やREADMEの整備
-
ただ機械的な検知もしたいので、カスタムcopを用いた検知やカスタムcop検知の監視
を対策として実施しています。
資料にも今後の展望として記載がありますが、私のチームでもパッケージ化を検討している機能があります。
講演を聞いて解像度が上がると共に、パッケージ化を進めていきたい気持ちが強まりました！
Identifying User Identity
「ユーザー」のアイデンティティについてと、「ユーザー」を良い感じに保てるとサービスの目玉機能を伸ばす役にも立てるよ といった内容でした。
冒頭で以下について述べられていました。
おそらくみなさんの中にも「うんうん」と頷く方がいるのではないでしょうか。
-
大半のサービスでは、サービスの利用者を大雑把に「ユーザー」と呼び、Userモデル = usersテーブルを作りがち
-
だが、サービスの事業領域ごとにいろんな呼び名があるはず
-
で、実際にどうしていくかですが架空の「ユーザー管理機能」のやることリストとして以下4つに沿って考えていきます。
-
ユーザーとして、サービスを利用したい
-
ユーザーとして、ログインしたい
-
ユーザーとして、サービスに登録したい
-
ユーザーとして、退会したい
ただ内容がとても濃いので一部のみ抜粋してさわりを記載します。
ユーザーとして、サービスを利用したい
「基本的主キー idだけでよい」としています。
初見だと多少驚くと同時にそれで大丈夫なのか？と思ってしまいますが、
-
「いる」こと = identifyがあることそのものを表現しており、その持ち物であるデータを作れる（サービスを利用してもらえる状態になる）
とのことでした。
名前やメアドに関してはbelongs_toなテーブルに保存し、情報の属性ごとにテーブルを分けてもOKとのこと。
※スライドの22ページ目を参照してみてください。
その後も上記のモデルに沿って「やることリスト」の方針が述べられているのですが、確かにUserテーブルは「主キー idだけ」の方針で実現できそうでした。
これができると複雑になりがちな「ユーザー」がシンプルになり、よくありがちな負債をなくせそうです。
新規サービスや個人開発時にこの方針で実装できないか吟味してみようと思います。
Kaigi on Rails2024を終えて
私個人としては初のKaigi on Railsだったのですが、総じてとても学びが多く楽しい2日間でした。
Rubykaigiには参加したことがあるのですが、Kaigi on Railsは実務寄りの内容が多く、また違った楽しさや関心を惹かれるカンファレンスだったなと思います。
来年も参加したいなと思いつつ、私もプロポーザルを出したりと貢献していければとも思いました。
最後に
コインチェックでは一緒に働くエンジニアを募集中です！
詳しくは求人ページをご覧ください。
https://corporate.coincheck.com/recruit/jobsearch/engineering
