KubeCon2019_NA_Recap__NATS_.pdf

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

取り上げるセッション参考< 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)

Slide 4

Slide 4 text

What is NATS?

Slide 5

Slide 5 text

Sample of NATS Clients

Slide 6

Slide 6 text

Use Case

Slide 7

Slide 7 text

Some NATS Users

Slide 8

Slide 8 text

Netlify(1/3)

Slide 9

Slide 9 text

Netlify(2/3)

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

tinder(1/2)

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Pub/Sub 基礎

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

NATS 基礎

Slide 19

Slide 19 text

1:1の基本的な構成

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

NATSの構成の話

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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