이 전까지는 개개인의 기술을 배웠다면 이 부분은 각각의 기술들을 전체의 구조를 봤을떄 어떻게 이뤄저있는가를 배울수 있는 부분이다.

그래서 간단한 서비스들을 예시로 풀어나가본다.

Stateless Web App : WhatIsTheTime.com

그냥 사용자가 몇시야? 라고 물어보면 시간을 알려주는 간단한 서비스이다.
데이터베이스 필요없고 작고 다운타임 또한 허용할꺼다.
그러나 수직,수평 확장성이 필요하고 다운타임은 허용안할꺼다?(??)

Starting Simple

Public Ec2 를 하나 생성하고 그냥 사용자가 물어보면 시간을 알려준다.
그리고 Instance 가 재시작 해도 고정된 IP Address 를 가질수 있게 Elastic IP Address 를 사용해줄것이다.

Scaling vertically

근데 이 서비스가 대박이 점점 나기 시작해서 Traffic 이 증가한다면?
instance 성능이 감당을 할수가 없을것이다.

그래서 t2.micro 성능을 m5.large로 성능을 바꿔준다.
이게 vertical scale 이다.
이렇게 바꿔도 어짜피 Elastic IP Address 는 있으니 IP 또한 수정안해도 된다.
그러나 성능을 바꾸는 기간중에 Downtime 이 생겨버려서 사용자가 화날수도 있음.;;

Scaling horizontally

이건 성능을 높이는것이 아닌 많은 instance 를 생성해서 Traffic 분산하는 것이다.
이렇게 된다면 더욱 많은 사람들이 서비스를 사용해도 Traffic . 을감당할수 있지만 사용자 입장에서는 각 Instance의 IP 주소를 알아야하고 개발자 입장에서 또한 더 많이 관리해야하기 때문에 불편하다.

그래서 우리는 Elastic Ip Address 를 삭제하고 Amazon Route 53을 사용해서 각각의 Public Ip Address 를 묶는다.
Routing 기법에 따라 바뀌겠지만 여기선 뭐 모든 가중치를 주고 줬나보다.

Removing Instances

근데 이렇게 Route 53으로 묶어서 TTL 도 1시간이라고한다고 했는데 Instance 중 하나가 삭제되어 버리면 어떡하나?

TTL 시간동안은 같은 응답을 받을수 있지만 그 이상은 불가한 문제가 생겨버린다.

Load Balancer

그래서 LB를 사용한다.
LB를 사용하면 Health check 도 있기 때문에 Instance 중 하나가 갑자기 안된다?
그럼 그 Instance 로는 연결을 해주지 않고 그냥 정상인것들 중에 하나를 내보낸다.

Auto Scaling Group

모든것이 완벽하다해도 지금은 고정적으로 Instance 를 가지고 있다.
시간을 알려주는 서비스는 아침에는 사용자가 적고 저녁에는 많다고 가정하면 아침에는 instnace 1개 저녁에는 3개를 설정할수있게한다.
그게 ASG이다.

Multi-AZ

근데 전 세계적으로 서비스를 사용하는데,,, 만약 한국에 지진이 일어나서 한국에서 안된다하면 되나?
그래서 다중 가용 영역을 설정해서 높은 가용성과 장애 발생도 대비해야한다.

Stateful Web App: MyClothes.com

이제는 옷가게를 만들꺼다 ㅋㅋ
장바구니도 있고 한번에 대량의 사람들이 들어온단다.
가능한 stateless 하게 해줬으면 한다한다.
장바구니 삭제되면 절대 안된다!

기본은 Route 53 을 Alias 로 ELB 와 묶고 ASG 된 Instance 들과 연결해뒀다. 이게 기본 구조이다.
근데 이런 구조일떄 첫번쨰 Instance 에서 장바구니를 만들어뒀는데 다음번에 접근할때는 또 두번째 instance 로 접근을 해버려서 내가 만들어둔 장바구니가 없어진다.
이러면 절대 안된다.

Stickiness ( Session Affinity)

그래서 ELB Sticiness 를 사용해서 해당 사용자는 첫번쨰 Instnace 만 접근할수 있게 하는것이다.!
그러나 이것도 만약 그 사용자가 접근하던 Instance 가 삭제되어 버리면 장바구니 또한 사라진다는 문제가 생긴다.

User Cookies

그래서 Instance가 정보를 가지고 있지 않고 사용자가 애초에 알려주는거다.
이게 Cookie 인데 Http header에 정보를 담아서 보내주는것.

그렇게 하면 어느 instance 를 접근하든 장바구니를 안 잃어버릴수 있음!
근데 이건 Stateless 하고 Http 또한 무겁고 보안 문제도 있다!
쿠키가 변경될수 있기 떄문.
그래서 Ec2 Instance 가 사용자 Cookie 내용을 검증해야한다.

Server Session

장바구니 전체를 Header에 담아서 보내는게 아니고 이제는 Session Id 만 보내는거임.
그럼 이 물건을 장바구니에 추가할거라고 instance에 요청하고 Instance 는 Elastic Cache에 추가한다.그렇게 가져오고도 할수 있다.
이러면 최고로 성능좋게 구조를 작성할수 있게 되는것!

Storing User Data in a database

말 그대로 DB에 모든것을 저장하는것이다.

Scaling Reads

만약 사용자가 많아져서 읽기 하는 활동을 많이 하는것을 확인했다.
그런데 현재는 RDS 가 한개가 있는데 이 한개가 감당하기 힘들다.
그래서 읽기전용 Replica 를 만들어서 읽기 Traffic 부하를 퍼트릴수있다.

Lazy Loading

그리고 중간에 cahce 를 두어서 만약 Cache 에 있으면 hit 하고 없으면 RDS 를 가서 가져오면 되는것이다.

Security Groups

ELB 어디서나 HTTP/HTTPS Traffic 을 열수있는데 ELB,Instance 서로가 이것들을 제외한 접근은 제한하고 서로만 접근할수 있게해서 보안을 높일수 있다.

Stateful Web App:MyWordPress.com

WordPress website 를 만드는데 사진을 저장하고 읽을수 있게 할려고한다.
모든 데이터 들은 MySql DB에 저장되게 하려고 한다.

기본 구조에서 RDS 가 있는 계층을 생성한다.

Scaling with Aurora:Multi AZ & Read Replicas

그래서 RDS 를 좀더 크게 확장하고 싶으면 Aurora 를 사용해서 연산을 줄일수 있다고 한다.

Storing Images with EBS

만약 한개의 instance 가 있다면 EBS 한개를 두어서 사진을 저장하고 사용자가 읽을수도 있다.

근데 확장할떄 문제가 생겨버린다.
만약 Instance 가 2개가 있는데 각각의 EBS가 있을것이다.
나는 첫번쨰 Instance 에 연결된 EBS에 사진을 저장했는데 읽어들일때 두번쨰 instance에 접근해버려서 내가 저장한 사진이 사라진것이다.
그래서 다중 Az & 다준 Instance로 확장을 시작하면 문제가 발생한다.

Storing Images with EFS

그래서 이걸 해결하기 위해 EFS 를 사용하면 된다.
EBS를 두지 말고 공용 EFS를 두어서 Instance 와 ENI 를 연결하고 ENI 와 EFS를 연결하여서 Storage 가 모두에게 공유될수 있게한다.