MySQL DB의 인스턴스 산정 - cpu,ram산정

1. 목적과 테스트 범위

처음에 고려했던 확장 방식은 쓰기 DB와 읽기 DB를 분리하고 읽기 DB를 확장하는 방식으로 진행하려고 했다. 그러기 위해서 테스트를 통해서 DB의 인스턴스를 산정하려던 도중 DB에 생각보다 큰 CPU와 RAM이 필요하지 않아 1대의 RDB를 가정하고 다시 부하테스트를 진행하려고 한다. (CPU 1대 미만으로 계산됨)

프로필 조회, 좋아요, 매칭, 채팅 부하를 바탕으로 CPU와 RAM을 계산했다. . Backend 2대와 채팅 서버 2대가 같은 DB를 사용한다고 가정했다. AI 서버 2대는 별도 DB를 사용하기 때문에 DB산정에서 제외했다.

설정	값
테스트 DB	로컬 Docker MySQL Server
DB 리소스	2 vCPU / 메모리 한도 4GiB
max_connections	151 (레퍼런스 자료 출처에 포함)
앱 연결 상한	Backend 2대 + 채팅 2대, 태스크당 풀 최대 10개씩 (레퍼런스 자료 출처에 포함)
테스트 데이터	사용자 126,000명, 전체 DB 데이터 182MiB

2. 부하 목표와 가정

네 가지 Backend 기능에 대해 설계한 피크 부하는 읽기 1476 QPS, 쓰기 643 QPS, 합계 2120 QPS다. 채팅 부하는 별도로 더했다. 요청당 SQL 수는 구현 후 바뀔 수 있다.

기능	피크 목표 요청/초	요청당 SELECT	요청당 쓰기 SQL	피크 읽기 QPS	피크 쓰기 QPS
프로필 목록 조회	210	2	0	420	0
프로필 상세 조회	420	1	0	420	0
좋아요 등록	630	1	1	630	630
매칭 수락	6.8	1	2	6.8	13.6
합계	1,266.8			1,476.8	643.6

채팅 전송 68요청/초, 읽음 68요청/초, 매칭 수락 6.8요청/초, 방 입장과 이력 조회 각 35요청/초로 가정했다.

시나리오 계획 DB 읽기 QPS 계획 DB 쓰기 QPS
비피크 7,000명	123.2	55.3
피크 126,000명	2,218.5	995.2

3. 측정 결과

테스트 결과 요청 오류가 0건이고 기능별 달성 요청률도 대체로 목표에 근접했다.

지표	비피크 7,000명	피크 126,000명
계획 DB 읽기 / 쓰기 QPS	123.2 / 55.3	2,218.5 / 995.2
실측 DB 읽기 / 쓰기 QPS	121.9 / 54.6	2,214.6 / 982.2
DB CPU 평균 / 최대	0.13 / 0.21 vCPU	0.57 / 1.55 vCPU
DB 컨테이너 메모리 최대	1.18GiB	1.16GiB
DB 연결 수 최대	42	42
버퍼 풀 적중률	100%	100%

4. CPU 사양 해석

목표 사용률 75%로 가정했다.

필요 vCPU= 측정된 최대 vCPU 사용량 ÷ 0.75

단계	실제 DB CPU 최대 75%	목표로 환산한 필요 vCPU
비피크	0.21	0.28
피크	1.55	2.07

2 CPU 기준 순간 최대 사용률은 77.5%로 목표 사용률 70%를 일시적으로 초과했지만 평균 사용률은 28.5%였기 때문에 2 CPU를 선택했다.

5. RAM 사양 해석

항목	비피크	피크
DB 컨테이너 메모리 최대	1.18GiB	1.16GiB
버퍼 풀 설정	1GiB	1GiB
버퍼 풀 적중률	100%	100%

메모리 여유를 보수적으로 확보하기 위해 사용률 50%를 자체 기준으로 설정했다. 로컬 테스트에서 측정한 최대 메모리 사용량 1.18GiB에 적용하면 필요 용량은 2.36GiB이므로 4GiB 인스턴스를 후보로 선정했습니다.

6. 현재 측정의 한계

1. 로컬 환경에서 측정했다. 테스트 DB가 노트북의 Docker에서 실행되어 디스크 쓰기 지연과 CPU 성능이 운영 RDS와 다를 수 있다.
2. 운영 테이블,인덱스,데이터 규모가 동일하지 못했다. Backend 기능의 SQL은 구현 전 가정이고 채팅 SQL도 실제 부하테스트에서 사용한 MongoDB 호출을 MySQL 스키마로 옮긴 가정이다. 테스트 데이터가 작아 버퍼 풀 적중률 100%로 나타났다. 실제 SQL의 실행 횟수와 운영 규모에서 발생할 읽기와 쓰기에 대한 부하는 측정이 추후에 필요하다.
3. 사용자 행동에 따른 부하가 달라질 수 있다. 기능별 요청 비율과 채팅 전송,읽음에는 추정값이 포함돼 있다. 실제 사용자가 특정 시간에 더 자주 접속하거나 일부 기능에 요청이 집중되면 같은 사용자 수에서도 DB QPS와 쓰기 경합이 달라진다. 운영 로그나 실제 행동 자료로 요청 비율을 보정해야 한다.
4. 참고자료

CPU 공식 :https://neo4j.com/developer/kb/capacity-planning-example/

안정적인 목표 사용률 aws공식 : https://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_proactive_adapt_auto.html

service demand 테스트 결과 : https://docs.aws.amazon.com/ko_kr/whitepapers/latest/optimizing-mysql-on-ec2-using-amazon-ebs/mysql-benchmark-observations-and-considerations.html

memory공식 명시 :

https://www.packtpub.com/en-us/learning/how-to-tutorials/getting-started-innodb

mysql 기준 innodb_buffer_pool = 50~75%권장 : https://dev.mysql.com/doc/refman/8.0/en/memory-use.html

테스트 커넥션풀=10 근거자료: https://github.com/brettwooldridge/HikariCP