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

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

Kenji KONDO
December 18, 2018

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

「JSUG勉強会 2018年その7 Spring Cloud Data FlowとSpring Bootで実装するエンタープライズ統合パターン」の発表資料。SlideShare から引っ越し。

Kenji KONDO

December 18, 2018
Tweet

More Decks by Kenji KONDO

Other Decks in Technology

Transcript

  1. 1 © Internet Initiative Japan Inc. Spring Cloud Data Flow

    で構成される IIJ IoTサービス 株式会社インターネットイニシアティブ クラウド本部 クラウドサービス2部 ビッグデータ技術課 近藤 憲児
  2. 2 IIJ 0から1以上を⽣みだす 1992 イ ン タ ー ネ ッ

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

    Cloud Data Flow の導⼊による改善アプローチ • スケーラビリティについて • デモ Enterprise Integration Patterns がいかにして具現化されうるのかを、 Spring Cloud Data Flow を本番環境へ導⼊した知⾒を基にご紹介
  4. 9 IIJ IoTサービスの機能 データハブ データストレージ デバイスモニタリング プライベート コネクタ デバイスコントロール クラウドアダプタ

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

    プライベート モバイルゲートウェイ IoT専⽤SIM • モバイルアクセス センサーデータの外部システムへの転送 センサーデータ送信 データハブ お客様システムA お客様システムB お客様システムC センサーデータ転送 HTTP/TCP/UDP HTTP/HTTPS インターネット
  6. 12 Spark App (データストレージ) 以前のアーキテクチャ Gateway Kafka Spark App (データハブ)

    Redis 顧客サーバ Object Storage HTTP-Client (データを顧客サーバへ転送する) Redis-Client (転送結果をRedisへ格納する) Aggregator (複数のデータを⼀つに束ねる) Uploader (束ねたデータをファイルにしてアップロード) Redis-Client (アップロードした結果をRedisへ格納する)
  7. 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
  8. 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
  9. 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
  10. 18 Spring Cloud Stream Gateway Kafka Redis 顧客サーバ Object Storage

    Aggregator, Uploader Redis-Client HTTP-Client Redis-Client Streaming処理を 実現
  11. 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
  12. 21 Spring Cloud Stream の機能拡張性 Gateway Kafka Redis 顧客サーバ Object

    Storage Aggregator, Uploader Redis-Client Pseudo- Splitter HTTP-Client Redis-Client コンポーネントを増 やすだけで機能拡張 を実現
  13. 22 Spring Cloud Data Flow Question: 「Spring Cloud Stream で実装したアプリケーションをどこのサーバ

    で動かす︖アプリケーションの可⽤性をどう担保する︖Stream の定義 をどこで管理する︖実装したjarはどこに持っておく︖」 などなど … このような microservice 特有の複雑さを、どのように管理する︖ Answer: Spring Cloud Data Flowを導⼊する。
  14. 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
  15. 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) が管理
  16. 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 • 「アプリケーションの状態の変化を、他のアプリケーションに伝播させて伝える仕組みを 提供するもの」
  17. 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
  18. 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つ⽴ち上げたい場合
  19. 29 Kafka Kafka Cluster App App App App App App

    Producer Broker Consumer Subscribe Publish http://kafka.apache.org/ Topic
  20. 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倍に
  21. 31 PartitionとConsumerClientの関係 Partition数 : Consumer数 = 1 : 1 が最適︖

    →必ずしもそうではない Partition数をわずかに⼤きくするとパフォーマンスが上がった さらにPartition数を⼤きくすると、パフォーマンスは⾼⽌まりした
  22. 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の⽐を求める。