こんにちは、Sansan Engineering Unit 部長の笹川裕人です。今回で8回目を迎える「Sansan Tech Talk」では、Sansanのテックリードが日々取り組んでいる技術的な課題や挑戦を深掘りしてお届けしています。今回は、研究開発部のArchitectグループで活躍する加藤慶彦にインタビューしました。
▼連載記事はこちら
buildersbox.corp-sansan.com
笹川：今回は研究開発部の加藤さんにお越しいただきました。加藤さん、自己紹介をお願いできますか。
加藤：よろしくお願いします。加藤慶彦と申します。約1年前に研究開発部のArchitectグループに転職してきました。最初はPlatformグループに所属し、主にCircuitと呼ばれるKubernetes基盤の管理を担当していました。その後、MLプロダクトのSREチームであるtakowasaチームに異動し、半年ほど働いています。
私は前職でもKubernetes Platformチームに所属しており、そこで得た知識をMLプロダクトにも活かす仕事をしていました。Sansanに転職してからは、MLエンジニアや研究員が効率よく働ける環境を作るための基盤構築に全力を注いでいます。
笹川：ありがとうございます。チーム異動について、当初の状況と比べて何か強い動機があったのでしょうか？
加藤：最初に所属していたMLPlatformチームでは、主にKubernetesの維持と改善に焦点が当てられていました。しかし、そのチームで行われていたKubernetesの改善によって得られるメリットが、研究員や開発者にあまり浸透させられていないという課題がありました。そこを改善したいと思い、SREを主に担当している隣のチームへの異動を決めました。
笹川：加藤さんが所属する研究開発部チームのアプリ開発の現状を教えてもらえますか？
加藤：研究開発部の特徴として、ソフトウェア開発のプロフェッショナルではない研究員が多いことが挙げられます。そのような環境で、高品質なプロダクトを迅速に開発するには、多くの部分を共通化し、自動化することが必要です。そこで私たちは、Kubernetesを導入し、その共通化部分をArchitectチームが担当する形で、効率的に高性能なプロダクトを開発できる仕組みを整えています。
笹川：MLアプリケーションは非常にハイペースで開発されている印象があります。現在も多くのアプリケーションがそのクラスターで稼働していると思うのですが、このようなハイペースな開発に伴い、研究開発部が直面している課題にはどのようなものがありますか？
加藤：新しいアプリケーションの開発やリリースを優先すると、古いプロダクトのメンテナンスが疎かになったり、共通部分を変更した際に全ての古いプロダクトで正常に動作するかを確認する必要が生じたりします。これにより、徐々に開発効率が低下するという問題に最近直面しています。この課題に対処するため、私たちは最近、Chassisというアプリケーション開発基盤の開発に取り組んでいます。
笹川：つまり、アプリケーションが10個の時は新しい仕組みを導入する際に10個を修正すればよかったのが、100個になると100個プラス1個を修正しなければならないということですね。歴史が積み重なるほどメンテナンスコストが増大していく問題に対して、古いアプリケーションにも最新のプラクティスを適用する方法を提供してくれるということですね。現在開発中のChassisというツールについて、簡単に説明していただけますか？
加藤：Chassisでは、これまでテンプレート生成でカバーしてきたKubernetesのリソース管理を、chassisctlというソフトウェアを介して管理するようにしています。従来はテンプレートを一度発行したら終わってしまっていたものを、Chassisを経由することで、常に最新の状態を保ち、ベストプラクティスを継続的に適用するシステムを構築しています。
ただ、例えばChassisを通じてネットワーク構成を更新した際に、古いプロダクトが動作しなくなるのは困ります。そのため、すべての古いプロダクトに対してE2Eテストを自動的に実行し、変更の妥当性を確認します。また、古いライブラリをアップデートする際も、そのアップデートが全プロダクトの動作に影響しないかを自動的にテストしながら、更新を進めていくアプリケーションになっています。
笹川：なるほど、ありがとうございます。Chassisの管理範囲は、具体的にアプリケーションコードやライブラリのバージョンなども含むのでしょうか。それとも、Kubernetesのコンフィグ周りに限定されているのでしょうか。
加藤：両方です。Chassisの実態は、アプリケーションのGitHub ActionsとKubernetesマニフェストの生成です。アプリケーション側で古いライブラリが使用されていないかを監視する、いわゆるDependabotのようなものをデプロイするのもChassisの役割です。さらに、その変更によってアプリケーションが正常に動作するかどうかを、Kubernetesマニフェストに反映させて実行確認するのもChassisの仕事になります。
笹川：ということは、Kubernetesからアプリケーションレイヤーまで全体をカバーしているんですね。これはとてもいいと思います。ところで、開発者がChassisを使う際に具体的に何をすればいいのでしょうか？
加藤：そこは1つのCLIツール、chassisctlにまとめられています。例えば、開発者が初めて使う場合はchassisctl initというコマンドを実行するだけです。すると、すべての必要なものが自動的にプルリクエストとして作成され、指定したリポジトリでChassisベースのアプリが動作するようになります。これはワンタッチの設定です。更新についてはchassisctl buildを実行すると、最新の状態に自動的に同期されます。
笹川：なるほど。Chassis自体は、特にマニフェストの最新化に関して、参照するリポジトリがあって、それを適用するようなイメージでしょうか？
加藤：chassisctl側が更新されると、すべてのリポジトリに対してプルリクエストが作成されます。そのプルリクエストの中でCIが既に設定されているので、それらのCI結果をchassisctlのCIとして見ることで、全アプリケーションのテスト進行を管理しています。
笹川：理解しました。ありがとうございます。ということは、おそらく適用までのプロセスは自動的なプルリクエスト作成で行われ、自動テストもChassisの範囲内ということですね。E2Eテストやデプロイ、そしてE2Eテストが成功したことを確認するところまで自動で行われた後、開発者の責任で承認するというフローだと想像します。そうなると、開発者にとってはE2Eテストを書くことが腕の見せ所になりそうです。「このシナリオをしっかり書いてね」という形で、徐々に進めていくアプローチなのでしょうか。
加藤：はい、そうですね。その点については、弊社のSETチームと協力しながら進めています。SETチームと開発者を引き合わせ、E2Eテストを作成するためのミーティングを設定するなど、サポート活動も行っています。また、まだアルファ版ではありますが、研究開発部チームでE2Eテストの自動生成ツールを開発中です。これがうまくリリースできれば良いと考えています。
笹川：SETチームというのは、QAグループのメンバーということですか？
加藤：はい、そうです。
笹川：なるほど、素晴らしいですね。
E2Eの実装周りは、現在テスト分野でも注目を集めていると思います。この協力体制で知見が蓄積されていくのは非常にいいことだと思います。E2E自動生成も、さまざまな意味で期待が高まりそうで楽しみですね。ところで、Chassisは新しい取り組みだと思いますが、今後のカバレッジ拡大についてどのような計画がありますか？
加藤：今後半年で、まずCircuitに現在搭載されているプロダクトを全てChassis化することを目標としています。さらに、研究開発部の全プロダクトをChassis化したいという目標がありますが、まだCircuitに搭載できていないものもあります。そこも含めてChassis化を進めていく予定です。
笹川：ありがとうございます。特に、Sansanの「Labs」と呼ばれているCircuitで動いているMLアプリケーションについては、Sansan上でも多く使用されているようです。そのため、一度枯れたアプリケーションになったとしても、アプリの最新化は、セキュリティなどの面で非常に重要になってくると思います。この仕組みは非常に価値が高いのではないかと、私も聞いていて感じました。
Chassisについてはここまでにして、今後、中長期的に取り組みたい別の課題は何かありますか？
加藤：はい。特にこの四半期から力を入れていこうと思っているのが社内認証基盤です。弊社のデータはほとんどが委託データかつ個人情報で、かなり扱いがセンシティブなものになっています。しかし、研究開発部の業務の特性上、多くのデータをダウンロードして学習させる必要があります。そのため、アクセス制限を厳格にしすぎるとさまざまな不便が生じてしまうので、そこのバランスを取る必要があります。SansanのMVVには「Premise」という項目があり、「セキュリティと利便性を両立させる」ことが謳われています。アーキテクトの立場からこれを実現することが、これから取り組もうと思っている課題です。
笹川：なるほど。委託データの取り扱いについては、他の連載記事でも言及されているとおり、Sansan社内全体で非常に重要なタスクとして位置づけられていますね。一方で、「どれが委託データなのか」という判別や、それらを全て探し出して解約に伴って確実に削除するのは非常に難しい問題だと思います。具体的に、まず認証認可の観点から、アクセス制御をどのように決めていくのか。このアプローチについて聞かせてください。
加藤：現状、2種類の方法を採用しています。弊社の従来のシステムではMicrosoftのActive Directory（以後ADと呼ぶ）が使われていましたが、今後はOktaへ移行する大きな流れがあります。旧ADで行っていたものを全てOktaに統合することで、いわゆる"車輪の再発明"が不要な状態を作りたいというのが、大きな方向性です。
笹川：つまり、Oktaを基盤の前段に配置して、それを経由しないとシステムにアクセスできない状況を作るのが直近の目標ですね。Oktaの基盤は既に全社で導入されているので、適切にクライアントを使用する程度の実装でうまくいきそうな印象です。ただ、利便性を担保しながらセキュリティと両立させる点は重要になってくると思います。
さらに、委託データは永続的に保持すべきものではありません。我々は解約後3カ月以内に削除するなどの仕組みもこの基盤で整えているようですが、委託データの削除漏れは問題です。現在は人手で行っている印象がありますが、このプロセスの自動化について何か検討されている施策はありますか？
加藤：はい、まだ理論段階ではありますが、ファイルの移動や、ネットワークからのファイルダウンロードのクエリ、ファイルの増加箇所などを、カーネル層からeBPFを使用して取得できると考えています。そのため、ファイル移動などのログを集中管理で収集する仕組みを模索しています。
笹川：委託データの元の位置が分かれば、そこからの移動履歴が追跡できるので、元のデータから派生したすべてのファイルを削除対象にできるというアプローチですね。確かにeBPFの興味深い応用ですね。この視点での使用例はあまり見たことがありませんが、当社特有かもしれません。実際の問題に効果的に対処しようとしている点がとても面白いと思いました。
この分野も今後の展開が楽しみですね。皆の煩わしい手作業からの解放も期待されているので、頑張ってください。
加藤：最後にもう一点だけ話したいことがあります。この会社の好きなところを共有したくて。先ほどのeBPFの話もそうですが、解決すべき目標や課題があり、それに対して技術を駆使して解決策を見出すというアプローチを評価してくれる会社だという点が気に入っています。そのため、仕事に取り組む際に前向きに捉えてもらえますし、その価値を適切に評価してくれるので、非常に働きやすいと感じています。広告っぽく聞こえてしまうかもしれませんが、これだけはどうしても伝えたくて。本当におすすめだと言いたいです。
笹川：課題の解決方法はプロのエンジニアに任されていて、特に制限されることなく、身につけた知識を活かす機会がたくさんあると実感されているんですね。
加藤：そうですね。多くの課題が与えられ、それに対して自分の持つスキルで解決すると、それが高く評価されるという点がとても仕事がしやすいところです。常に学び続けることに対して報いてくれる会社だと感じています。
笹川：いいですね！今後も引き続き頑張ってください。今日は加藤さんに来ていただきました。加藤さん、ありがとうございました！
加藤：ありがとうございました！
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途・新卒採用向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話します。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
