Data Oneのマイクロサービスアーキテクチャ / Data One's microservice architecture

■イベント

Sansan Builders Stage 2021

https://jp.corp-sansan.com/engineering/buildersstage2021/

■登壇概要

タイトル：
Data Oneのマイクロサービスアーキテクチャ
登壇者：技術本部 Data One Engineeringグループ　ソフトウェアエンジニア　秋田 祥平

▼Sansan Engineering
https://jp.corp-sansan.com/engineering/

1. STAGE A Data One Engineering Group SESSION TAG 秋⽥ 祥平 Data One の マイクロサービスアーキテクチャ
2. 技術本部 Data One Engineeringグループ ソフトウェアエンジニア 慶應義塾⼤学⼤学院理⼯学研究科修⼠課程修了。 2020年にSansan株式会社に⼊社後、Data Oneの開発・運⽤に従事。 最近の趣味は⼼理学関係の本を読むこと。 秋⽥ 祥平
3. • Data One とは • アーキテクチャ 〜ドメイン設計とIDEALS〜 • ローンチ後の課題と対策 • 今後の開発について
4. Data One とは
5. 獲得した顧客データを最⼤限に活⽤できない • データが古い • ⼊⼒漏れや、情報の不⾜がある • 表記揺れや、誤⼊⼒により利⽤できない • データが重複し、同⼀判定できずに泣き別れ Data One とは データ活⽤における課題 展⽰会 Webサイト もったいない…
6. Sansan や CRM・SFA、MAツールから 取り込んだデータの名寄せ・リッチ化を⾏う 最も正確で最新の顧客情報である「名刺」を軸に Sansan 独⾃の名寄せテクノロジーで統合 ⇒ 企業のみならず⼈物情報の精度が⾼いのが特徴 Data One とは 社内のあらゆるデータを 整理・統合する名寄せエンジン CRM SFA ERP 取引・契約情報 リード情報 案件情報 法⼈情報 法⼈基本情報 顧客マスタ 顧客情報 Data One 名刺情報 名刺からクレンジングされた顧客マスタ 企業と⼈物情報の精度が向上
7. アーキテクチャ 〜ドメイン設計とIDEALS〜
8. • マイクロサービスアーキテクチャとは • アプリケーションがモノリス (⼀枚岩) ではなく、 互いに通信しながら独⽴して動く 複数の⼩さなサービスから成り⽴つ アーキテクチャ • なぜマイクロサービス「的」なのか • マイクロサービスアーキテクチャを前提に設計したわけではないから ⇒ 次ページ以降、アーキテクチャの概要となぜそのようになったかを解説 Data One はマイクロサービス的アーキテクチャ アーキテクチャ
9. • Connector ドメイン 外部 SaaS との連携 • ETL ドメイン Transform と Load • Publishing ドメイン 書き込むデータの準備 どの Action を⾏うべきか評価 アーキテクチャ 概念図 SaaS ETL Transform Extract [Salesforce] Create Record [Salesforce] Update Record [Marketo] Post Leads Connector Actions … Organizations Business Locations Persons Publishing Evaluate Workflow Dataset … … Data Store Connector Data Sources Standard Data Sources
10. アーキテクチャ Connector ETL Publishing IAM Web
11. アーキテクチャ Connector ETL Publishing IAM Web
12. アーキテクチャ Connector ETL Publishing IAM Web
13. 事業に合わせて柔軟にスケールできるアーキテクチャ にする • クラウドプラットフォームは Azure > 「C# が使える」、「組織としての技術的選択肢の獲得」といった観点で選択 • ドメイン設計を丁寧にやる > ドメインの境界をきちんと分けて、Service Bus で繋ぐ • IDEALS を意識する > デプロイ容易性、イベント駆動、結果整合性など 設計時に意識したこと アーキテクチャ
14. フェーズに合わせて図を描くなどして、各ドメインへの理解を深める • 各ドメインの責務は何か？ • 各ドメインで扱うデータの特性は？ > どんなデータか？何のためのデータか？ ドメイン設計を丁寧にやる アーキテクチャ
15. フェーズに合わせて図を描き、各ドメインへの理解を深める ⽅法にこだわらず、 ⽬的に合わせたやり⽅、粒度で描く アーキテクチャ ドメイン設計を丁寧にやる ER図 システム概念図
16. • 各ドメインは Azure Functions で構築 • ドメインの境界は メッセージングサービス (Service Bus) で接続 アーキテクチャ ドメイン設計を丁寧にやる Connector ETL Publishing IAM Web ドメイン境界を Service Busで繋ぐ
17. Paulo Merson が2020年に提唱したマイクロサービスにおける設計原則 ※Data One ローンチのほうが先だが、この原則に沿う設計になっているので紹介 • Interface segregation: インターフェース分離 • Deployability (is on you): デプロイ容易性 • Event-driven: イベント駆動 • Availability over consistency: 整合性よりも可⽤性 • Loose coupling: 疎結合 • Single responsibility: 単⼀責任 IDEALS を意識する オブジェクト指向設計で 有名なSOLID原則でもお馴染 アーキテクチャ 本⽇はこちらについて 説明します
18. ⽬的 • Commit、Build、Test、Deploy といったプロセスを迅速化 • バージョン更新時のダウンタイムの最⼩化 • 障害を素早く特定して修正するためのよりよい監視の実現 Data One でどう実現したか • サーバレスアーキテクチャとして Azure Functions を採⽤ • DevOps を導⼊ ⇒ ⼩規模チームで開発/運⽤を両⽅やる • 監視Bot 等の導⼊ ⇒ Slack に Alert を通知 Deployability (is on you): デプロイ容易性 アーキテクチャ
19. ⽬的 • スケーラビリティの向上 • パフォーマンスの最適化 • サービスの部分停⽌の容易化 (メッセージを貯めておいて、再開後に処理) Data One でどう実現したか • メッセージブローカとして Service Bus を導⼊ Event-driven: イベント駆動 アーキテクチャ
20. ⽬的 • サービス利⽤不可時間の最⼩化 > 可⽤性を優先すると整合性が犠牲に ⇒ 結果整合性を保つようにする > 結果整合性: 即時ではなく⼀定時間後に⼀貫性がとれていればよいという考え⽅ Data One でどう実現したか • CQRS (コマンドクエリ責務分離) パターンの導⼊ > 読み取りと書き込み⽤のDBを分け、読み取り⽤DBの結果整合性を保つようにする > 読み取り側がクエリしやすい、読み取り/書き込み各々で性能最適化しやすいといった利点も Availability over consistency: 整合性よりも可⽤性 アーキテクチャ
21. ⽬的 • コンポーネントごとのパフォーマンス最適化の容易化 • コンポーネント単位での交換の容易化 Data One でどう実現したか • コンポーネント間の Contract をきちんと設計した > ドメイン知識に依存しないメッセージの設計 • ドメインごとにデータストアを分けた > ETL では Table Storage と Elasticsearch、Publishing では SQL DB と Cosmos DB Loose coupling: 疎結合 アーキテクチャ
22. ローンチ後の課題と対策
23. 良かったこと • 負荷対応がしやすい • ドメイン刷新、データストア変更がしやすい 悪かったこと • システム全体把握がとにかく⼤変 ローンチ後の課題と対策 マイクロサービスで良かったこと / 悪かったこと
24. ⼤量データの流⼊で Service Bus のメッセージを捌き切れなくなった • データ化した名刺や少量のデータは素早く処理したい > Service Bus にキューを複数⽤意し、優先度順に流し分けた 負荷対応事例: 優先度キュー対応 アプリケーション コンシューマー コンシューマー 優先度: ⾼ のキュー 優先度: 低 のキュー 名刺など素早く処理したいデータ 上記以外のデータ ローンチ後の課題と対策
25. 運⽤性改善のため実施 • 書き込みのログが追いづらい / 追えないといった状況があった • 書き込みに異常が発⽣した場合などの検知が難しかった やったこと • 書き込みログの保存先を SQL DB から Cosmos DB に移⾏ > データが増えてもコスパが良く、クエリもきちんとできる Cosmos DB を選択 • Publishing ドメインを 2 つに分け、どこで異常が起こっているかを分かりやすくした 改修事例: Publishing ドメイン刷新 (Pub v2) ローンチ後の課題と対策
26. 改修事例: Publishing ドメイン刷新 (Pub v2) ローンチ後の課題と対策 Publishing Workflow Dataset 書き込みに必要な データを集約 どの Action を ⾏うべきか評価 (新規作成、更新など)
27. マイクロサービスの恩恵 • 規模の⼤きな変更がしやすい > ログのデータストアの変更 > Publishing ドメインを細分化 • サービスを無停⽌でマイグレーションできる > Pub v1 と Pub v2 を並⾏稼働させ、徐々に移⾏ • 他のドメインの変更はほぼ無し 改修事例: Publishing ドメイン刷新 (Pub v2) 後から変更が容易 = 決定を先送りできる ローンチ後の課題と対策
28. • サービスが分散しているので全体像を把握しづらい • 特にドメインをまたぐ改修の設計に時間がかかる • ドメインをまたぐ異常が起こった場合の調査が⼤変 • システム全体像の理解促進のため、C4 モデルを導⼊中 • コンテキスト、コンテナ、コンポーネント、コードの4つの階層からなるアーキテクチャ図 • 階層ごとに図に起こすことで、知りたい粒度でシステム像を理解できる システム全体把握の難しさ ローンチ後の課題と対策
29. 今後の開発について
30. 現状 App Service Plan の VM 上で Function が動いている • 当時コンテナの運⽤知識が無かった • リソース調整は VM (正確には App Service Plan) 単位 > App Service は PaaS なので管理範囲はアプリケーションのみ > 処理の重い Function や処理負荷が⽐例する Function を 別の VM に分ければさほど不便はない Azure Functions をコンテナ上で動かす 今後の開発について ハードウェア ホストOS ハイパーバイザー ゲストOS ゲストOS MS が 管理 Azure Functions
31. 将来的にコンテナ上で Azure Functions を動かすことを検討 • より細かい単位で柔軟にリソースを管理できる > マイクロサービスの恩恵を最⼤限に受けられる Azure Functions をコンテナ上で動かす 今後の開発について ゲストOS コンテナーエンジン コンテナを Kubernetes で 管理 ハードウェア ホストOS ハイパーバイザー ゲストOS ゲストOS MS が 管理 Azure Functions
32. コンウェイの法則: システムを設計する組織の構造は、アプリケーションの構造に反映される • 逆に⾔えば、アプリケーションの構造は組織構造に反映される • マイクロサービスアーキテクチャなら⼩さなチームに分けやすい 将来的にドメイン別チームを検討 • 現状、Data One のコア部分は1つのチームで開発している • プロダクト規模が⼤きくなったらドメイン別にチームを分けたい チーム編成の⾒直し 今後の開発について
33. Data One Engineering Group Virtual Card 秋⽥ 祥平 Eight