Recomendados
Más contenido relacionado
Destacado
Destacado (20)
NSQ-Centric Architecture (GoCon Autumn 2014)
- 2. About me Greg Roseberry http://github.com/guregu • American • Went to college in Japan (Waseda) • The “Go person” at Gunosy • アメリカ人 • 早稲田大学出身 • Gunosyの「Go担当」
- 3. Gunosy News aggregator / portal app If you’re Japanese and have a TV you already know about it テレビを持っている日本人ならば ご存知のはず
- 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. Bring it on. かかってこい
- 6. The Problem • A chat server… • … that’s real-time • … and easily scalable • … and distributed • … and flexible, without complex configuration issues • チャット • … リアルタイム • … スケールしやすい • … 分散 • … 柔軟で、複雑な configいらず
- 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. Enter: NSQ “Spray some NSQ on it!” NSQをぶっかけよう！
- 9. NSQって何？ • What is NSQ? • It’s a message queue. • Written in Go. • Made and used extensively by bit.ly. • メッセージキュー • Goで書かれた • bit.lyが開発している
- 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. 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. Topics and Channels トピックにメッセージを送る。そのメッセージがコピ ーされて各チャンネルに送られる。複数のconsumer ( 消費者)の場合はランダムに届く。consumerがない場 合はメッセージが保管される。
- 14. NSQはそもそも何のために作られたの？ 分散統計処理とか、だが… • What was NSQ made for? • Distributed statics processing • But…
- 16. The Protocol • KISS. JSON. • Same for server→server and server→client • Easily routable • シンプルなJSON • サーバー同士のやり取 りとサーバーとクライ アントのやり取りが一 緒 • ルートしやすい
- 17. Message Format { "type": <message-type>, "to": <recipient-id>, "body": { ... } } オレオレRPC idを作れば完全にjson-rpc
- 18. Big Picture “chat” topic websocket-srv-1 websocket-srv-2 websocket-srv-… archive push bot
- 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. 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. 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. 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. 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. 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 • チャットメッセージと既読 メッセージを受けて、読ま れていないメッセージを数 える • 「新着メッセージが○件あ ります。」をプッシュ
- 26. 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台だけだとい ずれ問題が起こす • しばらくは大丈夫だけど いつか分散化へ
- 27. 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という管理画面で トピックとチャンネルを 一時停止もできる。 デプロイが楽！
- 28. 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がいなくなった ら消えるトピック • 今日紹介した仕組みすたれ ちゃうかも • ドキュメントがまだない。 研究が必要。
- 30. Order • Messages might get delivered out of order. • Solution: sort messages by their date. • Make sure your clocks are synchronized! • メッセージの届く順番 がない • 日付に応じてソートす ればOK • 時計を同期しましょう
- 31. 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 • メッセージは２回以上届 くかも • すでに届いたメッセージ のIDを記憶すればOK。 UUIDが便利 • メッセージの編集は日付 やバージョンで上書き
- 32. 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の変更が早い
- 33. Conclusion
- 34. • 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は助かる。 • これは別に新しい技術ではない が、開発しやすい仕組みです。 プログラマー１人が１ヶ月で MVP。
- 35. Thank you! 「毎日Goが書きたい！NSQとやら新技術を使ってみたい！」 と思っている諸君！ Gunosyはただ今、日本では数少ない Goエンジニア募集 を行っています。 ぜひ、一緒にGoを書きましょう！