nGrinder를 활용한 Amazon RDS 업그레이드 성능 테스트 방법

데이터베이스는 현대 애플리케이션의 핵심 구성 요소로서, 그 중요성은 계속 증가하고 있습니다. 그러나 데이터베이스 업그레이드나 주요 변경 작업은 다양한 위험을 내포하고 있으며, 이러한 변경들이 실제 운영 환경에 미칠 영향을 정확히 예측하는 것은 쉽지 않습니다. 이번 게시글에서는 오픈 소스 성능 테스트 도구인 nGrinder를 활용하여 Amazon RDS의 업그레이드 및 변경 작업을 안전하게 테스트하는 방법을 소개합니다.

Amazon RDS는 새로운 메이저/마이너 버전을 출시한 후 일정 기간이 지나면 기존 버전의 지원을 종료합니다. 각 버전은 보안 취약점이 개선되거나 성능이 향상되므로 안정적인 서비스 운영을 위해서는 정기적인 업데이트와 성능 최적화가 필수적입니다. 예를 들어, Amazon RDS MySQL 5.7의 지원은 2024년 2월 28일에 종료되며, Amazon Aurora MySQL 2 버전은 2024년 10월 31일에 EoL(End of Life) 됩니다. EoL 이후에도 최대 3년간 Extended Support를 통해 서비스를 이용할 수 있으나, 추가 비용이 발생할 수 있습니다. 따라서, 보안 강화와 최신 기능을 활용하기 위해 상위 버전으로의 업그레이드를 권장합니다.

이 글에서는 버전 업그레이드 뿐만 아니라 데이터베이스 구성 변경, 애플리케이션의 신규 기능 추가 및 변경 시에도 도움될 만한 유용한 정보를 제공하고자 합니다. 본문의 내용은 다음과 같이 구성되어 있으며, MySQL 버전별 성능 테스트가 주 목적이 아닌, nGrinder를 사용하여 테스트할 수 있는 방법에 집중하고 있습니다.

1. 테스트의 중요성
2. nGrinder를 선택 이유
3. 테스트 아키텍처 구성
4. 데이터 준비
5. 시나리오 구성
6. 테스트 실행 및 결과
7. 성능 모니터링 및 분석
8. 주요 고려 사항 및 팁

테스트의 중요성

데이터베이스 업그레이드, 설정 변경, 일반적인 애플리케이션 변경 과정에서 성능 저하, 호환성 문제, 데이터 손실과 같은 다양한 위험이 존재합니다. 이러한 위험들이 철저하게 관리되지 않을 경우, 프로덕션 환경에서 심각한 문제를 일으킬 수 있으며, 이는 고객 경험에 치명적인 영향을 미칠 수 있습니다. 따라서, 철저한 사전 테스트를 통해 시스템의 안정성을 확보하고, 업그레이드 후 데이터베이스가 원활하게 기능할 수 있도록 보장해야 합니다.

테스트의 성공은 사전에 테스트 시나리오를 얼마나 꼼꼼히 준비하느냐에 달려 있습니다. 변경 사항에 대한 꼼꼼한 검토와 영향 평가가 중요하며, 이를 테스트 시나리오에 반영해야 합니다. 또한, 해당 서비스의 기본적인 점검 항목을 추가하는 것도 중요합니다. 데이터베이스 변경을 위한 테스트 시나리오는 일반적으로 다음과 같은 항목을 포함시킬 수 있습니다.

• 기본 CRUD
• 복잡한 쿼리 성능 검증
• 동시성 및 스트레스 테스트
• 트랜잭션 처리 성능 테스트
• 기타 우려되는 모든 사항에 대한 부하 테스트

이러한 테스트는 수동으로 점검할 수도 있지만, 반복된 테스트 과정에서 일부 케이스의 누락 가능성이 있으며, 특히 스트레스 테스트는 수동으로 진행하기 어려울 수 있으므로, 여러 툴을 활용하여 이러한 어려움을 극복할 수 있습니다.

