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

Microservice, Data, and Data Mesh

hashi
February 17, 2022

Microservice, Data, and Data Mesh

Developers Summit 2022 登壇資料

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

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

hashi

February 17, 2022
Tweet

More Decks by hashi

Other Decks in Technology

Transcript

  1. 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.
  2. Microservices - circa 2012 5 Order Payment Credit Shipment ドメインモデル毎に独立したシステムと

    して設計/構築/運用。各々が個別のリ リースサイクルを持ち、個別にスケール することを前提とした自立型モデル。 • API = ドメインモデルの表現 • Product Mindset • 横断的な可観測性の確保
  3. How to Find the Domain Border? 6 Event Storming -

    Roberto Baltolini提唱のモデリング技法 • 事業部横断的にドメインとユビキタス言語の定義。 • Event (Fact) の集合から境界 (Bounded Context) を導き出す。 統合データモデルからも事業 部署でも境界を引かない。 それぞれのドメインモデルを 言語化する。 “Event Storming”, avanscoperta.
  4. Real Life Use Case - Life Insurance 8 Sales Policy

    Admin Claims Life Planning Illustration Application Life Planning: お客様の収支情報と将来的 な予測を収集しライフプラ ンを定義する。その上で万 が一の際にどのような保障 が必要かを特定する。 Illustration: 必要な保障に対し様々な製 品(もしくは製品の組み合 わせ)を当てはめ、条件を 微調整しながら保障と保険 料のベストバランスを見つ ける。 Application: 契約に必要な全ての情報を 収集する。
  5. 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
  6. 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
  7. 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
  8. 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
  9. Microservice Challenges - Orchestration 14 Independent Scalability コンポーネント単位でデプロイ&ス ケール可能。アプリケーションの 成長に応じて個々が独自のライフ

    サイクルによってサービスを管 理。個々のスケールが可能 - ボト ルネックとなる局所のみの増強に より全体スループットを向上。 Cascading Failure (連鎖障害) あるサービスが応答出来なくなると、その サービスにリクエストするサービスが応答不 能となる。1サービスの障害、高負荷による反 応速度低下が全体的な停止/パフォーマンス低 下に繋がる。 Data Consistency サービス毎に独立したデータストアを持つ - 異なるサービス間でデータ整合性を保つ必要 がある。2PCやSagaの様なパターンではデー タ同期コストが高く処理も複雑になる。ス ケールしにくい。
  10. Kafka-Based Durable Event Driven Architecture 15 Pull Model Pushモデルである為バックプレッシャーが不要 -

    Consumerをスケールする事により、他に影響を与 えず個別に対応。また一般的なMessage Brokerとは 異なり、同じストリームのConsumerが増えても Brokerの負荷にほとんど影響を与えない。 Durable Streams Brokerが任意の期間ストリームを保持できる為、 Consumeによる遅延は発生してもデータの欠損を起 こさない。Consumerが追いつく為の時間的バッ ファーが生まれる。
  11. CQRS and Change Data Capture - Consistent Data 16 CQRS

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

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

    in Apache Kafka: A Primer”, Michael Noll, Confluent Blog. チェスの一手一手とチェス盤の状態は 同じデータの異なる表現方法。 • チェス盤はある特定時点での完全な 状態 (State) を表現できる。 • チェスの一手一手を漏れなく、順序 通り適用すればチェス盤の状態を再 現できる。
  14. 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
  15. 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
  16. 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
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. Mesh - Organic Connections of Domains by Data 28 Domain

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