반응형
2024년 SAA-C03 자격증 준비하면서 필요한 노트 정리했습니다
강의는 유데미 "Ultimate AWS Certified Solutions Architect Associate SAA-C03" 통해 공부했습니다
https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c03
같이 공부해서 합격해보자구요 !
Section 11 : Classic Solutions Architecture Discussions
121. WhatsTheTime.com
- Stateful Web app
- requirements
- allows people to know what time it is
- db no required
- start small, accept downtime
- but eventually full scale vertically & horizontally and no downtime
1st step
- create a public ec2 (t2 micro)
- create a elastic ip address so ip does not change
Pros :
- users are now able to access the site
Cons :
- traffic starts to increase, one t2 instance is starting to be overwhelmed
2nd step
- decide to vertically increase from t2 -> m5
Pros :
- current traffic is being handled smoothly thanks to increasing the ec2 spec
Cons :
- downtime happens while changing instance from t2 to m5
- because of the downtime, users raised a voc complain why no internet >:O
3rd step
- Traffic is increasing more and more, decided to scale out horizontally by creating more instances manually and assigning each instance a elastic ip
Pros :
- traffic is handled smoothly
Cons :
- but because new instances are created with different elastic ip, each users must know specific elastic ip address in order to access the instances
- The developer has to be aware of each instance status and have to manually create new instances and new elastic ip address every time traffic becomes more and more
4th step
- Only 5 elastic ip address is assigned per region per account, so removing elastic ip addres, create a route 53
- api.whatisthetime.com dns
- A record
- TTL 1 hour
Pros :
- Users does not have know ip address for each instance, and dns name is easy to remember
Cons :
- If traffic decreases and scale in, once instance is going, user cannot access other instance until sometimes up to 1 hour, because ttl is 1 hour
- Why site down >:O to some user but other users can access the site
5th step
- Let's add a load balancer
- previously all ec2 were public, now we can move them to private
- create a elb + health checks, if instance is down, elb will stop sending traffic to down instance
- since load balancer ip changes, we have to change a record to alias record
Pros :
- Downtime does not happen because of elb health checks
Cons :
- while great, instance are still being added and removed manually by developers :(
6th step
- Let's add a auto-scaling group
- auto scalin group will control the number of ec2, scale in and scale out when required
Pros :
- Wow every thing works perfectly ! no need for manual work
Cons :
- A problem occurred, an earthquake happened and availability zone goes down, since we didnt prepare in advance, we simply put all the system at one availability zone
- Everything is down, users are frustrated >:O
7th step
- Let's make our app multi-az
- highly available
- elb on az 1, 2, 3
- auto scaling group on three different az region
Pros :
- Highly available, resilient to failure
Cons :
- now system is highly available, but cost wise is not considered
8th step
- only start up instances that are required let's say maximum of two while traffic is low
- if traffic increases then auto scale out increase by selecting on demand or spot on instances
Pros :
- Highly available, resilient to failure
Cons :
- public vs private ip and ec2 instances
- elastic ip vs route 53 vs load balancers
- route 53 ttl, a record & alias records
- manual ec2 instance vs auto sclaing groups
- multi az for disasters
- elb health checks
- security group rules
- save costs when possible
같이 파이팅해서 합격해봅시당 ㅎㅎ
저는 24년 10월 중순에 시험 볼 예정입니다 ! (후기 남기도록 하겠습니다 후후)
토니이츠얼랏 : 네이버 블로그
너무너무너무 많이 먹는 토니입니당 :)
blog.naver.com
반응형
