Band of brothers, building scalable social web apps on windows azure with mvc3, mongo db, rabbitmq


Published on

The presentation will be deep dive into how to build scalable social web apps on Windows Azure IAAS by utilizing latest technologies based on document based storage

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Band of brothers, building scalable social web apps on windows azure with mvc3, mongo db, rabbitmq

  1. 1. Band of Brothers, building scalable social web apps on Windows Azurewith ASP.NET MVC3, MongoDB, RabbitMQMarjan NikolovskiCo-Owner, Senior Software Engineer at EmitKnowledgeSenior Software Engineer at
  2. 2. Agenda• Social web architecture• Intro to MongoDB• Data modeling for MongoDB• Intro to RabbitMQ• Preparing your guns for pub/sub with RabbitMQ• Data painting with MVC3• Hosting and scaling strategies on Windows Azure
  3. 3. Social web architecture• By definition a social web must provide connectivity between the users for a common good• From functional aspect a social web must provide: • Connectivity (Relationships) • Privacy • Private messaging • Notifications and events (both real-time and offline) • Recommendations
  4. 4. Social web architecture• Connectivity, how users are socializing • Directional or bidirectional relations ? • How are users going to socialize ? • Post Sharing • Groups • Private messaging • Gamification
  5. 5. Social web architecture• Privacy • Beware of details • Who, When and WhatUserA User B User CWho can access my Y Ndata ?When can my data be After publish Delay with 1 dayaccessed ?What kind of data could Posts and events Postsbe accessed ?
  6. 6. Social web architecture• Private messaging aka Conversations • Define messaging types: • One to One • Group messaging • Define messaging strategy • When a new conversation starts ? • Until when does it last ? • Spam detection and prevention • Mark as spam strategy • Spam filtering strategy • Both ?
  7. 7. Social web architecture• Notifications and events (both real-time and offline) • When to notify ? • Frequency of notifications • To stream or to aggregate? • To filter or display all ?
  8. 8. Social web architecture• Recommendations • Define recommendation method: • Friends method • Recommends the friends of my friends • Ease to implement • Big miss factor • Recommends people that we possibly know • Not very practical • Sharing interests method • Recommend me a friend that we have a starting point to talk about • Efficient for connectivity • Needs initial user input for building the analytics
  9. 9. Social web architecture• From technical aspect must respect: • Stateless • Pluggability • Async execution • Load distribution • Intensive logging and auditing • Content delivery strategy
  10. 10. Social web architecture• Stateless • Azure instance load balancing is your enemy • We don’t know on which instance the request will end (cloud load balancing) • So, forget about using server side session or tempdata • Yes we can store it in DB, but performance per request ?
  11. 11. Social web architecture
  12. 12. Social web architecture• Pluggability • Enable the platform to go down partially • Develop your functionalities as plugins • Enable real-time plugin load/unload (hotplug) • Partial deployment
  13. 13. Social web architecture
  14. 14. Social web architecture• Async execution • Sequential processing only at the minimum, everything else delegate to background services • User registration use case • User reset password use case • User notification use case • Time and data intensive operations must execute as background services jobs
  15. 15. Social web architecture Web server Messaging infrastructure Worker servicesSend create user request Send confirmation email message User created response Notify for new user registration message
  16. 16. Social web architecture• Load distribution • We hit the processing limit per machine. Now what ? • Develop your data and time intensive functionalities with job distribution in mind • Event based Producer – consumer jobs • Each functionality requires • Job orchestrator • Job processor
  17. 17. Social web architecture Notify from 1 – 100 Notify from 101 – 123 Notify all of my friends Notify all of my friends Notify from 1 – 100New user post MESSAGING INFRASTRUCTURE Notify from 101 – 123
  18. 18. Social web architecture• Intensive logging and auditing • You will always want to know what your users are up to • Analytics can’t help ! • Put your intensive logging and auditing so you can playback later • Log and audit everything you can get • Build your own analytics system
  19. 19. Social web architecture{ "Username" : "some_username", "IsAuthenticated" : false, "RawUri" : "/Account/Login", "BaseUri" : "/Account/Login", "HttpMethod" : "POST", "IpAddress" : "", "Refferer" : "http://localhost:42378/", "UserAgent" : "mozilla/5.0 (windows nt 6.1) applewebkit/535.12 (khtml, like gecko) maxthon/ safari/535.12", "IsCrawler" : false, "IsSecureResource" : false, "Action" :"Emit.Knowledge.Controllers.RequestLogging.UserRequestLoggingController.VerifyUserCredentials(Stringusername, String password, User& verifiedUser)", "Data" : { "username" : "test333" }, "IsFaulted" : false, "CreatedOn" : { "UtcDateTime" : new Date("3/10/2012 01:40:52") }}
  20. 20. Social web architecture• Content delivery strategy • Reference your scripts with build number • .js?ver=1.0.1 to propagate script changes with ease • Minify as many js scripts into one • Group page images into sprites and add build number • .png?ver=1.0.1 • Reference user images to the CDN • Analyze the average change of user profile image to determine the image caching period
  21. 21. Intro to MongoDB • Document store • Fast, scalable and available • JSon – used for data hydratation • Dynamic • Stores data structured as documents instead of row as seen in RDBMS • Uses Query, Insert, Update and Remove for data manipulation • Used for adding data at high rates without “choking” the system
  22. 22. Intro to MongoDB• Documents in MongoDB • Each document can be of size max to 16mb • Each document you insert into MongoDB will be assigned an id consisted of: • This is a 12-byte value consisting of 4 parts: timestamp (4 bytes) • machine identifier (3 bytes) • process id (2 bytes) • increment (3 bytes) • in MongoDB, each document will contain not only the values, but the key names (~"column names" in relational db-speak) too. So if you have keys: “Username" and “Password", then those alone will add 16 bytes to each document. • MongoDB automatically adds some padding to the documents to allow for documents to grow in size to try and reduce the need for documents to be moved around if they do grow
  23. 23. Data modeling for MongoDB• Forget what you’ve learned at school and shift your mind• Want to be fast ? – Denormalize data that will be static (IAuditable – ring any bells ?)• Common pitfalls • To render a post we need the post content and the username • Modeling by the book will get you to model the Content entity to have Title, Content, UserId • Now we need to fire two queries to display the username
  24. 24. Data modeling for MongoDB• Beware of your queries • Analyze all of your queries • Set index per query • But don’t forget the order by in the index  • Mongodb has limitation for “OR” queries and sorts (indexing will not help you here) • Think in map/reduce way maybe ?
  25. 25. Intro to RabbitMQ• Robust and reliable messaging for apps• Supports many messaging patterns • Publish-subscribe • Topic based PubSub • Point-to-point • Request-reply • Store and forward • …
  26. 26. { Publish-subscribe Publisher Publish an event Topic Consumes the event Consumes the event Subscriber Subscriber
  27. 27. { Topic based PubSub Topic Consumes the event Consumes the event Subscriber Subscriber Consumes the event Subscriber Subtopic Publish an event Publisher
  28. 28. { Point-to-point Publisher Queue Subscriber
  29. 29. { Request-reply Subscriber Publisher/Subscriber Topic Subscriber Subscriber
  30. 30. { Store and forward Subscriber Publisher/Subscriber Topic Subscriber Subscriber Data
  31. 31. Preparing your guns for pub/sub with RabbitMQ• Establishing pub/sub architecture • Who will listen on what ? • Do we need to intercept messages ? • Do we need to deliver one message to many subscribers ? • Do we need to distribute the message processing ?• Two levels of messaging • Job coordination and distribution • Server instancing coordination• Messaging patterns of interests • Pub/Sub • Topic based Pub/Sub
  32. 32. Preparing your guns for pub/sub pub/sub withRabbitMQ• Persist messages that must be delivered, everything else just flush it through the wire• Topic subscription is your enemy • Don’t expand your topics tree in depth • Minimize topic root subscriptions
  33. 33. Data painting with MVC3• Delegate data render to the client with dynamic data instead on server side• Prepare your static content and the templates in the views (this will help you to reduce the traffic. Dom will be created on fly.)• Knockout your dynamic data
  34. 34. Data painting with MVC3 <script id="notes-template" type="text/html"> {{each notes }} <div class="note-wrap"> <div class="note-title"> <div class="title-text">${GetTitle}</div> <div class="title-date">${LastEditedDate}</div> </div> </div> </div> {{/each}} </script>
  35. 35. Data painting with MVC3 <div class="note-wrap"> <div class="note-title"> <div class="title-text">Title 1</div> <div class="title-date">2012-01-01</div> </div> <div class="note-title"> <div class="title-text">Title 2</div> <div class="title-date">2012-01-02</div> </div> <div class="note-title"> <div class="title-text">Title 3</div> <div class="title-date">2012-01-03</div> </div> </div> </div>
  36. 36. Data painting with MVC3 Template + Ajax Server render 638 bytes - JSON / 2246 bytes - HTML template 22460 bytes - HTML TOTAL 2884 bytes 22460 bytes – HTML
  37. 37. Hosting and scaling strategies on Windows Azure• Design deployment and scaling strategy per component: • Web server • Data server • Messaging server • Worker server
  38. 38. Hosting and scaling strategies on Windows Azure• When to scale ? • MongoDB instances • Indexes are too large to fit in memory • First scale vertically with RAM then shard • RabbitMQ instances • Message delivery slows down • Scale vertically with CPU then shard • ASP.NET MVC instances • Number of users goes large • Check what is eating the machine throughtput • Usually problem with the notifications long pooling • Scale horizontally with more extra small or small instances • Worker instances • Job processing time goes “large” • Scale horizontally with more extra small or small instances • Round robin processing strategy will help you to relax the job processing
  39. 39. Hosting and scaling strategies on Windows Azure• Two instances per type to meet with the SLA requirements• Use CentOS for MongoDB, Linux has better memory fragmentation than Windows• For RabbitMQ choose the OS that you are most comfortable with.• Windows 2K8 OS for the ASP.NET MVC
  40. 40. Hosting and scaling strategies on Windows Azure• Open SSH and MongoDB ports only• Don’t forget to disable anonymous login on the MongoDB and set u/p combinations for both server and database
  41. 41. Hosting and scaling strategies on Windows Azure• Open SSH/Remote Desktop ports and RabbitMQ communication port• Disable anonymous connections to the instance and add u/p combinations for connection to the RabbitMQ server