こんにちは！いい生活エンジニア採用・広報担当の黒江です🍉

今回も前回に引き続き、SRE 部の隆辻さんと CTO 兼 SRE 部の部長でもある松崎さんに、当社の開発を支える SRE 部について語ってもらいました💬

今回の対談は 3 つの記事に分けてご紹介させていただきます。
こちらの記事は中編です！
前編の記事は以下よりご覧ください💁‍♀️

新しい CI システムへの移行

インターンシップで CI システムの導入に携わる

松崎（以下 松崎）：
隆辻が中心に取り組んでいる CI / CD については、実は彼がサービス基盤システム部にいた時代から関係しているんですよね。

当時の CI / CD の仕組みは正直あんまりイケてなかったんだよね。
そんな中、セルフホスティングしてる GitLab 上で、いわゆるコードをビルドする CI の部分をいい感じにしようっていう動きがあって、当時ちょっと巷で流行ってた Drone を使ってみることになったんだよね。

SRE 部になる前に Drone を導入したと思うんだけど、導入したのはいつ頃だったっけ？

隆辻（以下 隆辻）：
2018 年にいい生活のインターンに参加したときに、当時のチームリーダーから「うちのプロダクトチームの中で新しい CI システムを使いたいから、ちょっとテストしてくれない？」 と言われたのが、Drone 導入に携わるきっかけでした。

そこで導入する検証までをやったタイミングでインターンが終わったんですけど、その後いい生活の社内で本格的に使われ始めて、僕が 2020 年に入社したときにもまだ使われていましたね。

ただ、導入から数年経ったことでいくつか問題が目立ってきていました。

一つはユーザーが増えたことで、ビルドが始まるまでの時間が長くなってしまっていました。

Drone による CI の実行は、コード変更によるビルド要求が来たらそれを待ち行列の中に入れていって、前から一つずつ順に処理していくようになっていました。
この待ち行列に入るものが多くなってきたことによって、後から入ってきたものがなかなか実行されないことが増えてしまっていました。
結果として、修正がリポジトリに反映されてから、CI が実行されるまでに 20 分ぐらいかかるという状態になってしまっていました。

CI の目的は、修正したコードがプロダクトチームのコーディング規約に反していないことや、テストを通じて機能的にはデグレーションを起こしていないことを確認すること、ビルドがちゃんとできるか確認をすることです。

CI の実行までの待ち時間が長くなると、開発者が待ってられず他の作業に取りかかり始めたころになって、ソースコードの修正に対する検証がようやく行われて結果が通知される状態になってしまいます。
開発者の立場からすると「もう別のことやっているのに、今頃それわかるのかよ……」と感じさせてしまうような、悪い状況でした。

もう一つは、そもそも CI を動かしているサーバーのスペックの増強が難しいという問題です。

結果として、どうしても実行そのものにとても時間がかかってしまうケースがありました。
最悪のケースだと実行に 2 時間ぐらいかかることもありましたね。
でも、開発メンバーみんながそれを普通だと思い込んでいて、「2 時間かかったけどできたからいいや」って思っちゃってたという現状があったんですね。

でもそれは、あまりよくない状況で。
何がよくないかというと、2 時間もかかっているということは、その間は行った修正に誤りがないか確認できないということです。
本当は、自動化することで、問題がないことを早く確認できることが嬉しかったはずのに、そうではない状況になってしまっていて。

松崎：
Drone よりも前は、この界隈だと老舗ソフトウェアの一つの Jenkins を使っていました。

Jenkins は世界中で使われていて、ユーザーも多くメンテナンスももちろんされているんだけど、仕組みとしてあまりモダンではないんですよね。

なので、「Jenkins ではない、もうちょっとモダンなやつやろうぜ」って言って取り組み始めたのが Drone でした。
隆辻がインターンで検証した後、2019 年あたりに「一通り使えるそうだから導入しよう」となったんですよね。

Drone の良くなかったところは、さっきちょっと隆辻も話していたけど、並列に実行できないこと。
どんどん前詰めされちゃうから、みんなが使えば使うほど詰まっていって、その行列がなかなか解消されない。

