AWS case study: real estate portal

4,312 views

Published on

Spitogatos.gr is a leading real estate portal in Greece.

This presentation describes high level architecture and the learnings of a recent migration from dedicated servers to a more scalable solution in the cloud of Amazon.

Presentation was given at a meetup of AWS Usergroup Greece (AWSUGGR).

Published in: Technology, Design
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,312
On SlideShare
0
From Embeds
0
Number of Embeds
2,034
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

AWS case study: real estate portal

  1. 1. Spitogatos.gr & Amazon Web Services High level architecture & lessons learned AWSUG GR meetup #1 16 Feb 2012 Andreas Chatzakis co-founder / IT Director @ Spitogatos.gr
  2. 2. By David Fletcher - www.cloudtweaks.com
  3. 3. #about_us
  4. 4. Helping you find a propertyFinding a property in Greece is complex, lacks transparency.We make life easier for househunters via:  Powerful search functionality  Web & Mobile  Location & Criteria  Quality content  Listings (we love photos)  Articles  mySpitogatos  Email alerts  Save your search  Favorite listings & notes  Contact the realtors 4
  5. 5. Realtors love us too!Professionals need help in those turbulent times.We add value in multiple ways:  Cost effective promotion & high quality leads  Targeted channel (very)  Leads already filtered (we ve seen the fotos!)  Technology services for realtors  Turnkey web site solution  Listing synchronization web service  B2B via Spitogatos Network (SpiN) business network / collaboration tool for realtors  Channel for foreign buyers via the English version 5
  6. 6. Not just “αγγελίες”Our vision is to become a one-stop-shop for all things house related 6
  7. 7. #why_aws
  8. 8. The need for changeInfrastructure change dictated by our business needs  Ongoing traffic increase  A nice headache  Growing Data  S3 to the rescue  Major new functionality  Higher CPU & RAM requirements  Uneven traffic pattern  Why should I pay for this server during the night? ...and constraints Lets not spend our time managing systems:  AMIs? Yes thank you!  Zero management services like ELB? √ Like 8
  9. 9. #architecture
  10. 10. Your typical multi-tier web architectureStorage Layer 10
  11. 11. Tools of the tradeCurrently utilizing the following AWS services EC2 S3  Property photos  Thumbnails  Online backups Elastic Load Balancer (ELB) CloudWatch Route53 11
  12. 12. A bit about ScalrCloud management solution reduced project risks & ITOPS effort Server Templates Config & Bootstrap Backups Scripts DNS Autoscaling Master Slave Recover Control Convention over Configuration - out-of-the-box automation and scalability 12
  13. 13. Services under our radarWe will utilize additional AWS services whenever that helps us:  Reduce in-house ITOPS overheads  Scale capacity and performance  Enable us to bring new added value services to the market faster  Cloudfront  Milan node makes it attractive vs our current CDN solution  Simple Email Service  ElastiCache  SimpleDB / DynamoDB  Sessions, Logs, Aggregate stats, Personalization etc  EMR / HiveQL  Xeround or Amazon RDS  MySQL as a service 13
  14. 14. #learnings
  15. 15. Not a walk in the parkFrom a single server to a scalable solution Deal with sessions  Sticky sessions no good when autoscaling (scale downs)  Memcache (nodes will die, sessions will be lost)  Shared file system (maybe...) or Key-value store  Zend Server cluster User uploads  Rewrite code to utilize S3  Or just plug in a POSIX compliant NAS solution Database  Master-slave needs code changes (Replication lag)  You thought splitting SELECTs from INSERTs/UPDATEs is sufficient? Individual nodes will fail – dont take them for granted  Holy grail: share nothing architecture 15
  16. 16. Continuous improvementIt is an iterative process Incrementally add robbustness  Measure and collect data (Newrelic, MONyog, sysstat...)  Alert (Cloudwatch, monit)  Self healing (beware of false positives)  Fall gracefully (MRT vs MTBF) Optimize  Test out different EC2 Instance Types  Once sure, reserve them for significant savings  Use Cloudwatch in front of S3  Test autoscaling strategies  Scaleup fast, scaledown slow 16
  17. 17. #questions

×