Microservice, Data, and Data Mesh

Developers Summit 2022 登壇資料

アプリの世界観が変わり、分散システムが特別な選択肢では無い事も増えてきました。アプリをより小さな単位で構成する概念は広く認知されましたが、一方、データストアの分割、分割されたデータストア間での整合性の確保にはまだ多くの課題があります。

本セッションでは分散システムにおけるデータ整合性と、それを支えるApache Kafkaの役割についてご説明します。また将来のステップとして、ドメイン駆動化されたデータを"Data as a Product"として横断的に活用するData Meshの構想についてご説明します。

Transcript

1. Developers Summit 2022
   Microservices, Data, and Data Mesh
   Shinichi Hashitani
   Solutions Engineer
   

   View Slide

2. Microservices and Data
   - データを生むサービスとサービスを支えるデータ
   

   View Slide

3. Hexagonal Architecture - circa 2002
   3
   Entity Entity
   Use Case
   Use Case
   Web Adopter
   UI Adopter
   DB Adoptar Lake
   Adopter
   Alistair Cockburnが提唱したアプリケーショ
   ンアーキテクチャの概論。Ports and
   Adapters Patternとも呼ばれる。アジャイル
   前提。Object指向前提。アクセスは外から
   中、依存関係は中から外の一方通行。
   ● Entity - Domain Modelの体現。ロジック
   を含まない。
   ● Use Case - Entityを扱い業務ロジックの実
   装を司る。
   ● Adopter - 業務モデルと外部の接続を司
   る。境界定義はAPI。
   “ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)”, Taiji Muto.
   

   View Slide

4. 4
   依存関係は中から外へ
   中心はドメインオブジェクト
   

   View Slide

5. Microservices - circa 2012
   5
   Order
   Payment
   Credit
   Shipment
   ドメインモデル毎に独立したシステムと
   して設計/構築/運用。各々が個別のリ
   リースサイクルを持ち、個別にスケール
   することを前提とした自立型モデル。
   ● API = ドメインモデルの表現
   ● Product Mindset
   ● 横断的な可観測性の確保
   

   View Slide

6. How to Find the Domain Border?
   6
   Event Storming - Roberto Baltolini提唱のモデリング技法
   ● 事業部横断的にドメインとユビキタス言語の定義。
   ● Event (Fact) の集合から境界 (Bounded Context) を導き出す。
   統合データモデルからも事業
   部署でも境界を引かない。
   それぞれのドメインモデルを
   言語化する。
   “Event Storming”, avanscoperta.
   

   View Slide

7. 7
   ドメインモデルの境界 = システムの境界
   統合データモデルとの決別
   

   View Slide

8. Real Life Use Case - Life Insurance
   8
   Sales
   Policy
   Admin
   Claims
   Life
   Planning
   Illustration Application
   Life Planning:
   お客様の収支情報と将来的
   な予測を収集しライフプラ
   ンを定義する。その上で万
   が一の際にどのような保障
   が必要かを特定する。
   Illustration:
   必要な保障に対し様々な製
   品（もしくは製品の組み合
   わせ）を当てはめ、条件を
   微調整しながら保障と保険
   料のベストバランスを見つ
   ける。
   Application:
   契約に必要な全ての情報を
   収集する。
   

   View Slide

9. People Data in Sales Process
   9
   Family
   Head of
   Household
   Children
   Spouse
   ✔ Age
   ✔ Income
   ✔ Non-Salary Income
   ✔ Disposable Income
   ✔ Occupation
   ✔ Age
   ✔ Income
   ✔ Age
   ✔ School
   Proposal
   ✔ Age
   ✔ Gender
   ✔ Smoker Status
   Policy Holder
   Insured Beneficiary
   ✔ Name
   ✔ Gender
   ✔ DOB
   ✔ Address
   ✔ Phone #
   ✔ Occupation
   ✔ Income
   ✔ Name
   ✔ Gender
   ✔ DOB
   ✔ Address
   ✔ Phone #
   ✔ Occupation
   ✔ Name
   ✔ Relationship
   

   View Slide

10. Modeling Data in Each Process
    10
    + Family ID
    - Household Type
    - Total Income
    Family
    + Child ID
    - Age
    - School Type
    Child
    + Household Head ID
    - Gender
    - Occupation
    - Salary Income
    - Non-Salary Income
    - Disposable Income
    Household Head
    + Spouse ID
    - Age
    - Income
    Child
    …
    - Age
    - Gender
    - Smoker Status
    …
    Proposal
    + Policyholder ID
    - Name
    - DOB
    - Gender
    - Address
    - Phone #
    - Occupation
    - Income
    Policyholder
    + Insured ID
    - Name
    - DOB
    - Gender
    - Address
    - Phone #
    - Occupation
    Insured
    + Beneficiary ID
    - Name
    - Relationship
    Beneficiary
    

    View Slide

