從劍宗到氣宗 － 談AWS ECS與Serverless最佳實踐
Download as PPTX, PDF19 likes1,638 views
This document summarizes a presentation about best practices for AWS ECS and serverless architectures. It discusses the challenges of traditional infrastructures and benefits of containerization. It provides an overview of AWS ECS for container management and auto-scaling capabilities. It also introduces AWS Lambda and API Gateway for building serverless applications, including their advantages of being cloud-native and cost-effective with minimal infrastructure to manage. Some limitations of serverless architectures are also outlined. The conclusion encourages embracing immutable infrastructure, event-driven computing, and focusing on business logic over infrastructure when possible.
Ad
More Related Content
What's hot (15)
Similar to 從劍宗到氣宗 － 談AWS ECS與Serverless最佳實踐 (17)
Ad
Recently uploaded (19)
Ad
從劍宗到氣宗 － 談AWS ECS與Serverless最佳實踐
- 1. 從劍宗到氣宗 談AWS ECS與Serverless最佳實踐 Pahud Hsieh April19 2016, Taipei
- 2. Best Practice in AWS ECS and Serverless • Last Updated: April/19 2016 • Scheduled for 45 minutes - The Challenges - Foundational Concepts of ECS and Serverless - New Challenges - The Future • Q & A
- 3. A Bit About Me • Both an IT Pro and developer for the past 15 years • Chief Architect of Astra Cloud(miiicasa.com) from Taiwan • Experienced in IoT cloud platform across multiple AWS regions globally • AWS All-5 Certificates holder - AWS Certified Solution Architect - Associate - AWS Certified SysOps - Associate - AWS Certified Developer - Associate - AWS Certified Solution Architect - Professional - AWS Certified DevOps Engineer - Professional
- 6. Challenges • You pay too much for EC2 instances • pay even much for micro services • Complexity in Infrastructure • VPC, subnet, routing-table, NAT, NACL, security groups, ELB, ASG • Complexity in A/B testing and B/G deployment • CFN re-deploy, EB env swap, CodePipeline/CodeDeploy, OpsWorks, etc. • complexity means error-proneness
- 7. More Challenges • dev/testing/QA/staging/prod consistency • CI & CD challenges • even worse to manage multiple AWS regions • service decoupling means nightmares
- 8. Questions • Can I just focus on my service stack unit, instead of computing unit(EC2) ? • Self-Healing, Auto-Scaling, AZ-balancing ? • Log Consolidation ? • Immutable and Stateless Architecture ? • Cost Optimization and Resource Optimization ? • still having full control on my tech stack (frameworks and languages) • simple deployment, A/B and B/G ?
- 9. a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster of Amazon EC2 instances. AWS EC2 Container Service
- 10. ECS Cluster ASG on demand ASG spot instance CloudWatch
- 11. Auto Scaling Policy Design • scale out spot on 30%-60% • scale out on-demand when >= 60% • scale in on-demand when <60% • scale in spot when <=30% • with minimal 1 on-demand or RI
- 12. Simply Put • on-demand/RI 打底 spot伸縮 • on-demand scale out last, scale in first • try spot fleet if you need couples of instances( lets talk about it next time )
- 13. external ELB internal ELB instance * 2 web * 2 app * 2 worker* 2 instance * 4 SQS CloudWatch web * 4
- 14. Benefits and Tips • Leverage ELB to build micro-services • Monitor service loading by CloudWatch and adjust spot fleet to scale out/in services/tasks dynamically • Self-healing in container level • Fully-managed deployment and rolling update with revisions • Better resource utilization • Consolidate application logs to CloudWatch Logs • Create filter, metrics and build alarms from CloudWatch Logs • Push your docker images to ECR and deploy across regions with exactly the same image
- 15. What if 20-30 micro services?
- 16. ECS Service Load Balancing docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balanc
- 17. Random ports LB and Service Discovery?
- 18. Load Balancing on Random Ports http://www.slideshare.net/JulienSIMON5/amazon-ecs-january-2016/12
- 19. Meteor Galaxy session-aware with random ports share.net/AmazonWebServices/dvo313-building-nextgeneration-applications-w
- 20. Is there a way to move the code in a cloud native way?
- 21. “No server is easier to manage than no server” - Werner Vogels, Amazon CTO AWS re:Invent 2015
- 22. AWS Lambda AWS API Gateway “a compute service where you can upload your code to AWS Lambda and the service can run the code on your behalf using AWS infrastructure” “a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale”
- 27. Mobile Integration AWS Lambda RequestResponse(Sync) Event(Asyc) {“foo”:”bar”} event.context={“ foo”:”bar”} SDK
- 28. API Gateway Lambda function Integration RESTful API HTTP PUT /items/123 {“foo”:”bar”} event.param_id=123 event.http_body={“foo”:”bar”}
- 29. API Gateway Service Proxy Integration RESTful API IAM assume role execution
- 30. API Gateway Call Flow
- 31. Pros • cloud native with your business code in Lambda • no infrastructure to manage • leverage AWS PaaS infrastructure at scale • custom or federated authorization • very minimal cost for small-medium teams - 30m requests = $11.63 per month (Lambda) - $4.25 per million requests(API Gateway)
- 33. Cons - Lambda Limit • Lambda soft limit concurrency is 100 • 300 seconds max duration per invocation • Lambda in VPC restriction - private IP addresses - ENIC limit(default 20*5=100)
- 34. Cons - API Gateway • 500-1000 QPS per AWS Account • 5M requests / month = $18.79 • 100 QPS = $974.07 / month = 31,350NTD • No async or parallel invocation with Lambda
- 35. Cons - Performance • push and pull invocation model of Lambda • -> delegation with higher memory • no connection pooling • -> always open/close conn in handler scope
- 36. Cons - Development • CloudWatch debugging • immature CI/CD toolchains • lack of PHP, Ruby and Golang • re-deploy the whole bundle could be a pain
- 37. When should I use ECS, instead of serverless?
- 38. Use ECS • financial concern - When you have traffic more than 100QPS＋ • operation concern - Long running process or API service • language concern - Golang, PHP, Ruby, etc. • performance concern - need really big memory or CPU- optimized • protocol concern - websockets, MQTT, other TCP protocols
- 39. Use Serverless • small project, simple business logic • focus on the code only • no infrastructure management • stateless • quick micro services implementation • simply integrated with other AWS services - i.e. API Gateway update DynamoDB, Kinesis, SQS as service proxy.
- 40. Conclusions • containerize your stack, and try serverless as much as you can • build stateless application • immutable architecture - every computing component can be replaced and scaled with no impact • focus on your business logic, instead of the infrastructure, forget your infrastructure • try not use any EC2, if necessary, avoid SSH into EC2 for manual operation • fully-managed and fully-automation is the way to go • embrace event-driven cloud computing
- 41. See You Next Time
- 42. Your Success Is Our Success