nGrinder를 선택한 이유

스트레스 툴은 소프트웨어 시스템, 서버, 네트워크 등의 IT 인프라 구성에 고도의 부하를 가하여 성능을 평가하는 도구입니다. 이러한 도구는 시스템이나 애플리케이션의 안정성, 오류 처리 능력, 그리고 최대 성능 용량을 테스트하는 데 사용됩니다. 주로 시스템의 한계점을 찾아내거나, 과부하 상황에서의 행동을 관찰하여 시스템을 개선하기 위한 중요한 정보를 제공합니다.

스트레스 테스트 도구에는 다양한 종류가 있습니다. 오픈 소스부터 상용 도구까지 다양하며, 각 도구마다 고유한 특징을 가지고 있습니다. 기존에 사용하던 익숙한 도구를 활용하는 것도 좋은 방법입니다. nGrinder는 오픈 소스 도구로, 다양한 기능을 제공하며 사용자 친화적인 인터페이스를 가지고 있습니다. 이를 활용하면 효과적인 스트레스 테스트를 수행할 수 있습니다.

nGrinder를 선택한 주요 이유는 다음과 같습니다:

• 강력한 기능 : 대규모 네트워크에서 복잡한 데이터베이스 쿼리를 실시간으로 모니터링하고 분석할 수 있습니다.
• 유연성 : Java와 Python 기반 스크립트를 지원하며, 다수의 에이전트를 동시에 관리할 수 있습니다.
• 실제 환경 시뮬레이션 : 대규모 가상 사용자를 생성하여 실제 운영환경의 다양한 시나리오를 테스트할 수 있습니다.
• 사용 편의성 : 직관적인 웹 인터페이스로 테스트 구성 및 모니터링이 용이합니다.
• 풍부한 자료 : 국내 개발자 커뮤니티에서 활발히 사용되며, 글로벌 사용자들의 레퍼런스도 쉽게 접근 가능합니다.

nGrinder는 다음과 같은 구성요소를 가집니다.

• 사용자(User) : 가상의 테스트 주체
• nGrinder 컨트롤러 : 테스트 스크립트를 관리 및 에이전트 조정
• 에이전트 컨트롤러 및 에이전트 : 실제 부하를 생성 및 테스트 실행
• 타겟 서버 및 모니터 : 테스트 대상 시스템 및 모니터링

테스트 아키텍처 및 구성

MySQL 5.7에서 8.0으로의 업그레이드는 철저한 사전 검증이 필요합니다. 이를 위해 동일한 환경에서 버전만 다른 RDS를 구성하여, 데이터베이스 버전 변경 외의 변수를 최소화해야 합니다. 또한 DB Connector의 변경 가능성을 고려하여 필요한 수정 사항도 반영해야 합니다.

테스트 환경 구성을 위해 일반적인 애플리케이션 구조를 고려한 아키텍처를 사용했습니다. 만약 현재 서비스 중인 환경에 Replica나 스테이징과 같은 안전한 테스트 환경이 있다면, 아래 제시된 구조를 참고하여 유사하게 구성할 수 있습니다.

<그림1. 테스트 아키텍처>

테스트 아키텍처를 구성하고 있는 구성요소는 아래와 같습니다.

애플리케이션 서버

• EC2 인스턴스 (m5.xlarge)
• Spring Boot 3.2.3 & MyBatis
• Java 17
• MySQL JDBC Driver (Connector J, 8.0.x)

데이터베이스

• Amazon RDS for MySQL (r6g.large)
• MySQL 5.7 및 8.0 버전

nGrinder

• EC2 인스턴스 (m5.xlarge)
• 버전 5.9
• Java 11

데이터 준비

테스트에 사용할 데이터 셋으로 Kaggle의 “Amazon Book Reviews” 데이터를 사용했습니다. 기본 데이터세트는 두 개의 테이블을 가지고 있기 때문에 다섯 개의 테이블로 정규화하고 적은 양의 데이터로 부하를 발생시키기 위해 별도의 인덱스는 생성하지 않았습니다.

