Please enable JavaScript.
Coggle requires JavaScript to display documents.
Design principles of Architecting Cloud (Automation (Auto Scaling, Elastic…
Design principles of Architecting Cloud
Scalability
Scaling
horizontally(
internet-scale app)
Distributed
process
Kinesis
EMR
Stateful
components
(Session affinity)
ELB
(
Client-side load balancing
, assign specific client to certain server using discovery API)
ELB
(
Sticky session
, assign same server to user during session)
Stateless
components
e.g HTTP cookies.
DynamoDB
is good choice to store native sessions.
S3 and EFS
for larger files.
SWF
(Simple Workflow Service) store
execution history
.
Stateless
application
(often series interactions form a session) Sateless app
no
knowledge of
previous interactions
and store
no sessio
n info.
Scaling
vertically
Add more RAM, CPU, IO or networking capabilities
Disposable Resources Instead of Fixed Server
Instantiating
compute resources
Bootstrapping
(EC2 instance or RDS DB instance)
Golden Image
(snapshot of particular state of resource e.g. EC2, RDS instances or EBS volumes or using
Docker
)
Hybrid
(e.g. Elastic Beanstalk is a hybrid model)
Infrastructure as Code
Automation
Auto Scaling
Elastic Beanstalk
EC2 auto recovery (by creating CloudWatch alarm)
CloudWatch alarm (alarm --> SNS --> lambda --> SQS or POST request to an HTTP/S endpoint)
CloudWatch Event (stream --> Lambda or Kinesis or SNS topics)
OpsWork Lifecycle events(e.g. trigger chef recipes)
Lambda scheduled event
Loose Coupling
Well-definded interfaces
(components interact ONLY through specific, technology-agnostic interfaces e.g. RESTful APIs)
API Gateway
Service discovery
(
Elastic load balancing
or APIs or 3rd-party tools e.g. Netflix Eureka, Airbnb synapse or HashiCorp Consul)
Asynchronous integration
(lambda, SQS, Kinesis, API Gateway)
Graceful failure
(e.g. Route53 DNS failover feature)
Service, Not server
Managed
services(e.g.SQS, S3, DynamoDB, CloudFront, ELB, CloudSearch, SES, Elastic Transcoder)
Serverless
architectures(Lambda, API Gateway, Cognito, AWS IoT)
Database
)
Relational Database (RDS)
Scalability(
Read replica
and
data partitioning and sharding
to scale write capacity)
High availability(
RDS multi-AZ deployment
feature)
Anti-pattern
s(use NoSQL if no need to join or complex transaction, use S3 for binary file e.g. image, video, audio)
NoSQL Database(DynamoDB)
Scalability(DynamoDB
partitioning and replication automatically)
High Availability (DynamoDB
synchronously replicate data
across three facilities in region)
Anti-pattern(Use RDS if schema can not be denormalized or requires join)
Data Warehouse(Redshift)
Scalability(massively parallel processing(
MPP
),
columnar
data storage and t
argeted data compression
encoding schemes)
High availability(
multi-nodes cluster
automatically replicate to another node,
continously backup to S3
, monitor health of cluster and
automatically re-replicate data
from failed drives and replace node if needed)
Anti-patterns(Redshift is a SQL DB, it is
not for OLTP
(Online Transaction Processing),
not for concurrency workload
involving reading and writing all columns for a small number of records at a time --use DynamaDB or RDS)
Search(CloudSearch-scala automatically, ElasticSearch- open source API )
Scalability (
CloudSearch partitioning and replication automatically
)
High availability(
Both
CloudSearch and ES
store data across AZs
)
Removing single point of failure
Introducing redundancy(to remove single point of failure.)
standby redundancy
-failover normally used in
RDS
.
active redundancy
(when one fail, other absorb its workload.)
Detect failure
ELB, Route53, AutoScaling, OpsWorks, Elastic Beanstalk,
deep health check
Durable data storage
Synchronous replication
--strong consistency, having performance and availability issue, not recommend to maintain many synchronous replication
Asynchronous replication
(decouple primary node from its replicas, used as a disaster recover solution)
Automated multi-data center resilience(protection over disruption, e.g AZs,ELB, autoscaling
Fault isolation and traditional horizontal scaling(handle harmful request)
Shuffle sharding
(8 instances --> 4 shards with 2 instances each --> distribute customer to each shard-->customer try every endpoint until one succeeds)
Optimize for Cost
Right size
Continuous monitoring and tagging
Elasticity
Use Services
which no capacity needed
e.g.ELB, CloudFront, SQS, Kinesis firehose, Lambda, SES, CloudSearch
AutoScaling
User service with
easily modify capacity
e.g. DynamaDB, RDS, ElasticSearch Service
Take advantage of variety of purchasing options
Reserved capacity
(ideal for predictable min requirement, Redshift, RDS, DynamaDB, CloudFront)
Spot Instance
(EC2, ideal for flexible start and end times)
Caching
Application data caching(ElasticCache)
I/O-intensive database queries
outcome of computationally intensive processing
Edge Cache(CloudFront)
Copies of static content(e.g. images, css files, streaming of pre-recorded video
Dynamic content(e.g. html response, live video)
Security
Utilize AWS features for defense in depth(VPC, WAF, IAM)
Offload security responsiblity to AWS (security patch repsonsiblity on AWS- RDS, ElasticCache, CloudSearch etc.)
Security as code (CloudFormation)
Real-time auditing(Config, Inspector, Trusted advisor, CloudWatch logs, CloudTrail, Lambda, EMR, ES)
Reduce privileged access