2019/07/01 【学生限定】Akatsuki Geek Live Vol.3【LT会：7/1（月）】 の発表資料です。

1. 大規模Railsアプリケーションを
バージョンアップするときのハマ
りどころ
河野 那緒

2. 自己紹介
 河野 那緒
 アカツキ新卒2期生（入社4年目）
 サーバーサイドエンジニア（Rails/AWS など）
 新卒の中で初めての子持ち

3. まえがき
 大規模（高負荷）なWebアプリケーションで起きること…

4. まえがき
 大規模（高負荷）なWebアプリケーションで起きること…
1台のサーバーでは
どんなに性能が高くても
負荷を受け止めきれない

5. ActiveRecord
（Rails内蔵ライブラリ）
アプリケーションサーバー
（EC2）
ロード
バランサー
データベース
水平分割／
レプリケーション
で負荷分散
Octopus
Gem
大規模Railsアプリケーションのインフラ基本構成例

6. 大規模になると
ハマりやすい
場所
• アプリケーションの処理ロジックを書きたい！
• ユーザーIDなどの条件に合わせて
データベースの保存先を変えたい！
さらに…
• データベースの構造変更をするときは
全部同時にやってほしい！
• 万一1台のデータベースが止まっても、
関係無い処理が詰まらないようにしたい
→増える要件に合わせて、より根本から
挙動を変えるGemや独自パッチが必要になる

7. Rails5.2で
ハマった場所
ActiveRecordのMigration
（データベース構造変更処理）の実装が変わった
class Migrator
class MigrationContext
class Migrator
クラスメソッド
- run メソッド
インスタンスメソッド
- run メソッド
インスタンスメソッド
- run メソッド
インスタンスメソッド
- run メソッド

8. 実際に
必要になった
修正箇所
1．Octopus側にバグがある。
データベースを作成するコマンドで、
Railsで必要なテーブル（schema_migrationsなど）
が、1つのデータベースにしか生成されない
→Octopusのライブラリで実装がバージョンアップ
対応が漏れていたので独自パッチ
マイグレーションを最初から実行すると、
Mysql2::Error: Table ‘XXX.schema_migrations’ doesn‘t exist

9. Rails5.2で
ハマった場所
2.独自パッチがOctopusの実装変更に阻まれる
class Migrator
class MigrationContext
class Migrator
クラスメソッド
- run メソッド
インスタンスメソッド
- run メソッド
インスタンスメソッド
- run メソッド
インスタンスメソッド
- run メソッドOctopusが複数DB対応
のため上書き
並列化のためモンキーパッチも
上書き…
データベースの接続先を共有しあって
いるので競合してしまい…失敗

10. 対処方法
1. MigratorではなくMigrationContextクラスを上書きしたい
→Octopus側の変更を打ち消すためのモンキーパッチも必要
→難易度が高く今後の保守性が大きく低下しそう…
2．Migrator.runメソッドに合わせて、スレッドごとに
Migratorクラスを複製したい
→dupではダメ
→deep_dupでもダメ
オブジェクトが複製不可能な場合、コピーせずそのまま返す罠
→そうとなればコピー＆ペースト
(Marshal.dump & Marshal.load)や

11. まとめ
 大規模なアプリケーションでは複数データベースの
使い分けが要
 本家がデータベースへの接続周りで実装を変えること
が多いので、対応Gemも変更やバグが起きやすい
 さらに高度な要件に応えるため独自パッチも多い。
RailsとOctopus両方の影響を受けるので、
バージョンアップのネックになりやすい。

12. さいごに
 次のRails6.0では公式に複数データベース対応を予定
 公式対応で嬉しい反面、既存のアプリケーションは大きな変更を伴う
→Octopus Gemとの別れ
→独自パッチ類の書き直し
次は最大の戦いが待っているかもしれない
To Be Continued…?