운영중인 레거시 시스템은 업체마다 스키마 세트가 생성되기에 업체가 지속적으로 증가해 MySQL 서버 하나에 90만개의 테이블이 생성되어 opend_tables 지표가 증가하여 부하를 일으키는 문제가 발생합니다. 운영중인 MySQL 버전은 5.7이였으며 opend_tables 지표가 어떤 시점에서 증가하는지에 대한 정확한 자료가 없었기에 소스코드 분석이 필요했습니다. 이를 통해 MySQL이 테이블을 여는 방식 및 대용량의 테이블 스키마가 존재할 경우 어떤 방식으로 Table Cache 관련 파라미터들을 튜닝해야하는지 정확히 파악할 수 있었습니다.
참고 : MySQL이 테이블을 열고 닫는 방법
innodb_buffer_pool_size 가 DB 메모리 사이즈 대비 현저히 낮은 수준으로 운영되고 있었으며 파라미터 수정 후 Select, Insert Latency 가 각각 16%, 45% 감소하였습니다.
수동 발송 기능 사용 시 과도한 IN 절에 걸리는 id 값이 길어지면서 전체 쿼리 사이즈가 커지고 이로 인해 발송 시 Table Full Scan이 진행되면서 특정 구간에서 Update Latency가 과도하게 증가하여 range_optimizer_max_mem_size 파라미터 튜닝을 통해 지연을 해소하여 결과적으로 기존 30만건 발송 시 30분이 소요되는 것을 10분내 55만건 발송 처리가 가능하도록 개선하였습니다.
또한 aurora mysql 2.02 버전의 인스턴스를 2.07 버전으로 올리면서 Commit Latency 가 약 50% 정도 개선되어 전체 서비스의 발송 성능이 기존 대비 약 550%가 향상되었습니다.
운영 중인 RDS 서버 34%(large 기준 77대)를 축소하여 억단위의 비용 절감을 가져올 수 있었으며 단순히 서버의 사이즈를 줄인 것이 아니라 CPU 사용량을 기준으로 사용량 대비 고스펙의 인스턴스 Scale Down을 진행하였습니다. CPU 사용량이 50%가 넘어가는 인스턴스도 엔진 업그레이드, r4 → r5 계열로의 전환, 쿼리 튜닝 등을 통해 CPU 사용량을 8%까지 감소시킨 후 Scale Down 을 진행하였습니다.
CPU 사용량이 현저히 낮고 Slow Query가 없었음에도 8xlarge → 4xlarge 인스턴스를 줄이면서 문제가 발생하는 쿼리가 발생하였고 모니터링과 빠른 대응을 통해 서비스에 영향도 없이 이슈를 해결할 수 있었습니다.
이러한 경험을 통해 클라우드 환경에서 유연한 환경 구성의 장점을 최대한 활용하여 비용과 비즈니스에 맞는 서비스 성능의 균형을 맞추는 FinOps 경험을 할 수 있었습니다.