AWS AutoScalling- Tech Talks Maio 2019
•Transferir como PPTX, PDF•
1 gostou•1,245 visualizações
Slide apresentado no Tech Talks Maio 2019
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a AWS AutoScalling- Tech Talks Maio 2019
Semelhante a AWS AutoScalling- Tech Talks Maio 2019 (20)
Mais de Amazon Web Services LATAM
Mais de Amazon Web Services LATAM (20)
Último
Último (20)
AWS AutoScalling- Tech Talks Maio 2019
- 1. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Mv – Marcus Vinicius Ferreira / Claick Oliveira Solution Architect Team, Public Sector, Education Maio/2019 AWS: AutoScaling Compute, AutoScaling, DevOps
- 2. Mv – Marcus Vinicius Ferreira mvferr@amazon.com SolutionsArchitect BR, Public Sector, Education Previous: Oracle, Sun, Abril, Dinda, NubankMv
- 3. Claick Oliveira claicko@amazon.com SolutionsArchitect BR, Public Sector, Education Claick
- 4. AWS Agenda AWS é Escala AWS Compute: EC2 AWS AutoScaling AWS Automation: DevOps AWS Casos de Uso
- 5. AWS is Architected for Government Security Requirements Certifications and accreditations for workloads that matter – Compliant Solutions AWS CloudTrail and AWS Config – Call logging and configuration management for governance and compliance • Log, review, alarm on all user actions • Browse-and-query database of current and previous state of cloud resources MTCS https://aws.amazon.com/compliance/
- 6. What Is (True) Cloud Computing? The on-demand delivery of IT resources over public or private networks with zero up-front costs, no long-term contracts, and pay-as-you-go pricing 6
- 7. Service Breadth & Depth TECHNICAL & BUSINESS SUPPORT Account Management Support Professional Services Training & Certification Security & Pricing Reports Partner Ecosystem Solutions Architects ENTERPRISE APPS Virtual Desktops Sharing & Collaboration Corporate Email Backup Regions Availability Zones Points of Presence INFRASTRUCTURE Compute Storage DatabasesCDN Networking CORE SERVICES HYBRID ARCHITECTURE Data Backups Integrated App Deployments Direct Connect Identity Federation Integrated Resource Management Integrated Networking Access Control Identity Key mgmt & Storage Monitoring & Logs SECURITY & COMPLIANCE Auditing Configuration, Compliance Firewalls Assessment, reporting MARKETPLACE Business Apps Business Intelligence Databases DevOps Tools NetworkingSecurity Storage IoT Rules Engine Device Shadows Device SDKs Registry Device Gateway DEV & OPSMOBILE SERVICESAPP SERVICESANALYTICS Data Warehouse Hadoop/Spark Data Collection Machine Learning Elastic Search Queuing & Notifications Workflow Search Email Transcoding One-click Deployment Identity Sync Single Integrated Console Push Notifications DevOps Application Lifecycle Management Containers Triggers Resource Templates API Gateway Data Analysis BI Mobile Analytics
- 8. AWS é Escala
- 9. AWS Global Infrastructure 18 Regions – 54 Availability Zones – 114 Edge Locations Region & Number of Availability Zones AWS GovCloud (2) EU Ireland (3) US West Frankfurt (2) Oregon (3) London (2) Northern California (3) Asia Pacific US East Singapore (2) N. Virginia (5), Ohio (3) Sydney (2), Tokyo (3), Seoul (2), Mumbai (2) Canada Central (2) China Beijing (2) South America São Paulo (3) Announced Regions Paris, Ningxia
- 10. Region New Region Coming Soon Edge Location Region & Number of Availability Zones# The Global Infrastructure
- 11. REGION ~ 2ms latency AZa AZc AZb Redundant Tier-1 Internet & Inter-Region Connectivity TCTC DC DC DC DC DCDC DC DC DC
- 12. Availability Zone 1a Availability Zone 1b Internet 10.0.0.5 10.0.0.6 10.0.3.17 10.0.3.5 10.0.1.5 10.0.1.25 10.0.1.8 10.0.1.6 VPC Subnet VPC Subnet VPC Subnet Virtual Private Gateway Customer Gateway VPN Connection Internet Gateway Customer Data Center Virtual Private Cloud
- 13. Deploy however you like Your Datacenter Amazon Web Services Fully Featured Compute Resource & Deployment Management Common Controls for Security & Access Integrated Networking Data Integration & Life Cycle Management Flexible hybrid options Comcast’s IT strategy focuses on combining its own data centers and AWS as the cornerstone of its next-generation TV service, X1. This has allowed them to rapidly scale interactive, on-demand content to millions of viewers.
- 14. AWS Compute: EC2
- 15. G2 GPU enabled M5 General purpose Memory optimized R4 Dense-storage & High-I/O optimized C5 Compute optimized C4M4 D2 I2 Compute: EC2 Instance Families T3 Burstable performance X1P3 T2
- 16. Instance generation c5.xlarge Instance family Instance size
- 17. Amazon EC2 Instances 256 128 64 32 16 8 4 2 1 1 2 4 8 16 32 64 128 Amazon EC2 Compute Units Memory(GB)
- 18. Instance sizing c5.18xlarge 2 x c5.9xlarge ≈ 4 x c5.4xlarge ≈ 8 x c5.2xlarge ≈
- 19. Machine Power Cluster compute instances Implement HVM process execution Intel® Xeon® processors 10 Gigabit Ethernet –c3 has Enhanced networking, SR-IOV cc2.8xlarge 32 vCPUs 2.6 GHz Intel Xeon E5-2670 Sandy Bridge 60.5 GB RAM 2 x 320 GB Local SSD c3.8xlarge 32 vCPUs 2.8 GHz Intel Xeon E5-2680v2 Ivy Bridge 60GB RAM 2 x 320 GB Local SSD
- 20. AWS Auto Scaling
- 21. Typical Weekly Traffic at Amazon.com Sunday Monday Tuesday Wednesday Thursday Friday Saturday Provisioned capacity
- 22. November Traffic to Amazon.com Provisioned capacity November 76% 24% Challenge is to efficiently ‘guess’ the unknown quantity of how much compute capacity you need
- 23. The Economics of the Cloud are Compelling Infrastructure cost $ Time
- 24. The Economics of the Cloud are Compelling Infrastructure cost $ Time Predicted demand Key:
- 25. The Economics of the Cloud are Compelling Infrastructure cost $ Time Large capital expenditure Predicted demand Traditional hardware Key:
- 26. The Economics of the Cloud are Compelling Infrastructure cost $ Time Large capital expenditure Predicted demand Traditional hardware Actual demand Key:
- 27. The Economics of the Cloud are Compelling Infrastructure cost $ Time Large capital expenditure Opportunity cost Predicted demand Traditional hardware Actual demand Key:
- 28. The Economics of the Cloud are Compelling Lost opportunity Infrastructure cost $ Time Large capital expenditure Opportunity cost Predicted demand Traditional hardware Actual demand Key:
- 29. The Economics of the Cloud are Compelling Lost opportunity Infrastructure cost $ Time Large capital expenditure Opportunity cost Predicted demand Traditional hardware Actual demand Automated virtualization Key:
- 30. instance instanceinstance instance Auto Scaling group Minimum = 2 Maximum = 10 Desired # of instances = 4 Availability Zone bAvailability Zone a Elastic Load Balancing Elastic Load Balancing, CloudWatch, and Auto Scaling CloudWatch
- 31. instance instanceinstance instance Auto Scaling group Minimum = 2 Maximum = 10 Desired # of instances = 4 Availability Zone bAvailability Zone a Elastic Load Balancing Elastic Load Balancing, CloudWatch, and Auto Scaling CloudWatch
- 32. instance instanceinstance instance Auto Scaling group Minimum = 2 Maximum = 10 Desired # of instances = 4 Availability Zone bAvailability Zone a Elastic Load Balancing Elastic Load Balancing, CloudWatch, and Auto Scaling CloudWatch
- 33. instance instanceinstance instance Auto Scaling group Minimum = 2 Maximum = 10 Desired # of instances = 6 instanceinstance Availability Zone bAvailability Zone a Elastic Load Balancing CloudWatch Elastic Load Balancing, CloudWatch, and Auto Scaling
- 34. instance instanceinstance instance Auto Scaling group Minimum = 2 Maximum = 10 Desired # of instances = 6 instanceinstance Availability Zone bAvailability Zone a Elastic Load Balancing CloudWatch Unhealthy Instances Get Replaced…
- 35. Unhealthy Instances Get Replaced… instance instanceinstance instance Auto Scaling group Minimum = 2 Maximum = 10 Desired # of instances = 6 instanceinstance Availability Zone bAvailability Zone a Elastic Load Balancing CloudWatch
- 36. …In a Different AZ if Necessary instanceinstance instanceinstance Auto Scaling group Minimum = 2 Maximum = 10 Desired # of instances = 6 instance Availability Zone bAvailability Zone a instance Elastic Load Balancing CloudWatch
- 37. Capacity matching Elastic Cloud-Based Resources Actual demand Resources scaled to demand Waste Customer Dissatisfaction Actual Demand Predicted Demand Rigid On-Premises Resources
- 38. AWS Storage: EBS e S3 172.31.0.0/16 sa-east-1a sa-east-1b sa-east-1c
- 39. Multi-AZ Architecture User Amazon Route 53 Internet Gateway Public Subnet Private Subnet Public Subnet Private Subnet Private Subnet Private Subnet Private Subnet BI / OLAP Public load balancer Private load balancer PROD / OLTP
- 41. Elastic Load Balancing, CloudWatch, and Auto Scaling Latency CPU Utilization CloudWatchAuto Scaling Elastic Load Balancing Auto Scaling group Execute Lauch Configuration
- 42. How Does Auto Scaling Work? Launch Configuration 1 Auto Scaling Group Auto Scaling Policy Scheduled Action 2 3 Launch configuration defines: • Name • AMI • Instance type • User data • Security groups • IAM role • Etc. Auto Scaling group defines: • Name • Launch configuration name • Min & Max • AZ or subnet • Load balancer • Desired capacity • Etc. Specifies when to dynamically increase or decrease Amazon EC2 instances based on CloudWatch alarms Tells Auto Scaling to perform a scaling action at a certain time in the future (minimum, maximum, and desired size for the ASG) EC2AMI Auto Scaling group Load balancer Auto Scaling group ? ? 1..N 1..20 What Where When
- 43. How Do You Decide on Minimum Capacity Size? Auto Scaling group Availability Zone 1 Availability Zone 2 Auto Scaling group defines: Desired capacity Minimum capacity Maximum capacity Do you have to specify desired capacity? What would be a good minimum capacity to set it to? What would be a good maximum capacity to set it to? ? Auto Scaling group Availability Zone 1 What about HA? Minimum = 2 instances (# of AZs) Desired capacity = 2 instances (Min.) 0 or 1?
- 44. Maximum Capacity Size and Auto Scaling Scenario: Auto Scaling Group: Minimum = 2 Maximum = 12 Auto Scaling Policy: When CPU utilization is greater than 60% Add 100% of group = double the capacity Availability Zone 2Availability Zone 1 Auto Scaling group CPU utilization triggers the alarm: capacity is doubled until CPU utilization drops below 60% or max capacity is reached.
- 46. AMIs and Boot Times Remember the AMI balancing act! Test various configurations to find what best meets your baseline performance. OS-Only AMI • More dynamic • Slower boots Full AMI Partially Configured AMIs • Less dynamic • Faster boots Balance between ease of new deployments and boot load times
- 47. AMI Creation Models Inventory of AMIs Golden AMI – Fetch Binaries on Boot JeOS AMI and Library of Recipes (Install Scripts) Linux JEE Your Code Log4J Spring Hibernate Struts Tomcat Apache Linux JEE Your Code Log4J Spring Hibernate Struts Tomcat Apache Amazon EC2 L i n u x J E E Y o u r C o d e L o g 4 JS p r i n g H i b e r n a t e S t r u t s T o m c a t A p a c h e L i n u x J E E Y o u r C o d e L o g 4 JS p r i n g H i b e r n a t e S t r u t s T o m c a t A p a c h e L i n u x J E E Y o u r C o d e L o g 4 JS p r i n g H i b e r n a t e S t r u t s T o m c a t A p a c h e L i n u x J E E Y o u r C o d e L o g 4 JS p r i n g H i b e r n a t e S t r u t s T o m c a t A p a c h e Amazon EC2 Amazon EC2 Your Code Amazon S3 Log4J Spring Struts Linux JEE Hibernate Tomcat Apache Linux JEE Your Code Amazon S3 Hibernate Tomcat Log4J Spring Struts Apache L i n u x J E E H i b e r n a t e T o m c a t A p a c h e L i n u x J E E H i b e r n a t e T o m c a t A p a c h e L i n u x J E E H i b e r n a t e T o m c a t A p a c h e Linux JEE Linux JEE Chef/Puppet Chef/Puppet Scripts Java AMI Java App Stack Java AMI JeOS AMI Fetch on boot Fetch on boot Fetch on boot Minimal provisioning Partial provisioning on boot Full provisioning on boot
- 49. Ready. AMI. Fire! Linux AMI EC2: build machine. • Size: Medium • Run: repo update -y • Add: pkg: apache • Add: pkg: php • Add: pkg: mod_php • Add: pkg: memcache-client • Add: git checkout: my-app-release-1.2 • Add: wget: app/config.php • Add: wget: conf.d/my-app.conf Customer AMI • Name: my-app-1.2 Your LAN Segments Dev QA Prod Packer and command-line tools.
- 50. AMI Approach Use Case: Netflix Uses a "tiered AMI" system with layered prerequisites. Foundation AMI (monitor agent, etc) Base AMI (Java) Application AMI (release 1.1) AMI provided by AWS Basic tools and system updates Core software and performance optimizations App-specific AMI generated by Jenkins CI platform AWS Linux AMI (Public AMI) Base AMI (Ruby Base AMI (Python) Application AMI (release 1.2) Application AMI (release x.x) Application AMI (release y.y)
- 51. Packaging/baking AMIs #1 reason to bake is to decrease your boot time Software packages that require painful/long setup Standard software that must be there at startup Any configuration items that cannot be remotely sourced or automated Strike a balance between those things that change often and those that don’t AWS provides easy interfaces to create the AMI or import the AMI Third-party tooling can be helpful • Packer (includes Linux and Windows) https://packer.io/ AMI Instances Tip: Starting from an existing Amazon-provided image is recommended. Once done customizing, you should stop the instance and capture the AMI.
- 54. Cloudformation
- 55. DevOps: What is AWS CloudFormation? Declarative programming language for deploying AWS resources. Uses templates and stacks to provision resources. Create, update, and delete a set of resources as a single unit (stack). Create/delete AWS CloudFormation Create/delete AWS resources Template Stack - Basic definition of resources to create - JSON text file - Collection of AWS resources
- 56. Example Environment Templates Dev Apps Stack Dev Base Stack Test Apps Stack Test Base Stack Private Subnet App tier Private Subnet DB tier Master Public Subnet Private Subnet Web tier Private Subnet App tier Private Subnet DB tier NAT Master AMIs Amazon EBS snapshots Internet Gateway Internet Gateway Development Account Production Account Private Subnet Web tier NAT Public Subnet
- 57. Cloudformation to the RESCUE! AWS VPC Your LAN Segments AMI for Python AMI for Perl AMI for Java Remember: DO NOT share your machines!
- 58. Integration with the cloud Your Data Center Project A Dev
- 59. Dedicated Infrastructures Your Data Center AWS VPC Physical Cluster C++/Fortran Bio Informatics Perl Engineer Python Physics Java … and use dedicated clusters for specific software solutions
- 61. Red-Black Deployment: Instant Cutover Web Server Fleet (Amazon EC2) ….. Load Balancing (Elastic Load Balancing) v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 Persistent Layer (Databases and S3)
- 62. Red-Black Deployment: Pre-Cutover Web Server Fleet (Amazon EC2) ….. Persistent Layer (Databases and S3) Load Balancing (Elastic Load Balancing) v1.2 v1.2 v1.2 v1.2 v1.2 v1.2 v1.1 v1.1 v1.1 v1.1 v1.1 v1.1
- 63. Red-Black Deployment: Cutover to New System Web Server Fleet (Amazon EC2) ….. Load Balancing (Elastic Load Balancing) v1.2 v1.2 v1.2 v1.2 v1.2 v1.2 v1.1 v1.1 v1.1 v1.1 v1.1 v1.1 Persistent Layer (Databases and S3)
- 64. Red-Black Deployment: Cutover to New System Web Server Fleet (Amazon EC2) Load Balancing (Elastic Load Balancing) v1.2 v1.2 v1.2 v1.2 v1.2 v1.2 Persistent Layer (Databases and S3)
- 65. Embracing Failure: Fault Injection Build a strong test harness to force out-of-spec failures to surface. • Refuses all connections. • Reads requests at 1 byte/second. • Accepts request, and sends responses at 1 byte/second rate. • …etc. Inject failures regularly into your systems under controlled circumstances, using third-party tools such as Netflix Simian Army which includes Chaos Monkey, Chaos Gorilla, etc.
- 66. Components: • EC2 Linux Auto-Scaling • RDS MySQL Multi-AZ • Elastic Load Balancer • S3 Bucket AWS: WordPress Reference Architecture
- 67. AWS Elastic Beanstalk é a ferramenta orquestrador que executa um deploy a partir do Git, numa infra-estrutura em Auto-Scaling. AWS: Git, Elastic Beanstalk, Architecture
- 68. Diferentes Sites terão: • Um repositório Git específico • Uma infra-estrutura Auto-Scaling dedicada • Uma rotina de deploy independente Múltiplos Sites: Git, Elastic Beanstalk, Deploy WebSite 1 WebSite 2 WebSite 3 WebSite 1 WebSite 2 WebSite 3
- 69. AWS Beanstalk and Wordpress https://aws.amazon.com/getting-started/projects/build-wordpress-website/
- 71. Website!
Notas do Editor
- All the details on AWS compliance levels can be found on https://aws.amazon.com/compliance/
- More than 90 services.
- AWS serves hundreds of thousands of customers in more than 190 countries. Amazon CloudFront and Amazon Route 53 services are offered at AWS Edge Locations
- Each AZ is placed in a way to ensure that latency is as low as 2 ms 99% of the time.
- As the saying goes, a picture is worth a thousand words. Take the opportunity to visually describe what a cloud based architecture would look like for their solution.
- We also provide options in how you deploy. AWS has supported hybrid cloud deployments from our inception. With legacy systems, there’s going to be a period where you’re in both environments, and we put a lot of time into making sure that your on-prem resources can operate seamlessly with the cloud. ----- COMCAST: By leveraging AWS, Comcast is able to quickly add capacity with Amazon VPC and Direct Connect, expanding their data centers as they scale to provide interactive entertainment on demand. Comcast is a global media and technology company committed to bringing the best in media and technology to its customers. Comcast’s IT strategy focuses on a hybrid architecture combining its own data centers and AWS, with AWS serving as the cornerstone of the hybrid cloud architecture for its next-generation TV service, X1. Demand for Comcast’s X1 delivery platform exceeded the capacity of its on-premises data centers, so the company turned to the cloud for the elasticity and flexibility it provides. [http://aws.amazon.com/solutions/case-studies/comcast/]
- Reference on the various AWS instance types. http://aws.amazon.com/ec2/instance-types/ http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html
- So before we start diving into the instances, I wanted to quickly go over how we name them so that we’re all speaking the same language. What you see here, is the c4 large instance. And the first letter you see is the instance family, this usually stands for what it’s best suited for or what sort of resources it has “c for compute” “r for ram”, “I for iops”, etc. The next number you see is the generation. And you can kinda think of this like a version number. So a c4 is a newer instance generation than the c3 instance. And lastly you have the different sizes of the instance. I heard them called T-Shirt sizes, so you have small, medium, large, and extra large and that’s actually a good way to think about them.
- Amazon EC2 lets you choose from a number of different instance types to meet your computing needs. Each instance provides a predictable amount of dedicated compute capacity and is charged per instance-hour consumed. First-generation (M1) general purpose instances provide a balanced set of resources and a low-cost platform that is well suited for a wide variety of applications. Second-generation (M3) general purpose instances provide a balanced set of resources and a higher level of processing performance compared to First-generation general purpose instances. Instances in this family are ideal for applications that require higher absolute CPU and memory performance. Applications that can benefit from the performance of second-generation general purpose instances include encoding applications, high traffic content management systems, and Memcached applications. High-memory instances offer large memory sizes for high throughput applications, including database and memory caching applications. High-CPU Instances have proportionally more CPU resources than memory (RAM) and are well suited for compute-intensive applications. There are also various high-storage and cluster-computer instance types available.
- Next let’s dive into instance sizing. We build our instances in such a way that allow you to scale both vertically and horizontally. Let’s look at the c4 family as an example. A c4.8xlarge is the largest c4 instance available and is generally suited for workloads that require a large number of resources like memory all on a single machine. Now that c4.8xlarge instance has roughly double the amount of resources as two c4.4xlarge’s. These are things like CPU, memory, and network. and those 4xlarges are roughly equal to four 2xlarges and so on and so forth.
- This family includes the C1, CC2, and C3 instance types, and is optimized for applications that benefit from high compute power. Compute-optimized instances have a higher ratio of vCPUs to memory than other families, and the lowest cost per vCPU among all Amazon EC2 instance types. We recommend compute-optimized instances for running compute-bound scale out applications. Examples of such applications include high performance front-end fleets and web-servers, on-demand batch processing, distributed analytics, and high performance science and engineering applications. C3 instances are the latest generation of compute-optimized instances, providing customers with the highest performing processors and the lowest price/compute performance available in EC2 currently. Each virtual CPU (vCPU) on C3 instances is a hardware hyper-thread from a 2.8 GHz Intel Xeon E5-2680v2 (Ivy Bridge) processor allowing you to benefit from the latest generation of Intel processors. C3 instances support Enhanced Networking that delivers improved inter-instance latencies, lower network jitter and significantly higher packet per second (PPS) performance. This feature provides hundreds of teraflops of floating point performance by creating high performance clusters of C3 instances. Compared to C1 instances, C3 instances provide faster processors, approximately double the memory per vCPU, support for clustering and SSD-based instance storage. CC2 instances feature 2.6GHz Intel Xeon E5-2670 processors, high core count (32 vCPUs) and support for cluster networking. CC2 instances are optimized specifically for HPC applications that benefit from high bandwidth, low latency networking and high compute capacity. Popular use cases: High-traffic web applications, ad serving, batch processing, video encoding, distributed analytics, high-energy physics, genome analysis, and computational fluid dynamics.
- Needless to say, the retail company Amazon.com is one of the largest AWS customers. Typically, the incoming traffic is very predictable. Before Amazon.com moved their infrastructure onto AWS, they had a traditional data center, as many companies had. In order to support the peak load, your data center must provide enough hardware and software to support the capacity.
- Amazon.com experiences a seasonal peak in November (Black Friday). Because of this peak in late November, they had to invest in enough resources to support this seasonal peak, knowing that this only occurs a certain time of the year. As the business grew, Amazon.com had to keep investing in additional hardware and software. At some point, they ran out of space so they had to add a new data center. The problem is that about 76% of the resources are idle for most of the year. But if you don’t have enough compute capability to support the seasonal peak, the server can crash and your business can lose customer confidence.
- So what is the underlying value proposition from an economics point of view? Let’s quickly walk through the typical way that the public cloud provides value to customers
- [click] First, let’s assume you have a good view of your predicted demand of IT infrastructure requirements, represented by this gray dotted line
- [click] In a typical on-premises environment, you would plan for and meet this demand with periodic purchases of hardware and services ahead of when you actually need it with large capital purchases; often having to go through lengthy prioritization, budgeting and procurement approval cycles to do this; and you hope that you’ve forecasted demand correctly
- What happens if you didn’t forecast demand correctly? The variability in potential demand is shown here in red
- So the impact of this is that you either overprovisioned and wasted precious resources [click] (shown here in green as an opportunity cost
- or worse, you’ve under-provisioned and missed out on opportunities [click] (shown here in the red-shaded box as lost opportunities)
- One of the ways moving workloads to the public cloud helps you avoid these pitfalls is giving the ability to flexibility to buy only what you need, and to scale it only when you need it – [click] essentially matching supply with demand…and saving money by doing this
- In this reference diagram note that you can have many S3 buckets: 1. Public S3 buckets, that will store static files to be cached by Cloudfront and 2. Private S3 buckets that can store logs, backups, config files that can be read by any server in any AZ.
- Notes: All of these services work well individually, but together they become more powerful and increase the control and flexibility our customers demand.
- Notes: Auto Scaling components Launch configuration Group Scaling policy (optional) Scheduled action (optional) Launch configuration Launch configuration defines how Auto Scaling should launch your Amazon EC2 instances (similar to ec2-run-instances API). Auto Scaling provides you with an option to create a new launch configuration using the attributes from an existing Amazon EC2 instance. When you use this option, Auto scaling copies the attributes from the specified instance into a template from which you can launch one or more Auto Scaling groups. Auto Scaling group Your Auto Scaling group uses a launch configuration to launch Amazon EC2 instances. You create the launch configuration by providing information about the image you want Auto Scaling to use to launch Amazon EC2 instances. The information can be the image ID, instance type, key pairs, security groups, and block device mapping. Auto Scaling policy An Auto Scaling group uses a combination of policies and alarms to determine when the specified conditions for launching and terminating instances are met. An alarm is an object that watches over a single metric (for example, the average CPU utilization of your Amazon EC2 instances in an Auto Scaling group) over a time period that you specify. When the value of the metric breaches the thresholds that you define, over a number of time periods that you specify, the alarm performs one or more actions. An action can be sending messages to Auto Scaling. A policy is a set of instructions for Auto Scaling that tells the service how to respond to alarm messages. Scheduled action Scaling based on a schedule allows you to scale your application in response to predictable load changes. To configure your Auto Scaling group to scale based on a schedule, you need to create scheduled actions. A scheduled action tells Auto Scaling to perform a scaling action at a certain time in the future. To create a scheduled scaling action, you specify the start time at which you want the scaling action to take effect, and you specify the new minimum, maximum, and desired size you want for that group at that time. At the specified time, Auto Scaling updates the group to set the new values for minimum, maximum, and desired sizes, as specified by your scaling action.
- Notes: You don’t have to specify the desired capacity because minimum capacity is the initial desired capacity. You pay for what you use; therefore, you don’t need to launch more instances than you need and auto scale based on demand. Deciding on the minimum capacity size depends on the type of applications that you are running. Here are some things to consider: If you are processing batches that run once a week, you might want to set the minimum to zero. Remember that it takes minutes to launch a new instance (depending on the complexity of your launch configuration). You may not be able to afford zero minimum capacity to start with. At least one instance running? What about HA? Does your environment require HA? If you require at least one instance per AZ to start with, the minimum capacity size should be set to the number of AZs.
- Notes: This scenario demonstrates how maximum capacity size plays a role in the way Auto Scaling works. As a discussion, you set the Auto Scaling policy to double the current group capacity when the CPU utilization becomes greater than 60%. You start with a minimum of two instances. The first time the alarm triggers the Auto Scaling policy to take effect, the desired capacity becomes four (2x2). Load keeps increasing and when CPU utilization reaches greater than 60%, the desired capacity becomes eight (2x4). The next time the alarm gets triggered, you can no longer double the current group capacity because the maximum capacity is set to 12. Auto Scaling adds four more instances equally balanced across the two AZs. Selecting a reasonable maximum capacity size depends on your application and possibly a budget. You pay for what you use; therefore, your organization may limit you from running more than a certain number of instances. Even if you don’t have a budget restriction, there is no single answer.
- Remember one of the most important factors in Amazon EC2 instance boot times discussed in an earlier slide deck: Striking a balance with your AMI management. A fully dynamic, boot-configured AMI will give you the most flexibility but will also give you the worst load times when a new instance is booted up in an Auto Scaling group. At the other end of the spectrum, fully "baking" your application into the AMI gives you great boot times but it slows down your rapid deployment process. (Every time your application changes, you need to create a new AMI.) Testing various configurations of a partially configured AMI will allow you to decide where the proper balance lies for your application.
- The first step is to create bootstrapped instances so that when they come up they automatically install all of the dependencies they require. There are several methods that you can use to customize an instance. In this slide, the numbers represent the following: Section 1: Create a custom AMI where you pre-install specific packages instead of installing them after the instance boots. Section 2: Launch a custom master AMI that includes the base applications (Gold image). The remaining apps can be fetched (pushed) and installed during first boot. Section 3: Create a custom AMI that includes the Chef or Puppet client that connects to a Chef or Puppet server and pulls configuration information to the AMI on first boot.
- A combination of Cloudformation and you own AMIs will make any infrastructure easily manageable.
- At the 2013 AWS re:Invent conference, Netflix explained how it is currently using a four-step pipeline process to create AMIs. Using a standard Linux AMI provided by AWS, Netflix creates a "foundation AMI" that contains all of the basic tools and certain customizations required by all Netflix AMIs. The next step is to create the "base AMI," which is loaded with software used by Netflix applications (Apache, Tomcat, Java, system monitoring utilities, etc.) and core performance optimizations that the company wants to propagate as best practices. The base AMI is relatively stable. Engineers at the company can use the latest stable base AMI or pilot more recent base AMIs that may contain performance tunings or other features required by their apps. Finally, Netflix software engineers publish their applications through Jenkins, a continuous integration service; the Netflix implementation of Jenkins uses the base AMI to create an "application AMI" specific to that team's application. This pipeline capability is supported by Netflix's own tool, Aminator (https://github.com/Netflix/aminator), which the company makes available to the public under open-source licensing. Sources: Your Linux AMI: Optimization and Performance at https://www.youtube.com/watch?v=-hwITRP4Pqk (Netflix presentation begins around the 7:50 mark) The Netflix Blog: AMI Creation with Aminator at http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html
- Taking Points Mention that one technique to avoid central domain permissions and group policy is to bake a user with limited permissions for remote access. Avoid sharing the local admin account always. Talk about how Windows is often weighed down by heavy install packages so baking AMIs is important
- AWS CloudFormation enables you to create and provision AWS infrastructure deployments in a predictable, repeatable, and automated fashion. You can create templates for the service or application architectures you want and then have AWS CloudFormation use those templates for quick and reliable provisioning of the services or applications (called “stacks”). When you use AWS CloudFormation, you work with templates and stacks. An AWS CloudFormation template is a JSON text file used to describe the AWS resources and their properties in your infrastructure. For example, in a template, you can describe an Amazon EC2 instance, such as the instance type, the AMI ID, block device mappings, and its Amazon EC2 key pair name. You use these templates to create a stack. A stack is a collection of AWS resources that has been created from a template. You may provision (create) a stack numerous times. When a stack is provisioned, the AWS resources specified by its template are created. Any AWS usage changes incurred from using these services will start accruing as they are created as part of the AWS CloudFormation stack. When a stack is deleted, the resources associated with the stack are deleted. The order of deletion is determined by AWS CloudFormation; you do not have direct control over what gets deleted when.
- AWS CloudFormation enables you to create and provision AWS infrastructure deployments in a predictable, repeatable, and automated fashion. You can create templates for the service or application architectures you want and then have AWS CloudFormation use those templates for quick and reliable provisioning of the services or applications (called “stacks”). When you use AWS CloudFormation, you work with templates and stacks. An AWS CloudFormation template is a JSON text file used to describe the AWS resources and their properties in your infrastructure. For example, in a template, you can describe an Amazon EC2 instance, such as the instance type, the AMI ID, block device mappings, and its Amazon EC2 key pair name. You use these templates to create a stack. A stack is a collection of AWS resources that has been created from a template. You may provision (create) a stack numerous times. When a stack is provisioned, the AWS resources specified by its template are created. Any AWS usage changes incurred from using these services will start accruing as they are created as part of the AWS CloudFormation stack. When a stack is deleted, the resources associated with the stack are deleted. The order of deletion is determined by AWS CloudFormation; you do not have direct control over what gets deleted when.
- With Infrastructure as Code, you can automate your entire dev, test, or production environment to be deployed, configured, and ready to use within minutes. For example, the entire setup on this slide can be deployed using AWS CloudFormation templates. You can create baseline templates for your Dev and Test environments, and then create stacks as needed from those templates. You can easily create production-like setups to perform your development and testing as part of your software development lifecycle. All the templates can be stored in a version control system like Git or AWS CodeCommit.
- A combination of Cloudformation and you own AMIs will make any infrastructure easily manageable.
- AWS can be used as the test environment for any project of you company.
- Or you can use AWS to run any workload that complements your current infrastructure.
- In this reference diagram note that you can have many S3 buckets: 1. Public S3 buckets, that will store static files to be cached by Cloudfront and 2. Private S3 buckets that can store logs, backups, config files that can be read by any server in any AZ.
- The idea of a red-black deployment was popularized by Netflix (http://techblog.netflix.com/2013/08/deploying-netflix-api.html), which uses it as the deployment strategy in its production systems. Before standing up a new version of a system, Netflix first uses what it calls a "canary". It replaces around 1% of its existing production system with the new version of the application, and monitors the new version for errors. If the canary clears this initial test, the system is deemed ready for deployment.
- In preparation for the switchover, a new version of the system is stood up side by side with the old version of the system. The initial capacity of the new system is set manually by examining how many instances are currently running in production, and setting this number as the desired capacity for the new Auto Scaling group. Once the new system is up and running, both systems are "red". The current version is the only version accepting traffic.
- Using Amazon Route53 or a similar DNS service, the system is then cut over from the existing version to the new version. At this point, the old version is considered "black"; it is still running, but is not receiving any traffic. If any issues are detected with the new version, reverting is as simple as pointing the DNS server back to the load balancer hosting the old version.
- Using Amazon Route53 or a similar DNS service, the system is then cut over from the existing version to the new version. At this point, the old version is considered "black"; it is still running, but is not receiving any traffic. If any issues are detected with the new version, reverting is as simple as pointing the DNS server back to the load balancer hosting the old version.
- There is no substitute for thorough testing. You can build your own test harness to intentionally trigger out-of-spec failures and see how your application behaves. Your applications may not be as fault-tolerant as you thought they were. Alternatively, you can use third-party tools such as Netflix’s Simian Army to inject failures in a controlled environment, and see how your application recovers. Chaos Monkey, Chaos Gorilla, and Latency Monkey are all a part of Simian Army. Read the blog to learn more about Netflix Simian Army at: http://techblog.netflix.com/2011/07/netflix-simian-army.html