csct3434
첫 서비스 출시기 (feat. EC2 Auto Scaling, Aurora Serverless) 본문
인트로
작년 11월 구름에서 주최한 해커톤에 참가하여 24절기를 테마로 한 일기 서비스를 개발했습니다.
해커톤 당시에는 데모 수준에 그쳤지만, 팀의 좋은 분위기로 인해 해커톤 이후로도 약 3개월 간 추가로 서비스를 개발하며 서비스를 정식으로 출시했습니다.
장애 대응
백엔드 개발자로서 서비스 출시를 앞두고 가장 우려되는 부분은 트래픽 증가로 인한 장애 발생이었습니다.
오프라인 행사와 온라인 플랫폼(에브리타임, 인스타그램 광고)에서 홍보를 동시에 진행할 예정이었기에, 어느 정도로 부하가 발생할 지 예측하기 힘든 상황이었습니다. 이에, 비용이 많이 발생하더라도 최대한 안정적으로 서버를 운영할 수 있도록 인프라를 재구성했습니다.
WAS
WAS의 경우 AWS ALB와 EC2 Auto Scaling을 활용하여 부하에 따라 수평 확장이 자동으로 이루어지도록 조치했습니다.
Oracle 문서에 따르면 Latency Senstive한 애플리케이션의 경우 80% 미만의 CPU 사용률을 유지하는 것이 좋다고 합니다.
이를 참고하여, CPU 사용률 70%를 기준으로 스케일링이 수행되도록 설정했습니다.
또한, 인스턴스의 사양이 낮을 경우 과도한 스케일링으로 인해 효율성이 떨어질 수 있다고 생각했습니다.
이에 대해 고민하던 중, 현업에서 t3.small 인스턴스로 서비스를 운영하는 사례를 발견했습니다.
이는 프리 티어인 t3.micro보다 한 단계 높은 타입으로 비용 또한 크게 부담되지 않아 저 또한 이를 선택했습니다.
DB
요청이 몰릴 경우 DB 커넥션이 고갈되어 병목 현상이 발생할 수 있습니다.
EC2의 경우 오토 스케일링을 지원하지만, RDS는 오토 스케일링을 지원하지 않아 프로비저닝으로 인스턴스를 구성해야 합니다.
DB 성능 튜닝에 대한 지식과 경험이 부족하기에 직접 데이터베이스를 구성하는 것이 부담되는 상황이었습니다.
과거에 AWS SAA 자격증을 취득하면서 자동으로 데이터베이스를 관리해주는 Aurora RDS Serverless에 대해 알게되었습니다.
1초 미만으로 즉시 확장하여 수십만 건의 트랜잭션도 처리할 수 있다기에, 적어도 DB 성능 문제는 발생하지 않겠다고 생각이 들어 이를 사용해보기로 했습니다.
결과
홍보 결과
3일간 5만원을 투자하여 인스타그램 홍보를 진행한 결과, 약 5,400명에게 광고가 노출되었고 이 중 107명의 사용자가 사이트에 방문했습니다. 최종적으로 5일의 홍보기간 동안 약 120명의 사용자가 가입했습니다.
WAS
홍보 기간 동안 CPU 사용률이 일시적으로 40%에 도달한 것을 제외하고는, 대부분 4% 미만의 사용률을 보였습니다.
예상되는 동시 접속자가 수 천명이 아닌 이상, 프리티어인 t3.micro와 오토스케일링 조합으로도 안정적인 운영이 가능하다고 생각합니다.
DB
5일간 Aurora RDS Serverless V2를 사용해 본 결과 약 12달러의 비용이 발생했습니다.
부하가 거의 발생하지 않은 상황을 감안하면 하루에 약 2.4달러의 기본 비용이 발생하는 것으로 추정됩니다.
홍보 기간 동안의 피크로드와 사용자 수를 고려해 봤을 때, 프리티어인 t3.micro 인스턴스로도 안정적인 서버 운영이 가능해 보였습니다.
이에 현재는 EC2와 RDS 모두 t3.micro 인스턴스 타입을 사용하고 있고, 만일을 대비하여 EC2 Auto Scaling은 그대로 적용하고 있습니다.
회고
Keep
- 오토 스케일링을 통한 안정적인 서버 운영
- 예측할 수 없는 트래픽 발생에 대비한 서버리스 데이터베이스 활용
Problem
- 부하 테스트를 사전에 진행하지 않아 인스턴스 타입 별 성능을 파악하지 못함
Try
- 부하 테스트를 통해 적정 DB 인스턴스 타입 결정하기
- 중앙 집중식 로깅 구현
- DB 커넥션 풀 크기 최적화
'개발 일지' 카테고리의 다른 글
| 중앙 집중식 로깅 구현하기 (feat. Logback, CloudWatch Logs) (0) | 2024.03.30 |
|---|---|
| Github Actions Secret 버그 (0) | 2024.03.27 |
| 페이지네이션 성능 비교 : LIMIT-OFFSET vs NO-OFFSET (0) | 2024.03.12 |
| equals() vs hashCode() (0) | 2024.02.29 |
| MySQL 더미 데이터 적재 속도 비교 (1) | 2024.02.29 |