ビルドする仕組みを丸々もう一つ増やせば、もちろん並列化できなくはないです。
でも、そうしたら「このプロダクトは 1 番レーン」「こっちは 2 番レーンにしよ」みたいに指定する必要が出てきてしまいます。
ビルドするものがどんどん増えていく度に、負荷状況を見ながらどれを何番レーンに割り当てるかを考えなきゃいけないわけですね。

なので、小さく始めた時期は良かったんだけど、こういった問題もあって、Drone でこの先もやっていくのはちょっと厳しいなと。

もちろん Drone 自体の新しいバージョンもあったものの、大きくバージョンアップしているので新バージョンに乗せ換えるのも大変ということもあり、もう 1 回新しいビルドシステムを導入する方針になりました。

GitLab CI を導入し開発者体験をよりよく

隆辻：
入社時にサービス基盤システム部に入って、そういった「直さなきゃいけないよね」という話もあったので、「隆辻くんはインターンのときの時も CI やっていたし、何か CI システムを新しくすることを検証してみて」というタスクをもらいました。

そこで複数の CI システムを検証して、最終的に僕らが使ってる GitLab に CI / CD を実現するための機能である GitLab CI が提供されているんでそれを使いましょう、となりました。

そして実際に Drone から GitLab CI に移行していく作業を進めて、1 年ぐらいかけて移行が完了しました。

その結果、最初に言った「実行まですごい時間かかってしまう問題」がだんだん無くなってきて、プロダクトチームにとっても信頼できるツールになったんじゃないかなと思います。

松崎：
GitLab CI の検証がサービス基盤システム部時代で、間に 1 年ほどブランクがあった後、実際の移行開始がちょうどSRE部発足タイミングぐらいだったかな。

SRE 部の 1 年目の仕事として、使っているビルドシステム、CI / CD のシステムを、Drone から GitLab CI へ実行基盤を新しく整備したんだよね。

隆辻：
そうですね。プロダクトチームに入って、使い方を確認して、「これから新しくどうやって使うか」を考えてやったって感じですね。

並列実行に関しては、ある程度いろんな人が同時に実行できる状態を作りました。

CI を使いたい人が増えたときに、体験が悪い、待たされる状況を防げるようになったのは大きいポイントだと思いますね。
あとは、いろいろと新しいシステムに変えたことで、できるようになったことも多いので、「CI のシステムを開発者にとってより使いやすくする」というミッションを達成できたと思います。

松崎：
プロダクトによっては、まだ Jenkins でビルドしているチームもあるけど、全体的には GitLab CI で動いてるものが多いよね。

隆辻：
そうですね。
社内で実行される CI の大半は GitLab CI に移行しきっているという状態で、週に 10,000 件程度のジョブが GitLab CI によって実行されてるのかな、という感じです。

また、以前に比べて、実行基盤の問題でそもそも実行ができないといったエラーもかなり減りました。

松崎：
あとは詰まることがなくなったのが大きいよね。

隆辻：
そうですね。開発者がソースコードの変更をアップロードしたら、すぐに実行されるようになったことが非常に大きいですね。
あとは CI を使ったリリースにおける待ち時間が従来だと大きい問題でしたが、それもだいぶ解消されています。

そういうことも含めて、「ソフトウェアの修正をより早くお客様に届けるために、僕らのエンジニアリングのパワーでそれを支援していく」というSRE部として一番大事にやっていっている活動を、うまく達成できるようになったと思いますね。

最終的に僕らの目的は、プロダクトチームが「プロダクトの新しい修正を考えて、それを実装して顧客に届ける」というサイクルをいかに早く、かつ問題なく回すことを支援していくということです。
なのでそのための活動の一つが、CI / CD の改善だったと思います。
新しい CI システムに載せ替えた後も、より効率的にするために、まだやらなきゃいけないことはいっぱいありますね。

プロダクトチームに対していかに安定して提供できるか

