AWS Cloud School 6기 3팀 미니 프로젝트 recruitment 사이트 Backend 팀 입니다.
대규모 트래픽 발생시 어떠한 Architecutre 를 구성해야 보다 원활한 Service 가 될지 고민하다 설정하게된 프로젝트 입니다.
이 화면을 보는데 1시간이 넘게 걸렸던 경험이 있습니다. 자동으로 어떤 Instance 를 사용했는지 Auto Scaling 은 사용했는지? 사용했다면 Metric은 뭔지 등등 의 의문이 자연스럽게 들었고 그 경험을 토대로 진행한 프로젝트 입니다.
- [Architecture]
- [배운점 + 해결한점]
간단한 3-Tier , HPA , RabbitMQ 순으로 3가지의 Architecture 로 나누어서 설계를 하였습니다.
Front,Back 각각 한개의 POD 만 작성해서 Test 한 결과 입니다.
한개의 POD 만 사용했던것을 넘어서 내부에 HPA 를 적용했습니다. Cloud 내에서도 Traffic Metric 을 두어서 Auto Scaling 을 하는것과 같이 HPA 도 같은 기능을 합니다.
이 부분에서 GET 은 처리량이 1번과 비교해서 상당하게 증가했다는것을 알수 있음.
1번에서 2번으로 Architecutre 를 변경하면서 GET 에 대한 TEST 의 처리량은 상당하게 증가했지만 POST 에 대한 처리량은 감소하기 시작합니다. 2번에서 3번으로 POST 처리량은 증가하긴 하였지만 1번에서 3번과 비교하면 1번이 더 우수한것을 확인할수 있다.
우리가 생각한 결과는 1번에서 3번으로 가면서 GET,POST 처리량이 더욱더 증가할것을 예상했지만 그렇지 못한것은 우리 모두가 가져야할 책임입니다.
Front 와 Back 사이에 내부 ALB를 두어서 Back 쪽의 로직들은 외부로 부터 숨기려고 했었습니다. 하지만 Front 측에서 RestAPI 통신시 내부에 있는 ALB 주소를 찾아가지 못하는 문제가 발생했습니다.
내부 ALB 를 외부 ALB로 변경해주면서 임시적인 해결을 할수 있었습니다.
이런 방식으로 외부 ALB를 두개 사용하는 경우 굳이 두개를 사용할 필요가 없었습니다. 그래서 ALB 한개에 Front,Back 을 각각 URL Mapping 으로 해주었습니다.
이러한 문제들을 해결하기 위해 최종적으로는 AWS API Gateway를 사용해서 해결했습니다.
API Gateway 를 배포하여 외부 노출해주었고 API Gateway 는 VPC LInk 를 통해 들어온 이후 내부에 연결된 NLB 로 연결이 되게 해주었습니다. 이러한 방식을 통해서 Private Subnet 안에 있는 Instance 에 접근할수 있게 됩니다.