Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

Sansan Data Hub・Bill Oneアーキテクト対談:事業を支えるシステムの設計方針を公開【後編】

社内に蓄積された顧客データを整理・統合し、マーケティングに最適なデータに進化させる顧客データ統合サービス「Sansan Data Hub」。そして、あらゆる請求書をオンラインで受け取り、企業全体の請求書業務を効率化するインボイス管理サービス「Bill One」。いずれも急成長を遂げており、Sansan株式会社の事業の柱になっているサービスです。

これらのサービスは、データの処理効率やシステムの信頼性などを向上させるために、さまざまなアーキテクチャの工夫が行われています。今回は「Sansan Data Hub」と「Bill One」それぞれの開発の中核を担う千田智己と加藤耕太にインタビューし、前後編の2回に分けて記事化。後編では、アーキテクチャについての質問・相談や今後の目標について語ってもらいました。

▼前編はこちら
buildersbox.corp-sansan.com

気になった点について、お互いに質問

――お互いに、アーキテクチャについての質問や相談はありますか?

千田:「Bill One」はバックエンドがKotlinで書かれていますよね。JVMに関連して、CIなどで運用のしづらさなどが出てくることなどはないですか?

加藤:基本的にはないですね。あえて挙げるならば、Javaの世界ではデータベース接続にJDBCという仕様がよく使われますが、これはブロッキングな処理なんです。Kotlinにはコルーチンという非同期処理のための機能がありますが、JDBCを使っている限りそのパフォーマンスを最大限に活かせないという課題があります。データベース接続で非同期処理を扱えるR2DBCという仕様はありますが、これはまだ十分には世の中に普及しておらずドライバのサポートなどが手薄なため、まだ導入には踏み込めないですね。

千田:.NETの場合、かなり早い段階から非同期処理関係の機能を積極的に取り入れていたので、それに関連した処理はやりやすいです。JVM言語との違いかもしれないですね。

加藤:「ドメインごとに完全に設計を分けている」という話がありましたよね。どれくらいの粒度で分けているんですか?

千田:上の表にあるくらいの粒度で分けています。外部サービスとの接続処理があるので、それも細かいドメインとして切り分けています。それから、PMSやActivityは汎用サブドメインであり、全体的なドメインが依存するものです。PMSはPrivacy Management System(個人情報保護マネジメントシステム)で、個人情報を閲覧したログなどを収集するもの。Activityはシステム内で起きた各種のイベントを収集するものです。巨大なのがETLとPublishingで、この中にさらにそれぞれ十数個のサービスがあります。

加藤:なるほど、そういう分け方になっているんですね。他の質問として「Bill One」ではCloud Tasksというタスクキューサービスを利用しており、エラーが連続するとキューの全体的な処理性能が低下するという課題があります。そういった部分で、Azure Service BusやAzure Event Hubsなどの運用に困ることはないですか?

千田:その点は「Sansan Data Hub」において設計をかなり頑張っているところで、エラーが起きた時にリソースがどのような挙動をするのかを、あらかじめ検証してから本番環境に投入しているんです。アプリケーションレベルでリトライをすると、全体的に処理が詰まってしまいます。そうではなく、Azure Service Busが持つリトライの機能などをうまく活用して、パフォーマンスが落ちない工夫を仕込んであります。

一方のAzure Event Hubsは部分的なリトライをしません。このサービスはバッチ処理に特化しているため、仮に100件のデータをバッチ処理して1件でもエラーがあると、その100件の処理をもう1回やり直すことになってしまうんです。これはあまりに非効率なので、その1件のデータだけをAzure Service Busに再投入して、Azure Event Hubsのチェックポイントは前に進めていく対応を入れています。

「Sansan Data Hub」「Bill One」の開発に携わるやりがい

――今後の目標はありますか?

千田:これまで「Sansan Data Hub」は、開発スピードを重視してプロジェクトを進めており、データの保存・活用のコストとあまり向き合ってこなかったんですね。その結果、データが膨れ上がっており無駄なコストが発生しています。その課題を解決するために、アーキテクチャ改善を着実に進めていきたいです。

それから、「Sansan Data Hub」をローンチしてしばらくの間は、運用の負荷が高い状態が続いていました。ドメインごとにデータストアが過度に分かれており、データや処理のトレーサビリティが落ちていたんです。ここ1~2年でだいぶ改善が進みましたが、まだまだ難があります。この部分にも引き続き取り組んでいきます。

加藤:「Bill One」をローンチしてから2年ほどが経ちましたが、ユーザーから見える機能の追加を最優先にしてきたこともあり、徐々に運用の負荷が高くなっています。管理画面などに実装すべき処理を後回しにしてきたため、今後はそういった機能も充実させたいです。また、各マイクロサービスのうち、主要機能のコードベースが大きくなり過ぎています。複数の小さなサービスに分割し、効率良く開発できる状態に持っていきたいです。

――今のフェーズの「Sansan Data Hub」と「Bill One」の開発に携わることは、エンジニアにとってどのような点がやりがいにつながると思われますか?

千田:「Sansan Data Hub」は、Sansanの扱っているサービスの中では最もデータの流量が多いです。それらのデータを効率良く処理する方法を考えることは、エンジニアにとって大変でもあり面白くもあります。それから、「Sansan Data Hub」はあらゆるデータを抽象的に扱いドメインモデルを考えるため、難易度の高い設計が好きなエンジニアは興味を持てるシステムだと思います。最近は機能追加が活発になっているため、アーキテクチャの再設計や新しいツールの導入などに挑戦できるのも良いところです。

加藤:「Bill One」はビジネスとして急成長しているところに面白さがあります。数年前には、世の中に請求書を受領する側としてのインボイス管理サービスは概念すら存在していませんでした。そこから、短期間で急激に「Bill One」の導入企業数を増やすことができました。これからいかにしてサービスを良くしていくか、エンジニアの力が問われます。インボイス制度への対応やグローバル展開など、今後もやりたいことは山ほどあります。ぜひ、興味のあるエンジニアの方々は私たちのチームに参画していただけると嬉しいです。


interview:中薗昴


media.sansan-engineering.com

© Sansan, Inc.