技術的負債とどう向き合う？
広木：では次のテーマにいきましょう。弊社の技術的負債について。デプロイパイプラインの自慢をさせてくださいってやつですね。どうでしょう？
横路：マイクロサービスって「最初からマイクロサービスにするな」って言われるでしょ？ うちには育ち切ったモノリスがあります！
広木：すばらしい！
横路：ぜんぜん自慢できることじゃないんですけど。サービスが8個くらいあるんですが、最初の会計サービスは丸々と太っていて、もうフォアグラですね。だいたいRailsなんですが、クックパッドのコアの部分も相当じゃないですか。あれの半分くらいはあると思います。
なので、モデルもコントローラーの数もだいたい数千ですね。フロントエンドのコードも数十万から100万行くらいですね。それをこれからしっかりマイクロサービス化していけるのがうちの強みだと思ってます。
マイクロサービスが役立つのはだいたいあれですね。エンジニアが100人を超えて、しかも500人、1000人を目指す企業がしっかり使うべきだと思います。まさにうちはそれにぴったり当てはまります。
今、DevOpsをつよつよなエンジニアでやろうとしているので、その人たちと働けるのはすごく魅力的かなと思います。たとえばGoogleでGoogleマップを作っていたメンバーがマイクロサービス基盤を作っています。
あとは、自動テストやDevOpsのパイプライン、継続的デリバリーなどは、ヤフーのテスト基盤を牽引していた人や、あとはソフトウェアエンジニアリングテストで超有名な人が、今月から続々入社されています。
今、ヤフーや楽天のようなITの大企業がここから誕生するということで、チャレンジしたい人がいればぜひ今のうちにチャレンジしてもらえればいいかなと思っています！
広木：きれいに自慢されてしまいました。
（会場笑）
横路：自慢しろって書いてあったから（笑）。
広木：すばらしいですね。テストカバレッジとかどのくらいなんですか？
横路：テストカバレッジは二大モノリスがだいたい70-80くらい。
広木：お！ すごい。すばらしい。
横路：最近上がってきてます。だいたいCircleCIで、30並列で15分くらいです。
広木：お～すばらしい！
横路：札束で殴れる時代が来たのが本当に嬉しくてですね。ありがたいことです。
（会場笑）
気づいたら負債を返していく
広木：どうでしょう？
上田：うちは社長が作った最初のアプリを全部1回捨てたと話しましたが、そのあと僕が作ったやつもさらに1回捨てて、アーキテクチャを更新したりしました。僕がエンジニアでそういうことが気になるので、気がついたら負債を返していくという感じです。
ただ、デプロイパイプラインというか、CI、CDはすごく弱くて。エンジニアの人数が少ないし、最初のころからずっと1人でやっているので、自動化しないでも自分のところでAPIを叩けば終わり、みたいな感じでした。
今、人数を増やすにあたって少しずつCircleCIを導入しているのですが、テストもアプリ側はほぼないですし、サーバー側もちょっとしかないので、そこが弱いです。デプロイ周りは自慢できないというか、昨日もバグを出しました。
（会場笑）
広木：すばらしい。赤裸々！ こういうコーナーです。これは伸びしろしかない（笑）。
巨大なリポジトリを分割する
徳永：うちの技術的負債は似たような話なんですが、もう4年くらいやっているサービスなので、かなり大きいモノリシックなのが1リポジトリでありまして。
かなり大きくなってしまっています。クローンすると8分とか。
横路：やばい！（笑）。
徳永：けっこうやばいんですけど。
横路：それうちも負けてる。
徳永：リポジトリのサイズが大きいのは些細な理由なんですけど、それを分けにかかっています。セルフコンテインドシステムみたいな思想のもとでやっていまして。
マイクロサービスといえばマイクロサービスなんですが、どちらかと言うとコンポーネントごとに切るよりも、チームごとに、チームありきで分けるみたいな思想でやっています。
おもしろいなと思うのが、エンジニアが入ってやるんですが、フロントで最近めっちゃつよつよな人たちがガンガン入って来ていまして。Vue.jsの日本人コミッターのkazuponさんが入ったりとか。
その同じのレイヤーの人があと2、3人入っていて、フロントの分割は進んでいますそして、これからうちのKARTEのコアであるトラッキングやアナライジングの部分を同じように分割して行きます。
それを数ヶ月でやるロードマップになっていて、ずれる可能性はとてもありますが、うちに来てもらえると、そのあたりの負債を最強のメンバーで返す、みたいなことができてすごくおもしろいかなと思います。
あとはデプロイパイプライン自慢なんですが、Spinnakerというツールをいち早く導入しています。去年のbuildersconで僕と同じチームの松井が登壇してSpinnakerの話をしているのですが、そういった新しいツールを使って大規模なデプロイを最初期からやっています。
うちは開発環境にかなり力を入れていて、エンジニア組織なので良くなってきている感じです。ただDevOpsのように専門の人がいるというよりも、気づいた人が解きにいく、やりたい人がやる、みたいなかたちです。ストレスドリブンでやる感じですね。
自慢なんですけど、先週フロントエンドビルドがめちゃめちゃ遅いという問題がありまして、40分くらいかかっちゃうんですよ。それがデプロイのたびに走るのでやってられないということで、17分くらいまで短縮しました。
広木：すばらしい。
徳永：それまではストレスドリブンみたいな感じで、やりたいやつがやる、みたいな感じで保たれていました。
広木：いいですね。Node Modulesもめっちゃ重い感じですか？
徳永：Node Modulesもけっこう重いですし、なんやかんやの負債というか、いらないものが入っていたりとか（笑）。
広木：あ～ありますよね。
徳永：やはり歴史はかなり長いので、そういったことがある感じですね。
広木：なるほど、ありがとうございます。個性が出てきましたね。
モブデプロイを行う理由
五十嵐：あまり個性的な話はありませんが、我々も4年くらいサービスを続けている中で、まだモノリシック中心なサービスになっています。
ですが技術的負債かと言うとまだ負債とは感じるほどボトルネックにはなっていません。
初期から強いエンジニアがいたので、社長が書いたコードが残ったりするといったこともなく、1回大きくチェンジしたことはありましたが、比較的コンスタントに解消してきました。いまいまはそこらへんの重さはないんですが、将来的にはそういう問題が出るんだろうなとは感じています。
ですが、マイクロサービス化なのか、早すぎる最適化もよくないと思いつつ、模索しているところではあります。ほかに技術的な負債を感じるところってありましたっけ？
原田：う～ん？ いっぱいありますけど。
五十嵐：あ、いっぱいあります？（笑）。あとはデプロイパイプラインのところで言うと、比較的初期から普通にCIを通して自動デプロイみたいなものを構築していたのでスタンダードなところはできていました。
開発のフローで言うとgit-flowで2週間に1回のペースで大きめなリリースをしていて、hotfixは日々リリースするようなデプロイフローにしています。
「2週間に1回くらいはみんなで盛り上がろうぜ」みたいなノリを大切にしています。モブプロじゃなくてモブデプロイみたいな感じで（笑）、巨大なディスプレイに写して、エンターを押して「お～」みたいな（笑）。
一部マニュアルなオペレーションがある中で各担当者に任せるのではなく、間違えないようにみんなでオペレーションを見ながら、「無事リリースしましたね」みたいな感じでやっています。
盛り上げる目的もありますが、それより事故防止とか、リリースデプロイのノウハウを共通化しようという目的ではあります。自動化しすぎないというかちゃんと温かみみたいなところをあえて残したいと思っています。
モブデプロイは何時から？
広木：ちなみにオープンロジさんの場合、24/365じゃなきゃいけない部分はどのくらいありますか？
五十嵐：そういう意味だと、現状、倉庫さんや荷主さんが主に稼働するのは、だいたい朝の6時過ぎから18時か19時。12時間くらいがマストで稼働していなければいけません。
それ以外はある程度融通が利いていて、リリースでは瞬断も発生しています。日々のリリースはなるべく瞬断がないようにしていますが、2週間に1回のリリースではメンテナンス時間を設けて、ある程度停止が許されるようなかたちで安全性を保ちつつ、リリースすることはできています。
ですが、今後より海外で使われるようになっていくとそれも難しくなってくるとは思うので、現状はそういったバランス感ですかね。
広木：今、モブデプロイは何時に当てていますか？
五十嵐：夜の19時から20時くらいですね。配送会社さんの集荷がだいたい15時から17時とかなので。それをやるとあとは締めの業務で、遅くとも18時には倉庫業務が終わるので、その後からですね。
広木：なるほどなるほど。
横路：リアルな裏側を（笑）。
（会場笑）
