KubeCon2019_NA_Recap__NATS_.pdf

Transcript

1. ç
   “NATS: Past, Present and the Future”
   Recap : KubeCon2019@NA
   Cloud Native Meetup Tokyo #11 KubeCon Recap@CyberAgent
   @yosshi_
   

   View Slide

2. ● 吉村 翔太
   ● NTTコミュニケーションズ所属
   ● データサイエンスチーム
   ● インフラエンジニア/データエンジニアリング
   ● Kurbernetes 、Prometheus　 etc
   ● 趣味：ボードゲーム
   ● コミュニティ活動 “Cloud Native Developers JP”
   @yosshi_
   自己紹介
   “Prometheus Meetup Tokyo”
   

   View Slide

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)
   

   View Slide

4. What is NATS?
   

   View Slide

5. Sample of NATS Clients
   

   View Slide

6. Use Case
   

   View Slide

7. Some NATS Users
   

   View Slide

8. Netlify(1/3)
   

   View Slide

9. Netlify(2/3)
   

   View Slide

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

    View Slide

11. tinder(1/2)
    

    View Slide

12. tinder(2/2)
    • 要件
    – アプリから更新が無いか2秒に1回ポーリングをやめたい
    • 他のユーザから自分宛に新規のメッセージが来ていないか等の確認
    • ポーリングは電池の消費も激しいし、 NWも使う
    参考< https://medium.com/tinder-engineering/how-tinder-delivers-your-matches-and-messages-at-scale-504049f22ce0 >
    

    View Slide

13. Pub/Sub 基礎
    

    View Slide

14. Pub/Subのよくある使い方
    • 急激な負荷の吸収
    – スマホのアプリ、IoTからのデータの収集
    – 負荷が予想しづらい、スケールしやすいもの
    • 分配
    – 同じ入力データを複数の用途で使う
    – 分析基盤に多い
    • イベント駆動
    – データを作る部分と、使う部分の処理を分けてたい
    PUB SUB
    

    View Slide

15. Subscribeのやり方
    • Push型
    • Pull型
    SUB
    SUB
    PUB
    PUB
    

    View Slide

16. QoS(送信の保証)
    • At Most Once
    – メッセージが一度だけ送られる
    – 重複は無いが、欠損はありうる
    • At Least Once
    – メッセージが届くまで送られる
    – 重複はありうるが欠損は無い。
    • Exactly Once
    – メッセージは一度だけ必ず送られる
    – “At Least Once”なプロダクトを使用する際にメッセージにIDを入れて、重複削除したり
    することで実現することが多い。
    

    View Slide

17. 設計のポイント
    • スケーラビリティ
    – 水平スケールをどうできるか？
    – リバランスできる？
    • 可用性
    – ノード障害時の挙動
    • レイテンシ
    – データを入れるのにかかる時間
    – データを取り出す時間、取り出した後に処理にかかる時間
    

    View Slide

18. NATS 基礎
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. Securing Connections
    • Authenticating
    – User and Password
    – Token
    – NKeys which uses Ed25519 signing
    – Credentials File
    • Encrypting Connections with TLS
    

    View Slide

25. NATSの構成の話
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

31. KafkaとNATSの使い分け
    • NATS
    – シンプルで軽量
    – スケールしやすい
    – Push型
    – (ディスクを意識しなくていいので楽：Core-NATSの話)
    • Kafka
    – 耐障害性が重要（レプリケーションがある）
    – 入れるデータに保管期間が必要（ディスクに入れる）
    – Pull型
    – (NATS StreamingならAt-Least-Onceも可能)
    

    View Slide

32. NATS Streaming
    Moduleを追加
    NATS Serverのみの構成を”Core NATS”と呼ぶ
    

    View Slide

33. Sample Dashboard(1/3)
    

    View Slide

34. Sample Dashboard(2/3)
    

    View Slide

35. Sample Dashboard(3/3)
    

    View Slide

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

    View Slide