<그림2. 정규화를 진행한 Amazon Book Reviews 스키마 다이어그램>

시나리오 구성

nGrinder를 사용한 테스트 시나리오는 CRUD 작업, 복잡한 쿼리 성능 검증, 동시성 및 스트레스 테스트 등 다양합니다. 각 시나리오는 실제 운영 환경의 요구사항을 반영하여 설계되며, 이를 통해 데이터베이스의 성능 지표를 측정하고 최적화 방안을 도출할 수 있습니다. 테스트에 활용한 주요 시나리오는 다음과 같습니다.

1. Simple Read
2. Simple Join
3. Heavy Join
4. Aggregation
5. Subquery

nGrinder는 내장된 SVN과 외부 Git을 지원하며, 사용자가 Groovy나 Jython으로 작성한 스크립트를 저장하여 위의 시나리오를 미리 준비할 수 있습니다. 각 스크립트는 애플리케이션의 단일 API 호출부터 복합 실행까지 다양하게 구성할 수 있습니다.

만약 Groovy와 Jython에 익숙하지 않더라도 Amazon Bedrock과 같은 생성형 AI를 활용하여 필요한 코드를 쉽게 작성할 수 있습니다. 또한 “@BeforeThread”, “@Before” 등의 어노테이션을 활용하여 스크립트 실행 단계를 적절하게 분리할 수 있습니다.

<그림3. nGrinder Script 작성 화면>

테스트 실행 및 결과

사전에 Groovy 또는 Jython으로 작성한 스크립트는 “Performance Test(성능)” 탭에서 “테스트 생성” 기능을 통해 불러올 수 있습니다. 생성된 테스트는 완료 후에도 결과를 확인할 수 있으며, 필요시 재실행이 가능합니다. 이를 통해 지속적인 성능 모니터링과 비교 분석이 가능합니다.

기본 설정의 주요한 몇 가지 구성요소는 다음과 같습니다.

1. Agent : 스크립트 정의를 직접 실행할 주체이며, 사용자가 미리 설치하여 nGrinder Controller와 연동된 개수만큼 최대로 설정할 수 있습니다.
2. Vuser per agent : 각 에이전트당 시뮬레이션할 가상 사용자 수를 설정합니다. 원하는 수치를 입력하게 되면 자동으로 Process와 Threads가 세팅되는데, Process 혹은 Threads의 수치를 변경할 경우 Vuser의 수치도 자동으로 반영됩니다.
3. Duration : 테스트 스크립트를 반복 실행할 횟수를 지정합니다. 이 시간동안 테스트 횟수의 제한은 없습니다.
4. Run Count : 테스트 스크립트를 반복 실행할 횟수를 지정합니다. 최대 지정 가능한 수치는 10,000개 입니다.
5. Ramp-Up : 이번 테스트에서는 사용하지 않았지만, 가상 사용자 수를 점진적으로 증가시키는 방식을 세부적으로 조정할 수 있습니다.

이러한 설정들을 통해 사용자는 다양한 부하 시나리오를 시뮬레이션하고, 시스템의 성능을 정밀하게 테스트할 수 있습니다.

<그림 4. nGrinder 테스트 구성>

테스트가 완료되면 아래의 화면과 같이 Performance, Mean Test Time, Mean Time to First Byte, Vuser, Error와 같은 세부 그래프와 통합 결과를 확인할 수 있으며, 각 agent에서 발생한 로그를 다운받을 수 있습니다.

<그림 5. nGrinder 리포트>

동일한 인프라 구성에서 MySQL 5.7과 8.0 각각에 대해 시나리오별 부하 테스트를 진행했습니다. 대부분의 경우, 유사한 성능 그래프를 보였으나, 일부 케이스에서 차이가 발견되었습니다. 성능 차이가 큰 경우에는 여러 차례 테스트를 반복하고, 그 결과에 따라 정확한 원인 파악 및 필요한 조치를 취해야 합니다.

