Multiple Databasesを用いて2つのRailsプロジェクトを統合する

Kaigi on Rails 2023で発表した際の資料です

Transcript

1. Multiple Databasesを用いて2つのRails プロジェクトを統合する pixiv Inc. imadoki 2023.10.28
2. 2 自己紹介 • ピクシブ株式会社でエンジニアをしています • お仕事ではRuby/Railsを書いています • Ruby歴は7年ほど • 今欲しいキーボードは kinesis advantage 360 • Github: @imadoki imadoki
3. 今日話すこと • 2つのRailsプロジェクトの統合についての経緯と課題 • 複数DB機能を用いたRailsプロジェクトの統合で実際に行ったこと • その他統合の上で工夫した点 3
4. pixivコミック • 2012年開始のマンガサービス • https://comic.pixiv.net • 現在はアプリ版(Android/iOS)、 ブラウザ版の3プラットフォーム • 商業作品の連載 / 電子書籍ストア / pixivの投稿作品閲覧 • バックエンド・管理画面はRailsで実装 ◦ リリース時はRails3.2 ◦ 現在はRails6.1 4
5. pixivノベル • 2015年開始の小説サービス • https://novel.pixiv.net • ブラウザ版オンリー • 商業の小説・ライトノベルの連載 • すべてRailsで実装 • 元々はpixivコミックをクローンして実装 された 5
6. 課題感 • pixivコミック・pixivノベルはそれぞれ別のサービスとして稼働してきた • 一方で掲載されているマンガ作品は小説・ライトノベルを原作とするものも多い 6
7. pixivコミックとpixivノベルを より連携させたい 7
8. Railsの複数DB機能を用いて連携する 8
9. なぜ複数DB機能を使う？ 選択肢としては… • APIベースで連携する • 複数DB機能を用いて1つのRailsプロジェクトに統合する 9
10. なぜ複数DB機能を使う？ • pixivノベルは元々pixivコミックをクローンして出来たものであり、 似たような機能が多い • pixivノベルは専門のチームがおらず、pixivコミックチームが見ているが どうしてもメンテナンスやリファクタリングが行き届いていない部分がある • 2つのRailsプロジェクトとして保守していくのではなく、 1つのRailsプロジェクトに統合していったほうがメンテナンスし易いと判断 10
11. 進め方 全体の流れとして 1. 一般ユーザー向けの機能をpixivコミックへ統合 2. 社内向け・社外向けの管理画面を統合 ビックバンリリースにならないように段階を経て統合作業を進める 11
12. 進め方 • pixivノベルのDBスキーマをpixivコミックへ移す • app/models/novel/* にpixivノベル用のActiveRecordのモデル定義を移植 • pixivノベルの機能に対して優先度をつけてAPIごとに機能をpixivコミック側に 再実装 12
13. pixivノベルのDBスキーマをコミックへ • pixivノベルを稼働したまま機能を移していくため、pixivノベルのDBスキーマは pixivノベルのものを正として管理することに • pixivノベルのスキーマデータをコピー ◦ pixivコミックのconfig/database.ymlにpixivノベルのDBに接続設定を追加 ◦ pixivノベルのdb/schema.rbをdb/novel_schema.rbにコピー ◦ pixivノベルのマイグレーションファイルを1つにまとめ db/novel_migrate/*に配置 13
14. pixivノベルのDBスキーマをコミックへ • 本番環境などでマイグレーションを実行する際に db:migrate ではなく、 db:migrate:primary を使う • pixivコミックではcapistranoを使ってマイグレーションを実行しているため、 migration_commandにdb:migrate:primaryを設定してあげれば良い 14 # config/deploy.rb set :migration_command, 'db:migrate:primary'
15. pixivノベルのモデルを移植 app/models/novel/* にpixivノベル用の ARモデル定義を移植 15
16. pixivノベルのモデルを移植 pixivノベル用のモデルはNovelモジュール以下にまとめる形にする • 同じ名前のモデルがpixivコミック上に存在するため見分けるため • 今後を想定してtable_name_prefixを指定できるようにしておく 16 module Novel def self.table_name_prefix '' end end
17. pixivノベルのモデルを移植 • Novel::ApplicationRecordを作成 • connects_toを使用してpixivノベル用のDBへ接続設定を追加 17 class Novel::ApplicationRecord < ActiveRecord::Base self.abstract_class = true connects_to database: {writing: :novel, reading: :novel_replica} # … end
18. 18 class Novel::ApplicationRecord < ActiveRecord::Base # … module ClassMethods def with_writable(&block) ActiveRecord::Base.connected_to(role: :writing, &block) end # novelのプライマリDBに接続しトランザクションを開始する def transaction_with(&block) ActiveRecord::Base.connected_to(role: :writing) do ActiveRecord::Base.transaction(&block) end end end extend ClassMethods end
19. pixivノベルのモデルを移植 19 # 書き込み用のDBに接続する場合 Novel::ApplicationRecord.with_writable do # このブロック内では書き込み用のDBに接続される end # トランザクションを貼る場合 Novel::ApplicationRecord.transaction_with do # … end
20. pixivコミックに実装を移植 • 基本的には愚直に実装を移していくしかない ◦ 可能な限り円滑に実装をすすめるため、設計上の方針だけ設定 20
21. pixivコミックに実装を移植 同じ機能はできるだけpixivコミックのAPIレスポンスに形式を合わせる 21 • pixivコミックとpixivノベルで同じような機能を扱っている部分が多い • pixivコミックではUIコンポーネントとAPIレスポンスの型が対応していて、 レスポンスの型が合っていればクライアント側の改修が容易になる
22. pixivコミックに実装を移植 pixivコミックでもpixivノベルでもバナー機能に差はないので同じレスポンスの型 • トップバナーはpixivコミックでもpixivノベルでも画像+リンクで表現できる 22 { "image_url": "https://www.example.com/banner.png", "width": 600, "height": 300, "in_app": true, "url": "https://comic.pixiv.net/link_url" }
23. pixivコミックに実装を移植 合わない場合は仕方がないので専用のレスポンス型を作る • pixivコミックでは一覧したいときは表紙のみを表示していた • pixivノベルは表紙に加えてあらすじを表示したい 23
24. まとめ • 複数DB機能を用いて、2つのRailsプロジェクトの統合を進めている • DBのマイグレーションを管理する方法を決めておく必要がある • モジュールによってネームスペースを切ってモデルを管理するとわかりやすい • 機能の移植自体は愚直にやることになるが今回はAPIの設計を工夫した 24
25. ご清聴ありがとうございました 25