MySQL 5.7은 현재 70% 더 비싸다
AWS 비용절감 시리즈
어쩌면 매달 약 $5000 넘는 금액을 더 지출하고 있을지도 모릅니다.
혹시 AWS RDS에서 MySQL 5.7 버전을 운영 중이라면 이 글을 꼭 보셔야 합니다. 지금 이 순간에도 의도치 않은 비용이 나가고 있을 수 있습니다. 저희 조직의 사례를 보면 2024년 12월 1일부터 원래 서버 사용비의 약 70%가 단지 MySQL 5.7을 사용하고 있기 때문에 발생했습니다. ‘버전을 미처 올리지 못했다’는 이유로 70%의 추가 비용이 발생한 거죠. 해결법은 오직 MySQL 8.0으로 버전업을 하는 것 뿐입니다.
AWS 비용을 절감하기 위해서는 AWS의 정책을 꼼꼼하게 살펴야 합니다. AWS RDS 및 Aurora MySQL 5.7 사용자는 2024년 12월부터 Extended Support 비용이 발생합니다. 이 비용은 인스턴스의 vCPU 수에 따라 과금되며, RI(예약 인스턴스)나 Savings Plan을 적용해도 무관하게 금액이 추가로 부과됩니다. 따라서 비용 절감을 위해 MySQL 8.0 이상으로의 업그레이드가 필요합니다.
Extended Support 비용 발생 이유
MySQL 5.7은 2023년 10월 31일에 커뮤니티 지원이 종료되었습니다. 이 뜻은 더 이상 업그레이드, 보안 패치가 없으므로 보안 취약점에 잠재적 노출 위험이 있습니다. AWS는 2024년 10월 31일까지 표준 지원을 제공합니다. 이후에는 Extended Support로 전환되어 추가 비용이 발생합니다.
https://aws.amazon.com/ko/rds/mysql/pricing/
위 내용을 보면 vCPU 시간당 금액이 나와 있습니다.
과금 시작일: 2024년 12월 1일
과금 기준: vCPU당 시간별 요금
2026년 2월 28일까지 $0.10 per vCPU-hr
2026년 3월 1일부터 $0.20 per vCPU-hr
실제로는 지금 vCPU-hr당 $0.12가 지출되고 있습니다. 예를 들어, db.r6i.2xlarge 인스턴스(8 vCPU)를 24시간 운영할 경우, 월 추가 비용은 약 $714.20입니다. db.r6i.2xlarge의 월 비용은 $1022로 현재 기준으로 지원비용은 월 서버비의 70%에 달합니다. 1년이면 1400원 환율로 1700만원입니다. 처음엔 단순한 유지비라 생각했지만, 알고 보니 ‘지나치게 비싼 연장요금’이었습니다.
아래는 실제로 저희 조직에서 발생했던 서비 유지 비용입니다. Cost Explorer에서 비용을 확인할 수 있습니다. 필터를 서비스 - RDS, 사용량 유형 - APN2-ExtendedSupport:Yr1-Yr2:AuroraMySQL2로 설정하면 확인할 수 있습니다.
2025년 12월 1일부터 요금이 과금되기 시작한 걸 알 수 있습니다. 2025년 1월 경 Read Instance를 한대를 줄이면서 과금이 줄기 시작했고 2월 초 MySQL 8.0 버전업을 완료하면서 더 이상 비용이 부과되지 않는 것을 확인할 수 있습니다.
시간당 $0.1에 이 부분을 간과했다가 큰 비용이 나갈 수 있습니다. 리소스의 vCPU당 계산이라는 점, 그리고 월 비용으로 따지면 1시간 x 24 x 31을 하게 됩니다.
MySQL 8.0 이상으로 업그레이드하는 방법
AWS는 Aurora MySQL 2.x (MySQL 5.7 기반)에서 Aurora MySQL 3.x (MySQL 8.0 기반)로의 인플레이스 업그레이드를 아래와 같은 방법으로 지원합니다. 일반적으로 MySQL을 버전업하기 위한 준비가 다 마친 상태라면 아래와 같은 절차를 따르면 됩니다.
업그레이드 절차
업그레이드 진행 전 사전 점검 수행: AWS는 업그레이드 전 자동으로 호환성 검사를 수행합니다. 여기에서 발생하는 문제가 있다면 선행적으로 해결해야 합니다. 따라서 본격적으로 AWS를 업데이트 하기 전에 현재 사용하는 인스턴스를 기반으로 새로운 인스턴스를 생성한 뒤 버전업을 사전에 테스트해봐야 합니다. 호환성 검사: AWS의 호환성 검사 외에도 어플리케이션 단에서 사용하는 쿼리 등에서 문제가 발생할 수 있습니다. 5.7과 8.0의 차이를 살펴본 뒤 발생 가능한 문제를 어플리케이션 단에서도 수정이 되어야 합니다.
업그레이드 진행 시 파라미터 그룹 준비: 새로운 버전에 맞는 파라미터 그룹을 생성합니다. 콘솔에서 업그레이드 실행: RDS 콘솔에서 클러스터를 선택하고, “수정”을 클릭하여 새로운 엔진 버전을 선택합니다. 적용 시점 선택: 즉시 적용하거나 다음 유지 관리 창에서 적용할 수 있습니다.
업그레이드 진행 후 업그레이드 진행 모니터링: 업그레이드 진행 상황을 모니터링하고, 완료 후 애플리케이션 테스트를 수행합니다. 모든 기능이 정상적으로 동작하는지 보는 것이 좋습니다. 만일의 상황을 대비해 롤백을 할 수 있도록 기존 데이터베이스를 반드시 백업해 두고, 롤백 리허설을 미리 해보는게 좋습니다.
주의사항
다운타임 발생: 업그레이드 중에는 클러스터가 재시작되므로, 일정 시간 동안 서비스 중단이 발생할 수 있습니다. 따라서 사용자가 적은 시점에서 실행할 필요가 있고 부득이한 경우 서비스 점검 공지를 해야 합니다.
파라미터 그룹 재설정: 기존 파라미터 그룹은 새로운 버전과 호환되지 않을 수 있으므로, 새로운 파라미터 그룹을 생성하여 적용해야 합니다.
데이터 볼륨: 대용량 데이터베이스일수록 마이그레이션 시간과 리소스가 많이 소요되니 미리 테스트를 해보고 마이그레이션 시간을 확인 후에 운영 플랜을 짜는 것이 좋습니다.
업그레이드 시 데이터 마이그레이션 방법
MySQL 업그레이드를 하면서 기존에 사용하던 데이터를 온전히 마이그레이션해야 합니다. 크게 아래 3가지 방식이 있는데 보통 인플레이스 업그레이드가 가장 쉬운 방식이라 추천을 드리고 있습니다.
인플레이스(In-place) 업그레이드
AWS에서 자체 지원하는 방식으로 Aurora에서만 가능합니다. Aurora MySQL 2.x에서 3.x로 직접 업그레이드하는 방식으로 데이터 마이그레이션 없이 업그레이드합니다. AWS에서 5.7과 8.0 사이의 호환성 검사를 위해 Prechecks을 자동으로 수행하게 됩니다. 다운타임이 발생할 수 있습니다. 가장 간단한 방법이라 할 수 있습니다.
논리적(Logical) 업그레이드
mysqldump를 사용해 전체 데이터를 백업 후 신규 MySQL 8.0에 복원하는 방식입니다. 가장 긴 다운타임이 발생 가능합니다. 가장 호환성이 뛰어나고 어렵지 않지만 대량 데이터를 이전할수록 성능 저하와 긴 다운타임 문제가 있을 수 있습니다. 인스턴스를 완전히 새로 구성하기 때문에 스키마/인덱스도 새로 정의도비니다. OS/플랫폼 변경을 염두에 두고 있다면 유용할 수 있습니다.
복제를 통한 업그레이드
MySQL 5.7을 마스터로 설정 후, MySQL 8.0을 슬레이브로 구성하여 동기화하는 방식입니다. 데이터는 5.7에서 8.0으로 실시간 정송되며 두 데이터베이스가 동시에 살아있습니다. 동기화가 완료되면 어플리케이션 연결을 8.0으로 전환해 마이그레이션이 완료됩니다. 무중단 전환이 가능하지만, 설정이 복잡하고 버전 호환성에 유의해야 합니다.
결론
Aurora MySQL 5.7을 계속 사용할 경우, Extended Support 비용이 지속적으로 발생합니다. 비용 절감과 최신 기능 활용을 위해 MySQL 8.0 이상으로의 업그레이드를 권장합니다. 업그레이드 전에는 충분한 테스트와 사전 검토를 통해 서비스 중단을 최소화해야 합니다.
가장 큰 문제는 MySQL 8.0이 5.7과 호환성 차이가 있다는 것입니다. 애플리케이션의 SQL 문법, 데이터 타입 등을 사전에 검토해야 합니다. 그리고 MySQL 8.0에서 장애가 발생할 수 있는 여지를 미리 충분히 테스트한 뒤에 실행해야 합니다. 다음 글에서는 실제 MySQL 버전업을 진행한 사례에 대해 글을 공유하겠습니다.
FinOps 커뮤니티에 함께 하실래요?
저는 최근 48%, $36000의 AWS 비용절감을 달성했습니다.
클라우드 비용을 효율화하고 싶은 분들, 비슷한 고민을 나누고 싶다면 제가 운영 중인 AWS-FINOPS-KR Slack 커뮤니티에 참여하세요. 실제 절감 사례, 질문, 전략 공유를 나누실 수 있습니다.