松崎：
今はどちらかというとビルドの仕方そのものや、ビルドスクリプト自体の改善提案などをしているよね。
あと最近のトピックスでいうと、ビルド実行に必要なメモリが大きくなってきてるというのがあるかな。

これはさっきの自動テスト整備に近い文脈もちょっと絡んできてるんです。
品質保証部の自動テストを進めていく過程で、E2E テスト以外にも、コードレベルのテスト実行やそのカバレッジなどもちゃんと評価したいという話が出てきて。
その流れもあって、いわゆるユニットテストのコードが以前よりもかなり増えてるんですよね。

「CI で回せるなら、テストもカバレッジ計測もガンガン詰め込んでいこう」みたいな良い傾向なんだけど、いろいろなことをしているので、パイプライン自体が担ってる責任も大きくなっていて、ビルドにかかるメモリが結構大きくなってる。
加えて、回転数というかビルド実行数自体も増えてるし。

隆辻：
従来の Drone に比べると、今使っている GitLab CI の実行基盤は、SRE 部が管理するクラウド環境で実行しているんで、結構簡単にスケールできるようになっています。
そこも、CI システムを切り替えてよかったという点ですね。

その一方で僕らが実行基盤を提供してるので、その分の責務があります。
プロダクトチームに対して、いかにビルド環境を安定して提供できるかということです。

例えば、特定のチームが使いすぎてしまったり、多くのキャパシティを利用するようなビルドを実行するときに「ちょっと待って」と言いに行くのも僕らの仕事ですね。
どうしても共有のリソースを提供している以上、どこかのチームが使いすぎることはあり得ます。

それを防いで、いろんなチームがそれぞれ同じように使える、かつそれが満足できるだけのスペックで使える状況を維持していくことは、僕らが仕組みを提供していく以上は続けていく必要がありますね。

松崎：
ビルド時間自体は、以前より確実に短くなってるはずなので、実際プロダクトチームとしての利便性は上がってるはずだから、ここは引き続き支援していく感じだよね。

あと、CI / CD だけをやるわけじゃなくて、開発を支えるいろんな仕組みを準備し、伴走して、チームで使ってもらえる状態に持っていくことが大事かな。
「困ってることあったら聞いてください」みたいにやっているのもそう言う理由。

隆辻：
そうですね。最終的に DevOps のサイクルといわれるものを、チームが主体となってうまく回してくれたらと思います。
品質を保ちながらリリースのサイクルを早めていくことなどに、意識を向けていけるような環境作りをしていくという感じですね。

ツールをうまく使う知識や導入する意義を伝える

ツールの導入から活用までサポートする

松崎：
今って「こういうツールがあったらこうできるじゃん」みたいなアイディアや技術は世の中にいっぱいあるし、僕らもそのアンテナを広げているじゃない。
でも、そのツールを導入することそのものよりは、うまく使ってもらえるように「なぜこれを使った方がいいのか」という意義をチームにインストールすることのほうが結構大変じゃない？

隆辻：
本当にそう思います。
結局 SRE 部が「新しいツールを使ってください」とただ言うだけでは、もちろん駄目なんですよね。

プロダクトチームが主体となって取り組めるような環境をどう作っていくか、かつプロダクトチーム自身がその知識などを持って新しいプラクティスを見つけていけるような状態を作るかどうかが大事です。
実際にプロダクトチームに対して、うまく知識をインプットするのはやっぱり難しくて課題ですね。

松崎：
SRE 部の 3 人で役割を分担しているよね。

1 人はチームにそのナレッジをインストールする担当。
もう 1 人は仕組みをうまく活用してもらうのを伴走する担当。
隆辻はツールを使いやすくするための整備と、品質保証部の自動テストのフォロー、と。

で、3 人で協力して、さまざまな角度から、チームに「こういう風にやると、こんな良くなるでしょ」というのを、体験してもらっています。

実際に体験をしてもらいながら知識をインプットする

黒江：
プロダクトチームに知識をインプットするときは実際に「こうやってやるんだよ」って画面共有しながら教えているんですか？

