この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー23日目の記事です。
はじめに
こんにちは。デベロッパーエクスペリエンスグループ（以下dev-exグループ）でエンジニアをしているkusamaです。
私たちのグループでは、その名前の通り、開発者体験の向上やCI/CD環境の整備を主な役割としており、Ruby/Rails や各種 Gem のアップデート対応も重要な仕事の一つです。弊社の組織について興味がある方は、是非こちらの記事もご覧ください。
そんなdev-exグループで一緒に働いている@ginkounoさんが運営に携わっている、RailsTokyo#2が、2025/12/18に開催されたので、参加してきました。
@ginkounoさんは今年、コインチェックの巨大なモノリス（一部パッケージ化）となっているコードにRBSを導入して下さいました。今回のRailsTokyoでスタッフトークとしても発表されていましたが、既に詳細な記事も公開されているため、あわせてご覧ください。
会場はタイミーさんのオフィス
今回のイベントは、メインスポンサーであるタイミーさんのオフィス、35階にあるイベントスペースで開催されました。
広くて綺麗なイベントスペースで、中央には巨大なタイミンが鎮座しており、その存在感と可愛らしさが場の空気を和ませていました。
※写真の掲載可否が分からなかったため、今回は掲載を控えています。
Active Record ADBC adapter
@ktouさんのセッションでは、Active Record ADBC adapter について紹介されました。
ADBC（Arrow Database Connectivity）とは、Apache Arrow を活用して大量データの高速なやり取りを可能にする DB 接続 APIです。Active Record からこれを利用できるようにするのがActive Record ADBC adapterとのことです。
正直、私自身は ADBC や Apache Arrow への解像度が高い状態ではありませんでしたが、大量データロードやダンプ処理における、生 SQL・従来の AR アダプタとの差に驚きました。
また、ADBC adapter は Rails の複数 DB 機能を併用できる設計になっており、大量データを扱う特定モデルに限定して使うなど、既存のアプリ構成に無理なく組み込みやすい点も使いやすいポイントです。コインチェックでも、日次・月次で大量データを扱うバッチ処理や、金融業界として不可欠なリコンサイル処理など、「処理時間がそのまま運用負荷に影響する箇所」で真価を発揮しそうだと感じましたが、現在はRDBにMySQLを採用しており、適用できない点が残念です。
Active Job 近況 - Continuations, Solid Queue
@igaiga555さんのセッションでは、Rails8.0で追加されたSolid Queue、Rails8.1で追加されたContinuationsの紹介がされました。
Continuationsは、ジョブを中断し進捗を記録した上で再開できる仕組みを提供します。記述の仕方と、実際にコードをトレースしながらの説明で動作イメージが伝わりやすい内容でした。
一方で、Continuationsのリトライ機能retry_jobと従来のActiveJobのリトライ機能retry_onについての注意も述べられていました。ジョブの中で例外発生時に再開することのできる柔軟性もメリットではありつつも、ジョブ設計そのものの質が強く問われる機能であるとも思えます。ステップ単位の冪等性や依存関係を明確に意識する必要があると感じ、設計難易度が高く、使いどころとしては慎重な判断が必要そうだという印象を受けました。
続いて紹介されたSolid Queueは、RDBを使用したActiveJobのキューイングシステムで、SidekiqのようにRedisを使用しないことや、キュー用のDBを独立して設定できる点がポイントです。
スケジュール実行も用意されており、Sidekiqとの比較対象になり得る機能ですが、@igaiga555さんや他の方の発表にもあるように、明確な移行理由や課題がない限り、現状ではメリットを感じにくいという印象を受けました。
マイクロサービスへの5年間、ぶっちゃけ何をしてどうなったか
最後に@joker1007さんの招待講演。マイクロサービス化に関する話題ということで、個人的にも特に楽しみにしていたセッションです。
Reproさんでの実際のマイクロサービス化の事例を基に話されていました。実際には、組織構造を先に設計する逆コンウェイ戦略に沿ったものではなく、10以上のマイクロサービスの大半を1人で設計され、初期構築していたとのこと。すごいです。
その過程の中で、意識していた理屈をお話し頂いたので、いくつか紹介します。
結合と変更範囲のコントロール
島田さんの著書、「ソフトウェア設計の結合バランス」と共に語られた下記ポイントが、参考になると感じました。
- 予期せぬ変更の波及をコントロールする
- 結合強度 x 距離 x 変更頻度で安定度が評価できる
特に、安定度の言語化は納得感が高く、即座に年末年始に読む本のリスト入りとしました。
SchemaRegistryの活用
IFとなるスキーマが正しければ正しく動くという前提のもと、大半のスキーマを独立リポジトリで管理し、互換性チェックをそこで行うというアプローチが紹介されました。
システム間連携の課題を考えると非常に合理的で、学びの多い内容でした。
モジュラーモノリスにも通用する考え方
ここまで紹介された内容はマイクロサービス化の事例を軸としたものでしたが、これらはモジュラーモノリスにも通用する考え方だと語られており、最後にモジュラーモノリス観点で意識すると良さそうな観点も紹介頂きました。
- コンポーネント境界のI/Fを定義する
- デプロイ速度、CI速度の改善
コインチェックでは、packwerkを使ったパッケージ分割を、一部コア機能について導入しており、IF定義や使用方法のドキュメント作成などでガイドライン整備を進めています。また、冒頭で紹介した@ginkounoさんのRBS導入の施策についても、今後パッケージからrbs-inlineの導入を予定しており、モジュラーモノリスとして、よりコンポーネント境界を意識しやすい構造に進化していくのではと考えています。
同時に、dev-exグループで日々取り組んでいる CI 速度改善の価値 についても、改めて再認識できたセッションでした。
全体を通して、マイクロサービスの話でありながらも現在のコインチェックの開発フェーズや課題感とも重なる部分があり、「今聞けて良かった」と感じるセッションでした。
おわりに
個人的には、育休を挟んで久しぶりのイベント参加になりましたが、普段の業務では触れない技術や事例を“生”の発表で聞くことができ、大きな刺激を受けました。こうした学びを日々の業務に還元していくことも、dev-exグループの大切な役割だと改めて感じています。
各スポンサーセッションの発表もどれも素敵でしたし、セッションの後は美味しいピザとビールを頂きながら、楽しい時間を過ごせました。
会場では次回開催のアナウンスもありました。運営メンバーの皆さん、登壇頂いた皆さん、ありがとうございました！
