AWS Cloud Kata 2014 | Jakarta - AWS Intro and Scale 2014

1. Jakarta
Intro to AWS and Getting to MVP: Launch Quickly and Scale
Chris Hampartsoumian
Technology Evangelist
@chrishampart

2. So how do we get to scale?

4. a lot of things to read

5. a lot of things to read
not where we want to start

6. Auto Scaling is a tool
and a destination. It’s
not the single thing that
fixes everything.

7. What do we need first?

8. Some basics…

9. US-WEST (Oregon)
EU-WEST (Ireland)
ASIA PAC (Tokyo)
US-WEST (N. California)
US-EAST (Virginia)
SOUTH AMERICA
(Sao Paulo)
AWS GovCloud (US)
ASIA PAC (Sydney)
ASIA PAC
(Singapore)
CHINA (Beijing)
EU-CENTRAL (Frankfurt)

10. US-WEST (Oregon)
EU-WEST (Ireland)
ASIA PAC (Tokyo)
US-WEST (N. California)
US-EAST (Virginia)
SOUTH AMERICA
(Sao Paulo)
AWS GovCloud (US)
ASIA PAC (Sydney)
ASIA PAC
(Singapore)
CHINA (Beijing)
EU-CENTRAL (Frankfurt)

12. Applica'ons
Applications Virtual Desktops Collaboration and Sharing
Platform
Services
Databases Analytics App Services Deployment & Management Mobile Services
Containers
Managed User Directories
Dev/ops Tools
Pla-orm
services
Resource Templates
Usage Tracking
Monitoring and Logs
Foundation
Services
Relational
No SQL
Caching
Hadoop
Real-time
Data
Warehouse
Data
Workflows
Founda'on
services
Global
infrastructure
Compute
(VMs, Auto-scaling and
Load Balancing)
Queuing
Orchestration
App Streaming
Transcoding
Email
Search
Storage
(Object, Block
and Archive)
Identity
Sync
Mobile Analytics
Notifications
Security &
Access Control Networking
Infrastructure Regions CDN Availability Zones and Points of Presence

13. Applications Virtual Desktops Collaboration and Sharing
Platform
services
Databases Analytics App Services Deployment & Management Mobile Services
Containers
Managed User Directories
Dev/ops Tools
Resource Templates
Usage Tracking
Monitoring and Logs
Foundation
services
Relational
No SQL
Caching
Hadoop
Real-time
Data
Warehouse
Data
Workflows
Compute
(VMs, Auto-scaling and
Load Balancing)
Queuing
Orchestration
App Streaming
Transcoding
Email
Search
Storage
(Object, Block
and Archive)
Identity
Sync
Mobile Analytics
Notifications
Security &
Access Control Networking
Infrastructure Regions CDN Availability Zones and Points of Presence

14. So let’s start from day one,
user one (you)

15. Elastic IP
EC2
instance
Amazon
Route 53
User

16. c3.8xlarge
m3.2xlarge
t2.micro

17. • Will hit an endpoint eventually
c3.8xlarge
m3.2xlarge
t2.micro

18. Elastic IP
EC2
Instance
Amazon
Route 53
User

19. • No failover
• No redundancy
• Too many eggs in one
basket
Elastic IP
EC2
Instance
Amazon
Route 53
User

20. Web
Instance
Database
Instance
Elastic IP
Amazon
Route 53
User

21. Self-managed Fully managed
Database server
on Amazon EC2
Your choice of
database running on
Amazon EC2
Bring Your Own
License (BYOL)
Amazon
DynamoDB
Managed NoSQL
database service
using SSD storage
Seamless scalability
Zero administration
Amazon RDS
Aurora,
Microsoft SQL,
Oracle, MySQL or
PostgreSQL as a
managed service
BYOL or License
Included
Amazon
Redshift
Massively parallel,
petabyte-scale data
warehouse service
Fast, powerful, and
easy to scale
Database options

22. But how do I choose
what DB technology I
need? SQL? NoSQL?

24. If your usage is such that you
will be generating several TB
( >5 ) of data in the first year
OR have an incredibly data
intensive workload, then you
might need NoSQL

26. Elastic IP
Web
instance
Amazon
Route 53
RDS DB
instance
User

