ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

[SAA + SAP] 18. Architecture Discussions - 1

2021-08-04 14:02:23  阅读:236  来源: 互联网

标签:use CONS ELB 18 SAA instance EC2 Discussions AZ


Case 1: WhatIsTheTime.com

Simple start

  • Use T2 instance
  • EIP to public access

CONS:

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

 

  • Change T2 to M5 to vertically scale out EC2

CONS:

  • When change from T2 to T5, users experience downtime

 

  • 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

  • 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

Load Balaner

  • 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

  • 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?

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

CONS:

  • How about cost?

  • 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

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.

 

  • 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.

  • 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

  • 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

  •  We can use RDS to stroe the data

CONS:

  • Read performance

  • Create Read Replicas for read operations

or

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

  • Enable multi AZ for ELB, ElasticCache, RDS

 

  • 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 

  • 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

标签:use,CONS,ELB,18,SAA,instance,EC2,Discussions,AZ
来源: https://www.cnblogs.com/Answer1215/p/15095608.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有