이번 테스트는 간단한 구성, 적은 양의 데이터, 제한된 쿼리로 진행되어 비교적 유사한 성능을 보였습니다. 그러나 실제 운영 중인 서비스에서는 버전 변경에 따른 예약어 변화, Temp Table 변경 등 다양한 요인으로 성능 차이가 발생할 수 있습니다. 따라서 실제 환경을 반영한 다양한 시나리오를 작성하여 철저한 테스트를 수행할 것을 강력히 권장합니다.

<그림 6. 각 DB버전에 대한 부하 테스트>

성능 모니터링 및 분석

nGrinder를 통한 테스트 진행 시, RDS에서 제공하는 Performance Insight를 함께 활용하는 것이 좋습니다. 다만, 기존에 사용 중인 다른 DB 모니터링 툴이 있다면 그것을 사용해도 무방합니다.

Performance Insight는 DB의 다양한 성능 지표를 모니터링 하며, 특히 높은 부하를 유발하는 쿼리를 식별하고 Average active Sessions (AAS), CPU 사용률 등의 세부 정보를 기록합니다. 또한 Amazon DevOps Guru for Amazon RDS를 활용하면 리소스에 대한 자동화된 권장 사항을 제공받을 수 있어, 성능 개선을 위한 최적의 조치 방안을 파악할 수 있습니다. 이를 통해 데이터베이스 성능 최적화에 대한 모범 사례를 적용할 수 있습니다.

<그림 7. Amazon RDS Performance Insight>

주요 고려 사항 및 팁

MySQL 5.7에서 8.0 버전으로의 업그레이드는 단순 버전 업데이트 이상의 의미를 가집니다. 새로운 기능과 개선 사항을 제공하며, 호환성과 성능에 중대한 변화를 가져올 수 있습니다. 메이저 버전 업그레이드를 수행할 때 고려해야 할 주요 사항과 유용한 팁을 몇 가지 정리하였습니다.

고려 사항

1. 호환성 문제 확인
2. 데이터 타입 및 인덱스 변경
3. 문자셋(Character Set)과 콜레이션(Collation)
4. 시스템 변수 및 설정
5. 예약어 관련 변경

업그레이드 팁

1. 테스트 환경에서 시작하기
2. 테스트 계획 수립
3. 백업 계획 수립
4. 점진적 업그레이드 고려
5. 공식 문서와 커뮤니티 활용

결론

AWS와 nGrinder를 활용한 MySQL 데이터베이스 업그레이드 및 성능 최적화 전략은 주요 변경 사항의 안정성을 크게 향상시킵니다. 이 체계적인 접근 방식은 수동 테스트에서 간과될 수 있는 오류를 발견하고, 실제 환경과 유사한 스트레스 테스트를 통해 잠재적 문제를 신속히 식별하고 해결함으로써 서비스 장애를 사전에 방지합니다.

데이터베이스 업그레이드 시 안정성을 확보할 수 있는 방법으로 Amazon Aurora는 Blue/Green Deployment 기능을 제공합니다. 이 기능을 활용하면 기존 데이터베이스와 동일한 환경을 쉽게 구성하여 사전 테스트를 수행할 수 있습니다. CQRS 패턴이나 Route53 트래픽 흐름 및 정책을 활용한 Blue/Green Deployment 환경 테스트 방법에 대해 더 자세히 알고 싶다면, “Amazon Aurora Blue/Green Deployment를 활용하여 애플리케이션 계층을 포함한 데이터베이스 변경 사전 테스트하기“를 참고하시기 바랍니다.

이 블로그를 통해 데이터베이스 업그레이드 및 변경, 성능 최적화에 대한 실용적인 접근 방식을 소개해 드렸습니다. 이러한 방법들이 여러분의 데이터베이스 관리에 도움이 되기를 바랍니다.