隆辻：
そうです。「この時間はこれに使いましょう」っていう風にチームの人とあらかじめ話し合って、イベントを主催し、ファシリテーションをしています。

松崎：
イベントを通じて、「以前よりも楽になりました！」みたいに実感してもらいながら、馴染ませていっている感じかな。

隆辻：
SRE として、単にそのシステムを何か運用するだけでなく、そういうファシリテーションなども含めて、チームにうまく知識を移していくことの両方が必要です。

両方の要素が組み合わさらないと、ツールの使い方や、あるいは世に知られている開発のプラクティスを活用できるんじゃないかという提案を、チームに実践してもらうみたいな活動の実現は難しいです。

なので、そういう風にチームの中に入って、イベントなどを主催して、チームに知識を落としていくみたいな作業ができる人はもちろん必要だなと思いますね。

そういう人がもう少し増えると、SRE 部の活動もわかりやすくなると思いますが……。

松崎：
今は最小人数でやっているのですぐには厳しいかな。
その点、その品質保証部はテストを自動化しないと、自分たちの業務量が大変なことになると分かっているから、より切迫感を持ってしっかりやってるよね。

隆辻：
必要性から生まれる需要と、それとは別に何か目指したい先があるから生まれる需要があって、今は前者が強いですね。
後者がもっと増えてくれると、組織としては健全に回っていける状態だと思うので、それを目指せるようにやっていきたいですね。

松崎：
やっぱりどうしても「目の前にある課題を何とかしないと」の方にエネルギーがかかってしまうよね。
だから、品質保証部のほうが自動テストの環境をよくするという目的があるので、他より意欲的に見えちゃうよね。

プロダクトチームの人たちは、確かにプラスアルファで便利になるのは分かっているんだけど、とても困っているわけでもない。
それに取り組むことで、どの程度自分たちの開発サイクルが良くなるか、イメージができていないところもあって、その部分にエネルギーを割こうという動きが出にくかったりはする。

開発してる最中は、そういうことがあんまり気にならないんですよね。
ただ、いざでき上がってテストやデプロイをするときに、はたと気づくことがあるけど。

あとは障害が起きて切り戻しを迅速にしようとしたときや、緊急でリリースしなきゃいけないときに、この辺が整備されてないと結構大変だったりして。
実際に体験してみないとわからないこともあるので、少しずついろんなところで布教活動を進めていきたいね。

隆辻：
そうですね。のど元過ぎれば熱さを忘れるじゃないですけど、やっぱり1回終わったら、解決できたから OK と思ってしまいます。
でもそれを次に生かすときに、どのようなプランがとれるかという選択肢を提供できるといいなと思います。
仕組みやツールの整備が落ち着いたら取り組んでいきたいです。

松崎：
仕組みの整備がまだ足りてないところなどもあるので、仕組みを少しずつ整理するところがメインだものね。
今のステージは、「どんどん新しいもの活用する」という「次の段階」に行くために、さっきのコード引っ越しみたいな「古いものから新しいものに移行していく作業」の終盤戦ですね。

隆辻：
ソースコードの移行は、僕らのプロダクトの最もコアになる部分なので、下手にいじると影響が大きくなってしまう問題があります。
そこをうまくプロダクトチームと調整しながらやるのが大変ですね。

松崎：
開発が止まらないようにする必要があるので、開発を普段と同じように継続させながら、コードを移しつつ移行先でも前と同じように作業が継続できる必要がある。
いかにシームレスに移行するか、ってあたりは結構腐心してるよね。
移行したその日に何かトラブルが発生して、緊急で修正してデプロイ・リリースしなきゃとなったときに、その活動ができなかったら大変だからね。

続きが気になるところですが、今回はここまでとさせていただきます！
読んでいただき、ありがとうございました😊

いい生活では新卒 / キャリア採用を行っております🧑‍💻
以下から気軽にご応募ください！

また、いい生活公式note の「いいnote」のフォローもお願いいたします！

それでは今回はこちらで失礼します！
次回の記事は松崎さんと隆辻さんの対談の最終回です！

撮影：杉山 泰之