Bill Oneデータ化の安定稼働 Sansan株式会社 技術本部 DSOC 研究開発部 Arc Group ⻄原 康貴 2021.12.13 新卒R&D LT

Data Strategy and Operation Center ⾃⼰紹介 2019/03：⾼専卒業 2021/03：⼤学卒業 2021/04：Sansan株式会社⼊社 ⻄原 康貴 Koki Nishihara Sansan 株式会社 技術本部 DSOC 研究開発部 Arc Group Architect Team エンジニア

Data Strategy and Operation Center 研究開発部の構成 研究開発部 Automation DataAnalysis Arc SocSci 3つの研究員グループ と 1つの エンジニアグループ

Data Strategy and Operation Center Arc Group Architect Team • サービス開発に関する業務を⾏う • 設計・実装・運⽤ • 研究開発部の⽣産性を向上させる ためのDevOps、MLOps • 研究員が研究やアルゴリズムの改良に集中できるように 開発やデータ周りの業務を⾏う • Group内にチームは2つ Data Direction Team • データ周りの業務を⾏う • 分析基盤の設計・構築・運⽤ • 新しいデータの集積・加⼯

Data Strategy and Operation Center Arc Group が関わるプロダクト・サービス • Sansan（データ化、名寄せ、スマート署名取り込み など） • Sansan Data Hub • Sansan名刺メーカー • Eight • Bill One etc... 特徴 • 関わるプロダクトが多いので全社的に影響を与えることができ、 マルチプロダクトを⽀えている • プロジェクトが多いとチャレンジできる機会も多い • 少ない⼈数で多くのプロジェクトに関わっているで裁量も⼤きい これらのプロダクトに複数のサービスを提供しており、 全て合わせると80個くらいのプロジェクトに関わっている。

Data Strategy and Operation Center ⼊社後の業務 1. toB向けサービスSansanのベータ機能の脆弱性修正 2. Data Visualization の開発 3. Bill One ⾃動⼊⼒の安定化 4. 名刺のデータ化機能の開発 etc...

Data Strategy and Operation Center ⼊社後の業務 1. toB向けサービスSansanのベータ機能の脆弱性修正 2. Data Visualization の開発 3. Bill One ⾃動⼊⼒の安定化 4. 名刺のデータ化機能の開発 etc...

請 求 書 受 領 か ら 、 ⽉ 次 決 算 を 加 速 す る

Data Strategy and Operation Center あらゆる請求書をオンラインで受け取る 業務フローの再構築のポイント：全ての請求書の受け⼝を集約し、データ化できること

No content

Data Strategy and Operation Center ⽉毎のリクエスト

Data Strategy and Operation Center ⽇毎のリクエスト 毎⽉初めがピークになる

Data Strategy and Operation Center メール Bill One データ化フロー 請求書受領 ⾃動⼊⼒ ⼿動⼊⼒ データ化完了 アップロード 郵送

Data Strategy and Operation Center メール Bill One データ化フロー 請求書受領 ⾃動⼊⼒ ⼿動⼊⼒ データ化完了 アップロード 郵送 リクエスト インスタンス起動 初期データ読み込み 請求書データ化 レスポンス

Data Strategy and Operation Center ⾃動⼊⼒システムの問題点 • インスタンスの起動が遅い • 短時間にアクセスが集中するとスケール アウトが間に合わずエラーを返す リクエスト インスタンス起動 初期データ読み込み 請求書データ化 レスポンス リクエストが集中する⽉初はエラーが多く なり⾃動⼊⼒できていないことも。 これでは⾃動⼊⼒の役割を果たせていない。

流⼊が増えてもシステムは耐えれるのか？

Data Strategy and Operation Center インスタンスの起動が遅い問題 GCPのApp Engine Flexible上でアプリケーションを構築している 遅い原因 • Docker imageのサイズが⼤きい • App Engine のヘルスチェックに時間がかかる • App EngineがVM型の仮想化技術を採⽤している 最⼩インスタンス数を増してもいいけどお⾦がかかる => コンテナ型のCloud Runへの移⾏を検討 ※ App Engine FlexibleとCloud Runは任意のコンテナイメージ上でアプリケーションを動かすことができるサーバレスなマネージドサービス

Data Strategy and Operation Center 移⾏前の負荷テスト Cloud Run のパフォーマンス検証 • リクエストが多い時は1req/1secのペース • 同時リクエスト数は20 vegeta というツールを使って検証 1. max-worker(同時リクエスト)は20 2. 3分間でどれくらいのリクエストが さばけるか Total requests Rate Duration Latencies(mean) Success ratio Cloud Run 98 0.54 3m22s 39.785s 100 App Engine 5457 7.70 12m30s 2.577s 0.02 App Engine2 68 0.09 12m52s 3m39s 52.94

Data Strategy and Operation Center App EngineでSuccess ratioが低い理由 アプリのレームダック インスタンスでは、トラフィックを処理するための準備が進んでいる。この間はアプリからは、 インスタンスでリクエストを処理できないことを⽰す 503 コードが返される。 AppEngineの2回⽬のテストでSuccess ratioが上がった理由 1回⽬のテストの直後で準備完了のインスタンスがあったから App Engineだと急なアクセスの集中に対応できない可能性が⾼い

Data Strategy and Operation Center インスタンスの起動速度改善 負荷テストの結果から、Cloud Runの⽅がリクエストが集中しても 安定して処理できることがわかった。 => Cloud Runの移⾏を決⾏ 移⾏結果 • ⽉1500件あったスケールのエラーがなくなる • App Engine Flexibleを使っていた時から60%のコストカット

Data Strategy and Operation Center まとめ • Bill Oneのプロジェクトに参加して初めてGCPを触る。プロジェクトに参加 して1カ⽉でCloud Run移⾏をリード。1500件あったスケールのエラーを解消、 コンピューティング費⽤を60%カット。 • 裁量ある環境で技術的なチャレンジもできる。 プロジェクトに⼊ったばかりの時は分からないことだらけだったが、周りのメンバー からサポートしてもらえた。 • ⼊社前はクラウドの知識0だったがクラウドの知識を⾝につけ、 アーキテクチャ設計も⾃分でできるぐらい技術的に成⻑できた。