Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
KubeCon2019_NA_Recap__NATS_.pdf
Search
yosshi_
December 10, 2019
Technology
0
150
KubeCon2019_NA_Recap__NATS_.pdf
yosshi_
December 10, 2019
Tweet
Share
More Decks by yosshi_
See All by yosshi_
Getting Started with Kubernetes Observability
yosshi_
8
2.4k
PromQL_Compatibility_Testing_Recap
yosshi_
0
1k
プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki
yosshi_
11
3.3k
これから学ぶKubernetesのReconciliation Loop
yosshi_
11
3.8k
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf
yosshi_
12
5.7k
“Running Apache Samza on Kubernetes” Recap : KubeCon2019@NA
yosshi_
3
1.1k
Kuberntes_Monitoring_入門.pdf
yosshi_
17
3k
Kubernetes_Logging入門.pdf
yosshi_
18
7.5k
Vitessの基礎.pdf
yosshi_
7
1.4k
Other Decks in Technology
See All in Technology
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
130
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
36
14k
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
32k
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
5分でわかるDuckDB
chanyou0311
10
3.2k
サイボウズフロントエンドエキスパートチームについて / FrontendExpert Team
cybozuinsideout
PRO
5
38k
日本版とグローバル版のモバイルアプリ統合の開発の裏側と今後の展望
miichan
1
130
KnowledgeBaseDocuments APIでベクトルインデックス管理を自動化する
iidaxs
1
260
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
280
LINE Developersプロダクト(LIFF/LINE Login)におけるフロントエンド開発
lycorptech_jp
PRO
0
120
ガバメントクラウドのセキュリティ対策事例について
fujisawaryohei
0
550
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
570
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Building an army of robots
kneath
302
44k
The Invisible Side of Design
smashingmag
298
50k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
98
Unsuck your backbone
ammeep
669
57k
Code Review Best Practice
trishagee
65
17k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Scaling GitHub
holman
458
140k
4 Signs Your Business is Dying
shpigford
181
21k
The Cost Of JavaScript in 2023
addyosmani
45
7k
Transcript
ç “NATS: Past, Present and the Future” Recap : KubeCon2019@NA
Cloud Native Meetup Tokyo #11 KubeCon Recap@CyberAgent @yosshi_
• 吉村 翔太 • NTTコミュニケーションズ所属 • データサイエンスチーム • インフラエンジニア/データエンジニアリング •
Kurbernetes 、Prometheus etc • 趣味:ボードゲーム • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”
取り上げるセッション 参考< 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)
What is NATS?
Sample of NATS Clients
Use Case
Some NATS Users
Netlify(1/3)
Netlify(2/3)
Netlify(3/3) 参考< https://www.slideshare.net/RyanNeal10/nats-and-netlify >
tinder(1/2)
tinder(2/2) • 要件 – アプリから更新が無いか2秒に1回ポーリングをやめたい • 他のユーザから自分宛に新規のメッセージが来ていないか等の確認 • ポーリングは電池の消費も激しいし、 NWも使う
参考< https://medium.com/tinder-engineering/how-tinder-delivers-your-matches-and-messages-at-scale-504049f22ce0 >
Pub/Sub 基礎
Pub/Subのよくある使い方 • 急激な負荷の吸収 – スマホのアプリ、IoTからのデータの収集 – 負荷が予想しづらい、スケールしやすいもの • 分配 –
同じ入力データを複数の用途で使う – 分析基盤に多い • イベント駆動 – データを作る部分と、使う部分の処理を分けてたい PUB SUB
Subscribeのやり方 • Push型 • Pull型 SUB SUB PUB PUB
QoS(送信の保証) • At Most Once – メッセージが一度だけ送られる – 重複は無いが、欠損はありうる •
At Least Once – メッセージが届くまで送られる – 重複はありうるが欠損は無い。 • Exactly Once – メッセージは一度だけ必ず送られる – “At Least Once”なプロダクトを使用する際にメッセージにIDを入れて、重複削除したり することで実現することが多い。
設計のポイント • スケーラビリティ – 水平スケールをどうできるか? – リバランスできる? • 可用性 –
ノード障害時の挙動 • レイテンシ – データを入れるのにかかる時間 – データを取り出す時間、取り出した後に処理にかかる時間
NATS 基礎
1:1の基本的な構成
1:N(Subject-Based Messaging) 送る側で Subject “foo”をつける 受ける側でもSubjectを持っていて “foo”の該当者が受け取る
Wildcard Subscribers Subjectは “.”で階層化できる Subjectに “*”が付けれる
Subject Hierarchies • Subjectは”.”で階層化出来るので 必要なとこにだけメッセージが届く構成が取れる
Load Balanced Queues 受ける側をグループ化出来る どれか1つにだけランダムで送られる 受け手側の負荷分散が出来る
Securing Connections • Authenticating – User and Password – Token
– NKeys which uses Ed25519 signing – Credentials File • Encrypting Connections with TLS
NATSの構成の話
NATS Cluster この1個がServer 相互接続されたServerの塊が Cluster ClientはどれかのServerに 所属してるイメージ
Supercluseters “Gateway Connections”で Cluster間を接続できる
Leaf Nodes • Leaf nodes allow you to bridge separate
security domains.
調べてて思ったこと・・・電話みたい 離島 関東エリア 関西エリア エリア間通信
KafkaとNATSの使い分け • 要件が”At-Most-Once”の時は – ”NATS” • 要件が”At-Least-Once”の時は – ”Kafka”
KafkaとNATSの使い分け • NATS – シンプルで軽量 – スケールしやすい – Push型 –
(ディスクを意識しなくていいので楽:Core-NATSの話) • Kafka – 耐障害性が重要(レプリケーションがある) – 入れるデータに保管期間が必要(ディスクに入れる) – Pull型 – (NATS StreamingならAt-Least-Onceも可能)
NATS Streaming Moduleを追加 NATS Serverのみの構成を”Core NATS”と呼ぶ
Sample Dashboard(1/3)
Sample Dashboard(2/3)
Sample Dashboard(3/3)
Roadmap 直近は、”NATS Streaming”絡みが多い MQTT、Websocket対応