11. Canonical Data Model - Unified View
    11
    + Customer ID
    - Name
    - BOD
    - Age
    - Gender
    - Occupation
    - Income
    - Salary Income
    - Non-Salary Income
    - Disposable Income
    - School Type
    - Smoker Status
    Customer
    + Family ID
    - Household Type
    - Total Income
    Family
    + Proposal ID
    - Date of Issue
    - Valid Period
    Proposal
    + Illustration ID
    - Date of Issue
    Illustration
    + Application ID
    - Date of Issue
    - Valid Period
    - Submit Date
    Application
    + Illustration ID
    - Customer ID
    - Relationship
    - Customer Type
    Illus to Cust
    + Application ID
    - Customer ID
    - Relationship
    - Customer Type
    App to Cust
    Proposal
    ✔ Age
    ✔ Gender
    ✔ Smoker Status
    

    View Slide

12. Ubiquitous Language
    12
    Spec
    Code
    Data
    Life Planning Illustration Application
    Homeowner Insured Policyholder
    Homeowner
    Customer
    Insured
    Customer
    Policyholder
    Customer
    Customer
    Life Planning Illustration Application
    Policyholder
    Beneficiary
    Homeowner
    Spouse
    Insured
    

    View Slide

13. Apache Kafka®
    - マイクロサービスとデータを繋げる
    

    View Slide

14. Microservice Challenges - Orchestration
    14
    Independent Scalability
    コンポーネント単位でデプロイ&ス
    ケール可能。アプリケーションの
    成長に応じて個々が独自のライフ
    サイクルによってサービスを管
    理。個々のスケールが可能 - ボト
    ルネックとなる局所のみの増強に
    より全体スループットを向上。
    Cascading Failure (連鎖障害)
    あるサービスが応答出来なくなると、その
    サービスにリクエストするサービスが応答不
    能となる。1サービスの障害、高負荷による反
    応速度低下が全体的な停止/パフォーマンス低
    下に繋がる。
    Data Consistency
    サービス毎に独立したデータストアを持つ -
    異なるサービス間でデータ整合性を保つ必要
    がある。2PCやSagaの様なパターンではデー
    タ同期コストが高く処理も複雑になる。ス
    ケールしにくい。
    

    View Slide

15. Kafka-Based Durable Event Driven Architecture
    15
    Pull Model
    Pushモデルである為バックプレッシャーが不要 -
    Consumerをスケールする事により、他に影響を与
    えず個別に対応。また一般的なMessage Brokerとは
    異なり、同じストリームのConsumerが増えても
    Brokerの負荷にほとんど影響を与えない。
    Durable Streams
    Brokerが任意の期間ストリームを保持できる為、
    Consumeによる遅延は発生してもデータの欠損を起
    こさない。Consumerが追いつく為の時間的バッ
    ファーが生まれる。
    

    View Slide

16. CQRS and Change Data Capture - Consistent Data
    16
    CQRS
    Command Query Responsibility
    Segregation - CRUD (Command) と検索
    (Query) の役割とデータストアを分離するア
    プローチ。既存システムへの影響を抑えつ
    つ、ボトルネックになりがちな検索機能を別
    のサービスとして切り離す。
    Change Data Capture
    データベースの更新を抽出/イベント化し連
    携することで、別データストア間のデータ整
    合性を非同期に保つ手法。更新イベントは漏
    れなく、順序通り連携する必要がある。
    Command Query
    

    View Slide

17. Stream Processing - Data Processing in Transit
    17
    Event Store
    分散ストレージというアーキテクチャを採用 -
    イベントは自動的にレプリケートされ保全対
    象となる。保全期間は数時間から数ヶ月、用
    途 (ストリーム) 単位に柔軟に設定が可能。
    イベントは保全期間内であれば何度でもリプ
    レイ可能。
    Event Streams
    個々のサービスはKafkaからイベントを受領、
    加工し、アウトプットとしてイベントを出力。
    アプリケーションは非同期処理のチェーンに
    よって構成され、処理の流れがストリームとし
    て組織全体を流れる。
    

    View Slide

18. Event, Total Order, and Data Consistency
    18
    “Streams and Tables in Apache Kafka: A Primer”, Michael Noll, Confluent Blog.
    チェスの一手一手とチェス盤の状態は
    同じデータの異なる表現方法。
    • チェス盤はある特定時点での完全な
    状態 (State) を表現できる。
    • チェスの一手一手を漏れなく、順序
    通り適用すればチェス盤の状態を再
    現できる。
    

    View Slide

19. Why Kafka? - Kafka Keeps Data Consistent
    19
    イベントはトランザクションログとして保存
    イベントはログとして永続化され、同じイベント
    を何度でも読み込み処理する事が可能。Pullモデ
    ルでもある為、イベントを漏れなく順序通り高速
    に連携出来る仕組みとなっている。
    customer login
    order confirmed
    order updated
    customer logout
    order canceled
    Append-Only
    Immutable
    1 2 3 4 5 6 8
    7 10
    9 11 12
    1 2 3 4 5 6 8
    7
    Old New
    

    View Slide

