$30 off During Our Annual Pro Sale. View Details »

巨大なRailsアプリケーションを「普通」にするための取り組み

 巨大なRailsアプリケーションを「普通」にするための取り組み

Kazuhito Hokamura

February 06, 2019
Tweet

More Decks by Kazuhito Hokamura

Other Decks in Technology

Transcript

  1. 巨大なRailsアプリケーションを
    「普通」にするための取り組み
    2019/02/06
    Repro Tech Meetup
    @hokaccha

    View Slide

  2. 自己紹介
    •@hokaccha
    •Cookpad Inc.
    •Nodebrew, Adventar, Bdash

    View Slide

  3. View Slide

  4. 3BJMTʹͳͬͯ೥Ҏ্͕ܦա

    View Slide

  5. •コードを変更すると意図しないところが壊れる。例えばウェブサービスをいじるとガラケーの認証が壊れる。
    •ライブラリが古かったとしても依存が多すぎて気軽に更新できない。
    •実行環境が非常に複雑かつ特殊で、迂闊にデータベースを追加したりできない。
    •普通のツールが動かない。例えばコードカバレージが取れない、並列テストが動かない。
    •ObjectクラスやStringクラスのような非常に基本的なクラスが改変されており、普通の動きをしない。
    •あるコードのオーナーが誰かわからない。例えばuserリソースのAPIを変更したくても誰にも相談できない。
    •開発者が多すぎて、改善系のpull requestを作ると頻繁にコンフリクトする
    •I/Oの激しいシステムを追加するためにDynamoDBを使いたいと思ったとしても、 AWS-SDKのバージョンが古いのでまずは
    SDKのバージョンを更新するのに1ヶ月かかる
    •テストが遅いので検証にも時間がかかり、そのあいだに別のpullreqがマージされてコンフリクト
    •実装を進めていくと既存のクラスに変更が必要そうなことがわかってきたがオーナーが誰かはわからない
    •がんばって実装してみたが触ってもいないバッチのCIが通らない
    •ようやく理由がわかって直してデプロイしたらなぜかガラケーサイトが落ちた
    •etc...................
    IUUQTUFDIMJGFDPPLQBEDPNFOUSZPEBJCBTUSBUFHZΑΓൈਮ

    View Slide

  6. 普通のRailsに戻りたい

    View Slide

  7. 改善プロジェクトの発足
    •2017年に @aamine が立ち上げ、お台場プロジェクト
    と名付けられる
    •コツコツとやってきてようやく成果が出始めてきた
    •今年から専任でやるチームとして分離したのでさらに
    加速する予定

    View Slide

  8. お台場プロジェクトの取り組み
    •システム分離
    •機能削除
    •コード削減
    •レガシーシステムからの脱却 ← 今日の話はこれ

    View Slide

  9. ここで言うレガシーとは
    •社内外問わずクックパッドのレシピサービス以外では

    ほぼ使われていないシステムやライブラリ
    •学習コスト、メンテナンスコストともに高い
    •最新の機能やエコシステムの恩恵を受けられない

    View Slide

  10. 今日の話
    •Machinist を FactoryBot に置き換えている話
    •RRRSpec をやめた話
    •hako 化している話

    View Slide

  11. Machinist → FactoryBot

    View Slide

  12. Machinist とは
    •テストの用のデータを作るためのライブラリ
    •5、6年前にメンテナンスが止まった
    •レシピサービスではずっと Machinist 1系に

    モンキーパッチをあてながら使っていた

    View Slide

  13. @amatsuda 曰く
    「断言しますが、Rails 4.2 と一緒に Machinist 1 を使ってい
    るプロジェクトは世界中でもこのプロジェクトだけのはず」

    View Slide

  14. FactoryBot
    •テストデータ作成系ではデファクトスタンダード

    なライブラリ
    •クックパッドでもレシピサービス以外は

    FactoryBot(or FactoryGirl)を使っている

    View Slide

  15. 移行したいが Machinist

    で書かれた大量のコードどうすんの...

    View Slide

  16. Machinist
    Recipe.blueprint do
    title { 'recipe title' }
    description { 'recipe description' }
    user { User.make }
    end
    Recipe.make(title: 'foo')

    View Slide

  17. FactoryBot
    FactoryBot.define do
    factory :recipe do
    title { 'recipe title' }
    description { 'recipe description' }
    user
    end
    end
    FactoryBot.create(:recipe, title: 'foo')

    View Slide

  18. ‼いけそう‼

    View Slide

  19. 移行手順
    •FactoryBot が Machinist の文法を喋れるようにする
    ラッパーを作る
    •Machinist の定義(blueprints)を FactoryBot の定義
    (factories)に置き換える
    •Machinist 互換レイヤーを撤去

    View Slide

  20. 進捗
    •@amatsuda がほぼ一人で進めてくれている
    •新規のテストは FactoryBot で書ける状態
    •古い Machinist のコードを順次書き換えていってる中

    View Slide

  21. RRRSpec

    View Slide

  22. 背景
    •1台のマシンで並列でテストを実行しても数十分かかる
    (当時の現実的なマシンスペックで)
    •テストの実行時間を10分以内に抑えたい
    •コストも最小限に抑えたい

    View Slide

  23. RRRSpec
    •複数台で並列に RSpec を実行できる

    分散テスト実行システム
    •実行するマシンはスポットインスタンスを使い

    自動でスケールされる
    •スポットインスタンスが途中で落ちたときのための

    リトライ機構なども備えている

    View Slide

  24. View Slide

  25. 時は流れ
    •高性能なスペックのマシンが安価になってきた
    •SpotFleet などの環境も整ってきた
    •コードもがんばって減らしてる
    •RRRSpec なくしてもいけるんじゃない?

    View Slide

  26. やってみた
    •c5.2xlarge 8並列: 約22分
    •c5.4xlarge 16並列: 約11分
    •c5.9xlarge 32並列: 約7分

    View Slide

  27. ‼いける‼

    View Slide

  28. というわけで RRRSpec 引退
    •c5.9xlarge(スポットインスタンス)で36並列で実行
    •並列実行には parallel_tests を利用
    •開発環境でのテスト実行は pull-request Builder で代替
    •安定化のために rspec-retry を利用

    View Slide

  29. View Slide

  30. hako化

    View Slide

  31. 現在のデプロイ
    •sorah/mamiya
    ‣ serf を利用した高速でスケーラブルなデプロイツール
    ‣ CI 中にパッケージ作成や配布などの処理を行う
    ‣ CI が通って開発者がデプロイを実行したときは切り替えを行うのみ

    View Slide

  32. •Dockerの登場によりデプロイのフローは大きく変わった
    •クックパッドでもほぼすべてのアプリケーションが

    Docker/ECSで動いている
    昨今のデプロイ

    View Slide

  33. View Slide

  34. hako
    •Dockerコンテナのデプロイツール
    ‣ 現在は ECS のみに対応
    •クックパッドではほとんどのアプリケーションが

    hako でデプロイされている
    •ただしレシピサービスを除く

    View Slide

  35. hakoに乗ると
    • 統合された管理コンソールが使える
    • Dockerを利用したバッチジョブの実行ができる
    • 用意されている様々なサイドカーコンテナが利用できる
    • などなど、他にも便利な機能に乗っかれる
    ‣ 逆にいうとhakoに乗らないとこれらを独自で作る必要がある

    View Slide

  36. hako化への道のり
    •symlink が大量にあって docker build がつらい
    ‣ rsync --copy-links で乗り切る
    •Spreadsheetで管理されていた秘匿値の移行
    ‣ がんばって Parameter Store に移行
    •古の fluentd の設定を読み解く
    •一部のサーバーでcronが動いてたりする

    View Slide

  37. 進捗
    •バッチが一部 hako で動くようになった
    •API サーバーがもうすぐ動きそう
    •今年中には全アプリケーション移行予定

    View Slide

  38. まとめ

    View Slide

  39. View Slide

  40. 次回予告 (3/23 Railsdm)
    •システム分離
    •機能削除
    •コード削減

    View Slide

  41. We are hiring!

    View Slide