RIZAP がKaigi on Rails2023にも初参戦！【各講演のレポート集】
↓↓↓ 現場レポートはこちら ↓↓↓
https://www.rizap-tech.co.jp/recruit/articles/entries/305
梅田智大の感想まとめ
1.初めてのパフォーマンス改善～君たちはどう計測す(はか)るか～ by Fu-ga - Kaigi on Rails 2023
https://kaigionrails.org/2023/talks/fugakkbn/
事業成長に伴う利用者増加によって、レスポンスに影響が出始めたため、パフォーマンス改善を図ったというお話でした。
chocoZAPもおかげさまで利用者が急増し、パフォーマンスの向上が日々の課題となっていたため、このセッションは非常に有意義なものでした！
さらに、このセッションはユニークなスライド展開とともに要点が分かりやすくまとめられ、とある映画をオマージュしたユーモアあふれるタイトリングのセンスも含め、非常に素晴らしい内容でした。会場からは笑いと拍手が起こりました！
パフォーマンス改善へのアプローチ その1
全体調査で原因っぽいところを把握する
APMを活用して、ざっくりどのページやアクションに原因がありそうかあたりをつける
どれぐらい遅いのか、実際に平均値や最大値を数値で計測
遅い箇所は何が原因っぽいかを想像する
改善が見込まれる箇所の対応優先順をつける
パフォーマンス改善へのアプローチ その2
本格的に調査をして改善を図る
ボトルネックが何かと、それが単数なのか複数なのかを把握
改善後に振る舞いが変わらないことを担保するため、事前にテストを書いておく
計測結果をもとに改善の仮説を立てる。仮説を立てたら実際に改善をして計測。計測してダメなら次の案を試す
Githubのissuesなどを活用し、試した内容と結果の調査経緯をまとめておく
パフォーマンス改善へのアプローチ その3
リリース後に経過を観察する
リリース直後は数時間単位で状況を確認し、極端にパフォーマンスの劣化がみられたら切り戻しの判断をする
初動が問題なければ数日単位で観察を続ける
パフォーマンスに劣化があった場合は早めに切り戻す
【感想】
パフォーマンス改善と一口に言われても、何から手をつければ…と悩んでしまいますし、実際に手をつけ始めてみても、時間をかけた割にイマイチ改善されなかったという状態に陥りがちです。
このセッションを通じて、最初に全体を把握し、原因のあたりをつけた後に対応の優先度を決めることで効率的に作業を進めるとともに、何を行った結果、どうなったかを数字で記録することで、もし改善が見られなかった場合も次につながるようにすることが非常に勉強になりました！
2.ペアプロしようぜ ～３人で登壇!? 楽しくて速いペアプロ/モブプロ開発～
https://kaigionrails.org/2023/talks/tebiki/
今回聴講したセッションの中では、一番ドキドキハラハラしました…！
その内容はなんと、ライブペアプロ…！実際にステージの上で三人が生で開発を行い、一つのissueを解決するまでを実践してくださいました。
ペアプロ/モブプロの良さ
ペアプロでは自分が何をコーディングしようとしているかを話しながらコードを書いていったり、コーディング中にペアと意見が分かれるとその場で議論が発生したりするので、単純にコードを書くスピードはソロプロに劣ります。 しかし、コードレビューで圧倒的な差が生まれます。
私自身、レビューをする時に、開発の意図や目的が汲み取れずキャッチアップに時間がかかったり、diff が多いとどこからコードを見れば良いかもわからず迷ってしまったり、といった経験があります… 。
さらに、レビューで欠陥に気づきほとんどコードを書き直すことになったことも。。
このレビューの時間や手戻りの工数を含めると、トータルしてペアプロのほうが効率がよいという結論が出ているようです。
ペアプロ導入の課題
とはいえ、ペアプロをメインで開発するのはハードルが高いと感じてしまいます。 tebikiさんも最初は、ペアプロを導入するまでは「何から始めてよいかわからない」、「お互いに何をしたいのかわからず迷走してしまう」、あげく「疲労コンパイルエラーが起きてしまう」…といった課題を抱えていたそうです。
色々と試行錯誤された結果、下記の方法をとるのがおすすめとのことです。
slackで画面共有をし、ペンツールを使いながら指示をする
開始前に何を開発するのかの方針を書き出しておく
1時間あたり10分を目安にこまめに休憩を入れる
タイマーを使って15～20分を目安に交代をする
1人が全部やってしまうのを避けるため、指示出しをするナビゲーターと、指示にしたがってコードを書くドライバーという役割に分ける
ライブでペアプロ！
これらの話を踏まえ、実際にステージでペアプロを実践してくださいました！ 要件としてはフォームにバリデーション機能を一つ追加するというもので、時間は11分。 時間がかなり短いので、早速コードを書き始めるのかと思いましたが、要件の確認とTo-doの書き出しに半分以上の時間を使っていました。
ペアプロ導入の課題の中で話されていた通り、お互いに何をしているかがわからなくなる状態を防ぐために、事前の確認はしっかりと時間を使って行っているのだというのが伝わりました。
要件定義と設計を明確にしないままコードを書き始めると、後から手戻りが発生して結局作業が無駄になるというのは頭で分かっていても、ついつい要件を書き出さないまま手を動かしてしまいがちです。
今回のライブペアプロでも、対象となるモデルは何か、その変更によってどこに影響が出るか、テストは何を書くか、バリデーションのエラーメッセージは何にするかなど細かい点までしっかりと確認されていました。
コードを書く段階では、ナビゲーターとタイピストの役割がしっかりと守られており、タイピストは指示に間違っている点があっても勝手に修正したり、「こうやったほうがいい」と意見をしたりせず、「ここはどうしますか？」とナビゲーターに疑問を投げかけるだけにとどめていたのが素晴らしいなと感じました。
そして何と時間ぴったりで開発が終了！最後も無事にテストが通り、会場は拍手喝采でした。
【感想】
バリデーションを一つ追加するだけの軽微な修正であっても、11分でマージまでしてしまうスピード感は驚きでした。 RIZAPでもペアプロをすることはありますが、ペアプロメインで開発はしていません。 セッションの後は今すぐにでもペアプロをしたい…！という気持ちになりましたし、何より見ていて本当に面白いセッションでした。
もちろん、ペアプロの難しさや課題はあるかと思いますが、今回のセッションを参考に積極的に導入していきたいです！
松永祐生の感想まとめ
3.返金処理を通して学ぶ、カード決済電文の沼バトル
https://kaigionrails.org/2023/talks/hirotea/
SmartBankのエンジニア・hiroteaさんのセッションです。
クレジットカードの返金処理は、フローのパターンが多数ある上に部分返金や海外事務手数料、為替変動など考慮するべきことが多く、甘く見積もって痛い目にあったという内容でした。
例えば返金処理の基本的なフローが以下だったとして
売上オーソリ → 売上クリアリング → 返金オーソリ → 返金クリアリング
以下のようなフローになることもあり
売上オーソリ → 売上クリアリング → 返金クリアリング
以下のようなフローになることもある?！
売上オーソリ → → 返金オーソリ → 売上クリアリング → 返金クリアリング
…と、何パターンもあるそうです。。。
さらに追い打ちをかけるように、部分返金や海外事務手数料、為替変動、その他さまざまな「面倒な仕様」があるとのこと。 想像しただけで苦笑いです。hiroteaさんはデータの流れの可視化や電文到着全パターンの書き出しを行い、解決していったとのことでした。
【感想】
クレジットカードの返金周りの沼を面白おかしく説明されていて、あまり決済に関わることがないエンジニアでも楽しく聴けるセッションでした。データの流れの可視化や全パターンの書き出しなどの設計工程は基本的なことですが、RIZAPのようなスピード感がある事業会社ではサボりがちなことでもあります。
「設計→設計レビュー」の大切さが再確認できてよかったです。
4.事業の試行錯誤を支える、コードを捨てやすくしてシンプルなシステムの設計と工夫
https://kaigionrails.org/2023/talks/zuckey/
株式会社スタディストのPMをされておられる@zuckeyさんによるセッションです。 新規事業にリードエンジニアとして参画し、開発を行ってきた経験から、スピード感のある事業を支えるための設計について話されました。
新規事業では試行錯誤・方向転換が多々あるため、作った機能が何年も使われるとは限りません。そのため、コードや機能を簡単に捨てられるシンプル(素結合)なシステムを目指したそうです。
一つ目の事例では一つのテーブル(scheme_summaries)を用途に応じて別個のテーブル(scheme_progresses、scheme_stats、scheme_sales_reports)に分割し、それぞれにモデルを対応させるというアプローチをとり、 それにより責任範囲がクリアになり、削除のハードルを下げることができるようになったそうです。
二つ目の事例では小売企業とメーカー企業を管理する際に販売店テーブル(retailers, retailer_users, retailer_user_authentications)を作り、ポリモーフィック的に小売とメーカーを切り分けるところを小売企業テーブル(retailers, retailer_users, retailer_user_authentications)とメーカー企業テーブル(makers, mader_users, maker_user_authentications)の２セットに分けて、それぞれにmodel, controllerを作成することで削除しやすくしたそうです。
また、使われていない機能を捨てることを事業側に理解してもらうため、開発者から意思決定を促すアプローチも大切という話もされていました。
【感想】
スピード感のある事業には試行錯誤や方向転換がよくあるという点で、chocoZAPと境遇が似ており共感が多く、とても参考になるセッションでした。
・一つ目の事例は特定のシナリオにおいてはかなり有効な戦略だと感じました。一般的なRailsの概念とはかけ離れているため新鮮な考え方で面白かったです。
・二つ目の事例においてもDRYの原則に従ってコードを書いているだけだと見えない設計だと感じ、すごく勉強になりました。
zuckeyさんのセクションを聞いて事業にとってのベストな設計は、時にRails wayを大きく外れることもあるというのを感じました。視野の広い設計を心がけたいです。
5.32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方
https://kaigionrails.org/2023/talks/ShoheiMitani/
SmartBankのバックエンドエンジニア: Shohei Mitani さんのセッションです。 Read/Writeが非常に多く、依存度が高いモデルの変更を無停止でリリースした話をされました。 以下、大まかな概要です。
MySQLのオンラインDDLを使うことでサービス否停止で行うことができます。
しかし、オンラインDDLにはエラーとなるケースも無数に存在し、検証環境で十分な検証を行う必要があるとのことでした。
また、いくらオンラインDDLでもカラム名の変更を行うと、デプロイ時にDBとAPPに状況不一致期間が生まれるため、カラム名の変更ではなく以下のような追加を軸にしたフローにすることで、安全に対処ができたそうです。
カラムの追加 → 役割の置き換え → 古いカラムの削除
実際に採用されたリリース手順は以下です。
カラム追加
値の同期 (既存のカラムと追加したカラムどちらにも同じ値が入るようにコード修正)
バックフィル (過去のデータの新旧カラムを同期させる)
Not null制約の追加
参照の置き換え
同期の停止 (2で追加したコードを削除する)
ignored_columns (特定のカラムに対するCRUDをモデルレベルでスキップさせる)
カラム削除
【感想】
何も考えずに変更をリリースするだけなら一つのPRで対応できる内容ですが、あえて32個のPRに分けて段階的にリリースすることで、可用性や完全性を満たすというのは目からうろこでした。
段階ごとに影響を監視することで致命的なエラーが発生するリスクが減りますし、ロールバックがしやすいです。 chocoZAPも24時間サービスなので今後似たような要件が出てくることが予想でき、DBの変更に関してかなり参考にできそうだと感じました
栗原敦巳の感想まとめ
6.やさしいActiveRecordのDB接続のしくみ
https://kaigionrails.org/2023/talks/kubo/
普段はdatabase.ymlに必要情報を記述し、適当なモデルのfind/whereメソッドを使うことでDB接続の確立がなされて、簡単にデータの取得ができます。スライドでは3つのセクションに分けて解説されていて、なかなか触れることのない領域を知れてとても興味深い内容でした。
ActiveRecordの接続までの主要なクラス
Mysql2Adapters
実際にmysql2アダプターを呼び出すクラス
Mysql2::Clientインスタンスが作成
initializeメソッドでdatabase.ymlの情報を元に接続要求
ConnectionPool
接続を管理するクラス
接続プールからの接続の調節（新規作成かプールからの再利用）
def new_connection
?database.ymlに記載されている情報を元にアダプタークラスとインスタンスが作成される
ConnectionHandler
接続プールを管理するクラス
データベースごとに接続プールを保持している
def checkout
【感想】
エラー原因の切り分け方法
・エラーを見ても原因箇所の想像がつかない場合があった
・注目すべきポイントがどこなのか原因を切り分けることができれば、あたりをつけやすい
・new_clientメソッド以前のエラーは接続確立前のアプリ側の問題
・new_clientメソッド時点のエラーは接続確立する時の問題Mysql2Adaptersのクライアントインスタンスはdatabase.ymlの情報を保持している
DBホストの変更を行う際はプールで保持されている変更以前のホストの接続が利用される可能性がある
環境構築の際にmysql2でちょくちょくエラーになったことがありましたが、そのような時に今回のような深掘りをしているかいないかで、エラーへの対応力が大きく変わってくると思いました。
7.Turbolinksアレルギー患者に捧げるTurbo & Stimulusでの時短実装術
https://kaigionrails.org/2023/talks/kubo/
Rails開発者の知る人は知っている「Turbolinks」の過去の話から、それらの上位互換として登場したHotwireを実際のプロダクト開発に採用することで得た知見と苦難についてのトークでした。
Turbolinks
Trubolinksはページ遷移を高速化する用途として、当時Railsでは標準として実装された機能でしたが、使いこなすのが難しいライブラリでした。
特にjQuery、JavaScriptとの相性が悪く、特定のライブラリが動作しなかったり、JavaScriptのライフサイクル機能が動作しなかったりと色々と問題がありました・・・ 。
Hotwire
tubo+stimulus+stradaの3ライブラリの総称
RailsだけでSPAライクなページをシンプルに実装できる機能です。
turbo
・JSを書かずにSPAっぽいことができるstimulus
・turboで対応しきれない制御をサポートstrada
・主にモバイル向けの機能
確認画面実装って大変
Railsで登録画面の実装をする場合、def newを用意する場合
入力途中の情報はどう保持する
railsのviewだけだと画面全体が切り替わっちゃう
キャンセルなどフローが増える
など、意外と考慮することが多く大変です。
hotwireなら、確認ページをモーダル実装にすることで、確認画面を別で用意して情報を用意することなくその場で利用でき、このあたりの問題をカバーできます。
【感想】
自分自身が過去にTubolinksに苦しめられた経験があったので、聴講していて非常に面白いと感じたセッションでした。
HotwireはJSを書く労力が最小限でSPAを導入できます。一方でVueやReactほど複雑で細かい実装には向いていないため、プロダクト要件に基づいて柔軟に採用の意思決定に持っていきたいと思いました。
メンバーの感想は以上となります。
もりだくさんの内容で、大盛況に終わったKaigi on Rails2023。
ここで得た学びをメンバーがどのように生かしていくのか、今後のRIZAPにご注目ください！
関連する求人情報