27. Web
Instance
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancer
Amazon
Route 53
User

28. • Create highly scalable applications
• Distribute load across EC2 instances
in multiple Availability Zones
Feature
Details
Available
Elastic Load
Balancer
Load
balances
across
instances
in
mul'ple
Availability
Zones
Health
checks
Automa'cally
checks
health
of
instances
and
takes
them
in
or
out
of
service
Session
s6ckiness
Routes
requests
to
the
same
instance
Secure
sockets
layer
Supports
SSL
offload
from
web
and
applica'on
servers
with
flexible
cipher
support
Monitoring
Publishes
metrics
to
CloudWatch
and
can
get
logs
of
requests
processed
Elastic Load Balancer

29. Scaling this horizontally and
vertically will get us pretty far
( 10s-100s of thousands )

30. User >10ks-100ks
RDS DB Instance
Active (Multi-AZ)
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancer
RDS DB Instance
Read Replica
Availability Zone Availability Zone
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User

31. This will take us pretty far, but
we care about performance
and efficiency, so let’s improve
further

32. Elastic Load
Balancer
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Amazon
Route 53
User

33. Elastic Load
Balancer
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Amazon
Cloudfront
Amazon S3
Amazon
Route 53
User
• Move static content from
the web instance to
Amazon S3 and Amazon
CloudFront

34. Amazon Simple Storage Service (S3) is
cloud storage for the Internet:
Amazon S3

35. CloudFront
Amazon CloudFront is a web service for scalable
content delivery:
• Cache static content at the edge for faster delivery
• Helps lower load on origin infrastructure
• Dynamic and static content
• Streaming video
• Zone apex support
• Custom SSL certificates
• Low TTLs (as short as 0 seconds)
• Lower costs for origin fetches (between Amazon
S3 / Amazon EC2 and CloudFront)
• Optimized to work with Amazon EC2, Amazon S3,
Elastic Load Balancing, and Amazon Route 53
Response
Time
Server
Load
Response
Time
Server
Load
Response
Time
Server
Load
No
CDN
CDN
for
Sta'c
Content
CDN
for
Sta'c
&
Dynamic
Content
80
60
40
20
0
8:00
AM
9:00
AM
10:00
AM
11:00
AM
12:00
PM
1:00
PM
2:00
PM
3:00
PM
4:00
PM
5:00
PM
6:00
PM
7:00
PM
8:00
PM
9:00
PM
Volume of Data
Delivered (Gbps)

36. Elastic Load
Balancer
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Amazon
Cloudfront
Amazon S3
Amazon
Route 53
User

37. • Move session/state and
DB caching to Amazon
ElastiCache or Amazon
DynamoDB
Elastic Load
Balancer
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Amazon
Cloudfront
Amazon S3
Amazon
Route 53
User
ElastiCache
DynamoDB

38. • Managed, provisioned throughput
NoSQL database
• Fast, predictable performance
• Fully distributed, fault tolerant
architecture
• JSON support (NEW)
• Items up to 400 KB (NEW)
Feature
Details
Provisioned
throughput
Dial
up
or
down
provisioned
read/write
capacity
Predictable
performance
Average
single
digit
millisecond
latencies
from
SSD-­‐backed
infrastructure
Strong
consistency
Be
sure
you
are
reading
the
most
up
to
date
values
Fault
tolerant
Data
replicated
across
Availability
Zones
Monitoring
Integrated
with
Amazon
CloudWatch
Secure
Integrates
with
AWS
Iden'ty
and
Access
Management
(IAM)
Amazon
EMR
Integrates with Amazon EMR
for complex analytics on large
datasets

40. • Move dynamic content from
the ELB to Amazon
CloudFront
Elastic Load
Balancer
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Amazon
Cloudfront
Amazon S3
Amazon
Route 53
User
ElastiCache
DynamoDB

41. • Move dynamic content
from the ELB to Amazon
CloudFront
Elastic Load
Balancer
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Amazon
Cloudfront
Amazon S3
Amazon
Route 53
User
ElastiCache
DynamoDB

42. Now that our web tier is
much more lightweight, we
can revisit the beginning of
our talk…

43. Auto Scaling!

