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

Apache_Kafka_and_Modernization.pdf

hashi
October 25, 2022
51

 Apache_Kafka_and_Modernization.pdf

hashi

October 25, 2022
Tweet

Transcript

  1. YugabyteDB Japan Hour #5 Apache Kafka® and Modernization - How

    Old Data Meets New Data Shinichi Hashitani, Solutions Engineer, Oct. 2022. #YugabyteDB #Confluent
  2. @ShinHashitani | developer.confluent.io #1 New Apps - Microservices Independent Scalability

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

    - CRUD (Command) と検索 (Query) の役割とデー タストアを分離するアプローチ。既存システム への影響を抑えつつ、ボトルネックになりがち な検索機能を別のサービスとして切り離す。 Change Data Capture データベースの更新を抽出/イベント化し連携す ることで、別データストア間のデータ整合性を 非同期に保つ手法。更新イベントは漏れなく、 順序通り連携する必要がある。 Command Query
  4. @ShinHashitani | developer.confluent.io #3 Monolith Decomposition (Stranglar) 段階的オフロード アプリの機能性は損なわず、基幹 系の主機能以外を部分的に分離。

    ドメイン毎に独立したサービスと して切り出す。 基幹系の延命 or リプレース アドオンや付随する別ドメインの機能を全 て切り離すことにより基幹系自体の更新が 容易になる。場合によっては最後に残った コアも新規のサービスでリプレースする。
  5. @ShinHashitani | developer.confluent.io Event, Total Order, and Data Consistency “Streams

    and Tables in Apache Kafka: A Primer”, Michael Noll, Confluent Blog. チェスの一手一手とチェス盤の状態は 同じデータの異なる表現方法。 • チェス盤はある特定時点での完全な状 態 (State) を表現できる。 • チェスの一手一手を漏れなく順序通り 適用すればチェス盤の状態を再現でき る。
  6. @ShinHashitani | developer.confluent.io How Database Works fsync buffer load 処理は全てメモリ上でなされる。

    処理に必要なデータはメモリに読み込 まれる。処理後更新されたデータは定 期的にストレージと同期される。 処理はログとして記録される。 障害発生時、ストレージへの同期が未 完の処理を漏れなく順序通り実行する ことでデータを復元する。
  7. @ShinHashitani | developer.confluent.io How Kafka Works customer login: abc order

    confirmed: #001 order updated: #002 customer login: efg order canceled: #003 package received: #a01 at dist center: #b02 left dist center: #a02 delivered: #a01 customer C: 0001 order U: 0003 payment U: 0002 payment C: 0003 customer U: 0002 store-order order confirmed: #001 order updated: #002 order canceled: #003 store-customer customer login: abc customer login: efg logistic package received: #a01 left dist center: #a02 delivered: #a01 at dist center: #b02 orderdb-c customer C: 0001 customer U: 0002 orderdb-o order U: 0003 orderdb-p payment C: 0003 payment U: 0002
  8. @ShinHashitani | developer.confluent.io How Kafka Stores Data イベントはトランザクションログとして保存 イベントはログとして永続化され、同じイベント を何度でも読み込み処理する事が可能。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
  9. @ShinHashitani | developer.confluent.io Kafka Connect - あらゆるSource/Sinkと繋げる Oracle SQL Server

    DB2 Elastic Yugabyte Kafka Connect API Kafka Pipeline Connector Connector Connector Connector Connector Connector Sources Sinks S3 Kafka標準の接続API 様々なデータストアと接続し、 差分更新の取得とトラッキング を標準化した仕様。どの Source/Sinkとも一貫した方法 で接続できる。 実装であるConnectorは接続情 報を設定するだけで利用可能 - 更新情報がKafkaにデータとし て渡る or データをターゲット に更新する。
  10. @ShinHashitani | developer.confluent.io ksqlDB - リアルタイム処理 with SQL Kafka Storage

    Capture events, launch connectors Perform continuous transformations (aggregate, filter, join) Create materialized views Serve lookups against materialized views Transform Filter Join Aggregate Window Query End-to-Endのリアルタイムデータフローを SQLで実現 ksqlDB Compute Introduction to ksqlDB
  11. @ShinHashitani | developer.confluent.io Old Data Meets New Data Platform Destination

    Systems Source Systems Oracle Database CDC Connector PostgreSQL Extract Load Transform Schema Registry ksqlDB Security Governance Resiliency 様々なデータソースから Kafka Connectを利用して Kafkaにリアルタイム イベントとして転送 1 2 3 ストリームとして流れているデータに対 してksqlDBによってリアルタイムに加工 加工を終えたストリームを Kafka Connectを利用してタ イムリーにシンクにフィード
  12. @ShinHashitani | developer.confluent.io How and When to Consume Data Oracle

    Database Old Data to New Platform Clickstream Edge/IoT Real-Time Processing Data as a Product Data Analytics ACID Transaction Massive Recordset Real-Time Alert Master Data Mgmt Fraud Detection User Interaction Inventory Financial Transactions Source of Truth どこでデータを消費するのか? 時系列データの即時集計、不正検知、ユーザー エンドポイントとの通信等、データの鮮度とリ アルタイム性が高い処理はKafka/ksqlDBによ る処理が向いている。しかしユースケースの多 くはSource of Truthに関わるトランザクショ ン処理。ここではYugabyteの様な堅牢かつ可 用性の高いストレージが重要な役割を果たす。 誰がデータを消費するのか? リアルタイム処理の作法には慣れと異なる経験 値が必要。開発者が求めるデータアクセスはリ レーショナルモデルが一般的。より多くの開発 者がデータを利用するためには、彼らに馴染み のあるYugabyteの方がリーチを広げやすい。
  13. @ShinHashitani | developer.confluent.io Central Nervous System and New Source of

    Truth Old Source of Truth Oracle Database New Source of Truth New Data Real-Time Alert Fraud Detection User Interaction Master Data Mgmt Inventory Financial Transactions Central Nervous System あらゆるデータソースが繋がり、Productと してのデータをリアルタイムで利用システム に供給する。リアルタイムアクションはその 場で消費し活用する。 New Source of Truth レガシーな基幹システム/データ をクラウドネイティブな基盤に段 階的に移行し、最終的にはここを 新たな基幹とする。