Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

How to Host and Manage Enterprise Customers on AWS (ARC213) | AWS re:Invent 2013

2.070 visualizaciones

Publicado el

(Presented by cloudpack)
cloudpack is a premium consulting partner of AWS in Japan, and since 2010 has been helping customers architect their workloads for scalability, availability and disaster recovery. In this session, cloudpack explains how they are solving customer pain points with AWS architecture best practices. Specifically, they will discuss a multi-region Disaster Recovery system designed for Toyota and a highly available and scalable second screen system for Nippon Television (JoinTV).

Publicado en: Tecnología
  • Sé el primero en comentar

How to Host and Manage Enterprise Customers on AWS (ARC213) | AWS re:Invent 2013

  1. 1. How to host and manage enterprise customers on AWS: TOYOTA, Nippon Television, UNIQLO use cases Kazutaka Goto - Evangelist, cloudpack Ken Tamagawa - Sr. Manager, Solutions Architecture, Amazon Web Services November 15, 2013
  2. 2. Japan Market • Tokyo region opened in March 2011 • Tokyo region was the fastest growing AWS region in its first year • There are more than 20,000 AWS accounts in Japan
  3. 3. • Launched in 2010 as a managed hosting service provider • Systems integrator for enterprise companies • Premier Consulting Partner for 2013 & 2014
  4. 4. cloudpack Manages AWS Accounts for 300+ Clients
  5. 5. Focus of Today’s Session: Real world use cases in Japan Second Screen Disaster Recovery
  6. 6. What is Second Screen? Second Screen First Screen Shazam provided “2012 Super Bowl advertising platform” on AWS, handled 500,000 requests per second
  7. 7. • Interactive communication service by Nippon Television Network, one of Japan’s largest broadcasting companies • Combines TV and Internet into a unified experience
  8. 8. 143,199 Tweets Per Second
  9. 9. Share Digital Contents Analog Broadcast API Apps Request Contents Comment Mobile App Source: Evangelion New Theatrical Edition Q Official Site
  10. 10. Requirements from JoinTV • Handle sudden access surges • Share across social networks with little delay • Build a scalable system for the above requirements
  11. 11. Our Approach • Determine minimum resources to handle traffic surges with on-demand load testing service “neuster” – Configure load testing setting – Set up the console and run load testing repeatedly – Optimize application and identify minimum resources • Minimize delay by desynchronizing feed requests to social networks
  12. 12. Basic System Design Batch Batch Auto Scaling Web and App servers in two Availability Zones with Elastic Load Balancing
  13. 13. Basic System Design Batch Auto Scaling Batch Redis cache server cluster in each AZ to store session data 1. save the data
  14. 14. Basic System Design Batch Auto Scaling Batch RDS Multi-AZ for persistent data
  15. 15. Architecture for Minimizing Delay Batch Batch Auto Scaling SQS and Batch server cluster with Auto Scaling mechanism to share message to social networks
  16. 16. Traffic War Room
  17. 17. 300 Million Taps(API Calls)
  18. 18. Architecture for Minimizing Delay Batch Batch Auto Scaling SQS and Batch server cluster with Auto Scaling mechanism to share message to social networks
  19. 19. “Job Observer” Pattern CloudWatch Web Servers Auto Scaling Put EC2 New SQS EC2 Get EC2 19 API Requests
  20. 20. AWS Cloud Design Pattern CDP
  21. 21. It might be similar to… “This allows builders to create advanced model with simple parts”
  22. 22. Example of “Cloud Design Pattern” Route 53 “Floating IP Pattern” Elastic IP EC2 EC2
  23. 23. Floating AC Adaptor
  24. 24. CDP Template • Problem • • Wanted to exchange servers with a shorter amount of down time Solution • • Using EIP to exchange an existing EC2 instance to a newly launched one Elastic IP Diagram Pros • • • Route 53 Implementation • • • Using IP address to exchange an existing server to a newly launched server Can exchange servers regardless of DNS TTL Notes Others EC2 EC2
  25. 25. CDP Categories Basic Snapshot Stamp Scale Up On-demand Disk Static Contents Web Storage Direct Hosting Private Distribution Cache Distribution Rename Distribution Availability Multi-Server Multi-Datacenter Floating IP Deep Health Check Scaling Scale Out Clone Server NFS Sharding NFS Replica State Sharing URL Rewriting Rewrite Proxy Cache Proxy Scheduled Scale Out Data Uploading Write Proxy Storage Index Direct Object Upload Relational Database DB Replication Read Replica In-memory DB Cache Sharding Write Batch Processing Queuing Chain Priority Queue Job Observer Scheduled Auto Scaling Maintenance Bootstrap Cloud DI Stack Deployment Server Swapping Monitoring Integration Web Storage Archive Networking On-demand NAT Backnet Functional Firewall Operational Firewall Multi Load Balancer WAF Proxy CloudHub
  26. 26. Cloud Design Pattern wiki 26
  27. 27. • Global auto manufacturer (US$ 221B annual rev.) • 20 websites • 100M Page Views (PVs)
  28. 28. TOYOTA Official Websites 100 million PV 4.5 billion hits / month; Access tripled at new model announcement
  29. 29. Requirements from TOYOTA • Large-scale migration into AWS for 20 websites experiencing traffic surges – Those sites need to interact with their on-premises system • A system for prompt multi-regional disaster recovery
  30. 30. Our Approach • Build an environment able to handle traffic larger than requested by TOYOTA (100-300 million PVs/month) • Design disaster recovery process across regions in short time – – – – Identify the order of processes Prepare OS images (AMIs) Write configuration for AWS CloudFormation template Import latest data from their data center
  31. 31. Overview of System Architecture • Redundant and scalable • Make an additional backup on-premise • Disaster recovery in Singapore region daily backup On-premises
  32. 32. Architecture for • Each website has 1 load balancer and at least 3 EC2 instances – for redundancy Availability Zone Availability Zone On-premise Availability Zone daily backup Availability Zone Availability Zone daily backup Availability Zone
  33. 33. Management Servers • Monitoring, CMS, gateway... • Server-to-server connection for on-premise system – via VPN – with internal load balancer for redundancy daily backup On-premise
  34. 34. Backup strategy • Make an additional backup on-premises – also have original backup in AWS daily backup daily backup On-premise
  35. 35. AWS CloudFormation for Disaster Recovery • Develop same system in Singapore on AWS CloudFormation • One-click deployment with a template Data recovery On-premises
  36. 36. Infrastructure Design and Development NAT is running on a single instance, which could fail! daily backup On-premises
  37. 37. daily backup On-premise
  38. 38. Design Pattern for Architecting High Availability NAT Bootstrap Multi-Datacenter DB Replication Stack Deployment
  39. 39. In Real World Cases... • For situations that traditional Auto Scaling can’t handle, optimize provisioning by using load testing similar to the real access environment – You can do scheduled Auto Scaling too if necessary • Multi-regional disaster recovery is now possible if necessary and can be done quickly
  40. 40. Questions? Booth# 215
  41. 41. Please give us your feedback on this presentation ARC213 As a thank you, we will select prize winners daily for completed surveys!