Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
NSQ-Centric 
Architecture 
NSQ中心の構造
About me 
Greg Roseberry 
http://github.com/guregu 
• American 
• Went to college in Japan (Waseda) 
• The “Go person” at ...
Gunosy 
News aggregator / portal app 
If you’re Japanese and have a TV 
you already know about it 
テレビを持っている日本人ならば 
ご存知のはず
Life at Gunosy 
• We like Go 
• The API server is all Go 
• Anything else I get my hands 
on will be Go 
• You can use bas...
Bring it on. 
かかってこい
The Problem 
• A chat server… 
• … that’s real-time 
• … and easily scalable 
• … and distributed 
• … and flexible, witho...
The Basics 
• Go (obviously) 
• In-app webview, so 
WebSockets for realtime 
stuff 
• How can we stick our 
WebSocket serv...
Enter: NSQ 
“Spray some NSQ on it!” 
NSQをぶっかけよう!
NSQって何? 
• What is NSQ? 
• It’s a message queue. 
• Written in Go. 
• Made and used 
extensively by bit.ly. 
• メッセージキュー 
•...
NSQ Features 
• Distributed, no SPOF 
• Easily horizontally scalable 
• Low-latency, push-based 
messages 
• Can do load-b...
NSQ Guarantees 
• messages are not durable (by 
default) 
• set --mem-queue-size=0 to 
persist all messages to disk 
• mes...
Topics and Channels 
トピックにメッセージを送る。そのメッセージがコピ 
ーされて各チャンネルに送られる。複数のconsumer ( 
消費者)の場合はランダムに届く。consumerがない場 
合はメッセージが保管される。
nsqlookupd 
自動サービスディスカバリ
NSQはそもそも何のために作られたの? 
分散統計処理とか、だが… 
• What was NSQ made for? 
• Distributed statics processing 
• But…
The Mission 
WebViewでiMessage風チャットアプリ
The Protocol 
• KISS. JSON. 
• Same for 
server→server and 
server→client 
• Easily routable 
• シンプルなJSON 
• サーバー同士のやり取 
り...
Message Format 
{ 
"type": <message-type>, 
"to": <recipient-id>, 
"body": { 
... 
} 
} 
オレオレRPC idを作れば完全にjson-rpc
Big Picture 
“chat” topic 
websocket-srv-1 
websocket-srv-2 
websocket-srv-… 
archive 
push 
bot
WebSocket Channels 
“chat” topic 
websocket-srv-1 
websocket-srv-2 
websocket-srv-… 
archive 
push 
bot 
Msg A 
Msg A 
Msg...
WebSocket Channels 
• One unique channel per server 
(uses hostname) 
• Every server gets every 
message, drops uninterest...
Archive Channel 
“chat” topic 
websocket-srv-1 
websocket-srv-2 
websocket-srv-… 
archive 
push 
bot 
Msg A 
Msg B 
Msg C ...
Archive Channel 
• One channel, many consumers 
• Consumers grab every 
message, and persist relevant 
ones to the databas...
Push Channel 
“chat” topic 
websocket-srv-1 
websocket-srv-2 
websocket-srv-… 
archive 
push 
bot 
Msg A 
Msg A 
Msg B 
Ms...
Push Channel 
• One channel, one 
consumer 
• Receives chat messages 
and read receipts, 
counting unread 
messages 
• Sen...
Push Problems 
• 1 server is going to get 
overwhelmed eventually 
• Not a problem for us 
right now, but could be 
solved...
Microservices 
“chat” topic 
websocket-srv-1 
websocket-srv-2 
websocket-srv-… 
archive 
push 
bot 
Just by adding a new c...
NSQ 0.3 
• Came out less like a week 
ago 
• Introduces ephemeral topics: 
topics that disappear when 
there are no consum...
Client-side 
Considerations
Order 
• Messages might get 
delivered out of order. 
• Solution: sort messages 
by their date. 
• Make sure your clocks 
...
Duplicates 
• Messages might get 
delivered more than once. 
• Solution: keep a list of 
received messages, ignore 
duplic...
Why React 
• It’s easy to reason about 
updating data if you 
keep a single source of 
truth. 
• It’s easier to think abou...
Conclusion
• It’s easy to make a flexible, 
distributed app with an “NSQ-first” 
attitude. 
• … but it’s hard to make a truly 
“queue...
Thank you! 
「毎日Goが書きたい!NSQとやら新技術を使ってみたい!」 
と思っている諸君! 
Gunosyはただ今、日本では数少ない 
Goエンジニア募集 
を行っています。 
ぜひ、一緒にGoを書きましょう!
NSQ-Centric Architecture (GoCon Autumn 2014)
Upcoming SlideShare
Loading in …5
×

