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

Editor's Notes

• #3: 自己紹介もかねて会社の紹介を インターネットイニシアティブ、IIJ 日本で最初に商用インターネットサービスを行った会社 最近はIIJ mioという格安SIMでもおなじみ 私は新卒でこの会社に入社して、それ以来IoTに関する事業に携わっている。 最近はもっぱらIIJ IoTサービスの開発と運用を行っている
• #5: 今日お話することです。 先ほどのセッションでは理論的なお話であった。 ここからは、そのEIPが実際の要件に対してどのようにはまるのかを伝える。 また、それで実装したアプリケーションがどのように運用されるのかを、SCDFというワードとともに説明する。
• #6: まずはじめに、要件として、これからお話するために必要なベースとなる知識として、IIJ IoTサービス概要を説明する
• #7: キャッチフレーズ IoTシステムはえてして巨大で面倒なことになる。 センサーからクラウドにどうにかしてあげる、のどうにかしてあげる部分 ネットワーク デバイス ここのわずらわしさを吸収するサービスである
• #8: 機能はこのようなものです。
• #9: 今日のTopicです。
• #10: 読む センサーをPFに送ってもらい、そこで10分間で送ってもらったデータを一つのファイルにまとめて、ObjectStorageに配置する。 IoTシステムの要件は様々だが、データをためる、というのは汎用的。これをクリックぽちぽちで実現できる機能です。
• #11: 読む データを送ってもらって、 お客様は同一のエンドポイントに送信し続けるだけでよい。エンドポイントの変更、追加などでデバイスに変更を加える必要がない
• #12: これからのお話を劇的なものにするために、以前のアーキテクチャについてご説明します。
• #13: Sparkベースであった （データのフローを説明） （Kafkaについて簡単に説明）
• #14: しばらくよく動いてくれたが、内部でいくつかの課題や、やりたいことがでてきた。 ここでは3つfeatureする 処理をStreamingにしたい データハブの話 機能の拡張性・保守性をあげたい 今はシンプルな処理しか行っていないが、これから機能を拡張していこうとすると巨大なアプリケーションになる。巨大なアプリケーションになるほど保守性が下がることは皆さんもご承知の通り。なので処理を分けることはできないか、という課題 スケールが難しい 特にデータストレージの話。Sparkはもともと分散処理基盤なのでスケールのしやすさが志向されているものであるが、これはどちらかというと使い方の問題で、パフォーマンスをあげるにはスケールアップするしか手段がない状態であった。
• #15: 本題です。 こうした課題を解決する手段として、結果的にSCDFの導入を決めた。 その軌跡を順番に紹介する。
• #16: Spring Cloud Stream で実装した。
• #17: （処理の説明） （処理がEIPでかくとこうなることを説明） 特に「メッセージをうけて処理をする」という意味ではHTTPもRedisも同じになるので、似たような図が並んでいる （それをCloud Streamで実装する単位に分けたときの説明）
• #18: 同様に説明 特にAggregaterについて説明
• #19: 全体図 一つ目：Streaming処理を実現 二つ目：Redis-Clientを同じJarを使っていること。これにより、異なるアプリケーションに共通する処理を、コードをコピペして対応する、という冗長な作業をする必要がなくなった。
• #20: ここからはQA方式でご紹介 Questionの説明 Answerの説明
• #21: Answerについて詳細に説明 特にPseudo-Splitterについて説明 Pseudo-Splitterは近藤が勝手に名づけたものなので注意。厳密にはこれはSplitterではない。 なぜなら、Splitterは一つのMessageをSplitして複数のMessageにすることを指すが、今回は一つのMessageをクローンしているため。
• #22: HTTP-Client, Redis-Clientについては、別のアプリケーションなので、テストをしなくても良い部分というのがより明確になった。 またアプリケーションが分離されているので、パフォーマンスを挙げるために増やす必要のあるInstanceの単位が分かれて経済的。
• #24: 特にBinderとDeployerについて SCDFを導入するには、この二つの環境を選定することが必要 IoTサービスでは BinderはKafka. 理由はリリース時から使ってきてナレッジも多くある。わざわざRabbitMQなどを使うことを検討するメリットも理由もなかったので。 DeployerはYARN. 理由はチームにHadoop Clusterの運用経験者が複数人いたため。 Deployerの候補に共通するのは、一つはリソースの抽象化を行うもの、もう一つはアプリケーションの可用性を担保してくれるものであること。 YARNはEOLなので、これから導入する人はこれを選ぶべきではない。
• #26: 一つめのQuestionは次のようなもの ユーザが設定変更を行ったなどでDBに更新があった際、各Instanceのメモリ上に持っているDB情報する必要があるが、それをどのように悟るか また、並列化された複数のInstanceは同じタイミングで更新する必要がある。それをどういう仕組みで実現するか。 二つ目のQuestionは、application.ymlの変更を、アプリケーションのrestartなしで行う方法はあるのか、というもの
• #27: （アニメーションの説明） ここで問題になるのは、各Instanceが抽象化されたリソース上で動いていること。これにより Cloud busの機能でEdgeから直接InstanceにRequestを送る必要があるが、このInstanceのIPアドレスやPortを特定できないこと Application.ymlをホストに配置する、ということができないこと
• #28: 以上でSCDFを使ったIoTサービスのアーキテクチャについての説明を終わります。 最後にスケーラビリティについてご説明して、このセクションを終えます。
• #29: 次にスケールアウトを実際にどのように実現するか、についてです。 Questionはそのまま「スケールさせたいとき、どのような操作が必要になる？」です。 この回答としては、私たちはSCDFのDeployコマンドを実行するときに、以下のようにinstanceの数を指定することで実現しています。 このようにオプションをつけるのです。人間がやるオペレーションとしては、ここにあるinstanceの数を指定しなおして、Deployするだけ。 そうすると、SCDFが勝手にDeployerに対して指定したinstance数分たててくれる
• #30: これまで何度も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の概要です。
• #31: さらに詳細に言うと、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倍になる、という結論がでるであろう。こういう仕組みをベースにして、スケールアウトを実現します。 これはすごく単純化した説明であるので、例えば処理に必要なデータの集まりや実行順序というところをどのように担保するか、については言及していない。
• #32: ここでpartitionとClientの数について考えてみる。 先ほどの理論から出てくる結論としては、PartitionとClientの数を1:1にすると、もっともパフォーマンスがでる、となるであろう。 しかしながら、実際そうではなかった。 一つのConsumerが2つ以上のPartitionを担当している場合、1:1よりもパフォーマンスがでた。 さらに、Consumer一つに対してPartitionの数をどんどん増やしてみると、今度はパフォーマンスが高止まりし始めた。パフォーマンスが下がるケースもあった。 これはなぜかわからない。 ここで次のような疑問が生まれる、 ConsumerとPartitionの最適な組み合わせは？？ 以下はこれを求めるために使った一つの手法のご紹介です。
• #33: 結論から申しますと、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サービスではこういう結果がでたが、これは環境に依存するもの。しかしながら、放物曲面を仮定することと勾配ベクトルを使うところの手法は汎用的に使える。
• #34: SCDFでアプリケーション実行のデプロイ Streamの定義をDSLで行うこと Streamのデプロイ Instanceを増やすことでThroughputがあがること
• #35: おわり 質問受け付ける