Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Sansan
November 05, 2021

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/

Sansan

November 05, 2021
Tweet

More Decks by Sansan

Other Decks in Technology

Transcript

  1. STAGE A
    Data One Engineering Group SESSION TAG
    秋⽥ 祥平
    Data One の
    マイクロサービスアーキテクチャ

    View full-size slide

  2. 技術本部 Data One Engineeringグループ
    ソフトウェアエンジニア
    慶應義塾⼤学⼤学院理⼯学研究科修⼠課程修了。
    2020年にSansan株式会社に⼊社後、Data Oneの開発・運⽤に従事。
    最近の趣味は⼼理学関係の本を読むこと。
    秋⽥ 祥平

    View full-size slide

  3. • Data One とは
    • アーキテクチャ 〜ドメイン設計とIDEALS〜
    • ローンチ後の課題と対策
    • 今後の開発について

    View full-size slide

  4. Data One とは

    View full-size slide

  5. 獲得した顧客データを最⼤限に活⽤できない
    • データが古い
    • ⼊⼒漏れや、情報の不⾜がある
    • 表記揺れや、誤⼊⼒により利⽤できない
    • データが重複し、同⼀判定できずに泣き別れ
    Data One とは
    データ活⽤における課題
    展⽰会 Webサイト
    もったいない…

    View full-size slide

  6. Sansan や CRM・SFA、MAツールから
    取り込んだデータの名寄せ・リッチ化を⾏う
    最も正確で最新の顧客情報である「名刺」を軸に
    Sansan 独⾃の名寄せテクノロジーで統合
    ⇒ 企業のみならず⼈物情報の精度が⾼いのが特徴
    Data One とは
    社内のあらゆるデータを
    整理・統合する名寄せエンジン
    CRM
    SFA
    ERP
    取引・契約情報 リード情報
    案件情報
    法⼈情報
    法⼈基本情報
    顧客マスタ
    顧客情報
    Data One
    名刺情報
    名刺からクレンジングされた顧客マスタ
    企業と⼈物情報の精度が向上

    View full-size slide

  7. アーキテクチャ
    〜ドメイン設計とIDEALS〜

    View full-size slide

  8. • マイクロサービスアーキテクチャとは
    • アプリケーションがモノリス (⼀枚岩) ではなく、 互いに通信しながら独⽴して動く
    複数の⼩さなサービスから成り⽴つ アーキテクチャ
    • なぜマイクロサービス「的」なのか
    • マイクロサービスアーキテクチャを前提に設計したわけではないから
    ⇒ 次ページ以降、アーキテクチャの概要となぜそのようになったかを解説
    Data One はマイクロサービス的アーキテクチャ
    アーキテクチャ

    View full-size slide

  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

    View full-size slide

  10. アーキテクチャ
    Connector
    ETL
    Publishing
    IAM
    Web

    View full-size slide

  11. アーキテクチャ
    Connector
    ETL
    Publishing
    IAM
    Web

    View full-size slide

  12. アーキテクチャ
    Connector
    ETL
    Publishing
    IAM
    Web

    View full-size slide

  13. 事業に合わせて柔軟にスケールできるアーキテクチャ にする
    • クラウドプラットフォームは Azure
    > 「C# が使える」、「組織としての技術的選択肢の獲得」といった観点で選択
    • ドメイン設計を丁寧にやる
    > ドメインの境界をきちんと分けて、Service Bus で繋ぐ
    • IDEALS を意識する
    > デプロイ容易性、イベント駆動、結果整合性など
    設計時に意識したこと
    アーキテクチャ

    View full-size slide

  14. フェーズに合わせて図を描くなどして、各ドメインへの理解を深める
    • 各ドメインの責務は何か?
    • 各ドメインで扱うデータの特性は?
    > どんなデータか?何のためのデータか?
    ドメイン設計を丁寧にやる
    アーキテクチャ

    View full-size slide

  15. フェーズに合わせて図を描き、各ドメインへの理解を深める
    ⽅法にこだわらず、 ⽬的に合わせたやり⽅、粒度で描く
    アーキテクチャ
    ドメイン設計を丁寧にやる
    ER図
    システム概念図

    View full-size slide

  16. • 各ドメインは
    Azure Functions で構築
    • ドメインの境界は
    メッセージングサービス
    (Service Bus) で接続
    アーキテクチャ
    ドメイン設計を丁寧にやる
    Connector
    ETL
    Publishing
    IAM
    Web
    ドメイン境界を
    Service Busで繋ぐ

    View full-size slide

  17. Paulo Merson が2020年に提唱したマイクロサービスにおける設計原則
    ※Data One ローンチのほうが先だが、この原則に沿う設計になっているので紹介
    • Interface segregation: インターフェース分離
    • Deployability (is on you): デプロイ容易性
    • Event-driven: イベント駆動
    • Availability over consistency: 整合性よりも可⽤性
    • Loose coupling: 疎結合
    • Single responsibility: 単⼀責任
    IDEALS を意識する
    オブジェクト指向設計で
    有名なSOLID原則でもお馴染
    アーキテクチャ
    本⽇はこちらについて
    説明します

    View full-size slide

  18. ⽬的
    • Commit、Build、Test、Deploy といったプロセスを迅速化
    • バージョン更新時のダウンタイムの最⼩化
    • 障害を素早く特定して修正するためのよりよい監視の実現
    Data One でどう実現したか
    • サーバレスアーキテクチャとして Azure Functions を採⽤
    • DevOps を導⼊ ⇒ ⼩規模チームで開発/運⽤を両⽅やる
    • 監視Bot 等の導⼊ ⇒ Slack に Alert を通知
    Deployability (is on you): デプロイ容易性
    アーキテクチャ

    View full-size slide

  19. ⽬的
    • スケーラビリティの向上
    • パフォーマンスの最適化
    • サービスの部分停⽌の容易化 (メッセージを貯めておいて、再開後に処理)
    Data One でどう実現したか
    • メッセージブローカとして Service Bus を導⼊
    Event-driven: イベント駆動
    アーキテクチャ

    View full-size slide

  20. ⽬的
    • サービス利⽤不可時間の最⼩化
    > 可⽤性を優先すると整合性が犠牲に ⇒ 結果整合性を保つようにする
    > 結果整合性: 即時ではなく⼀定時間後に⼀貫性がとれていればよいという考え⽅
    Data One でどう実現したか
    • CQRS (コマンドクエリ責務分離) パターンの導⼊
    > 読み取りと書き込み⽤のDBを分け、読み取り⽤DBの結果整合性を保つようにする
    > 読み取り側がクエリしやすい、読み取り/書き込み各々で性能最適化しやすいといった利点も
    Availability over consistency: 整合性よりも可⽤性
    アーキテクチャ

    View full-size slide

  21. ⽬的
    • コンポーネントごとのパフォーマンス最適化の容易化
    • コンポーネント単位での交換の容易化
    Data One でどう実現したか
    • コンポーネント間の Contract をきちんと設計した
    > ドメイン知識に依存しないメッセージの設計
    • ドメインごとにデータストアを分けた
    > ETL では Table Storage と Elasticsearch、Publishing では SQL DB と Cosmos DB
    Loose coupling: 疎結合
    アーキテクチャ

    View full-size slide

  22. ローンチ後の課題と対策

    View full-size slide

  23. 良かったこと
    • 負荷対応がしやすい
    • ドメイン刷新、データストア変更がしやすい
    悪かったこと
    • システム全体把握がとにかく⼤変
    ローンチ後の課題と対策
    マイクロサービスで良かったこと / 悪かったこと

    View full-size slide

  24. ⼤量データの流⼊で Service Bus のメッセージを捌き切れなくなった
    • データ化した名刺や少量のデータは素早く処理したい
    > Service Bus にキューを複数⽤意し、優先度順に流し分けた
    負荷対応事例: 優先度キュー対応
    アプリケーション
    コンシューマー
    コンシューマー
    優先度: ⾼ のキュー
    優先度: 低 のキュー
    名刺など素早く処理したいデータ
    上記以外のデータ
    ローンチ後の課題と対策

    View full-size slide

  25. 運⽤性改善のため実施
    • 書き込みのログが追いづらい / 追えないといった状況があった
    • 書き込みに異常が発⽣した場合などの検知が難しかった
    やったこと
    • 書き込みログの保存先を SQL DB から Cosmos DB に移⾏
    > データが増えてもコスパが良く、クエリもきちんとできる Cosmos DB を選択
    • Publishing ドメインを 2 つに分け、どこで異常が起こっているかを分かりやすくした
    改修事例: Publishing ドメイン刷新 (Pub v2)
    ローンチ後の課題と対策

    View full-size slide

  26. 改修事例: Publishing ドメイン刷新 (Pub v2)
    ローンチ後の課題と対策
    Publishing
    Workflow Dataset
    書き込みに必要な
    データを集約
    どの Action を
    ⾏うべきか評価
    (新規作成、更新など)

    View full-size slide

  27. マイクロサービスの恩恵
    • 規模の⼤きな変更がしやすい
    > ログのデータストアの変更
    > Publishing ドメインを細分化
    • サービスを無停⽌でマイグレーションできる
    > Pub v1 と Pub v2 を並⾏稼働させ、徐々に移⾏
    • 他のドメインの変更はほぼ無し
    改修事例: Publishing ドメイン刷新 (Pub v2)
    後から変更が容易
    = 決定を先送りできる
    ローンチ後の課題と対策

    View full-size slide

  28. • サービスが分散しているので全体像を把握しづらい
    • 特にドメインをまたぐ改修の設計に時間がかかる
    • ドメインをまたぐ異常が起こった場合の調査が⼤変
    • システム全体像の理解促進のため、C4 モデルを導⼊中
    • コンテキスト、コンテナ、コンポーネント、コードの4つの階層からなるアーキテクチャ図
    • 階層ごとに図に起こすことで、知りたい粒度でシステム像を理解できる
    システム全体把握の難しさ
    ローンチ後の課題と対策

    View full-size slide

  29. 今後の開発について

    View full-size slide

  30. 現状 App Service Plan の VM 上で Function が動いている
    • 当時コンテナの運⽤知識が無かった
    • リソース調整は VM (正確には App Service Plan) 単位
    > App Service は PaaS なので管理範囲はアプリケーションのみ
    > 処理の重い Function や処理負荷が⽐例する Function を
    別の VM に分ければさほど不便はない
    Azure Functions をコンテナ上で動かす
    今後の開発について
    ハードウェア
    ホストOS
    ハイパーバイザー
    ゲストOS ゲストOS
    MS が
    管理
    Azure
    Functions

    View full-size slide

  31. 将来的にコンテナ上で Azure Functions を動かすことを検討
    • より細かい単位で柔軟にリソースを管理できる
    > マイクロサービスの恩恵を最⼤限に受けられる
    Azure Functions をコンテナ上で動かす
    今後の開発について
    ゲストOS
    コンテナーエンジン
    コンテナを
    Kubernetes で
    管理
    ハードウェア
    ホストOS
    ハイパーバイザー
    ゲストOS ゲストOS
    MS が
    管理
    Azure
    Functions

    View full-size slide

  32. コンウェイの法則: システムを設計する組織の構造は、アプリケーションの構造に反映される
    • 逆に⾔えば、アプリケーションの構造は組織構造に反映される
    • マイクロサービスアーキテクチャなら⼩さなチームに分けやすい
    将来的にドメイン別チームを検討
    • 現状、Data One のコア部分は1つのチームで開発している
    • プロダクト規模が⼤きくなったらドメイン別にチームを分けたい
    チーム編成の⾒直し
    今後の開発について

    View full-size slide

  33. Data One Engineering Group Virtual Card
    秋⽥ 祥平
    Eight

    View full-size slide