cookpad_allの歴史 まずは、巨大アプリケーションがいくつも詰まっているcookpad_allというリポジトリですね。それについての今昔を紹介したいと思います。 前提知識なんですが、cookpad_allとはcookpad.comの裏側を支える巨大なRailsアプリケーションが複数ぶち込まれていて、その共有ロジックをまとめたsharedというgemが含まれているリポジトリです。 cookpad_all内の各アプリケーションはほとんどモデルとDBの共有によりロジックの共有をしていて、まあDB共有いいですよね。 （会場笑） ね、早いし。あんまり落ちたりしないし。あるとき限界が来るまでは。 ひと昔前のクックパッドの開発風景は、だいたい社内のエンジニアみんながcookpad_allのアプリケーションに対してやたらめったらコミットしていて、みんなそこで開発していっている状況でした。 開発基盤やインフラのリソースもcookpad_allに集中しています。とにかくみんなで巨大なモノリシックRailsアプリをどんどん整備していって。これはRubyやRailsのコミッターをやっている松田明さんが2015年にオレゴンで開催されたRuby on Alesというイベントで発表してきた内容です。 世界最大のRailsモノリスということで、クックパッドという会社が超巨大なRailsアプリケーションをどうやってメンテナンスしているかみたいなタイトルで発表しました。これがクックパッドのモノリシックRailsアプリ最盛期みたいな時期でした。

お台場プロジェクトが誕生 というわけで、お台場プロジェクトを実際にどういう感じに実践していったかというを紹介したいなと思います。 実際にやったこと。 こんな感じで、開発メトリクスを定点観測して、いらないシステムを削除したり、システムをcookpad_allから分割していきました。あとコードを削除していろいろやってきました。 詳細に触れていきます。まず開発メトリクスの定点観測。これに関してはtechlifeという技術ブログですでに紹介しているところではあるんですけれども。 コード削除などをいい感じにしていくには、まず今がどれくらいダメで、日々どれくらいいい感じにできているのかを可視化しなければいけないと思いました。ですので、まずダッシュボードを作って可視化できるようにしました。 実際にcookpad_allの改善、お台場プロジェクトでどのようにやってきたのか、最近までの数字を出しています。こういったことをやってきました。 昔はCIで10分くらいかかっていたのが、最近では5分くらいまで短縮できたとか。一番短いやつだと7分くらいかかっていたのが3分くらいになったとか。そのくらいになっりました。 これも可視化していたおかげで、日々こうして「このへんをがっつりやっていったことで、これ時間短縮できたんだな」みたいな。日々自分たちの心を慰めながら改善を進めることができました。 これはアプリのロード時間ですね。 rails sをしてからちゃんと動き始めるくらいまで、という感じで考えてください。10秒くらいかかっていたのが4秒くらいまで短縮できています。 あとはCode Statistics、rails statsみたいなやつですね。 cookpad_allに含まれている一番巨大なRailsアプリであるcookpadは、コードラインで40万行くらいあったのが30万以下くらいに減っています。 こう示すと、一番ガクッと出てるところやこういうところに注目したくなる気持ちかもしれませんが、お台場プロジェクトに参画してやっていた身としては、日々ちょっとずつ下がっていってるところに注目してほしいです（笑）。 日常的に細かく削除していって、ちょっとずつでもちゃんとやっているという気持ちがこの図に出ていて、どちらかと言うとなだらかな曲線のほうが見ていて心が温かくなるという、そんな話ですね。 （会場笑）

