Spring Cloud Data Flow で構成される IIJ IoTサービス

Slide 1

Slide 1 text

1 © Internet Initiative Japan Inc. Spring Cloud Data Flow で構成される IIJ IoTサービス株式会社インターネットイニシアティブクラウド本部クラウドサービス2部ビッグデータ技術課近藤憲児

Slide 2

Slide 2 text

2 IIJ ０から１以上を⽣みだす 1992 インターネット「そのもの」から「新たな使い⽅」まで私たちは変化の最先端に⽴ち、提案しつづけています。 IIJのコアは、インターネットを作り、⽀え、変えていく「技術者」です。ネットワーク事業インテグレーション事業現在ビジネス活⽤のため、インターネット商⽤接続サービスを開始。 IIJのはじまりクラウド事業セキュリティ事業モバイル事業ネットワーク事業国内初 1993 インターネット接続サービス開始研究⽬的ビジネス活⽤会社、家庭、学校などを「つなぐ」事業です。 ITシステムとネットワークの安全を「守る」事業です。お客様の要望を、ITで「作って叶える」事業です。例えばスマホ、IoTなど「無線でつなぐ」事業です。ネットワーク経由で「システムの機能を貸す」事業です。

Slide 3

Slide 3 text

3 ⾃⼰紹介(IIJ) • 近藤憲児 • IIJ IoTサービスの開発・運⽤に従事

Slide 4

Slide 4 text

4 お話すること • IIJ IoTサービス概要 • 以前のアーキテクチャと課題 • Spring Cloud Data Flow の導⼊による改善アプローチ • スケーラビリティについて • デモ Enterprise Integration Patterns がいかにして具現化されうるのかを、 Spring Cloud Data Flow を本番環境へ導⼊した知⾒を基にご紹介

Slide 5

Slide 5 text

5 IIJ IoTサービス概要

Slide 6

Slide 6 text

6 IIJ IoTサービスの概要デバイスゲートウェイ機器センサー（温湿度・振動・位置・電⼒等）ネットワーク（モバイル・有線・無線・LPWA）デバイス管理／データ収集・蓄積アプリケーション／ミドルウェア／データベースデータ分析／特定業務開発データ分析／特定業務開発センサー（温湿度・振動・位置・電⼒等） IIJ IoTサービスアプリケーション／ミドルウェア／データベース IoTシステムの「つなぐ」部分をもっと楽に。

Slide 7

Slide 7 text

7 IIJ IoTサービスの機能データハブデータストレージデバイスモニタリングプライベートコネクタデバイスコントロールクラウドアダプタプライベートモバイルゲートウェイ IoT専⽤SIM • モバイルアクセス

Slide 8

Slide 8 text

8 IIJ IoTサービスの機能データハブデータストレージデバイスモニタリングプライベートコネクタデバイスコントロールクラウドアダプタプライベートモバイルゲートウェイ IoT専⽤SIM • モバイルアクセス Today’s topics!

Slide 9

Slide 9 text

9 IIJ IoTサービスの機能データハブデータストレージデバイスモニタリングプライベートコネクタデバイスコントロールクラウドアダプタプライベートモバイルゲートウェイ IoT専⽤SIM • モバイルアクセスデータを蓄積する低コストストレージを提供センサーデータ送信データストレージ HTTP/TCP/UDP Amazon S3互換API HTTPS ブラウザアクセスファイルアップロード/ ダウンロード HTTPS

Slide 10

Slide 10 text

10 IIJ IoTサービスの機能データハブデータストレージデバイスモニタリングプライベートコネクタデバイスコントロールクラウドアダプタプライベートモバイルゲートウェイ IoT専⽤SIM • モバイルアクセスセンサーデータの外部システムへの転送センサーデータ送信データハブお客様システムA お客様システムB お客様システムC センサーデータ転送 HTTP/TCP/UDP HTTP/HTTPS インターネット

Slide 11

Slide 11 text

11 以前のアーキテクチャと課題

Slide 12

Slide 12 text

12 Spark App (データストレージ) 以前のアーキテクチャ Gateway Kafka Spark App (データハブ) Redis 顧客サーバ Object Storage HTTP-Client (データを顧客サーバへ転送する) Redis-Client (転送結果をRedisへ格納する) Aggregator (複数のデータを⼀つに束ねる) Uploader (束ねたデータをファイルにしてアップロード) Redis-Client (アップロードした結果をRedisへ格納する)

Slide 13

Slide 13 text

13 以前のアーキテクチャと課題 ü処理をstreamingにしたい l マイクロバッチをやめたい ü機能拡張性・保守性をあげたい l 処理を分けたい üスケールが難しい l スケールアップしか⽅法がない

