[SAA + SAP] 18. Architecture Discussions - 1

Case 1: WhatIsTheTime.com

Simple start

[SAA + SAP] 18. Architecture Discussions  - 1

  • Use T2 instance
  • EIP to public access

CONS:

  • When more people come to your website, T2 instance is not enough to handle.

 

[SAA + SAP] 18. Architecture Discussions  - 1

  • Change T2 to M5 to vertically scale out EC2

CONS:

  • When change from T2 to T5, users experience downtime

 

[SAA + SAP] 18. Architecture Discussions  - 1

  • We grow horizontally by adding more M5 instances with EIPs

CONS:

  • Users need to remember the IP addresses
  • We have to manage more infrstrures

 

Route 53

[SAA + SAP] 18. Architecture Discussions  - 1

  • We don‘t user EIP anymore
  • We use Route 53 A Record point to EC2‘ public IP
  • With TTL 1 hours

CONS:

  • When we remove one instance, users for that instances cannot access app anymore, downtime for 1 hour

[SAA + SAP] 18. Architecture Discussions  - 1

Load Balaner

[SAA + SAP] 18. Architecture Discussions  - 1

  • We have EC2 instances in one AZ
  • We add ELB health check
  • Security group for EC2, only allow connection from ELB
  • Since we are using ELB, the IP address change all the time, we have to use Route 53 Alias Record.
  • Now load balacner + health check, we won‘t experience downtime anymore when we add/remove instance

CONS:

  • Adding / removing EC2 is hard to do manully

ASG

[SAA + SAP] 18. Architecture Discussions  - 1

  • With ASG, we are able to scale up/down based on traffic or time
  • We also make EC2 instance in private subnet to make it enhance security

CONS:

  • How about disaster happen to that AZ?

[SAA + SAP] 18. Architecture Discussions  - 1

  • Deploy EC2 in multi AZ for DR
  • ELB also in multi AZ

CONS:

  • How about cost?

[SAA + SAP] 18. Architecture Discussions  - 1

  • If we know that we have to use 2 AZs, then we must have at least 2 EC2 instances in total, one for each.
  • Then we can reserve instances for cost saving

 

Summary

  • Public vs Private IP and EC2 instanes
  • EIP vs Route 53 vs Load Balancers
  • Route 53 TTL, A record and Alias Recoreds
  • ASG vs Maintaining EC2 instances manually
  • Multi AZ to survive disasters
  • ELB Health Checks
  • Security Group Rules
  •  Reservation of capacity for costing saving when possible
  • 5 Pillars for well architected application:
    • Performance
    • Reliabillity
    • Security
    • Cost
    • Operational excellence

 

Case 2

[SAA + SAP] 18. Architecture Discussions  - 1

[SAA + SAP] 18. Architecture Discussions  - 1

For a stateless application, it doesn‘t matter, everytime users visit page, traffic goes to the same EC2 instance or not.

But for stateful application, it does matter. Imaging shopping cart app, suddendly after refresh the page, data is lost. That is really bad.

 

[SAA + SAP] 18. Architecture Discussions  - 1

  • We can enable ELB Affinity (stickniess), so that everytime, same user goes to same instance.

CONS:

  • We might still lose the data once one EC2 goes down.

[SAA + SAP] 18. Architecture Discussions  - 1

  • Let‘s say that we want to make EC2 instance stateless by store the shopping cart information in Cookies

CONS:

  • Secuirty risk by alert cookies
  • More validations needed
  • Limit on Cookies size 4 KB

[SAA + SAP] 18. Architecture Discussions  - 1

  • Now let‘s try to use Session with Session ID
  • Instead of sending whole shopping cart information, we just send session_id from client
  • We can use ElastiCahe or DynamoDB to store shopping cart information by session_id
  • Now that each request can go to different EC2 instace
  • And we still able to get all the information needed from DB

[SAA + SAP] 18. Architecture Discussions  - 1

  •  We can use RDS to stroe the data

CONS:

  • Read performance

[SAA + SAP] 18. Architecture Discussions  - 1

  • Create Read Replicas for read operations

or

[SAA + SAP] 18. Architecture Discussions  - 1

  • Can use ElastiCache to cache the content with Write Through, so keep the cache up to date

[SAA + SAP] 18. Architecture Discussions  - 1

  • Enable multi AZ for ELB, ElasticCache, RDS

[SAA + SAP] 18. Architecture Discussions  - 1

 

[SAA + SAP] 18. Architecture Discussions  - 1

  • Simpfiy with Aurora with Multi AZ

Summary

  • 3-tier architecture for web applications
  • ELB sticky sessions
  • Web clients for storing cookies and making our web app stateless
  • ElastiCache
    • For storing session (or DynamoDB)
    • For caching data from RDS
    • Multi AZ
  • RDS
    • For storing user data
    • Read replicas for scaling reads
    • Multi AZ for disaster recovery
  • Tight Security Group referencing each other
  • Aurora

 

Case 3 Wordpress 

[SAA + SAP] 18. Architecture Discussions  - 1

  • We can save the images/files into EFS
  • Each instances should has ENI to talk to EFS

 

Case 4 Instantiating Applications quickly

  • EC2 Instances
    • Use a Golden AMI: Install your app, OS dependencies etc... beforehand and launch your EC2instance from the Golden AMI
    • Boostrap using User Data: For dynamic configuration, use User Data Scripts
    • Hybrid: mix Golden AMI and User Data (Elastic Beanstalk)
  • RDS
    • Restore from a snaphost: the database will have schemas and data ready
  • EBS
    • Restore from a snapshot: then disk will already be formatted and have data

[SAA + SAP] 18. Architecture Discussions - 1

上一篇:MATLAB读写txt文件,并对数据进行二/十/十六进制转换(量化)


下一篇:关于vue3简单状态管理约定引发的思考