[논의] Prod RDS → EC2 전환에 따른 Stage DB 관리 방식 변경 필요 여부

[Hexeong]

논의 배경

비용 절감 요구사항으로 Prod 환경의 RDS를 EC2 t4g.nano 자체 관리 DB로 전환하는 것이 결정되었습니다.

아래는 의사결정 과정에서 공유된 벤치마크 결과 및 현재 AWS 비용 현황입니다.

벤치마크 결과 (같은 sweep 기준)

항목	EC2 t4g.nano	RDS db.t4g.micro
TPS	428.4	282.9
p99 latency	149ms	786ms

EC2 t4g.nano가 TPS 약 51% 높고, tail latency도 훨씬 낮음.

nano 튜닝 후 최고 결과

• EC2 t4g.nano: 811.7 TPS, p99 126ms
• 추천 설정: max_connections=64, shared_buffers=64MB, work_mem=1MB, maintenance_work_mem=64MB, effective_cache_size=256MB

현재 AWS 비용 현황 (26년 5월 기준)

서비스	비용
Relational Database Service	$21.22
EC2 - Compute	$23.05
Virtual Private Cloud	$11.16
EC2 - Other	$6.42
기타	$0.09

Prod DB 전환이 결정된 만큼, Stage 환경의 DB 관리 방식에 대해서도 논의가 필요합니다.

참고: Stage 환경은 현재 enable_rds = false로 Docker 컨테이너 DB를 사용 중이며, Stage를 별도 환경으로 분리한 결정적 이유는 부하 테스트를 위함입니다.

---

의견 후보

의견 A — Stage도 Prod와 동일하게 별도 EC2 t4g.nano로 DB 분리 (상시 운영)

근거

• Prod-Stage DB 구조 통일 → DB 관련 이슈 사전 검증 가능
• EC2 자체 관리 DB 설정/튜닝 경험을 Stage에서 먼저 쌓을 수 있음

부하 테스트 관점

• DB 구조가 Prod와 완전히 동일 → 부하 테스트 결과를 그대로 Prod에 적용 가능, 신뢰성 가장 높음

우려사항

• 현재 Stage는 Docker DB로 추가 비용 없이 운영 중 → EC2 t4g.nano 상시 운영 시 비용 추가 발생

---

의견 B — 현행 유지 (평상시 Docker 컨테이너 + 부하 테스트 시 EC2 수동 설치로 전환)

근거

• 평상시에는 비용 부담 없이 Docker 컨테이너로 운영
• 부하 테스트가 필요한 시점에만 EC2 수동 설치 방식으로 전환해 Prod와 유사한 환경 구성

부하 테스트 관점

• 전환 시점에 Prod와 유사한 DB 구조를 갖출 수 있어 테스트 신뢰성은 확보 가능
• 단, 부하 테스트마다 DB 환경 전환 작업이 필요 → 전환 절차 표준화 및 자동화가 없으면 운영 부담 발생

우려사항

• Docker → EC2 수동 설치 전환/복구 과정에서 휴먼 에러 리스크
• 전환 시 데이터 초기화 및 설정 일관성 관리 필요
• 부하 테스트 빈도가 높아질수록 비효율 심화

---

의견 C — Stage는 단일 EC2 내 앱 + DB 공존 방식으로 전환 (중간 타협안)

근거

• 별도 EC2 추가 없이 Prod의 "자체 관리 DB" 운영 방식과 맞출 수 있음
• Docker 추상화를 걷어내고 실제 DB 설정/튜닝을 Stage에서 검증 가능
• 의견 B의 전환 작업 부담 없이 상시 EC2 수동 설치 방식 유지

부하 테스트 관점

• 부하 테스트 시 앱과 DB가 동일 EC2 자원을 공유 → CPU/메모리 경합으로 DB 순수 성능 측정이 어려움
• Prod(앱-DB 분리 구조)와 다른 병목 패턴이 나타날 수 있어 결과 해석에 왜곡 발생 가능
• 세 안 중 부하 테스트 신뢰성 측면에서 가장 취약

우려사항

• Prod 구조(앱-DB 분리)와 여전히 다름
• app_stack 모듈 구조 변경 필요 가능성

---

세 가지 의견 중 어떤 방향이 적절한지 의견 남겨주세요.

[lsy1307]

A는 기술적으로 가장 깔끔합니다. Prod와 Stage가 같은 구조라서 DB 튜닝, 장애 양상, 커넥션 설정, 배포 검증이 잘 맞습니다. 부하 테스트 신뢰성도 가장 높습니다. 다만 비용 절감이 목적성이 큰데 Stage에 t4g.nano DB를 상시 추가하는 건 방향이 조금 어긋납니다.

C는 솔직히 단점이 너무 커서 고려할만한 사항이 아닌 것 같습니다.

B의 환경 전환 자동화는 제가 작업을 해놔서 전환하는데 ec2 기반으로 필요한 스크립트만 추가하면 되고 설정 일관성도 parameter store로 관리할 수 있습니다.
환경 전환이 자동화가 되면 사람이 느끼는 비효율과 휴먼 에러 리스크는 크지 않고 비용 상 이점과 부하 테스트 결과의 신뢰성까지 확보할 수 있을 것으로 사료됩니다.

부하 테스트 시:

• 임시 DB EC2 t4g.nano 생성
• Prod와 동일한 DB 설치/튜닝 적용
• Stage 앱 datasource를 임시 EC2로 전환
• 테스트 종료 후 Stage 원복 + 임시 EC2 제거

이렇게 진행하는 게 가장 깔끔한 방법인 것 같습니다.

[whqtker]

a안에서 rds 하나 내리고 t4g nano 두 개 띄우는 방식이 의미있는 비용 절감이 된다면 가장 좋은 방식 같습니다

기존 stage 서버 인스턴스에서 db 컨테이너 띄우는 방식이 부하 테스트 결과에 큰 영향을 주지 읺는다면 b안이 좋을 거 같습니다
만약 그렇지 않다면 부하 테스트 때는 t4g nano 띄우는 게 낫겠지만, 기술적 복잡성이 얼마나 높을지는 모르겠네요

[Hexeong]

다른 분들의 의견을 종합해봤을 때 A안이 최선이지만, 비용절감 목적이 이번 작업의 최우선 목표인만큼 B안으로 가는게 좋아보입니다! 해당 방식으로 작업 진행하겠습니다!