研究開発部 Architectグループ ML PlatformチームのKAZYこと新井です。ちなみに名古屋にある中部支店に所属です。
開発リードタイムを改善するためにGitHub ActionsでKubernetesのマニフェスト生成できるようにした話をします。
前後編の２つに分けて公開する予定で、今回は前編として全体像をお話します。
▼後編 buildersbox.corp-sansan.com
なお、本記事は【R&D DevOps通信】という連載記事のひとつです。
目次
背景
研究開発部の研究員とArchitectグループ
弊社の研究開発部はサービスのコアとなるアルゴリズムの研究と開発を行う研究員で大部分が構成されています。
いくつかの異なる分野で高い専門性を持つ研究員たちがそれぞれの専門分野で研究成果を上げ、Architectグループは研究員と協力しながら開発や運用における技術的な課題解決を推進しています。
また研究員による試行錯誤を増やし、継続的に素早くリリースするためのML/アプリケーション基盤の構築・推進を行っています。
研究員がアプリケーションのロジックをコンテナイメージとして作成し、インフラ作成、監視設定、CICD設定といった領域はArchitectグループが必要なサポートをできる開発体制を取ることが多いです。
またArchitectグループの人数は研究員と比較すると少なく限られており、全ての研究員を手厚くサポートするためにはさらなるリソースが必要です。*1
Kubernetes(EKS)を導入
研究開発部では、絶え間なく生まれる研究員による成果を最速でリリースするために、Kubernetesによるアプリケーション基盤(Circuitと呼んでいます)を構築しました。
導入の経緯やCircuitの設計については詳しくは別のブログにしています。
動機
Circuitでボトルネックを解消し開発リードタイムを改善したい
クラウドインフラ作成にはそれなりに強い権限が必要であるため、研究開発部全体で強い権限を持たせて開発することはせずArchitectグループに絞ってTerraormで開発を行っています。
Architectグループは研究員と比較すると人数も少なく開発が重なると優先順位やリソースなどの関係でArchitectグループ側のインフラ作成着手が遅れ開発のリードタイムが伸びてしまうことがしばしば起きていました。
Kubernetesを導入することで全てのTerraformによるIaCが消えたわけではありませんが、アプリケーション作成に必要な多くのリソースをKubernetes側のマニフェストに置き換えられるようになりました。
そこで、研究員の開発領域をマニフェスト作成まで広げ、Architectグループと研究員両方が扱える領域を作ることで開発のリードタイムが短くできるのではないかと考えました。
また、一部のアプリケーションではマニフェストの記述だけでインフラ構築が完結できるようになります。その場合、研究員がArchitectグループのリソースをほとんど使わずに新機能をデプロイできます。これが実現するとこれまでの研究開発部では考えられなかった爆速リリースとなるでしょう。
いきなりマニフェストを書けと言われても辛い
ただ、マニフェストを書くだけと言われてもKubernetes周りの話は覚えることが多く、最初は腰が重いものです。
Circuit開発をメインで行っている私もそうであったので、研究開発が主たる業務である研究員であればなおさらのことでしょう。
取り組み
Github Actionsでマニフェスト生成とPR作成
少しでも初期の学習コストを減らして研究員がCicruitにアプリケーションを載せてもらうためにマニフェストの雛形を用意することにしました。
予め用意できる所は用意しておこうという極めてシンプルな発想です。
雛形を利用してもらうだけでもいくらか効果はあると思うのですが、開発のリードタイムを更に減らすためにもう一歩踏み込んでGitHub Actionsから雛形のダウンロードとプルリクエスト作成までできるようにしました。
ユーザはパラメータを入力をして手動トリガーを引くだけです。すると新規アプリケーションのマニフェストがプルリクエストとして作成されます。その時間わずか5分といったところでしょうか。
社内勉強会で紹介
せっかく作っても使ってもらえなければ意味がないので、毎月研究開発部全体で行っている社内勉強会で今回作成したマニフェスト生成方法を紹介しました。
Kubernetesの基礎的な話から研究員がマニフェストを扱えるようになることで開発のボトルネックを解消したいこと、Github Actionsからマニフェストを生成して実際にアプリケーションをデプロイするところまで行いました。
実際に紹介で使ったスライドの一部を紹介します。
”できそう”や"デプロイしたい"という嬉しい声ももらえました。
参入障壁の低さの観点でポチポチはやはり偉大だなと感じました。
効果
Sansan Labs開発が爆速に
弊社のプロダクトであるSansanには研究員が中心になって開発しているSansan Labsというサービスがあります。
ユーザーの皆様に未来の働き方を体験してもらうための、実験的な機能を提供するサービスです。 当社の研究開発部が、ビジネスの出会いの証である、名刺交換データの研究をもとに開発しています。 Sansan Labsで、未来の働き方を体験する vol.1 - ユーザー向け活用ナビサイト【Sansan Innovation Navi】
データ x 技術で出せる新しい価値の探索する場としてガンガンリリースをしていきたいサービスなのですが、なんとこちらの機能開発がほぼ研究員のみできるようになりました。
これで着想からリリースまで研究員が一気通貫でできるようになり開発リードタイムがギュッと縮まりました。
実験的機能をどんどんリリースしていきたいSansan Labsとしてのあるべき姿に一歩近づいた瞬間です。
おわりに
まだまだCircuitの運用は始まったばかりです。 今回の施策によってどれくらい開発化が捗るか、そしてどんな問題が出てくるかにドキドキワクワクしていこうかと思います。
次回は今回踏み込めなかったKubernetesのマニフェスト雛形作成やGitHub Actionsでの実装の紹介をしたいと思っています。
アナウンス
求人
私の所属するML Platformチームを含む、研究開発部Architectグループでは一緒に働く仲間を募集しています。最近募集の給与レンジが上がりました。私の所属する中部支社勤務も上がりましたのでオススメです。この記事を読んでArchitectグループとして研究開発の成果をドライブしたいと思った方(思わなくても可)は是非一緒に働きましょう。
R&D MLOps/DevOpsエンジニア / Sansan株式会社
*1:Architectグループの人数増やせば良いのではと思ったあなたの応募をお待ちしております。