NSQ-Centric Architecture (GoCon Autumn 2014)

Designing a real-time chat system using NSQ and Go

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

NSQ-Centric Architecture (GoCon Autumn 2014)

  1. 1. NSQ-Centric Architecture NSQ中心の構造
  2. 2. About me Greg Roseberry http://github.com/guregu • American • Went to college in Japan (Waseda) • The “Go person” at Gunosy • アメリカ人 • 早稲田大学出身 • Gunosyの「Go担当」
  3. 3. Gunosy News aggregator / portal app If you’re Japanese and have a TV you already know about it テレビを持っている日本人ならば ご存知のはず
  4. 4. Life at Gunosy • We like Go • The API server is all Go • Anything else I get my hands on will be Go • You can use basically any software/library/whatever you’d like… if you’re willing to take responsibility. GunosyはGoが好き APIなどで Goを喜んで利用 責任を持てば… 好きな技術を 使っていい という主義
  5. 5. Bring it on. かかってこい
  6. 6. The Problem • A chat server… • … that’s real-time • … and easily scalable • … and distributed • … and flexible, without complex configuration issues • チャット • … リアルタイム • … スケールしやすい • … 分散 • … 柔軟で、複雑な configいらず
  7. 7. The Basics • Go (obviously) • In-app webview, so WebSockets for realtime stuff • How can we stick our WebSocket servers behind a load balancer? • Goに決まってるだろ • アプリ内WebViewなので リアルタム処理は WebSocket • WebSocketはどうやって ロードバランス?
  8. 8. Enter: NSQ “Spray some NSQ on it!” NSQをぶっかけよう!
  9. 9. NSQって何? • What is NSQ? • It’s a message queue. • Written in Go. • Made and used extensively by bit.ly. • メッセージキュー • Goで書かれた • bit.lyが開発している
  10. 10. NSQ Features • Distributed, no SPOF • Easily horizontally scalable • Low-latency, push-based messages • Can do load-balanced style and multicast style • Data format agnostic • etc • 分散SPOFなし • 横にスケールしやすい • レイテンシーが低く、プッシュ でメッセージを送る • ロードバランスもマルチキャス トも可能 • データフォーマットは何でもOK • 等々
  11. 11. NSQ Guarantees • messages are not durable (by default) • set --mem-queue-size=0 to persist all messages to disk • messages are delivered at least once • messages received are un-ordered • consumers eventually find all topic producers • デフォルトでメッセージは耐久 性がない • --mem-queue-size=0で問題解 決 • メッセージが必ず一回以上届く • メッセージは順番がない • consumerは少し時間かかっても 結局全部のトピックを見つける
  12. 12. Topics and Channels トピックにメッセージを送る。そのメッセージがコピ ーされて各チャンネルに送られる。複数のconsumer ( 消費者)の場合はランダムに届く。consumerがない場 合はメッセージが保管される。
  13. 13. nsqlookupd 自動サービスディスカバリ
  14. 14. NSQはそもそも何のために作られたの? 分散統計処理とか、だが… • What was NSQ made for? • Distributed statics processing • But…
  15. 15. The Mission WebViewでiMessage風チャットアプリ
  16. 16. The Protocol • KISS. JSON. • Same for server→server and server→client • Easily routable • シンプルなJSON • サーバー同士のやり取 りとサーバーとクライ アントのやり取りが一 緒 • ルートしやすい
  17. 17. Message Format { "type": <message-type>, "to": <recipient-id>, "body": { ... } } オレオレRPC idを作れば完全にjson-rpc
  18. 18. Big Picture “chat” topic websocket-srv-1 websocket-srv-2 websocket-srv-… archive push bot
  19. 19. WebSocket Channels “chat” topic websocket-srv-1 websocket-srv-2 websocket-srv-… archive push bot Msg A Msg A Msg A Msg A
  20. 20. WebSocket Channels • One unique channel per server (uses hostname) • Every server gets every message, drops uninteresting ones (uses message To: field and a map/sync.RWMutex) • NSQ will hold on to all of our messages if we disconnect, so we can reconnect and catch up • Distributed (at least, multiplexed) chat! • サーバー1台につき、1つのチャンネル • 全部のメッセージが全部のサーバーに 行く。宛先を見て、関係ないメッセー ジは無視する(mapとsync.RWMutex) • もしネットワーク障害とかあったら、 NSQが届かなかったメッセージを保管 してくれる。 • 分散(少なくともマルチプレックス) チャット出来上がり!
  21. 21. Archive Channel “chat” topic websocket-srv-1 websocket-srv-2 websocket-srv-… archive push bot Msg A Msg B Msg C Randomly distributed Msg A Msg B Msg C
  22. 22. Archive Channel • One channel, many consumers • Consumers grab every message, and persist relevant ones to the database • It’s easy to add load balancing: just add more consumers • You can put the archiver processes on the same server as a DB and messages to be archived will be delivered directly • 一つのチャンネルに複数の consumer • 全部のメッセージを見て、DBに 書き込む • ロードバランスで分散するのに 、サーバーを追加するだけでOK • アーカイブプロセスとDBを一緒 にすればメッセージが直接DBサ ーバーへ
  23. 23. Push Channel “chat” topic websocket-srv-1 websocket-srv-2 websocket-srv-… archive push bot Msg A Msg A Msg B Msg C Msg B Msg C
  24. 24. Push Channel • One channel, one consumer • Receives chat messages and read receipts, counting unread messages • Sends a push message after a message goes unread for a certain time • 一つのチャンネルに一つの consumer • チャットメッセージと既読 メッセージを受けて、読ま れていないメッセージを数 える • 「新着メッセージが○件あ ります。」をプッシュ
  25. 25. Push Problems • 1 server is going to get overwhelmed eventually • Not a problem for us right now, but could be solved in the future (split servers based on message ID, etc). • サーバー1台だけだとい ずれ問題が起こす • しばらくは大丈夫だけど いつか分散化へ
  26. 26. Microservices “chat” topic websocket-srv-1 websocket-srv-2 websocket-srv-… archive push bot Just by adding a new channel, we can easily add a new service. It’s even possible to pause topics or channels on the NSQ web admin interface. チャンネルを追加するだけで、 新しいマイクロサービスを 追加できる。 nsqadminという管理画面で トピックとチャンネルを 一時停止もできる。 デプロイが楽!
  27. 27. NSQ 0.3 • Came out less like a week ago • Introduces ephemeral topics: topics that disappear when there are no consumers left • Could completely obsolete this architecture/the multicast method. • No docs, needs more research. • 一週間前くらいに出た • ephemeral topicsという、 consumerがいなくなった ら消えるトピック • 今日紹介した仕組みすたれ ちゃうかも • ドキュメントがまだない。 研究が必要。
  28. 28. Client-side Considerations
  29. 29. Order • Messages might get delivered out of order. • Solution: sort messages by their date. • Make sure your clocks are synchronized! • メッセージの届く順番 がない • 日付に応じてソートす ればOK • 時計を同期しましょう
  30. 30. Duplicates • Messages might get delivered more than once. • Solution: keep a list of received messages, ignore duplicates. UUIDs. • You can handle message edits by date or revision number or something fancier • メッセージは2回以上届 くかも • すでに届いたメッセージ のIDを記憶すればOK。 UUIDが便利 • メッセージの編集は日付 やバージョンで上書き
  31. 31. Why React • It’s easy to reason about updating data if you keep a single source of truth. • It’s easier to think about components than controllers, services, factories, scope, etc. • Virtual DOM is fast • 情報の更新は一元化す れば捗る • コンポーネント指向は 捗る • DOMの変更が早い
  32. 32. Conclusion
  33. 33. • It’s easy to make a flexible, distributed app with an “NSQ-first” attitude. • … but it’s hard to make a truly “queue-only” app that avoids hitting the DB. Groupcache can help. • Nothing here is particularly novel, but it was simple to develop. Less than a month for a MVP between one programmer and one designer. Not bad for a distributed service. • NSQを中心にすれば、分散で フレキシブルなサービスが作り やすい。 • しかし、ほとんどDBをたたか ない「キューのみ」のサービス はちょっと難しい。 Groupcacheは助かる。 • これは別に新しい技術ではない が、開発しやすい仕組みです。 プログラマー1人が1ヶ月で MVP。
  34. 34. Thank you! 「毎日Goが書きたい!NSQとやら新技術を使ってみたい!」 と思っている諸君! Gunosyはただ今、日本では数少ない Goエンジニア募集 を行っています。 ぜひ、一緒にGoを書きましょう!

×