1 / 28

Distributed Bidding System (DBS)

Distributed Bidding System (DBS). An Amazon EC2 Cloud Application. Authors: Jason Lu Michael S. Peña Sashmit Bhaduri Center for Lifelong Continuing Education University of Texas at Austin Austin Texas, U.S.A. DBS Presentation Outline. Introduction Motivation Relationships

elaina
Download Presentation

Distributed Bidding System (DBS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Bidding System (DBS) An Amazon EC2 Cloud Application Authors: Jason Lu Michael S. Peña SashmitBhaduri Center for Lifelong Continuing Education University of Texas at Austin Austin Texas, U.S.A

  2. DBS Presentation Outline • Introduction • Motivation • Relationships • Architecture • Implementation • Scenarios • Design Considerations • Future Work • Conclusion

  3. Introduction • E-commerce “..healthy 12.6% increase to $176.2 billion in 2010, U.S. online retail sales are expected to reach $278.9 billion in 2015” - Forrester Research Inc. online • Bidding System & Other sites Ex. Ebay, dealighted.com, slickdeals.net, etc.. • Need of Distributed Systems • Cloud Computing Ex. Amazon EC2, Microsoft Azure, Google, Salesforce, Rackspace, and Zoho

  4. Motivation • Goals : IS vs. IS NOT • IS: Scalability, Consistency, Adequate Performance System • IS NOT: Persistent, Security, Real Auction System • Focus • Distributed algorithm vs Consumer friendly

  5. Motivation (Cont.) • Cloud Computing Comparison • Free tier licensing • Free accounts • Rich APIs support • Most widely utilized Cloud service

  6. Relationships • Java TCP Client/Server • Distributed Resource Allocation • 1st explored Lamport Mutual Exclusion Algorithm • Used Ricart and Agrawala’s Algorithm • Transactions, No Leader Election

  7. Architecture

  8. Architecture End user (web browser) -> BidClientServlet Sequence of Operations: • Open HTTP connection to HTTP server (running on :8081) • HTTP server passes control to BidClientServlet • BidClientServlet processes request, perhaps connecting to a random BidServer depending on the specific action • BidClientServlet generates HTML, sends back to web browser

  9. Architecture • HTTP API (specified via RFC1738/RFC3986-encoded params in URL): • Login – performs login e.g, action=login&username=foobar • Sets HTTP Cookie to track username (w/o cookie, goes back to login page automatically) • Nothing sent to BidServers – Web Browser only • Auction List – shows auction list • Connects to a BidServer • Gets ItemIds, ItemInfo, TopBid for each Auction • Disconnects, generate HTML table w/ info • Detail/Place • Same HTML output page • Connects to a BidServer • If Placing Bid, sends PlaceBid • Gets ItemInfo, all Bids • Disconnects, generate HTML w/ results of ItemInfo/Bid List • Logout – logout, clears cookie

  10. Implementation Technologies • OpenJDK 6 •  BidServers, BidClientServlet • Apache Tomcat 6.0 • Catalina/J2EE •  BidClientServlet (running within HTTP server) • Deployment: • Amazon’s Elastic Compute Cloud • Amazon EC2 API Tools (utilizes EC2 Java API) • Ubuntu 10.10 using Linux 2.6.x • OS for EC2 instances • Python 2.6 • openssh

  11. Implementation (Cont.) GUI Screenshot • Login Page:

  12. Implementation (Cont.) GUI Screenshot

  13. Implementation (Cont.) GUI Screenshot

  14. Communication Bid Server 1 Bid Server 2 Bid Client

  15. Protocol

  16. Scenario: Bid Server joins the cluster

  17. Scenario: Bid Client Retrieves Auction Info

  18. Scenario: Client Place A Valid Bid

  19. Design Considerations • Performance • Ricart & Agrawala’s mutex instead of Lamport’s to have 2(N-1) instead of 3(N-1) messages. • CS applies to each item instead of globally so that mutex conflict is low • Applies ReadOnly and ReadWrite CS on item so that multiple reads, which is the majority of the request, can happen at the same time. • Partition Item info so that some data doesn’t need to be locked even for reading. • Read static data: no synchronization • Read dynamic data: Read Only mutex • Write dynamic data: Read/Write mutex

  20. Design Considerations • Scalability • Queue grows with # of processes with pending requests on the same item instead of # of all processes. • Even though the mutex is applied on item level, # of mutex data structures only grows with the # of items the current process actively requests CS on. • Resilience (Fault tolerant) • Handles Node join and leave

  21. Conclusion • Distributed bidding system that works  • Includes Scalability, Consistency, Adequate Performance • Features have great promise • Class Project  Consumer application • No evaluations / comparison to real-world applications  • Fun project with high potential

  22. Future Work • MySql Database • Initial database, but not interfaced • Nice to have Client Features • Adding auctions • Auction categories • Real accounts • Auction alerts • Nice to have Cloud Features • Auction Server Portioning • Auto-Scaling/Load Balancing Cloud • Auto-Deployment

  23. Q & A

  24. Backup Slides EC2 management console

  25. Backup (Cont.) EC2 Running Instances

  26. Backup (Cont.) EC2 EBS Volumes

  27. Backup (Cont.) EC2 Health Services

  28. Backup (Cont.) Deployment script • Easier solution than creating own AMI

More Related