20. Kafka is a Durable Storage Supporting Concurrency
    20
    Broker 1 Broker 2 Broker 3 Broker 4
    Topic1
    partition1
    Topic1
    partition2
    Topic1
    partition3
    Topic1
    partition4
    Topic1
    partition1
    Topic1
    partition1
    Topic1
    partition2
    Topic1
    partition2
    Topic1
    partition3
    Topic1
    partition3
    Topic1
    partition4
    Topic1
    partition4
    Concurrent Access
    Data
    Replication
    

    View Slide

21. Next 10 Years with Data
    - Data Mesh and Data-as-a-Product
    

    View Slide

22. What Happened in Tech in 10 Years
    22
    2014
    2011 2017
    Data Mesh
    2020
    React
    Kotlin
    Microservices
    Spring Boot
    Microservices
    Kubernetes
    Terraform
    Prometheus
    AWS Lambda
    gRPC
    GraphQL
    Argo CD
    SRE
    Apache Kafka
    Apache Druid
    Big Query
    Elasticsearch
    RocksDB
    Snowflake
    Cloud Spanner
    TiDB
    Apache Spark
    Amazon Aurora
    Tensorflow
    

    View Slide

23. Compute and Data - Widening Gap
    23
    Compute
    Data
    Distributed
    Aggregated
    

    View Slide

24. The Learning from the Last Decade
    24
    Keep agility to adopt
    increasing needs.
    Remove coordination
    bottlenecks.
    Align business, tech,
    and now data.
    「データ集約→ダッシュボード
    化」の世界から、データ量も利用
    領域も飛躍的に拡大している。組
    織のあらゆる部署がデータを必要
    としている。
    データはどこか特定の場所に集約/
    集計され、特定チームが運営し、
    特定の形態でしか提供できないの
    ではデータの利用は広がらない。
    「データ活用には集約」という神
    話からと統合データモデルからの
    脱却 - データは集約から分散へ。
    データの発生場所と利用場所、こ
    れらを直接的に繋げる。第三者が
    運用する「パイプライン」に依存
    したデータ移送は常に経済的/時間
    的/人的コストがつきまとう。
    ビジネスの動きに合わせてシステ
    ムは分散されつつある。ドメイン
    駆動、プロダクト マインドセット
    と、組織/技術両面においてシステ
    ムの新しいあり方が広がる。
    次の明確なステップとして、その
    流れに呼応する形でデータのあり
    方も変わる必要がある。
    “Data Mesh” ch. 2, Zhamak Dehghani, 2022, O’Reilly Media.
    

    View Slide

25. Data Mesh - from Aggregation to Distribution
    25
    E
    T
    L
    Unified
    Data
    Platform
    E
    T
    L
    E
    T
    L
    E
    T
    L
    T
    T
    T
    T
    T
    Data Platform / Tools
    “Data Mesh” ch. 2, Zhamak Dehghani, 2022, O’Reilly Media.
    

    View Slide

26. Data Mesh - Domain Data as a Product
    26
    Plan
    ning
    Illust
    ration
    Appli
    cation
    E
    T
    L
    E T
    L
    E T
    L
    Planning
    API
    Data
    Illustrati
    on
    API
    Data
    Applicat
    ion
    API
    Data
    Pricing
    API
    Validat
    ion
    API
    T
    T
    T
    “Data Mesh” ch. 2, Zhamak Dehghani, 2022, O’Reilly Media.
    

    View Slide

27. Data Product Quantum - Connecting Two Planes
    27
    API
    Data
    Product
    Quantum
    Self Service Infrastructure
    Quan
    tum
    Quan
    tum
    Quan
    tum
    Data Product Quantum
    ドメイン内のデータをData
    Productとして提供する上で
    アーキテクチャのユニット。
    利用するデータテクノロジー
    の複雑さを隠蔽し、かつ提供
    するData Productがプロダク
    トとして成立する為に必要な
    特性を補完する。
    Discoverable
    Secure
    Trustworthy
    Composable
    Natively Available
    “Data Mesh” ch. 2, Zhamak Dehghani, 2022, O’Reilly Media.
    

    View Slide

28. Mesh - Organic Connections of Domains by Data
    28
    Domain
    Sales
    Policy Admin
    Claims
    ...
    Data
    Product
    データの分析と利用は組織
    全体のニーズに拡大
    データは広く共有され、利用者は
    データ所有者から直接消費。
    データは各々のドメイン保
    有/運用
    データ品質/有益性はドメインの
    責任で加工し利用者に提供。
    データはサービス (API) 同
    様にドメインで運用可能
    既存スキルセット+αでデータを
    プロダクトとして提供できる。
    

    View Slide

29. Domain-driven
    Decentralization
    データの分散 - 独立
    したドメイン毎のオー
    ナーシップ
    Data as a
    First-class Product
    Productマインドセッ
    ト - データのプロダ
    クト化
    Federated
    Governance
    データの利用促進と横
    断的ガバナンス
    Self-serve
    Data Platform
    一般スキルでData
    Productが提供可能な
    プラットフォーム
    1 2 3 4
    The Principles of a Data Mesh
    “Data Mesh” Part II, Zhamak Dehghani, 2022, O’Reilly Media.
    

    View Slide

30. View Slide