인프라 아키텍처가 여러번 수정되었고, 변경되는 과정을 시간 순서에 따라 기술하였습니다.
현재 아키텍처
- AWS AutoScaling을 통해 ec2에 부하가 늘어나면 (cpu 사용량 60% 이상) 최대 5개까지 인스턴스를 늘려나갑니다.
- 늘어난 인스턴스에서는 도커를 통해 스프링부트 어플리케이션을 구동하게 됩니다.
- 또한 5개까지 늘어나는 인스턴스를 AWS ELB를 통해 로드밸런싱하게 됩니다.
- Redis는 한개의 별도 인스턴스에서 구축되었습니다.
- DB서버는 프라이빗 서브넷 상에 구축되었으며, 스프링부트 인스턴스가 가동되는 퍼블릭 서브넷에서만 접속 가능하도록 설정하였습니다.
- Github Action을 통한 CI-CD가 구축되어 있으며 빌드 실패시, 배포되지 않습니다. 또한 배포가 되면 슬랙으로 알림이 날아옵니다.
아래는 시간 순서대로 기술한 아키텍처 변화 과정입니다.
1.대용량 트래픽에도 끄떡없는 아키텍처를 구성하고 싶었다.
지난번에 성능평가를 한 후에 오토스케일링에 대해 알아보고
다음과 같은 아케텍처를 구상했다.
쿠버네티스를 이용하고, hpa를 통해 트래픽이 늘어나면 pod를 증가시키는 식으로 부하를 분산하고 싶었다.
그래서 미니쿠베로 쿠버네티스도 공부해보고,eks로 클러스터도 구성해봤는데 생각보다 많이 어려웠다.
구글링해가면서 하면 어찌저찌 오토스케일링을 구현할 수는 있었지만, 그건 쿠버네티스를 잘 모르는 상태에서 사용하는 것이기 때문에 별로라는 생각이 들었다.
또한 무지막지한 비용도 걱정이었다. eks는 요금이 어마어마하게 청구된다. 미니쿠베는 단일 노드여서 머스터,워커노드가 존재하는게 아니어서 실습용에 불과하다.
차라리 다른 방법을 사용해서 오토스케일링을 구현하고, 쿠버네티스를 차근차근 공부한 다음, 준비가 되면 서비스를 쿠버네티스로 전환하는게 좋을 것 같았다.
그래서 aws에 있는 오토스케일링과 로드밸런서를 이용해서 구성할 계획이다.
aws의 오토스케일링 서비스를 이용하면 원하는 조건에 맞춰 ec2 인스턴스가 복제된다. 복제된 인스턴스는 로드밸런서를 통해 접근 가능하다.
대충 요런 느낌이 되지 않을까 싶다.
2. AWS로 구축한 오토스케일링 아키텍처
- AWS AutoScaling을 통해 ec2에 부하가 늘어나면 (cpu 사용량 60% 이상) 최대 5개까지 인스턴스를 늘려나갑니다.
- 늘어난 인스턴스에서는 도커를 통해 스프링부트 어플리케이션을 구동하게 됩니다.
- 또한 5개까지 늘어나는 인스턴스를 AWS ELB를 통해 로드밸런싱하게 됩니다.
- Redis는 한개의 별도 인스턴스에서 구축되었습니다.
- DB서버는 프라이빗 서브넷 상에 구축되었으며, 스프링부트 인스턴스가 가동되는 퍼블릭 서브넷에서만 접속 가능하도록 설정하였습니다.
- Github Action을 통한 CI-CD가 구축되어 있으며 빌드 실패시, 배포되지 않습니다. 또한 배포가 되면 슬랙으로 알림이 날아옵니다.
문제점
현재 DB는 여전히 한개로 늘어나는 서버에 대비해서 개수가 일정하기 때문에 부하 문제가 생길 것으로 예상됩니다.
또한 Redis 서버가 다운되었을 때, 복구 방안이 존재하지 않습니다.
비용에 대한 부담 문제도 존재합니다.
3. 로컬 쿠버네티스 아키텍처
지난번 아키텍처의 단점을 보완하기 위해 쿠버네티스를 적용해보고 싶다는 생각이 들었지만 지난번 AWS상에 구축한 이후로 AWS요금이 5만원이나 과금이 되어서 EKS는 포기하기로 했습니다.
현재 프로젝트는 학습이 주된 이유입니다. 또한 AWS상에 구축하는 것은 이전에 공부했기 때문에 이번에는 로컬에서 쿠버네티스 환경을 구축해서 원하던 목표를 공부해 보는것이 중요하다고 생각했습니다.
따라서 도커 데스크톱에서 제공하는 쿠버네티스 서비스를 이용하기로 했습니다.
