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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Compute and Data - Widening Gap 23 Compute Data Distributed Aggregated

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.

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.

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.

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.

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

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.

No content