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
220
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
KubeCon2019_NA_Recap__NATS_.pdf
yosshi_
December 10, 2019
More Decks by yosshi_
See All by yosshi_
From 5 to 1,300+ Clusters: Declarative Scaling for Private Kubernetes
yosshi_
0
56
Scaling In Kubernetes Safely on On-Prem KaaS Across 1,300+ Clusters and 40,000+ Nodes
yosshi_
1
94
Getting Started with Kubernetes Observability
yosshi_
8
2.8k
PromQL_Compatibility_Testing_Recap
yosshi_
0
1.2k
プロダクト誕生の背景から学ぶ PrometheusとGrafana Loki
yosshi_
11
3.8k
これから学ぶKubernetesのReconciliation Loop
yosshi_
16
5.3k
伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf
yosshi_
13
6.4k
“Running Apache Samza on Kubernetes” Recap : KubeCon2019@NA
yosshi_
3
1.3k
Kuberntes_Monitoring_入門.pdf
yosshi_
17
3.2k
Other Decks in Technology
See All in Technology
【CEDEC2026】コードレビュー支援ツール開発から学ぶ:LLMを用いた業務システムの実践的な運用設計と誤出力対策
cygames
PRO
0
750
変化の早いClaude Codeを 書籍に落とし込む
oikon48
7
1.4k
【CEDEC2026】『ウマ娘 プリティーダービー』 英語版のキャラクターの方言や口調をローカライズするための創造的アプローチ
cygames
PRO
2
760
グローバル基準のSREは、運用現場でどう機能したか:成熟度アセスメントの実践 / SRE NEXT 2026
sorawatanabe
0
230
DatadogのBits Chatが開発組織にもたらしたもの / What Bits Chat Has Brought Us
sms_tech
1
260
AIコーディングの次。コードレビューと理解負荷を解消して組織の開発生産性を高める
moongift
PRO
2
2.5k
AWS ネットワーク構築でハマった(ハマりかけた) 5選とそこから得た教訓
nagisa53
4
210
AIペネトレーションテスト・ セキュリティ検証「AgenticSec」紹介資料
laysakura
2
9k
[ChatGPT Work LT]事務作業が苦手な人のための バックオフィスの「半」自動化
chimaki_iot
0
280
【CEDEC2026】『Relink』を拡張せよ - 『GRANBLUE FANTASY: Relink - Endless Ragnarok』の開発速度と品質を守るCI運用
cygames
PRO
0
170
2026-08-05 IBM Z開発最前線!IBM Bob Premium Package for Zって何がすごいの?
yutanonaka
0
110
事業価値と Engineering 2026年度版
recruitengineers
PRO
49
23k
Featured
See All Featured
Utilizing Notion as your number one productivity tool
mfonobong
4
540
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
370
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
4 Signs Your Business is Dying
shpigford
187
22k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
410
The Curious Case for Waylosing
cassininazir
1
450
The Language of Interfaces
destraynor
162
27k
Amusing Abliteration
ianozsvald
1
240
YesSQL, Process and Tooling at Scale
rocio
174
15k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
200
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.3k
Mind Mapping
helmedeiros
PRO
1
310
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対応