從劍宗到氣宗 － 談aws ecs與serverless最佳實踐
TRANSCRIPT
從劍宗到氣宗談 AWS ECS 與 Serverless 最佳實踐
Pahud HsiehApril19 2016, Taipei
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
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
Old-Schools
Web Web
RDS RDS
ELB/ASG
Web Web
Looking Good?
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
More Challenges
• dev/testing/QA/staging/prod consistency• CI & CD challenges• even worse to manage multiple AWS
regions • service decoupling means nightmares
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 ?
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
ECS Cluster
ASGon demand
ASG spot instance
CloudWatch
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
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 )
external ELB
internal ELB
instance * 2web * 2app * 2worker* 2
instance * 4
SQS
CloudWatchweb * 4
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
What if 20-30 micro services?
ECS Service Load Balancing
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html
Random ports LB and Service Discovery?
Load Balancing on Random Ports
http://www.slideshare.net/JulienSIMON5/amazon-ecs-january-2016/12
Meteor Galaxy session-aware with random ports
http://www.slideshare.net/AmazonWebServices/dvo313-building-nextgeneration-applications-with-amazon-ecs
Is there a way to move the code in a cloud native way?
“No server is easier to manage than no server”
- Werner Vogels, Amazon CTOAWS re:Invent 2015
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”
Mobile Integration
AWS Lambda
RequestResponse(Sync)Event(Asyc)
{“foo”:”bar”} event.context={“foo”:”bar”
}SDK
API Gateway Lambda function Integration
RESTful APIHTTP PUT /items/123{“foo”:”bar”} event.param_id=123
event.http_body={“foo”:”bar”}
API Gateway Service Proxy Integration
RESTful APIIAM assume role
execution
API Gateway Call Flow
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)
http://www.slideshare.net/CaseyLee2/serverless-delivery
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)
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
Cons - Performance• push and pull invocation model of Lambda• -> delegation with higher memory• no connection pooling• -> always open/close conn in handler
scope
Cons - Development• CloudWatch debugging• immature CI/CD toolchains• lack of PHP, Ruby and Golang• re-deploy the whole bundle could be a pain
When should I use ECS, instead of serverless?
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
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.
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
See You Next Time
Your Success Is Our Success