Slide 14

Slide 14 text

14 Spring Cloud Data Flow の導⼊による改善アプローチ

Slide 15

Slide 15 text

15 Spring Cloud Stream Sink Source Processor Stream Spring Cloud Stream の基本的な概念 • Message を単位とした、Event-Driven な処理を実現することに特化したフレームワーク • Source, Processor, Sink はそれぞれ Spring Cloud Stream で実装したアプリケーション(あるいはtopic)に相当する • Binder は、Kafka や RabbitMQ といったメッセージングシステムであり、各コンポーネントは Binder を介して Message のやりとりを⾏う • Binder は EIP の “Channel” に相当 • Source, Processor, Sink を Binder で結合したものを Stream と呼ぶ Binder Binder

Slide 16

Slide 16 text

16 Spring Cloud Stream Gateway HTTP-Client (データを顧客サーバへ転送する) Redis-Client (転送結果をRedisへ格納する) Gateway Server Service Activator Service Activator IoTデータレスポンスデータ Message Message Channel Channel HTTP- Client Redis- Client (Kafka topic) Source Processor Sink データハブ EIP Spring Cloud Stream Binder Binder

Slide 17

Slide 17 text

17 Spring Cloud Stream Gateway Uploader (束ねたデータをファイルにしてアップロード) Redis-Client (アップロード結果をRedisへ格納する) Gateway Server Aggregator Service Activator IoTデータレスポンスデータ Message Message Channel データストレージ EIP Aggregator (複数のデータを⼀つに束ねる) Service Activator Channel Aggregator, Uploader Redis- Client (Kafka topic) Source Processor Sink Spring Cloud Stream Binder Binder

Slide 18

Slide 18 text

18 Spring Cloud Stream Gateway Kafka Redis 顧客サーバ Object Storage Aggregator, Uploader Redis-Client HTTP-Client Redis-Client Streaming処理を実現

Slide 19

Slide 19 text

19 Spring Cloud Stream の機能拡張性 Question: 「データハブで、⼀つのデータに対して複数の顧客サーバへの転送が⾏えるよう、機能拡張を⾏いたい。どのように設計する︖」 Answer: ⼀つのデータをクローンするProcessorアプリケーションを増やす。 Pseudo- Splitter Redis- Client (Kafka topic) Source Processor Sink HTTP- Client Processor HTTP- Client Redis- Client (Kafka topic) Source Processor Sink

Slide 20

Slide 20 text

20 Spring Cloud Stream の機能拡張性 Pseudo- Splitter Redis- Client (Kafka topic) Source Processor Sink データハブ(機能拡張) Gateway Server Service Activator Service Activator Message Channel Message Channel (Pseudo-)Splitter Channel Message Gateway HTTP-Client (データを顧客サーバへ転送する) Redis-Client (転送結果をRedisへ格納する) IoTデータレスポンスデータ HTTP- Client Processor Duplicator (データを複製する) 複製されたIoT データ Spring Cloud Stream EIP

Slide 21

Slide 21 text

21 Spring Cloud Stream の機能拡張性 Gateway Kafka Redis 顧客サーバ Object Storage Aggregator, Uploader Redis-Client Pseudo- Splitter HTTP-Client Redis-Client コンポーネントを増やすだけで機能拡張を実現

Slide 22

Slide 22 text

22 Spring Cloud Data Flow Question: 「Spring Cloud Stream で実装したアプリケーションをどこのサーバで動かす︖アプリケーションの可⽤性をどう担保する︖Stream の定義をどこで管理する︖実装したjarはどこに持っておく︖」などなど … このような microservice 特有の複雑さを、どのように管理する︖ Answer: Spring Cloud Data Flowを導⼊する。

Slide 23

Slide 23 text

23 Spring Cloud Data Flow Spring Cloud Data Flow • Spring Cloud Stream や Spring Task で実装されたアプリケーションのコンポーネント間のパイプライン(Stream)の定義や、アプリケーションのデプロイ/アンデプロイ実⾏、デプロイ状態の管理などを提供するマネジメントツール • GUI, CLI 完備 • コンポーネント間のパイプラインをDSLで表現できる • Binder … メッセージングミドルウェア • Kafka, RabbitMQ, Azure EventHubs, Amazon Kinesis Stream … • Deployer … アプリケーションのランタイム環境 • local, Apache YARN(EOL), Apache Mesos, Kubernetes, Cloud Foundry :sourceTopic > pseudo-splitter | http-client > redis-client

