スマートシティのデータパイプラインと してのApache Pulsar (Pulsar Meetup Japan #5)

スマートシティのデータパイプラインと してのApache Pulsar
@Pulsar Meetup Japan #5
2023年6月30日

Transcript

1. スマートシティのデータパイプラインと してのApache Pulsar NTTソフトウェアイノベーションセンタ Hongjie Zhai @Pulsar Meetup Japan #5 2023年6月30日
2. 1 Copyright NTT CORPORATION スマートシティのデータパイプライン • 様々なデータを一元管理 • センサ：大量デバイス・高頻度のイベ ントデータ • カメラ：2MB~画像・映像データ • 様々なアプリで利用 • 人流分析、危険検知、衝突検知... • 一部のアプリの出力は再びパイプライ ンに保存して、再利用される › e.g. サービスAPP エッジデバイス データパイプライン (データ管理、蓄積) RTSP REST HDFS Object Storage RDB コネカのセンサ、GPS... カメラの映像、画像... 物体検知 画像 人流分析 危険検知 Bounding Box
3. 2 Copyright NTT CORPORATION データパイプラインの問題 サービスAPP エッジデバイス データパイプライン (データ管理、蓄積) RTSP REST HDFS Object Storage RDB コネカのセンサ、GPS... カメラの映像、画像... 多様な要件によって複雑化 • データの使い方による問題 • データブロックとして使う（S3） • SQLを使いたい（RDB） • ファイルとして使いたい（HDFS） • ... • データの与え方による問題 • 異なるエンドポイント・プロトコル › IoTデータ：MQTT、映像：RTSP, etc. • データの永続化が必要
4. 3 Copyright NTT CORPORATION データパイプラインの問題 サービスAPP エッジデバイス データパイプライン (データ管理、蓄積) RTSP REST HDFS Object Storage RDB コネカのセンサ、GPS... カメラの映像、画像... 多様な要件によって複雑化 データ＆基盤の維持管理問題 RTSP REST サーバー HDFS Object Storage RDB
5. 4 Copyright NTT CORPORATION データパイプラインとしてのPulsar サービスAPP エッジデバイス コネカのセンサ、GPS... カメラの映像、画像... Apache Pulsarを ブローカー＆ストレージとして運用 • パイプラインの簡素化 • デバイス側もアプリ側もブローカーのみ に接続 • ストレージへのアクセスパターンも削減 • データ管理の一元化 • Pulsarによって自動永続化 • データ間の同期や統合が簡単 Apache Pulsar ストレージ
6. 5 Copyright NTT CORPORATION 1. 疎結合の設計 • ストレージ・ブローカを個別にスケール可能 • 追加実装する場合の影響範囲が限定的 2. Pulsar Protocol Handler • Pulsar以外のプロトコルにも対応可能 なぜPulsarを選ぶのか？ サービスAPP エッジデバイス コネカのセンサ、GPS... カメラの映像、画像... Apache Pulsar ストレージ Subscription Apache BookKeeper Consumer Cursor Apache Plusar Apache Pulsar MQTT on Pulsar[1] Kafka on Pulsar[2] Custom Protocol [1] https://github.com/streamnative/mop [2] https://github.com/streamnative/kop
7. 6 Copyright NTT CORPORATION Pulsarは性能要件を満たすのか？ サービスAPP エッジデバイス コネカのセンサ、GPS... カメラの映像、画像... Apache Pulsar ストレージ 1. 大量デバイスを接続しても性能維持 できること • 10万以上の同時接続＆同報配信 2. 大容量データを転送できること • Payload: 2MB • 画像、動画のセグメントなど 3. 上記いずれのUCでもE2E Latency は1s以下であること • 危険検知などでの許容時間
8. 7 Copyright NTT CORPORATION Pulsarは性能要件を満たすのか？ サービスAPP エッジデバイス コネカのセンサ、GPS... カメラの映像、画像... Apache Pulsar ストレージ 1. 大量デバイスを接続しても性能維持 できること • 10万以上の同時接続＆同報配信 2. 大容量データを転送できること • Payload: 2MB • 画像、動画のセグメントなど 3. 上記いずれのUCでもE2E Latency は1s以下であること • 危険検知などでの許容時間
9. 8 Copyright NTT CORPORATION UC：コネクテッドカーへの情報配信 • 地域・車種などの単位でメッセージ を配信 • 1Topicあたり10万〜デバイスが接続 • メッセージを全てのデバイスに同報配信 • アプリ (Producer)送信から車(Consumer) 受信までのE2E Latencyは1s以内に抑 えたい Apache Pulsar 地域A 車種B Topic：地域A Topic：車種B 地域危険検知 推薦システム 一括通知（同報配信） Apache Pulsarはどこまで 性能要件満たせる？
10. 9 Copyright NTT CORPORATION Pulsarの性能検証 • 単一Topicの同報配信能力の検証 • 1Publisherから10万Consumerへの性能（Latency）を計測 • ConsumerごとにShared Subscriptionを作成 • 検証設定：10KB Message * 1 Msg/s、AWS i3.4xlarge Publisher Pulsar 2.10 Apache BookKeeper Consumer Persistent Topic 永続化 ZooKeeper Consumer Consumer Consumer Consumer Consumer ※詳細はPulsar Summit 2022 Asiaに参照 OMB 100K Shared Subscription Shared Subscription Shared Subscription Shared Subscription Shared Subscription Shared Subscription
11. 10 Copyright NTT CORPORATION 検証結果 • 10万Consumerの接続時間はまだまだ長い(1h以上) ➢ データから2.2h以上かかると予想 ➢ 朝など車が一気に動き出す場合大量の接続あるため、分単位に削減したい • E2E Latency(特に99%)も指数的に増加 Benchmark Item 20,000 Consumers 30,000 Consumers 40,000 Consumers 100,000 Consumers E2E Lat.(Avg.) 0.23s 0.48s 2.9s - (接続時間>1h) E2E Lat.(99% Tile) 0.68s 1.07s 4.09s - (接続時間>1h) Connection Time 252s 594s 1196s - (接続時間>1h) ※詳細はPulsar Summit 2022 Asiaに参照 Subscriptionが性能問題を引き起こす SubscriptionはBookKeeperへの定期アク セス含め多くの処理を行っているため、 性能へのインパクトが大きい
12. 11 Copyright NTT CORPORATION Subscriptionの削減方法 • スケールアップ: Broker単体のSubscription性能を向上させる • 複数のConsumerに同報配信可能なSubscriptionを実装 › ConsumerはSubscriptionと比べて動作が軽いため、性能向上につながる › Pulsarの設計上、Subscriptionの実装は独立しているため簡単に実装可能 • スケールアウト：複数台のサーバで同じTopicの配信を実現する • コミュニティによって実装中：https://github.com/apache/pulsar/issues/16153 › PIP-63 Read-only Topic, PIP-180 Shadow Topic (@Jason918) • 現在のTopicのクローンを他のサーバで作ってメッセージ配信機能を実現 › 書き込みは本体のTopicのみに対して行う › PulsarのGeo-replication機能を活用して実装 ※詳細はPulsar Summit 2022 Asiaに参照
13. 12 Copyright NTT CORPORATION Pulsarは性能要件を満たすのか？ サービスAPP エッジデバイス コネカのセンサ、GPS... カメラの映像、画像... Apache Pulsar ストレージ 1. 大量デバイスを接続しても性能維持 できること • 10万以上の同時接続＆同報配信 2. 大容量データを転送できること • Payload: 2MB • 画像、動画のセグメントなど 3. 上記いずれのUCでもE2E Latency は1s以下であること • 危険検知などでの許容時間
14. 13 Copyright NTT CORPORATION UC：機械学習によるカメラ画像分析 • カメラの画像をリアルタイム収集 • 4K画像の場合は2MB/msgと想定 • 最大限の転送Throughputが欲しい • 機械学習のデータパイプラインとして利用 • 前処理のメタデータ（画像の認識結果、Bounding Box情報、etc.）も取り扱う • 学習改善するためのデータの利用履歴記録も必要 今回はデータ転送性能に注目 Apache Pulsar Topic：画像 前処理 Topic：共通中 間データ 危険検知 画像データ
15. 14 Copyright NTT CORPORATION Pulsarの性能検証 • 単一Brokerのデータ受信能力の検証 • Publisher→ConsumerのLatencyを計測 • Publishの最大Throughputを計測 • 検証設定：2MB Message Size、AWS i3.4xlarge Publisher Pulsar 2.10 Apache BookKeeper Consumer Persistent Topic 永続化 ZooKeeper OMB Shared Subscription クライアントライブラリの仕様上、 一時的なThroughputは安定 に出せると限らない
16. 15 Copyright NTT CORPORATION クライアントライブラリの仕様 • Produceしたメッセージはクライ アントでキャッシュされる • Brokerの受信能力を一時的に超えても エラーが起きない • 一時的なThroughput変動を吸収可能だ が... • 常時大量送信してると、Out Of Memoryが起きる • E2E Latencyも増え続ける Producer OutOfMemory OOMエラーが起きた場合の E2E Latency 長時間転送できるThroughput の上限を計測
17. 16 Copyright NTT CORPORATION 検証結果 Target Throughput 180 msg/s 190 msg/s 200 msg/s Ave. Latency [ms] 12.61 19.80 (OOMエラー) E2E Latency 99% [ms] 65.36 287.66 Max latency [ms] 116.91 424.73 • 2MBメッセージに対して、最大Throughputは190msg/s ~ 200msg/s • i.e. ~400MB/s、 Latencyは限界性能まで<0.5sのため十分小さい Disk I/Oの実測性能：800MB/s 100msg/s 200msg/s 300msg/s 平均書き込み速度：420MB/s BKサーバの書き込みログ • BookKeeper側のDisk IOがネック • DiskIOの上限性能は400msg/s • DiskIO上限までのスパイクもあるが、 平均値はDisk限界性能の半分程度 BookKeeperに改善余地がある
18. 17 Copyright NTT CORPORATION BookKeeperの性能 Apache BookKeeper as a long term distributed store,JV Jujjuri(Salesforce), BookKeeper meetup on, Nov. 2016
19. 18 Copyright NTT CORPORATION BookKeeperの性能 Apache BookKeeper as a long term distributed store,JV Jujjuri(Salesforce), BookKeeper meetup on, Nov. 2016 大きいデータだと性能が発揮しにくい
20. 19 Copyright NTT CORPORATION BookKeeper性能の向上 • スケールアップ：Bookie単体のDisk使用率の向上 • i.e. 並列書き込みDisk IO スパイクを対処 • パラメータ設定(Write Thread Pool, Journal Thread etc.)によるボトルネック解消[1] • スケールアウト：Bookie数を増やし、効率的に利用する • EnsembleSize、 Write Quorumを増やし、Ack Quorumはそのままにしておく • 各Bookieの性能に合わせて、独自Replication方法も実装可能（DistributionSchedule） [1] Apache BookKeeper Internals ,https://medium.com/splunk-maas/apache-bookkeeper-internals-part-2-writes-359ffc17c497 項目 改善前（単体Bookie） 改善後（単体Bookie） スケールアウト Bookie Disk IO(MB/s) 420 610 (1.5x) ほぼ線形 （2台構成でBookie単 体性能*2より早いこと も！） Throughput (msg/s) 190 270 (1.42x) Avg. Latency (ms) 19.8 11.3 (-43%)
21. 20 Copyright NTT CORPORATION まとめ • 多様なプロトコルが存在するシステムに対して、Pulsarでデー タパイプラインを簡略化できる • PulsarはDC内（マイクロサービス間）での利用を対象に設計されており、 一部の極端なUCを考慮していないため、回避策が必要 • 場合によっては、無理に既存機能を使い回すより、独自実装の 方が効率よい • Pulsarの疎結合設計のおかげで、改善・改造自体も簡単