こんにちは、Sansan Engineering Unit 部長の笹川裕人です。今回で7回目を迎える「Sansan Tech Talk」では、Sansanのテックリードが日々取り組んでいる技術的な課題や挑戦を深掘りしてお届けしています。今回は、研究開発部で活躍するWebアプリエンジニアの新井和弥にインタビューしました。
▼連載記事はこちら
buildersbox.corp-sansan.com
笹川：今日は研究開発部の新井さんにお越しいただきました。新井さん、自己紹介をお願いできますか。
新井：よろしくお願いします、新井と申します。現在、技術本部研究開発部のArchitectグループにあるML Platformチームでリーダーを務めています。Sansan株式会社には約2年半前に中途入社しました。主な業務は、研究開発部内でのアプリケーションプラットフォームの開発と運用です。私達はこのプラットフォームを“Circuit"と呼んでおり、その実態はAWS EKSを利用したKubernetesベースのシステムです。細かいアプリケーションでいうと、数十から百程度の単位が稼働しているプラットフォームになっています。
笹川：なるほど。EKSクラスターで大規模なものを運用し、その上で多数のアプリケーションが稼働しているのは、社内でも有名なワークロードですね。そもそも研究開発部の方向性や具体的な取り組みについても、あらかじめ紹介しておきたいと思います。その辺りについても説明いただけますか。
新井：はい。研究開発部という名前から、研究ばかりを行っているように聞こえるかもしれませんが、実際にはビジネスに直結する研究開発を行っています。弊社の創業プロダクトであるSansanで使用されているOCRや自然言語処理などのコアな技術を長年開発してきた歴史があります。最近では、Sansan Labsというデータを活用したプロダクトアイデアを
ベータ版的に迅速にリリースする仕組みも取り扱っています。
これら以外にもグラフ機械学習を活用した検索・レコメンデーションやA/Bテストなども運用しています。例えば特定企業に類似している企業で勤めている候補者を検索可能にしたり、複数の候補から効果的な訴求メッセージを選択している仕組みなどがこれに当たります。これらは、大規模なCPUインスタンスやGPUインスタンスなどワークロードもさまざまです。また、OSもLinuxインスタンスやWindowsインスタンスとシステムによって使い分けられています。
他には、システムの特殊性も有しています。一般的なシステムでは、APIを作成する際に低レイテンシーを求められることが多いですが、機械学習の推論などでは、結果が返ってくるまでに数秒かかるものもあります。極端に時間がかかるものは、バッチ処理のような非同期の形で対応するなど、さまざまなアプローチを使い分けています。
笹川：確かに、通常のWebAPIだと100ms程度でレスポンスを返すことが多いですが、データベースからデータを取得して少し処理してから返すだけ、というのがよくあるパターンですよね。しかし、モデルで推論を行う場合は、数秒から数十秒かかることもあるので、そういった意味でML以外にも特殊なエンジニアリングが必要になるということがよく分かりました。
開発の仕組みについて、MLエンジニアが全てを担当するのか、それとも新井さんのチームがサポートしているのか、もう少し詳しく教えていただけますか。
新井：研究開発部の開発プロセスは案件によってさまざまです。研究開発部には研究員とエンジニアのロールがあって、基本的に研究員が主にアルゴリズムの開発を担当しますが、エンジニアも協力して開発を進めているものもあります。
例えば、あるAPIを開発する場合、実際のアルゴリズムの考案からコンテナ化までは研究員が担当します。その後のCircuitへの展開、実際のリリースやデプロイのプロセスは、エンジニアがサポートするといった形です。
ただし、これも本当にケースバイケースで、エンジニアリングのスキルが高い研究員であれば、CIrcuitへの展開まで自身で行うこともあります。一方、特定の分野に特化したスキルを持つ方の場合は、エンジニアの担当の比率が大きくなってきます。
笹川：プラットフォームチームが展開しているCircuitは、今おっしゃった範囲までをカバーしているということですね。それ以降はオーダーメイドでの対応になると。そのプラットフォームのカバー範囲について、もう少し教えていただけますか。
新井：そうですね。Kubernetes的な話になってしまうんですけど、マニフェストを書くところまで研究員が行えることを念頭にCircuitは整備はしているものの、いきなり研究員に対して「Kubernetesのマニフェスト作ってください。よろしく！」っていうのは結構ひどいんじゃないかというところで、テンプレートを用意しています。一定必要な部分を埋めると生成されるようになっていて、あとはデプロイまで持っていけるよう準備してあります。あとデプロイ周りもGitOpsにして、マニフェストを作成してプルリクエスト上げてもらうと、マニフェストに間違いがないかとかを自動でチェックした上で、エンジニアのレビューも経てデプロイする、もしくはマージすればデプロイされるので、あんまりデプロイ用の手順とかはないっていうような形にはしています。あまり扱ったことがない人はテンプレートに乗っかり、使い慣れてきたら独自でこういう機能使うなど、自身で調べて使ってもらうといった使い方ができるようにしています。
笹川：ありがとうございます。Kubernetesに関しては、YAML地獄と呼ばれるほど設定が複雑になりがちですよね。また、アプリケーションとインフラを抽象化している関係で、ネットワーク関連の設定なども必要になります。MLエンジニアにとってはハードルが高い部分もあると思うので、そういったサポートのバランスがうまく取れているという印象を受けました。
研究開発部は歴史的な経緯もあり、加えて弊社には複数のプロダクトがあることから、Circuitにまだ載っていないコンポーネントも含めると、かなり多様なコンポーネントを運用していると思います。実際にどのような環境があるのか、異なる環境を使用する際の苦労も併せて教えていただけますか。
新井：前提として、私たちはマルチプロダクト環境で開発を行っており、研究開発部はさまざまなプロダクトにシステムを提供しています。多くの場合、プロダクトごとにクラウドサービスの選定や技術選定を行うため、結果的にAWS、Google Cloud、Azureといった主要なクラウドプラットフォームすべてを扱う機会があります。
この状況で難しいのは、選択肢が多いことです。必要に応じて「この機能はGoogle Cloudの方が使いやすい」といった理由で、特定の機能は特定のクラウドで運用するといった状況になっています。
現在、CircuitはAWS上のEKSで構築されています。このプラットフォームが洗練されてくると、便利さから他のサービスもこちらに移行したいという要望が出てきます。しかし、マルチクラウド環境での移行は想像以上に困難です。
マイグレーションに関してはゼロから作る場合と異なり、既存の状態と新しい状態を常に比較する必要があります。パフォーマンスが少しでも変化すれば、その理由を説明しなければなりません。コストの面においてもｒ、移行によってコストが上昇した場合、その正当性を示す必要があります。
さらに、私たちはマルチプロダクト環境で、かつマイクロサービスのように細分化されたサービスを多数運用しています。おそらく数十から100近くのサービスが存在すると想定され、これらすべてを「便利だからCircuittに移そう」としても、簡単にはいかないのが現状です。
笹川：直近、別の環境で動いていたものをCircuitに移行する際に苦労したという具体的なエピソードがあれば、簡単に教えていただけますか。
新井：直近で経験した事例ですと、これまでCircuitは、主に小規模なサービスを多数稼働させるという使い方が中心でした。代表的な例としてはSansan Labsのようなものです。
しかし、ひとつのチャレンジとして、数百vCPUを使用するような大規模なシステムをCircuitに載せる試みを行いました。これにより、システムのモダナイズ化や運用の効率化を図ろうとしたのです。
ワークロードのKubernetes移行と、異なるパブリッククラウド間でのコスト比較を伴う移行が課題でした。移行中にコストの変動を調整し、見積もりを立てて進めました。
しかし、実際に移行を進めると、見積もりと実費の間にいくつかの相違点が生じました。Circuitは小規模なサービスを多数動かすことに長けていましたが、大規模なシステムを一度に載せることには課題がありました。ノードの取り扱いやスケーラビリティの調整など、まだ経験が不足している部分がありました。
さらに、このシステムがかなり大規模だったため、「試しに載せてみよう」といった実験も難しく、最終的には元の環境に一旦ロールバックせざるを得ませんでした。十分な時間と調整をかけて移行を試みたにもかかわらず、うまくいかなかったのは苦い経験でした。
笹川：小規模なサービスを多数運用するノウハウはあったものの、リソース的にも規模的にも大きなコンポーネントの移行は難しかったということですね。その移行の際に発生した問題について、具体的に教えていただけますか？
新井：具体的な問題としては、Kubernetesに移行する際にノードの管理にKarpenterというツールを使用しました。これにより、個別のノード設定が不要になり、リソースを動的に調整できるはずでした。しかし、移行前は「このくらいのリソースを使う」という大まかな見積もりで運用していたため、Karpenterの柔軟性に頼りすぎてしまい、細かいチューニングが難しくなりました。
また、監視体制が不十分だったため、システムは動作しているものの、非効率な部分に気づくのに時間がかかりました。
さらに、ネットワーク関連の問題も想定外でした。当初は、複数のクラウド間でインターナルな通信を使用することでデータ転送コストを削減できると見込んでいました。例えば、異なるパブリッククラウド間で連携させる際、一つのクラウドに集約することでコストを下げられると考えていました。しかし、実際にはクラウドアカウント間の内部通信がうまく機能せず、予想外にコストが上昇しました。特に、NATのような機能は使用側のコストが高くなる傾向があり、この点に気づくのが遅れました。
笹川：一旦は元のコンポーネントに戻したんですね。確かに難しい問題ですよね。小規模だと見えづらく、ケアしていなかった部分が大規模なものに移行したときに顕在化したり、コンポーネント固有の特殊性を十分に把握できていなかったことが主な原因だったんでしょうか。
新井：そうですね。リソースの調整も、ワークロードが変わるとベストな領域も変わってきます。今振り返ると、もう少し注意深くケアすべきだったと思います。
笹川：今後もCircuitを使っていく方向性で、便利な機能も進化していくと思うのですが、それに伴って現在感じている課題や、今回の経験からの教訓、あるいは今後起こりうると予測していることはありますか？
新井：CircuitはSansan Labsでの使用が始まりで、そこに合わせてチューニングしてきました。しかし、SansanやBill Oneといった他のサービスでも使用されるようになると、複数の異なるシステムが同時に動作する状況に対応しなければなりません。
例えば、コスト面でも課題があります。ビジネス上、特定のプロダクトがどれだけコストをかけているかという情報は、特に会計上の適正な運用のために非常に重要です。「おおよそこのくらい使っているからOK」というような曖昧な話では済まなくなります。コストに関する説明責任を果たせるような単位で管理する必要があります。
また、複数のプロダクトで使用されるということは、ステークホルダーも増えるということです。「これは開示してよい」「これにはアクセスできる/できない」といった権限管理もより細かく行う必要が出てきます。
さらに、これまでは特定のプロダクトにR&Dのシステムを載せるという整理をすることが多かったのですが、Circuitに複数のシステムが載るようになると、必要に応じて移行しなければならないケースも出てくるでしょう。
笹川：これまではシステムの実装はR&Dで行っていても、例えばSansanの環境や、提供対象先のAWSのアカウントにデプロイするという状況だったので、ある意味で運用も一定程度関わっていたと思います。それを一気にCircuitに集約する形になると、責任の切り分けが課題になりますね。プロダクト側の人も関わるし、R&D側で見なければならない部分もあるということですか？
新井：そうですね。責任の切り分けは非常に重要です。Kubernetesの利点の一つとして、システムを柔軟に分散させて使用できる点があります。これにより、リソースの無駄を省くことができるなどとても便利です。
一方で、注意しなければならない点もあります。例えば、Sansanの一部で使用されているシステムとBill Oneで使用されているシステムが同じ環境に乗った場合、あるシステムの影響が別のサービスに波及するリスクがあります。これは利用者側からすると望ましくありません。
また、問題の切り分けが非常に難しくなります。別のプロダクトのサービスが引き起こした問題が、思わぬところで発生する可能性があるのです。そのため、これらの点に十分注意を払う必要があります。
対策として、スコープを切り分けやすくするためにマルチテナント形式を採ったり、クラスターごとに分けたりといった方法も考えられます。これらの対応は、状況を見ながら手探りで改善していく必要があると考えています。
笹川：先ほど説明のあったBill Oneなども、請求としてはR&Dの環境のコストとして計上されるけれど、コンポーネントAはいくら使用していて、Bはいくら使用しているかというように、費用を分けたいというモチベーションがあるということですよね。これはなかなか難しい問題ですね。
新井：そうですね。サーバーやストレージのコスト分割は比較的容易ですが、ネットワークコストとなると難しくなります。もちろん、使用量も影響しますが、細かく分析しようとすると、完全に分離された環境のほうが整理しやすいのは確かです。
ただ、一つのエコシステムに乗ることの利便性と、細かく分けることのバランスが求められます。このバランスを取ることが、大きな課題のひとつだと考えています。
笹川：先ほどの責任の件について、今考えていることはありますか？例えば、プロダクトサイドの人に担当してもらう部分、プラットフォームチームが担当する部分、そしてMLエンジニアが担当する部分というように、主に3つに分かれると思いますが。
新井：そうですね。もちろん、これまで通りサポートが必要な部分はありますが、徐々に抽象化を進めるなど、慣れていくことで改善できる部分もあると思います。
理想的なのは、開発のサイクルを研究員だけで完結できるようにすることで、開発のリードタイムを短縮できると考えています。そのためには、事前に便利な環境を用意しておき、あまり深く考えなくても動作する仕組みを作ることが重要です。もちろん、必要に応じて細かい設定もできるようにしておくべきです。
チームや人を介すということは、多大な時間的コストがかかるので、自分たちで作って自分たちでデプロイするような、DevOps的なアプローチをMLエンジニアでも実践できる環境を目指しています。これにより、試行錯誤や開発サイクルを加速できると考えており、そのためのプラットフォームを目指しています。
笹川：確かに、このようなアプローチは工数削減につながりますね。全体に影響を与える変更を行うことで、アプリケーションが自動的に改善される一方で、予期せぬ影響を受ける可能性もあります。これらをうまく切り分け、個別の影響を最小限に抑えるのは、まさに腕の見せどころですね。
新井：まさにその通りです。そこが面白いところだと思います。システムを一緒に動かすということは、予期せぬことが起こる可能性もあるということです。それを技術的にどうカバーしていくかが重要なポイントになりますね。
笹川：R&Dにおいて、近い将来新しいプロダクトが増えていく可能性があると思います。既存のシステムも載せる必要があるでしょうし、場合によっては置いておく可能性もあります。載せ替えるべきシステムもかなりの数あるんでしょうか？
新井：正直なところ、R&Dには多くのシステムがありますが、Circuitに載っているのはごく一部なので可能性としては大きいですね。
別のパブリッククラウドで動いているものもありますし、同じパブリッククラウド内でも別の環境にデプロイされているものもあります。例えば、AWS ECSで動作しているシステムもあります。他の部署の環境にデプロイされているものもあります。
一方で、プラットフォーム側を改善していくと、新しいシステムはプラットフォームに載せることが多くなりやすいです。慣れてくると、既存のシステムもこちらで使いたいという要望も出てきます。
移行対象となるシステムは多いですが、移行するかどうかはケースバイケースです。何らかの形で手を加える必要があるタイミングで移行する可能性もありますし、すでに問題なく動作しているものに手を加えることで新たな問題が発生する可能性もあるので、積極的に移行をしないほうが良いケースもあるでしょう。
また、大きな工数をかけて改善する必要のないもの、例えば近い将来使用しなくなるようなシステムもあります。そのため、各システムの将来性や現状を見極めながら進めていく必要があります。
笹川：移行するかどうかの判断や移行方法を含めて、かなりチャレンジングなタスクですね。プラットフォーム自体の改善についても、さまざまな知識が必要で、影響を最小限に抑えながら徐々にリリースしていくような方法も含めて、プラットフォーム自体の改善も非常に興味深いタスクだと思います。
今日は新井さんに来ていただいて、R&Dの組織、特にプラットフォームについて、現在取り組んでいることや今後の課題についてお話しいただきました。新井さん、ありがとうございました。
新井：ありがとうございました。
