Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Spring Cloud Data Flow で構成される IIJ IoTサービス
Semelhante a Spring Cloud Data Flow で構成される IIJ IoTサービス (20)
Spring Cloud Data Flow で構成される IIJ IoTサービス
- 1. 1© Internet Initiative Japan Inc. Spring Cloud Data Flow で構成される IIJ IoTサービス 株式会社インターネットイニシアティブ 2018年12月14日 クラウド本部 クラウドサービス2部 ビッグデータ技術課 近藤 憲児
- 2. 2 IIJ ０から１以上を生みだす 1992 イ ン タ ー ネ ッ ト 「 そ の も の 」 か ら 「 新 た な 使 い 方 」 ま で 私 た ち は 変 化 の 最 先 端 に 立 ち 、 提 案 し つ づ け て い ま す 。 IIJのコアは、インターネットを作り、支え、変えていく「技術者」です。 ネットワーク事業 インテグ レーション事業 現在 ビジネス活用のため、インターネット 商用接続サービスを開始。 IIJのはじまり クラウド事業 セキュリティ事業 モバイル事業 ネットワーク事業 国内初 1993 インターネット 接続サービス開始 研究目的 ビジネス活用 会社、家庭、学校などを「つなぐ」事業です。 ITシステムとネットワークの安全を「守る」事業です。 お客様の要望を、ITで「作って叶える」事業です。 例えばスマホ、IoTなど「無線でつなぐ」事業です。 ネットワーク経由で「システムの機能を貸す」事業です。
- 3. 3 自己紹介(IIJ) • 近藤 憲児 • IIJ IoTサービスの開発・運用に従事
- 4. 4 お話すること • IIJ IoTサービス 概要 • 以前のアーキテクチャと課題 • Spring Cloud Data Flow の導入による改善アプローチ • スケーラビリティについて • デモ Enterprise Integration Patterns がいかにして具現化されうるのかを、 Spring Cloud Data Flow を本番環境へ導入した知見を基にご紹介
- 6. 6 IIJ IoTサービスの概要 デバイスゲートウェイ機器 センサー（温湿度・振動・位置・電力等） ネットワーク（モバイル・有線・無線・LPWA） デバイス管理／データ収集・蓄積 アプリケーション／ミドルウェア／データベース データ分析／特定業務開発 データ分析／特定業務開発 センサー（温湿度・振動・位置・電力等） IIJ IoTサービス アプリケーション／ミドルウェア／データベース IoTシステムの「つなぐ」部分をもっと楽に。
- 9. 9 IIJ IoTサービスの機能 データハブデータストレージ デバイスモニタリング プライベート コネクタ デバイスコントロール クラウドアダプタ プライベート モバイルゲートウェイ IoT専用SIM • モバイルアクセス データを蓄積する低コストストレージを提供 センサーデータ送信 データストレージ HTTP/TCP/UDP Amazon S3互換API HTTPS ブラウザアクセス ファイルアップロード/ ダウンロード HTTPS
- 11. 11 以前のアーキテクチャと課題
- 12. 12 Spark App (データストレージ) 以前のアーキテクチャ Gateway Kafka Spark App (データハブ) Redis 顧客サーバ Object Storage HTTP-Client (データを顧客サーバへ転送する) Redis-Client (転送結果をRedisへ格納する) Aggregator (複数のデータを一つに束ねる) Uploader (束ねたデータをファイルにしてアップロード) Redis-Client (アップロードした結果をRedisへ格納する)
- 13. 13 以前のアーキテクチャと課題 処理をstreamingにしたい マイクロバッチをやめたい 機能拡張性・保守性をあげたい 処理を分けたい スケールが難しい スケールアップしか方法がない
- 14. 14 Spring Cloud Data Flow の導入による 改善アプローチ
- 15. 15 Spring Cloud Stream SinkSource 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
- 16. 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
- 17. 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
- 18. 18 Spring Cloud Stream Gateway Kafka Redis 顧客サーバ Object Storage Aggregator, Uploader Redis-Client HTTP-Client Redis-Client Streaming処理を 実現
- 19. 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
- 20. 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
- 21. 21 Spring Cloud Stream の機能拡張性 Gateway Kafka Redis 顧客サーバ Object Storage Aggregator, Uploader Redis-Client Pseudo- Splitter HTTP-Client Redis-Client コンポーネントを増 やすだけで機能拡張 を実現
- 22. 22 Spring Cloud Data Flow Question: 「Spring Cloud Stream で実装したアプリケーションをどこのサーバ で動かす？アプリケーションの可用性をどう担保する？Stream の定義 をどこで管理する？実装したjarはどこに持っておく？」 などなど … このような microservice 特有の複雑さを、どのように管理する？ Answer: Spring Cloud Data Flowを導入する。
- 23. 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
- 24. 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) が管理
- 25. 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 • 「アプリケーションの状態の変化を、他のアプリケーションに伝播させて伝える仕組みを 提供するもの」
- 26. 26 Spring Cloud Config, Spring Cloud Bus, Spring Cloud Netflix Edge ServerEvent (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
- 27. 27 スケーラビリティについて
- 28. 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つ立ち上げたい場合
- 29. 29 Kafka Kafka Cluster App App App App App App Producer Broker Consumer SubscribePublish http://kafka.apache.org/ Topic
- 30. 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倍に
- 31. 31 PartitionとConsumerClientの関係 Partition数 : Consumer数 = 1 : 1 が最適？ →必ずしもそうではない Partition数をわずかに大きくするとパフォーマンスが上がった さらにPartition数を大きくすると、パフォーマンスは高止まりした
- 32. 32 PartitionとConsumerClientの関係 • 𝑝: Partition数 • 𝑐: ConsumerClient数 • 𝑡: Throughput(無単位) • 目的関数を 𝑦 𝑝, 𝑐, 𝑤 = 𝑤0 𝑝2 + 𝑤1 𝑐2 + 𝑤2 𝑝𝑐 + 𝑤3 𝑝 + 𝑤4 𝑐 として、𝐸 𝑤 = 𝑖(𝑦(𝑝𝑖, 𝑐𝑖, 𝑤) − 𝑡𝑖)2 が最小となる 𝑤 = 𝑤0 𝑤1 𝑤2 𝑤3 𝑤4 𝑇 を求める。 ∴ 𝑤 = −𝟏. 𝟏𝟑 − 𝟐. 𝟐𝟑 𝟑. 𝟏𝟏 𝟑𝟔. 𝟓𝟗 𝟏𝟖𝟐. 𝟗𝟖 𝑇 . • 𝛻𝑦 𝑝, 𝑐 | 𝑝=0,𝑐=0 = 36.59, 182.98 ∴ 𝑝 𝑐 = 182 36 ~ 5 1 → IoTサービスでは、およそ Partition数 : ConsumerClient数 = 5 : 1 が最適な比率であった。 最適な Partition数 と ConsumerClient数 の比率は何か？ → Throughput が Partition数 と ConsumerClient数 をパラメータに持つ放物面 で近似できると仮定して、回帰曲面を出す。その後、求めた曲面の勾配ベクト ルの内、(p, c) = (0,0) 地点での pとcの比を求める。
- 33. 33 デモ
Notas do Editor
- 自己紹介もかねて会社の紹介を インターネットイニシアティブ、IIJ 日本で最初に商用インターネットサービスを行った会社 最近はIIJ mioという格安SIMでもおなじみ 私は新卒でこの会社に入社して、それ以来IoTに関する事業に携わっている。 最近はもっぱらIIJ IoTサービスの開発と運用を行っている
- 今日お話することです。 先ほどのセッションでは理論的なお話であった。 ここからは、そのEIPが実際の要件に対してどのようにはまるのかを伝える。 また、それで実装したアプリケーションがどのように運用されるのかを、SCDFというワードとともに説明する。
- まずはじめに、要件として、これからお話するために必要なベースとなる知識として、IIJ IoTサービス概要を説明する
- キャッチフレーズ IoTシステムはえてして巨大で面倒なことになる。 センサーからクラウドにどうにかしてあげる、のどうにかしてあげる部分 ネットワーク デバイス ここのわずらわしさを吸収するサービスである
- 機能はこのようなものです。
- 今日のTopicです。
- 読む センサーをPFに送ってもらい、そこで10分間で送ってもらったデータを一つのファイルにまとめて、ObjectStorageに配置する。 IoTシステムの要件は様々だが、データをためる、というのは汎用的。これをクリックぽちぽちで実現できる機能です。
- 読む データを送ってもらって、 お客様は同一のエンドポイントに送信し続けるだけでよい。エンドポイントの変更、追加などでデバイスに変更を加える必要がない
- これからのお話を劇的なものにするために、以前のアーキテクチャについてご説明します。
- Sparkベースであった （データのフローを説明） （Kafkaについて簡単に説明）
- しばらくよく動いてくれたが、内部でいくつかの課題や、やりたいことがでてきた。 ここでは3つfeatureする 処理をStreamingにしたい データハブの話 機能の拡張性・保守性をあげたい 今はシンプルな処理しか行っていないが、これから機能を拡張していこうとすると巨大なアプリケーションになる。巨大なアプリケーションになるほど保守性が下がることは皆さんもご承知の通り。なので処理を分けることはできないか、という課題 スケールが難しい 特にデータストレージの話。Sparkはもともと分散処理基盤なのでスケールのしやすさが志向されているものであるが、これはどちらかというと使い方の問題で、パフォーマンスをあげるにはスケールアップするしか手段がない状態であった。
- 本題です。 こうした課題を解決する手段として、結果的にSCDFの導入を決めた。 その軌跡を順番に紹介する。
- Spring Cloud Stream で実装した。
- （処理の説明） （処理がEIPでかくとこうなることを説明） 特に「メッセージをうけて処理をする」という意味ではHTTPもRedisも同じになるので、似たような図が並んでいる （それをCloud Streamで実装する単位に分けたときの説明）
- 同様に説明 特にAggregaterについて説明
- 全体図 一つ目：Streaming処理を実現 二つ目：Redis-Clientを同じJarを使っていること。これにより、異なるアプリケーションに共通する処理を、コードをコピペして対応する、という冗長な作業をする必要がなくなった。
- ここからはQA方式でご紹介 Questionの説明 Answerの説明
- Answerについて詳細に説明 特にPseudo-Splitterについて説明 Pseudo-Splitterは近藤が勝手に名づけたものなので注意。厳密にはこれはSplitterではない。 なぜなら、Splitterは一つのMessageをSplitして複数のMessageにすることを指すが、今回は一つのMessageをクローンしているため。
- HTTP-Client, Redis-Clientについては、別のアプリケーションなので、テストをしなくても良い部分というのがより明確になった。 またアプリケーションが分離されているので、パフォーマンスを挙げるために増やす必要のあるInstanceの単位が分かれて経済的。
- 特にBinderとDeployerについて SCDFを導入するには、この二つの環境を選定することが必要 IoTサービスでは BinderはKafka. 理由はリリース時から使ってきてナレッジも多くある。わざわざRabbitMQなどを使うことを検討するメリットも理由もなかったので。 DeployerはYARN. 理由はチームにHadoop Clusterの運用経験者が複数人いたため。 Deployerの候補に共通するのは、一つはリソースの抽象化を行うもの、もう一つはアプリケーションの可用性を担保してくれるものであること。 YARNはEOLなので、これから導入する人はこれを選ぶべきではない。
- 一つめのQuestionは次のようなもの ユーザが設定変更を行ったなどでDBに更新があった際、各Instanceのメモリ上に持っているDB情報する必要があるが、それをどのように悟るか また、並列化された複数のInstanceは同じタイミングで更新する必要がある。それをどういう仕組みで実現するか。 二つ目のQuestionは、application.ymlの変更を、アプリケーションのrestartなしで行う方法はあるのか、というもの
- （アニメーションの説明） ここで問題になるのは、各Instanceが抽象化されたリソース上で動いていること。これにより Cloud busの機能でEdgeから直接InstanceにRequestを送る必要があるが、このInstanceのIPアドレスやPortを特定できないこと Application.ymlをホストに配置する、ということができないこと
- 以上でSCDFを使ったIoTサービスのアーキテクチャについての説明を終わります。 最後にスケーラビリティについてご説明して、このセクションを終えます。
- 次にスケールアウトを実際にどのように実現するか、についてです。 Questionはそのまま「スケールさせたいとき、どのような操作が必要になる？」です。 この回答としては、私たちはSCDFのDeployコマンドを実行するときに、以下のようにinstanceの数を指定することで実現しています。 このようにオプションをつけるのです。人間がやるオペレーションとしては、ここにあるinstanceの数を指定しなおして、Deployするだけ。 そうすると、SCDFが勝手にDeployerに対して指定したinstance数分たててくれる
- これまで何度もKafka、Kafkaと連呼してきましたが、このKafkaはこれまでご説明してきたアーキテクチャの中で重要なものになっています。 まずこのKafkaの概要をご説明します。 Kafkaは分散メッセージングシステムである。Kafkaによって、非同期にMessageのやり取りを行うことができる。 最もベーシックなKafkaの説明では、Producer、Broker、Consumerの3つの役割がある。 まずBrokerはKafka自身をさす。Brokerはtopicと呼ばれる、メッセージを書き込むまさに掲示板のようなものを持っています。 ProducerとConsumerはそれぞれアプリケーションで、ProducerはConsumerにメッセージを伝えることを目的としている。 Producerは伝えたいメッセージをtopicに書き込む。これをPublishと呼ぶ。 Consumerはこのtopicを、まるでtail –f コマンドでファイルの更新を監視しているように、常に更新されたものをみている。これをSubscribeと呼ぶ。 このKafkaを使えば、メッセージを送る側と受信する側を疎結合にする、いわゆるPublish-Subscribeモデル実現することができる。ProducerはConsumerを気にせず、topicに書き込むことに専念すればよいし、ConsumerはProducerのことを意識せず、topicに書き込まれた・書き込まれていない、だけを意識することができる。 以上がKafkaの概要です。
- さらに詳細に言うと、topicにはPartitionという概念を持っている。 例えば「一つのtopicに対してpartition数=3を設定する」といった使い方をする。 Producerが一つのtopicにメッセージをpublishするとします。すると、Kafkaの中で、PublishされたメッセージはPartitionのどれか一つに入ります。ここで一つのMessageが異なるPartitionにまたがって存在するということはありません。 一方、一つのtopicをsubscribeしているConsumerは、Partition単位でsubscribeの粒度を決めることができる。 例えばpartitionが3のtopicに対してConsumerが一つの場合、はこの絵のように、Consumerは3つのPartitionを同時にSubscribeすることになります。 一方、Partitionが③のtopicに対して、Consumerが3つの場合、この絵のように、それぞれ異なるPartitionをまたそれぞれ異なるConsumerがSubscirbeしていることになります。 ここでConsumerに注目してみると、上よりも、下のほうが、一つのConsumerが処理すべきMessageの量が少ない、つまり1/3になっている。故に、下のほうが並列に処理が進むため、パフォーマンスは3倍になる、という結論がでるであろう。こういう仕組みをベースにして、スケールアウトを実現します。 これはすごく単純化した説明であるので、例えば処理に必要なデータの集まりや実行順序というところをどのように担保するか、については言及していない。
- ここでpartitionとClientの数について考えてみる。 先ほどの理論から出てくる結論としては、PartitionとClientの数を1:1にすると、もっともパフォーマンスがでる、となるであろう。 しかしながら、実際そうではなかった。 一つのConsumerが2つ以上のPartitionを担当している場合、1:1よりもパフォーマンスがでた。 さらに、Consumer一つに対してPartitionの数をどんどん増やしてみると、今度はパフォーマンスが高止まりし始めた。パフォーマンスが下がるケースもあった。 これはなぜかわからない。 ここで次のような疑問が生まれる、 ConsumerとPartitionの最適な組み合わせは？？ 以下はこれを求めるために使った一つの手法のご紹介です。
- 結論から申しますと、ConsumerとPartitionの数の比を1:5にするとよい。 手法としては、回帰分析を行った。 partitionをp, Consumerをcとして、throughputをtとおく。このthroughputの単位は言及しない。実はHTTP Requestの毎秒単位のもの。 モデルを二次形式としておいて、得られたテストデータから、この評価関数を最小にするような二次係数の係数の組み合わせを導く。これはRに任せた。 そこから以下のような関数がでてきた function(p, c) { -1.133499 * p^2 + -2.229904 * c^2 + 3.112091 * p * c + 36.596983 * p + 182.988513 * c } これは二変数関数なので、③次元にプロットできる。それが右の絵である。これが頂上ここのz軸に相当するものがthroughputを示しているので、坂の上にいくほど、throughputはあがる。 ここで、例えばthroughputを1000にするとして、最適なPartitionとConsumerの数の組み合わせは何であろうか。 throuputを1000とすると、この絵では、z軸が1000である等高線全てがその組み合わせの候補となる。 ここで初期値を(partition, Consumer )= (0, 0)からはじめれば、絵でいう原点から頂上まで向かうのにどの方向に向かえば一番最短距離でいけるか、を考えればいい。 そういうときは勾配ベクトルを求めればいいのでそれを計算する。するとc:p = 37:183 、(c = 37k, p = 183k)となった。つまりc/p = 37/183 およそ 1:5というのがわかった。 IoTサービスではこういう結果がでたが、これは環境に依存するもの。しかしながら、放物曲面を仮定することと勾配ベクトルを使うところの手法は汎用的に使える。
- SCDFでアプリケーション実行のデプロイ Streamの定義をDSLで行うこと Streamのデプロイ Instanceを増やすことでThroughputがあがること
- おわり 質問受け付ける