RDS Proxy!! Maxscale 오픈소스 전환

오픈 소스인 Maxscale 전환 과정을 얘기하기에 앞서 간략히 기존 RDS Proxy를 적용한 이유에 대해 말씀드리겠습니다. AuroraMysql의 경우 Cluster Endpoint(RW, RO) 가 존재하여 해당 엔드 포인트를 통해 로드밸런싱, Failover 등을 지원하고 있습니다. 하지만 Cluster Endpoint의 경우 DNS TTL Time이 5초 정도로, 이때 순간적으로 트래픽이 발생하면 RO 노드들에 대한 분배가 원활히 되지 않습니다. 저희 팀에서 이러한 문제를 해결하고자 connection pool(Hikari) -> Aurora Protocol -> RDS Proxy 까지 많은 과정을거쳐왔습니다. 이제 한 단계 더 나아가 RDS Proxy에서 오픈 소스인 Maxscale로 전환한 이야기를 해보려합니다. 검토 배경 처음 오픈 소스를 검토하게 된 목적은 다음 세가지입니다. 밸런싱 깨짐현상 엔드 포인트 변경 작업 최소화를 통한 리소스 낭비방지 RDS Proxy 대비 낮은비용 기존 RDS Proxy가 적용되어 있는 모듈의 DB는 평소에는 CPU 사용률이 30% 이하로 높지 않습니다. 하지만 순간적으로 트래픽이 많이 유입되어 사용률이 올라가면 AutoScaling과 Scale-in 작업이 반복되는DB입니다. 이때 문제점은 Scale-in 작업 시에발생했습니다. CPU Connection 위의 사진처럼 CPU 사용률을 보면, 트래픽이 여러 RO 중 일부 노드로만 몰려 특정 노드들 간의 CPU 차이가 70% 이상 나는 것을 확인할 수있습니다. 이러한 현상이 발생했던 이유는 앞서 말씀드린 대로 Aurora Cluster Endpoint의 DNS TTL Time이 5초 정도이고, 이때 순간적으로 트래픽이 발생되면 RO 노드들에 대한 분배가 되지 않아 RDS Proxy를 적용했었지만 RDS Proxy의 경우 custom endpoint가 별도로 존재하지 않아 scale in 작업 시 사용이불가능했습니다. 또한, Scale-in 작업을 위해서는 WAS의 엔드포인트 변경이 필요합니다. 하지만 운영 환경에서 엔드포인트를 변경하는 작업은 사용률이 안정화되더라도 바로 진행할 수 없고, 일정을 협의하여 진행해야 하기에 리소스 낭비가발생했습니다. 마지막으로는 비용입니다. RDS Proxy의 경우 VCPU 당 비용이 발생합니다. 저희가 RDS Proxy를 도입했던 이유는 RO의 밸런싱 때문이지만 추후에 발생할 수 있는 페일오버(failover)까지 고려해야 하기에 RW에 사용되는 비용, 그리고 위에서 언급한 즉각적인 Scale-in이 불가능하여 발생하는 Scale-out 노드의 VCPU 비용 등 낭비되는 리소스가 많다고 판단되었습니다. 최종적으로 Maxscale이라는 오픈 소스로 전환을 검토하여 적용하게되었습니다. Maxscale 이란? 데이터베이스 프록시 (Database Proxy). Query Routing & Splitting. 모니터링을 통한 고가용성 관리 (High availability) 유연한 확장성 (Scalability) 높은 보안성 유지 (Security) RDSProxy vs Maxscale 장단점 RDS Proxy의 경우 Managed Service이기에 관리성이 편리하지만 빈번한 Scale in 작업, RDS 에만 적용 가능 제약 사항 등으로 인해 충분히 Maxscale 적용을 고려해 볼 수있었습니다. 검토 사항 및 테스트시나리오 라이선스(현재 2.2.21 까지 GPL로 전환, 2.1 버전부터 aurora지원) TPS 벨런싱 성능 scale in시 벨런싱 유지 및 autoscaling 가능여부 failover 테스트 포트 제약여부 Maxscale 가용성스펙 모듈에 맞는 Maxscale 설정 값수립 테스트 진행 방식은 별도의 테스트 장비 -> 작은 모듈 -> 본 적용 순으로 진행하였으며, 추후에는 RDS뿐만 아니라 설치형 MySQL까지 적용할 수있었습니다. 밸런싱 성능 및 TPS테스트 TPS의 경우 RDS Proxy의 가이드에서도 5% 정도의 차이가 발생할 것이란 가이드를 받았었습니다. 테스트 상황에서도 크게 차이가 안 되는 것을 확인할 수 있었고 cpu, connection 밸런싱 분배가 잘 되는 것을 확인 할 수있었습니다. Scale in시 밸런싱 유지 및 Autoscaling 가능여부 Maxscale을 사용하며 Scale in을 진행할 수 있어 밸런싱 유지가 가능하였지만 Maxscale의 경우 클러스터 엔드 포인트를 지원하지않았습니다. 그 이유로 서는 다음과같습니다. Aurora Monitor Maxscale에서 지원하는 auroramon이라는 모듈을 사용하여모니터링. Aurora는 데이터를 복제하지 않기 때문에 표준 MySQL 복제 프로토콜을 따르지않음. 모니터링 방법 각 노드에는 고유식별자인 aurora_server_id가 존재. information_schema.replica_host_status 테이블에 aruroa_server_id에 대한 정보확인 Maxscale이 인스턴스 엔드 포인트만 지원이가능하여 해당 문제를 해결하고자 Autoscaling과 같은 트리거를 캐치할 수 있도록 별도로 아키텍처를 구성하고 자동화 스크립트를 구현하여 Autoscaling에도 대응이 가능할 수 있도록하였습니다. Failover 테스트 현재 Maxscale의 경우 RO에 대한 분산이기에 failover에 대한 자동화 기능도 추가하여해결하였습니다. Maxscale 가용성스펙 처음 사용하는 것이다 보니 처음엔 사용치를 추정할 수밖에 없어 작은 모듈부터 적용하며 스펙을 줄여 나갈 수밖에없었습니다. 그러다 보니 처음엔 m5.2xlarge -> m5.xlarge -> c5.xlarge 등등 현재는 DB에 들어오는 트래픽을 Maxscale이 받아 주기에 네트워크 트래픽까지 고려하여 c5n.xlarge로 최종적으로 적용할 수 있었습니다. 생각보다 많은 사용률을 보이지는않았습니다 포트 제약여부 기존 RDS Proxy의 경우 3306포트만 가능한 포트 제약이 있었습니다. 하지만 Maxscale의 경우 3306외에도 다른 포트들로 변경이 가능하여 진행되는데 이상이없었습니다. 결과 적용된 현재까지 CPU나 connection 수치는 어느 정도 일정한 것을 확인할 수 있었습니다. 또한 RDS Proxy를 제거함으로써 연간 비용 절감을 크게 할 수있었습니다. CPU Connection 이뿐만 아니라 기존 설치형 Mysql의 경우에도 순간 적으로 트래픽이 몰려 밸런싱이 맞지 않은 DB에 적용하여 개선할 수도있었습니다. 세션이 일부 DB에만 트래픽이 몰려 지연이 발생하던 현상을 트래픽 분산을 시켜줄 수 있게 됨으로 써 지연 문제를 해결할 수있었습니다. 설치형 Mysql AS-IS Active Session CPU TO-BE Active Session CPU 회고 이번 RDS Proxy -> Maxscale로 전환을 하며 많은 것들을 배울 수 있었습니다. 현재 저희가 설정되어 있는 WAS 설정값들부터 스펙 산정, POC를 할 때 고려해야 하는 상황 등 여러 상황들을 경험하며 성장할 수 있는 좋은 기회였다고생각합니다. 지금까지 롯데 ON의 Maxscale 오픈소스 전환 프로젝트 경험을 공유드렸습니다. 추후 aurora의 밸런싱 깨짐 현상을 경험하여 문제 해결을 위해 도입 검토를 하시는 분들께 도움이 되셨으면 좋겠습니다.이상입니다. RDS Proxy!! Maxscale 오픈소스 전환 was originally published in 롯데ON 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.