페이스북, 트위터와 비슷한 SNS앱 서버 사이드 프로젝트입니다. SNS의 회원, 포스팅, 팔로우 기능을 구현과 더불어 인프라 구축을 하였습니다.
- 평균적으로 300명의 팔로워가 있습니다.
- 일일 활성 사용자는 1000만명이며 각 사용자는 하루에 5번 뉴스피드를 가져옵니다.
- 하루 5000만 회, 초당 대략 578회 요청이 발생합니다.
고가용성 서비스를 위해 부하 테스트를 진행하였습니다. 개선점을 찾아 수정 후 2차 부하 테스트를 진행할 예정입니다.
테스트 조건
- 리소스는 CPU 1, RAM 1000mi인 Pod를 2개 사용하였습니다.
- 데이터베이스는 RDS이며, vCPU 2, RAM 8GB인 db.t3.large 클래스를 사용하였습니다.
- get /api/v1/newsfeed 요청을 실행하였습니다. 각 사용자 팔로워의 최근 글 20개를 가져옵니다.
- K6를 사용하여 EC2 vCPU 2, RAM 8GB인 t3.large에서 실행하였습니다.
스케일 아웃
서버 확장 전략으로 스케일 아웃을 선택하였습니다. 스케일 업 전략으로는 컴퓨터 자원이 향상됨에 따라 가격 또한 매우 급격하게 상승하는 문제와 하나의 서버는 다운될 경우 서비스 전반에 문제가 생기기 때문에 스케일 아웃을 필수적이라고 생각하였습니다.
코드형 인프라
AWS 리소스를 생성하는 작업은 30분 ~ 1시간 정도 소요되었습니다. Terraform을 사용하여 명령어 한번에 VPC, EKS Cluster, Managed node group 등을 생성하였습니다. 이후 시간 절약과 휴먼 에러를 방지할 수 있어 매우 잘한 일 중 하나가 되었습니다.
Kubernetes와 Helm을 통해 다수의 Server application, Monitoring tool, Load test tool을 실행하는데 몇개의 명령어로 가능하게 활용하였습니다.
CI 환경 구축
Github Actions를 통해 main 브랜치로 병합될 때 테스트 코드를 실행, 컨테이너 빌드, 빌드된 이미지를 저장소에 저장하도록 하였습니다.
결과 및 개선점
초당 처리할 수 있는 요청 수는 초당 500회입니다. Pod는 1개일 경우 초당 약 380개의 요청을 처리하고 2개일 경우 500개까지 늘어나는 것을 확인하였습니다. 이후 Pod를 3개~8개까지 늘렸으나 처리량이 늘지 않았습니다. 이를 통해 병목지점은 Server application이 아니라고 생각하였고 데이터베이스 CPU 사용량이 100%인 것을 보고 우선 데이터베이스의 문제인 것으로 예상하고 있습니다. 정말 병목 지점이 데이터베이스가 맞는지 2차 부하테스트에서 확인하겠습니다.
진행중
