こんにちは！サーバーサイドエンジニアの近藤です。
Kaigi on Rails 2023 が、10月27日から10月28日にかけて開催されました。 2020年から続くKaigi on Railsですが、今年が初のオンライン&オフライン同時のハイブリット開催となります。 メドピアはゴールドスポンサーとして協賛し、15名ほどのメンバーが現地で参加しました。
当記事では、現地で聴いたセッションのうち印象に残った発表をピックアップしてご紹介したいと思います。
Exceptional Rails
メドピアで技術顧問をしていただいている前島さんによるセッションです。 Railsにおいて例外をいかにして扱うか、というお話でした。
Railsコード中の例外処理ひとつ取っても、考えることは数多くあります。
- いつ例外を発生させるか
- 発生した例外をいつどのようにrescueするのか
- 通知が必要な例外をどのように開発者に通知するのか
- エラーページをユーザにどう表示するのか
エラーを扱う際のこれらの観点について、方針とその理由を身近な具体例を交えながら解説していました。
個人的に印象的だった話題は、外部サービス起因のエラーの通知についての話題です。 エラーを通知するか否かについて
- エラーが起きる状況を考えてみる
- そのエラーが開発者側では対応できないこと（外部サービスの不具合など）が原因で起きるものであれば（即時の）通知はしない
- 対応できないエラーが来てもノイズになるため
- レベルをwarningなどに設定し、短期間に頻発するようであれば通知するのはあり
といった判断基準を紹介しており、通知に対する考え方の面で学びになったお話でした。
全体的に、今後例外を扱う際にぜひ見返したくなるようなセッションでした。
Update Billion Records
レコード数が50~60億という巨大なテーブルに対してカラムを追加し埋める際に、なにを考えどのような手段を取ったかについてのお話です。
この巨大なテーブルを更新するにあたって、
「更新中にサービスを止めてはいけない」
「更新処理はいつでも中断・再開できなければならない」
などの要件がありました。
適切な更新手段を見つけるために、最初は既存手法の踏襲から始め、
（要件や現状の）整理 →（手段の）発案 → 検証
というサイクルを繰り返し、最終的にたどり着いた手段は「更新対象をqueueで管理し非同期jobで少しずつ更新する」というものでした。
発表の後半で、スピーカーのtokutomiさんは今回の改修を次のように振り返っています。
最終的な構成も参考になるものでしたが、それと同じくらい、 最終的な構成に至るまでの改善プロセスも参考になる発表でした。
Turbolinksアレルギー患者に捧げるTurbo & Stimulusでの時短実装術
弊社エンジニアの草分さんが「Turbolinksアレルギー患者に捧げるTurbo & Stimulusでの時短実装術」というタイトルで登壇しました。
[草分さん]「Hotwireという名前をご存知でしょうか？」
[会場] 「👏 👏 」
[草分さん]「では、Hotwireを本番環境等でちゃんと使っていましたでしょうか？」
[会場] 「......」
[草分さん]「🤯」
という笑い溢れる導入から始まったこのセッションは、 なにかと避けられがちなHotwireを実プロダクトで採用した話と、 その際にどのようにHotwireを使い時短を実現したかについての発表でした。
タイトルにもある「時短」について、
- create (= フォームのsubmit) 前の確認画面
- フォームの動的切り替え
という2つの状況を例に、 Hotwireを使った時短実装術をデモと共に紹介していました。
確認画面をモーダルで出すことでユーザー入力の再描画処理を省けたり、 Hotwireを使うことでリッチなUIもお手軽に実装できたとのことです。
Hotwireをオススメできる状況として
- 画面側がHotwireで十分実現できるとき
- 社内向けの管理画面
- バックエンドエンジニアが多いプロジェクト
を挙げており、実際にヤクチエの開発で採用した実例も紹介していました。
スライドの所々に小ネタが散りばめられており、会場から笑い声が絶えないセッションでした。
32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方
既存システムを動かしたままREAD/WRITEの多いテーブルのカラムを置き換えるために、MySQLのオンラインDDL機能（ロックを取得せずにマイグレーションを行える機能）を利用したお話です。
一言で「オンラインDDL機能を利用」といっても、考慮すべき点は数多くあります。
たとえばオンラインDDLそのものに対する注意点として、
- 本来はオンラインDDLの対象になる操作であっても、場合によってはそうならない場合がある
- オンラインDDLは一部の期間でメタデータロックというロックを取得するため、ロックを取る他の処理の確認が必要
などの注意点を紹介していました。
また、リリースフローに関する注意として、
コンテナを用いてBlue/Greenデプロイをしているような環境では、
「マイグレーションの完了タイミング」と
「コンテナの入れ替わりタイミング」にずれが生じてしまいます。
これにより、古いアプリが新しいデータベースを見に行ってしまう状況が発生するため、 単純に「カラム名の変更」をするのではなく「カラムの追加 → 役割の置き換え → 古いカラムの削除」という手順を踏んでリリースしたとのことです。
実際のリリースでは下図のような段階的な対応を行ったとのことで、このリリースに万全の体制で臨んだことが伺えます。
現在私が携わっているプロダクトでも大きなテーブルのマイグレーションには苦しんでおり、オンラインDDLの注意点や段階的なリリース手法など、ぜひ今後の参考にしたいセッションでした。
おわりに
全体的なセッションの傾向として、実際のプロダクト開発に関連する内容のものが多くを占めており、 drinkupや懇親会の会場でもプロダクト開発の話題が数多く飛び交っていたように思えます。 Kaigi on Railsを軸にして、Railsまわりの知見の交換が行われているのを感じました。
今回のイベントで得た知見を、私も日々のプロダクト開発に活かしたいなと思いました。 Kaigi on Railsへの参加は初めてだったのですが、とても充実した2日間でした！
Afterイベントやります！
11/9（木）の19時から、メドピア株式会社、株式会社スマートバンクさん、株式会社マイベストさんの3社合同で、アフターイベント「After Kaigi on Rails LT Night」を行います。
各社から1名ずつのLTと公募によるLTが3つの、計6つのLTが行われる予定です。 会場はメドピアのオフィスで、最寄り駅は東銀座駅となります。 RubyやRailsの関連技術について、食事とともにお話できる場になればなと思います。
ご興味ありましたら上記リンクからぜひご参加ください！
是非読者になってください！
メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております！
■募集ポジションはこちら
■エンジニア紹介ページはこちら