日々モニタリングを行う rails statsの数字を出してみたんですけど小さくてあんまり見えないので、トータルのところだけ触れます。 cookpad_all内にはRailsアプリが今で4つ5つくらい入っているんですけれども、その中で一番巨大なcookpadというRailsアプリケーションの数字です。 ほかにも同等サイズのものが3つくらいあったりしますが、そのcookpadのやつで2017年7月1日時点でトータルで54万行ありました。それが今朝測ってきた数字だと34万行ということで、20万行くらい減っているというですね。いやー、がんばりました。 書いたコード量で給料が決まるような会社だと、きっと僕はマイナス給料で会社にお金を数千万円払うとかそんな感じになってたのかなと。そうじゃなくてよかったです（笑）。しょうもないことを言いました。 （会場笑） これは依存gem数みたいなのを出していて、Gemfile.lockを見るだけで出せるので2011年頃まで遡って出してみました。まあおもしろ半分なんですが。 2017年7月ごろ、このころにちょっとだけそういうことを始めたので上限がたまに下がるところがあるんですが、そういう努力をしない限り、基本的にgem数はどんどん膨れ上がっていきます。Rails自体が依存するgem数なんかもすごく増えていってますし。 とあるgemを導入したいときに「あ～こっちのgemと依存関係だ」とか、みなさん感覚としてわかると思います。それは時間が経つと増えていく。昔はRailsももうちょっと素朴だったみたいでそういうのはあると思いますが、それが図に出ていて、減らすと減るという。減らすと減る？ 何言ってんだろうな。 （会場笑） これはGemCollector、依存gemの最新度みたいなのを取っていて、これは社内にあるRubyアプリケーションの数値から相対的に出している数値です。 cookpad_allのRailsアプリケーションになにも触らなかったとしても、cookpad_allがRailsをアップグレードしない間にほかがRailsアップグレードしていくとどんどん数値が下がっていくという。そんなものになっています。 2017年7月ごろ、お台場プロジェクト発足と前後していますが、気持ちをもってエイっとbundleアップデートしたのが左側にガツンと上がっているところで。それまですごく少なかったのがちょっとずつ上がりました。 でもがんばらないとどんどん下がっていって、たまにがんばって上げて、みたいなことをやっています。毎月1日に上げるとか、そういうことをやるべきかもしれません。

2017年ごろのcookpad_allの構成 システム削除の話に入ります。cookpad_all内にある不要なシステムを削除していきます。これはとくに工夫はありません。がんばって削除です。 （会場笑） 2017年当初のcookpad_allの構成はこういう感じです。cookpadというアプリケーションは恐ろしいことにデプロイ先が4ヶ所くらいあったと。 嫌ですね。「これいらねぇよな」みたいな。ちょっといらなそうというのはわかっていたので、がんばって削除しました。 がんばって削除したら1個減りました（笑）。 （会場笑） 次にbackground worker、これは新しい仕組みがすでにあったのに残っていた非同期処理システムみたいなもので、それもがんばって削除しました。 もう1つ減った。まだ1個残ってるのが気になる。気になるけど、これはまた次のところで。

システムを正しく分割する 次にシステム分割をしていきます。システムを正しく分割する。DB共有はやっちゃいけないので、アプリ間はAPIとかそういったもので通信する。 pantryを分割します。 これはcookpad_all内で分割します。さっきの図は明らかにここに誘導していたんですが、こうなってたら普通こうしたほうがいいですよね、という感じに分割しました。1アプリ1デプロイ先という自然な状態になりました。 さまざまなマイクロサービスアプリに切り出していきました。これはもういろんな、いい感じに切り出していったというそれだけです。 そして、いろんなアプリを切り出していきました。特にどういうサイズで切り出すという明確な境界があるわけでもなく、機能群とかいい感じの……本当にいい感じのサイズで切り出していったとしか言いようがないですね（笑）。 （会場笑） ECS Clusterみたいな、そういうのはすでにあったのでそっちに載っけていきました。載せる先はマイクロサービス化の流れで整備されていたのでそこは困ることはありませんでした。 その中にmobileというのがありました。mobileといったら普通にスマホかな、みたいな感じですが、これはクックパッドでは携帯電話版向けサイト『モバれぴ』というものがございまして。 うちではまだアクティブに稼働していますので、それをやるmobileというアプリケーションなんですが、誰も開発していないんですね。メンテナンスくらいはしているんですが、アクティブな開発はしていない。作り直すのにブロッカーがなにもないからモダンな技術で作り直そうという意思決定をして、モダンな技術で作り直していきました。 というわけでcookpad_all内のアプリは4つになりました。