KubeCon2019_NA_Recap__NATS_.pdf

24606216ae4bbee28494552cb71cc220?s=47 yosshi_
December 10, 2019

 KubeCon2019_NA_Recap__NATS_.pdf

24606216ae4bbee28494552cb71cc220?s=128

yosshi_

December 10, 2019
Tweet

Transcript

  1. ç “NATS: Past, Present and the Future” Recap : KubeCon2019@NA

    Cloud Native Meetup Tokyo #11 KubeCon Recap@CyberAgent @yosshi_
  2. • 吉村 翔太 • NTTコミュニケーションズ所属 • データサイエンスチーム • インフラエンジニア/データエンジニアリング •

    Kurbernetes 、Prometheus  etc • 趣味:ボードゲーム • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”
  3. 取り上げるセッション 参考< https://sched.co/UdIm > Keynote: NATS: Past, Present and the

    Future Derek Collison, Founder and CEO, Synadia(p42) 参考< https://sched.co/UdIm > Deploy Secure and Scalable Services Across Kubernetes Clusters with NATS(p81)
  4. What is NATS?

  5. Sample of NATS Clients

  6. Use Case

  7. Some NATS Users

  8. Netlify(1/3)

  9. Netlify(2/3)

  10. Netlify(3/3) 参考< https://www.slideshare.net/RyanNeal10/nats-and-netlify >

  11. tinder(1/2)

  12. tinder(2/2) • 要件 – アプリから更新が無いか2秒に1回ポーリングをやめたい • 他のユーザから自分宛に新規のメッセージが来ていないか等の確認 • ポーリングは電池の消費も激しいし、 NWも使う

    参考< https://medium.com/tinder-engineering/how-tinder-delivers-your-matches-and-messages-at-scale-504049f22ce0 >
  13. Pub/Sub 基礎

  14. Pub/Subのよくある使い方 • 急激な負荷の吸収 – スマホのアプリ、IoTからのデータの収集 – 負荷が予想しづらい、スケールしやすいもの • 分配 –

    同じ入力データを複数の用途で使う – 分析基盤に多い • イベント駆動 – データを作る部分と、使う部分の処理を分けてたい PUB SUB
  15. Subscribeのやり方 • Push型 • Pull型 SUB SUB PUB PUB

  16. QoS(送信の保証) • At Most Once – メッセージが一度だけ送られる – 重複は無いが、欠損はありうる •

    At Least Once – メッセージが届くまで送られる – 重複はありうるが欠損は無い。 • Exactly Once – メッセージは一度だけ必ず送られる – “At Least Once”なプロダクトを使用する際にメッセージにIDを入れて、重複削除したり することで実現することが多い。
  17. 設計のポイント • スケーラビリティ – 水平スケールをどうできるか? – リバランスできる? • 可用性 –

    ノード障害時の挙動 • レイテンシ – データを入れるのにかかる時間 – データを取り出す時間、取り出した後に処理にかかる時間
  18. NATS 基礎

  19. 1:1の基本的な構成

  20. 1:N(Subject-Based Messaging) 送る側で Subject “foo”をつける 受ける側でもSubjectを持っていて “foo”の該当者が受け取る

  21. Wildcard Subscribers Subjectは “.”で階層化できる Subjectに “*”が付けれる

  22. Subject Hierarchies • Subjectは”.”で階層化出来るので 必要なとこにだけメッセージが届く構成が取れる

  23. Load Balanced Queues 受ける側をグループ化出来る どれか1つにだけランダムで送られる 受け手側の負荷分散が出来る

  24. Securing Connections • Authenticating – User and Password – Token

    – NKeys which uses Ed25519 signing – Credentials File • Encrypting Connections with TLS
  25. NATSの構成の話

  26. NATS Cluster この1個がServer 相互接続されたServerの塊が Cluster ClientはどれかのServerに 所属してるイメージ

  27. Supercluseters “Gateway Connections”で Cluster間を接続できる

  28. Leaf Nodes • Leaf nodes allow you to bridge separate

    security domains.
  29. 調べてて思ったこと・・・電話みたい 離島 関東エリア 関西エリア エリア間通信

  30. KafkaとNATSの使い分け • 要件が”At-Most-Once”の時は – ”NATS” • 要件が”At-Least-Once”の時は – ”Kafka”

  31. KafkaとNATSの使い分け • NATS – シンプルで軽量 – スケールしやすい – Push型 –

    (ディスクを意識しなくていいので楽:Core-NATSの話) • Kafka – 耐障害性が重要(レプリケーションがある) – 入れるデータに保管期間が必要(ディスクに入れる) – Pull型 – (NATS StreamingならAt-Least-Onceも可能)
  32. NATS Streaming Moduleを追加 NATS Serverのみの構成を”Core NATS”と呼ぶ

  33. Sample Dashboard(1/3)

  34. Sample Dashboard(2/3)

  35. Sample Dashboard(3/3)

  36. Roadmap 直近は、”NATS Streaming”絡みが多い MQTT、Websocket対応