44. Auto Scaling Trigger auto-scaling policy
Automatic resizing of compute
clusters based on demand
Feature
Details
Control
Define
minimum
and
maximum
instance
pool
sizes
and
when
scaling
and
cool
down
occurs.
Integrated
to
Amazon
CloudWatch
Use
metrics
gathered
by
CloudWatch
to
drive
scaling.
Instance
types
Run
Auto
Scaling
for
on-­‐demand
and
Spot
Instances.
Compa'ble
with
VPC.
Amazon
CloudWatch
aws autoscaling create-auto-scaling-group
--auto-scaling-group-name MyGroup
--launch-configuration-name MyConfig
--min-size 4
--max-size 200
--availability-zones us-west-2c, us-west-2b

45. Typical
weekly
traffic
to
Amazon.com
Sunday Monday Tuesday Wednesday Thursday Friday Saturday

46. Typical
weekly
traffic
to
Amazon.com
Provisioned capacity
Sunday Monday Tuesday Wednesday Thursday Friday Saturday

47. November

48. Provisioned capacity
November

49. 76%
24%
Provisioned capacity
November

50. November

51. Auto Scaling lets
you do this!

52. Web
Instance
Availability Zone
Amazon
Route 53
User
Amazon S3
Amazon
Cloudfront
Web
Instance
Availability Zone
Elastic Load
Balancer
DynamoDB
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
ElastiCache RDS DB Instance
Read Replica
Web
Instance
Web
Instance
RDS DB Instance ElastiCache
Standby (Multi-AZ)
RDS DB Instance
Active (Multi-AZ)

55. AWS application management solutions
Higher-level services Do it yourself
AWS
Elastic Beanstalk
AWS
OpsWorks
AWS
CloudFormation Amazon EC2
Convenience Control

57. HOST
LEVEL
METRICS
AGGREGATE
LEVEL
METRICS
LOG
ANALYSIS
EXTERNAL
SITE
PERFORMANCE

58. There are further
improvements to be
made in breaking apart
our web/app layer

61. Use
Amazon
SQS
as
buffers
Controller
A
Controller
B
Controller
A
Controller
B
Q
Q
Tight
coupling
Loose
coupling

62. In the early days, if someone has a service for it already,
opt to use that instead of building it yourself.
DON’T REINVENT THE WHEEL
Examples:
• Email
• Queuing
• Transcoding
• Search
• Databases
• Monitoring
• Metrics
• Logging
Amazon SNS Amazon SQS
Amazon
CloudSearch
Amazon Elastic
Transcoder
Amazon SWF
Amazon SES

64. RDS DB Instance
Active (Multi-AZ)
Availability Zone
Elastic Load
Balancer
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User
Amazon S3
Amazon
Cloudfront
Amazon SQS
DynamoDB
ElastiCache
Worker
Instance
Worker
Instance
Amazon
CloudWatch
Internal App
Instance
Internal App
Instance
Amazon SES

65. The next big steps

67. • Split up databases by function/
purpose
• Harder to do cross-function
queries
• Essentially delaying the need
for something like sharding/
NoSQL until much further down
the line
• Won’t help with single huge
functions/tables
ForumsDB
UsersDB
ProductsDB

68. Sharded horizontal scaling
• More complex at the
User ShardID
application layer
002345 A
• ORM support can help
002346 B
• No practical limit on
002347 C
scalability
002348 B
• Operation complexity/
002349 A
sophistication
Shard C
• Shard by function or key
space
• RDBMS or NoSQL
Shard A
Shard B

69. Shifting functionality to NoSQL
• Similar in a sense to federation
• Again, think about the earlier points for when you need
NoSQL vs SQL
• Leverage hosted services like DynamoDB
• Some use cases:
– Leaderboards/scoring
– Rapid ingest of clickstream/log data
– Temporary data needs (cart data)
– “Hot” tables
– Metadata/lookup tables
DynamoDB

70. A quick review

73. Putting all this together
means we should now easily
be able to handle
10+ million users!

74. To infinity…..

75. Iterating on top of the
patterns seen here will get
you up and over 100 million
users.

76. Deploying an MVP with AWS Elastic Beanstalk

77. THANKS
FOR
LISTENING!

78. AWS Cloud Kata for Start-Ups and Developers
台北
6⽉月25⽇日