研究開発部 Architectグループ ML PlatformチームのKAZYこと新井です。
名古屋にある中部支店に所属しています。
先日、一時的にML Platformチームを離れて社内向けシステムを、チームが開発・運用するアプリケーション基盤 "Circuit" に構築しました。 基盤自体の開発ではなく、初めて利用者として基盤を利用しました。
体験が良かったのでCircuitの紹介がてらブログにします。
テックなブログかは怪しい部分もありますが、どうぞお付き合いくださいませ。
研究開発部のアプリケーション基盤 "Circuit"
Circuitとは、2022年に研究開発部で導入したアプリケーション基盤です。
AWS EKSを用いたKubernetesで動いています。
【R&D DevOps通信】アプリケーション基盤としてKubernetesを導入、そして周辺技術選定と運用設計 - Sansan Tech Blog
わたしのこれまで
私は2022年3月にSansanに入社し、Circuitはその直後ぐらいに本番環境で運用が開始されました。 Kubernetesの導入は社内で初であり、私自身も経験はありませんでした。
その背景もあり、これまではKubernetesの勉強をしつつCircuitの改善、利用者の運用支援といったことを頑張ってきました。 一方で、自分で開発したシステムをCircuitにてデプロイ・運用したことはありませんでした。
これまでの頑張りにはこんなものがあります。
Circuitの改善話
【R&D DevOps通信】初めてのEKS Kubernetesバージョン更新を振り返る - Sansan Tech Blog
EKSのクラスタに追加のセキュリティーグループを導入してクラスタバージョン更新に備える - Sansan Tech Blog
利用者の生産性改善話
GitHub ActionsでK8sのマニフェストを生成できるようにして開発リードタイムを改善する(前編) - Sansan Tech Blog
GitHub ActionsでK8sのマニフェストを生成できるようにして開発リードタイムを改善する(後編) - Sansan Tech Blog
KubernetesのCronJobからJobを気軽に実行できるGitHub Actionsの仕組み - Sansan Tech Blog
MeetupでLT
Kubernetes Meetup Tokyo #59 - connpass
Circuitの利用者になる
話が少し変わりますが、研究開発部では、開発生産性やレビューの負荷の可視化ツールを主に部内向けに提供しています。
１年ほど細々と運用していたシステムなのですが、嬉しいことに部外からも使いたいという声がありました。 そこでこのツールを拡張して、全社向けに開発情報を提供するミニプロジェクトを行うことにしました。
システムはAWS ECSで稼働していたのですが、
- 実行基盤をCircuitに寄せて今後の運用を楽にしたい
- 柔軟なパイプラインと並列実行を行いたい
- Circuitの利用者になりたい
といったやや個人的な希望も含んでいますが、これらの理由で実行基盤のCircuit移行にも挑戦することにしました。
一時的にチームを離れる
プロジェクトは上司と相談して約1ヶ月ほどチームを離れて行いました。
短い期間でも離れたのは次の狙いがあったからでした。
- 短期間で開発データの全社展開を行いたかった
- チーム外プロジェクトの掛け持ちは、稼働バランスが偏りやすく期待値調整が難しくなるから
- チーム内の属人的な要素の発見と除外を狙いたかった*1
作ったもの
Circuitに導入しているArgoWorkflowsを最大限に活かしたシステムを構築しました。
システム自体がメインのエントリではないのでざっくりとした説明をします。
システム概要 外部APIから開発データを日次で取得するバッチ型システム
アーキテクチャ ArgoWorkflowsを利用し、開発に関するデータをWorkflow並列実行する。 成果物はS3に保存する。
バッチパイプラインの実行にはエムスリーさんが開発しているgokartを使用しています。
gokartとEC2のスポットインスタンスを使って運用コストに配慮した設計になっています。
以前LTで詳しく説明したスライドもあるので気になる方は読んでみてください。
今回の経験を通しての気づきと感想
約1ヶ月ほどプラットフォームチームを離れて、私やチームメンバーはこんなことを感じました。
私個人
チームメンバー以外との開発する経験
普段所属しているチームメンバー以外との開発経験は新鮮で刺激が多かったです。 技術レベルに関わらず、人が変わると考え方や技術の引き出しやレビュー切り口は変わるもので刺激的でした。
チームの頑健さ
チームから私個人への問い合わせは殆どなく、チームとしての頑健性を感じました。 属人性の低さや業務のカバーできるメンバーがいるということは、チームとして頼もしいなと思います。 もともと私が大した仕事をしていなかったのでは？というツッコミは禁止です。
Circuit開発体験の解像度向上
実際に自分が開発者になることで、Circuit利用者がこれまで寄せてくれていたフィードバックの解像度が上がりました。
例えば、 開発環境でCircuit同等の環境を構築できるようにしたい という要望がありました。
私自身も開発を進める上で、
- Circuitで動かすための制約を潰してからレビュワーの負荷を下げたい
- 手元の開発環境で動作確認して開発速度を上げたい
等々の理由で同様の要望を持ちました。
チーム
業務の役割が変わる
チームではスクラムというフレームワークでアジャイル開発を行っており、メンバーが着手するタスクの種類に制限は設けていません。 しかし、どうしても知らず知らずのうちに行うタスクに一部偏りが出てしまうようです。
また、チーム内でのサポートや問い合わせなどで気がつけば私が優先的に対応していたものもありました。
私が一時的に抜けることでそれらの業務が強制的に他のメンバーが行うことになり、メンバーの業務領域が微増する効果がありました。
さいごに
プラットフォームとして利用者になる経験をして得られるものが多かったです。 他のメンバーにも勧めたいと思っています。
ちなみに弊社のR&D新卒研修ではCircuit開発体験を組み込んでいたりします。
では。
求人
私の所属するML Platformチームを含む、研究開発部Architectグループでは働く仲間を募集しています。
一緒にCircuitを最高のアプリケーション基盤に急成長させてくれる方大大大歓迎です。
*1:気がつけば私はチーム内でそれなりの古株になっていた背景があります。