Slide 24

Slide 24 text

24 Spring Cloud Data Flow Kafka Aggregator, Uploader Redis- Client Pseudo- Splitter HTTP-Client Redis-Client Hadoop Cluster (YARN, HDFS) SCDF server streamのパイプラインやデプロイ状態を管理 Localに配置した jarをデプロイアプリケーションの冗⻑性はYARN(とHDFS) が管理

Slide 25

Slide 25 text

25 Spring Cloud Config, Spring Cloud Bus, Spring Cloud Netflix Question: 「Instanceで保持したDB情報の更新をどのように⾏う︖」「Configのランタイムアップデートをどのように実現する︖」 Answer: Spring Cloud Config, Spring Cloud Netflix (Eureka), Spring Cloud Bus を利⽤する。 • Spring Cloud Config • 「アプリケーション毎に分散するapplication.yml の、中央集権管理機能を提供するもの」 • Eureka • 「DNSのようなもの」 • Sring Cloud Bus • 「アプリケーションの状態の変化を、他のアプリケーションに伝播させて伝える仕組みを提供するもの」

Slide 26

Slide 26 text

26 Spring Cloud Config, Spring Cloud Bus, Spring Cloud Netflix Edge Server Event (ex. REST API) Eureka Server http-client Kafka http://192.168.10.13:21234/management/bus/refresh aggregator redis-client http-client http-client RDB ConfigServer (Spring Cloud Bus) http-client http-client http-client “Who is http-client ?” “192.168.10.13:21234” Register “http-client is 192.168.10.13:21234” Request Resources refresh refresh refresh

Slide 27

Slide 27 text

27 スケーラビリティについて

Slide 28

Slide 28 text

28 Spring Cloud Data Flow でのスケールアウト Question: 「どのようにスケールさせるのか︖」 Answer: Spring Cloud Data Flow で Stream をデプロイする時に、起動するInstance数を指定する。 stream deploy --name datahub-stream --properties "deployer.http-client.count=3" 例: データハブのHTTP-Clientを3つ⽴ち上げたい場合

Slide 29

Slide 29 text

29 Kafka Kafka Cluster App App App App App App Producer Broker Consumer Subscribe Publish http://kafka.apache.org/ Topic

Slide 30

Slide 30 text

30 ConsumerClient ConsumerClient PartitionとConsumerClientの関係 Topic Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8 Data 9 Partitions = 3, ConsumerClient = 3 Topic Partitions = 3, ConsumerClient = 1 Partition-0 Partition-1 Partition-2 Partition-0 Partition-1 Partition-2 Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8 Data 9 ConsumerClient (ex. Processor App) ConsumerClient Throughput が3倍に

Slide 31

Slide 31 text

31 PartitionとConsumerClientの関係 Partition数 : Consumer数 = 1 : 1 が最適︖ →必ずしもそうではない Partition数をわずかに⼤きくするとパフォーマンスが上がったさらにPartition数を⼤きくすると、パフォーマンスは⾼⽌まりした

Slide 32

Slide 32 text

32 PartitionとConsumerClientの関係 • 𝑝: Partition数 • 𝑐: ConsumerClient数 • 𝑡: Throughput(無単位) • ⽬的関数を 𝑦 𝑝, 𝑐, 𝑤 = 𝑤!𝑝" + 𝑤# 𝑐" + 𝑤" 𝑝𝑐 + 𝑤$ 𝑝 + 𝑤% 𝑐 として、𝐸 𝑤 = ∑& (𝑦(𝑝&, 𝑐&, 𝑤) − 𝑡&)" が最⼩となる 𝑤 = 𝑤! 𝑤# 𝑤" 𝑤$ 𝑤% ' を求める。 ∴ 𝑤 = −𝟏. 𝟏𝟑 − 𝟐. 𝟐𝟑 𝟑. 𝟏𝟏 𝟑𝟔. 𝟓𝟗 𝟏𝟖𝟐. 𝟗𝟖 '. • 𝛻𝑦 𝑝, 𝑐 |()!,+)! = 36.59, 182.98 ∴ 𝑝 𝑐 = 182 36 ~ 5 1 → IoTサービスでは、およそ Partition数 : ConsumerClient数 = 5 : 1 が最適な⽐率であった。最適な Partition数と ConsumerClient数の⽐率は何か︖ → Throughput が Partition数と ConsumerClient数をパラメータに持つ放物⾯で近似できると仮定して、回帰曲⾯を出す。その後、求めた曲⾯の勾配ベクトルの内、(p, c) = (0,0) 地点での pとcの⽐を求める。