BLOG
Amazon RDS 프록시의 장점 중 하나는 데이터베이스 장애 조치 후 애플리케이션 복구 시간을 단축시킬 수 있다는 것입니다. RDS 프록시는 MySQL 및 PostgreSQL 엔진을 모두 지원하지만 오늘 블로그 포스팅에서는 MySQL 테스트 워크로드를 사용하여 RDS 프록시로 장애 조치 후 클라이언트 복구 시간을 Amazon Aurora MySQL의 경우 최대 79 %, MySQL용 Amazon RDS의 경우 최대 32 %까지 단축시키는 방법을 보여드리려 합니다. 더불어 RDS 프록시가 어떻게 작성자 전환 문제를 방지하고 차선의 클라이언트 구성을 복구하는지 설명해 드리며, 장애 조치를 통해 유휴 연결을 유지함으로써 활성 연결 모니터링을 통한 계획 및 계획되지 않은 장애 조치 및 클라이언트 연결 풀에 대한 RDS 프록시 이점을 알려드리겠습니다. 마지막으로는 클라이언트 구성에 대한 모범 사례를 제공해 드릴 예정입니다.
배경
RDS 프록시는 MySQL / PostgreSQL 및 Aurora MySQL / PostgreSQL 데이터베이스용 Amazon RDS를 지원합니다. 데이터베이스에 대한 응용 프로그램의 액세스를 관리하고 연결 풀링, 멀티플렉싱 및 정상적인 페일 오버를 제공합니다. 데이터베이스 연결 제한을 넘어 확장하고 응용 프로그램의 연결 및 요청을 관리할 수 있습니다. 이 게시물에서는 RDS 프록시의 장애 조치 이점에 중점을 둡니다.
기본 데이터베이스 인스턴스에 액세스할 수 없고 다른 인스턴스가 새 기본 인스턴스로 넘어가면 장애 조치가 발생하고 이로 인해 클라이언트 연결이 중단됩니다. 장애로 인해 페일오버 발생 시 롤링 업그레이드와 같은 관리 조치에 의해 유도되거나 계획되지 않은 장애로 인한 경우에는 장애 조치를 계획할 수 있습니다. 두 경우 모두 클라이언트 중단을 최소화하기 위해 다운타임을 감소시키고자 할 것입니다.
Amazon RDS에는 여러 고 가용성 옵션이 있으며 RDS 프록시는 각 옵션에 대한 페일 오버 복구 이점을 제공합니다. Amazon RDS 다중 AZ 옵션은 동기식 복제가 포함된 기본 및 대기 구성입니다. Aurora는 최대 15개의 비동기 복제본과 다중 마스터의 두 가지 고 가용성 옵션을 제공합니다. 모든 Aurora 복제본은 읽기 전용 액세스가 가능합니다. 데이터 손실 없이 페일 오버가 발생하는 경우 모든 복제본을 클러스터의 새로운 기본 노드로 선택하고 선택할 수 있습니다. Aurora 다중 마스터는 여러 활동을 제공합니다.
이러한 모든 옵션을 사용하여 장애 조치가 발생하면 클라이언트는 연결 실패를 감지하고 새 기본을 발견한 후 가능한 빨리 재연결해야 합니다. RDS 프록시를 사용하면 응용 프로그램에서 장애 조치와 관련된 복잡성을 피하고 3초 이내에 빠른 복구를 경험할 수 있습니다. 장애 조치가 더 빠른 Aurora의 경우 DNS 전파 지연이 전체 장애 조치 시간의 가장 큰 원인입니다. RDS 프록시는 적극적으로 데이터베이스 인스턴스를 모니터링하고 클라이언트를 올바른 대상에 자동으로 연결합니다. 또한 삭제하지 않고 데이터베이스 장애 조치를 통해 유휴 클라이언트 연결을 유지 관리합니다. 이 컨텍스트에서 유휴 연결은 미해결 요청이 없는 연결입니다.
Aurora 장애 조치
RDS 프록시를 통한 Aurora 클러스터 연결과 Aurora 클러스터 연결 간의 장애 조치 시간을 100회 비교한 내부 테스트 결과는 크게 개선되었습니다.
다음 표는 이러한 결과를 밀리 초 단위로 요약합니다.
| 테스트 | 최소 | 맥스 | 평균 | 프록시 장점 |
| Aurora를 사용한 RDS 프록시 | 1,667 | 15,511 | 3,138 | 87 % |
| MariaDB 드라이버를 사용하여 Aurora로 직접 | 9,720 | 31,491 | 24,037 |
RDS 프록시를 사용한 평균 장애 조치 시간은 MariaDB 드라이버를 사용하여 데이터베이스에 직접 연결할 때 24 초가 아닌 3.1 초였습니다. 이는 87 % 개선된 결과입니다.
3초의 장애 조치 중단은 관계형 데이터베이스, 심지어 기본 벤치 마크에서도 효과적이며 Aurora 혁신의 결과라고 할 수 있습니다. 그러나 장애 조치 시간을 줄이기 위한 최적화 기능이 포함된 권장 MariaDB Aurora 드라이버조차도 Aurora의 모든 이점을 경험하기에 충분하지 않다는 것도 분명합니다. 현재 병목 현상이 클라이언트 드라이버가 데이터베이스만큼 빠르게 복구할 수 있기 때문에 빠른 Aurora MySQL 장애 조치를 최대한 활용하려면 RDS 프록시가 필요합니다.
DNS 시간
다양한 방법으로 클라이언트 드라이버를 조정할 수 있습니다. 예를 들어 MariaDB ConnectorJ 드라이버에는 거의 100 개의 구성 설정이 있습니다. OS, JVM 및 연결 풀 프레임 워크에는 더 많은 구성 옵션이 있습니다. 이 게시물은 DNS 클라이언트 캐시 구성으로 시작하여 가장 중요한 내용을 다룹니다.
클라이언트는 DNS 이름을 사용하여 데이터베이스에 연결할 때 먼저 DNS 서버를 쿼리하여 IP 주소로 확인해야 합니다. 그런 다음 클라이언트는 응답을 캐시합니다. 프로토콜에 따라 DNS 응답은 TTL (Time to Live)을 지정하며, 클라이언트가 레코드를 캐시해야 하는 시간을 결정합니다. RDS는 기본 TTL을 4초로 설정합니다. 그러나 많은 시스템이 다른 설정으로 클라이언트 캐시를 구현하고 TTL을 더 길게 만듭니다. OS 및 JVM 런타임 환경에는 모두 이러한 캐시가 있습니다. JVM의 캐시 설정은 버전 및 OS마다 다르므로 명시 적으로 설정하는 것이 중요합니다. 다음 코드는 권장 설정을 보여줍니다.
java.security.Security.setProperty(“networkaddress.cache.ttl” , “1”);
java.security.Security.setProperty(“networkaddress.cache.negative.ttl” , “1”);
이는 JVM에서 기본 DNS 캐싱을 줄이므로 드라이버는 장애 조치 중에 DNS 이름 IP 주소 변경을 더 빨리 발견 할 수 있습니다.
최적화된 클라이언트를 통한 장애 조치 벤치마킹
다음 벤치킹은 앞에서 설명한대로 DNS TTL 설정으로 최적화 된 클라이언트와 이 게시물에서 나중에 설명할 다른 권장 클라이언트 설정을 사용합니다. 다음 그래프는 최적의 설정으로 MariaDB 드라이버를 사용하고 RDS 프록시를 통해 Aurora MySQL에 직접 연결할 때의 장애 조치 시간을 비교합니다.
다음 표는 이러한 결과를 밀리 초 단위로 요약합니다.
| 테스트 | 최소 | 맥스 | 평균 | 프록시 장점 |
| 프록시 오로라 (MariaDB 드라이버) | 1,644 | 11,642 | 2,913 | 79 % |
| 다이렉트 오로라 (MariaDB Aurora 드라이버) | 5,146 | 30,782 | 13,783 |
잘 조정된 MariaDB 클라이언트를 사용하면 RDS 프록시 사용시 평균 페일 오버 시간이 2.9 초, 직접 연결 시 13.8 초 (RDS 프록시보다 79 % 향상)를 얻을 수 있습니다. 복구 시간의 향상은 특정 작업 부하에 따라 다릅니다.
Aurora 클라이언트 구성
위의 테스트에서는 권장되는 MariaDB ConnectorJ를 Aurora 특정 기능과 함께 사용했습니다. 특히 데이터베이스에 대한 직접 연결은jdbc:mariadb:aurora://<cluster-endpoint>
로 시작하는 연결 URL을 사용했습니다. 이를 통해 MariaDB ConnectorJ 드라이버는 Aurora 특정 시스템 테이블을 사용하여 기본 데이터베이스 인스턴스를 신속하게 발견할 수 있습니다. 자세한 내용은 MySQL 호환성을 가진 Amazon Aurora에서 MariaDB JDBC 드라이버 사용을 참조하세요. RDS 프록시를 통한 연결에는 jdbc:mariadb://<proxy-endpoint>와 같은 URL이 있는 바닐라 드라이버 기능이 사용되었습니다. 특별한 클라이언트 구성을 사용하지 않더라도 RDS 프록시는 장애 조치 시간을 최소화하는 데 더 효과적이었습니다. 더 간단한 클라이언트 로직을 사용하면 원하는 클라이언트를 사용할 수 있기 때문에 유리합니다.
Reader와 write 역할 전환
어떤 이유로든 기본 인스턴스를 사용할 수 없게 되면 Aurora는 자동으로 장애 조치를 수행합니다. 이 페일오버 중에 기본 인스턴스는 역할을 변경하고 리더가 되며 Aurora 클러스터의 리더 중 하나는 기본으로 변환됩니다. 클러스터 엔드 포인트에 직접 연결하는 경우 DNS 레코드가 캐시 되었기 때문에 클라이언트가 이전 기본 인스턴스에 다시 연결될 수 있습니다. 연결이 설정되더라도 클라이언트는 더 이상 기본 인스턴스가 아니며 읽기 전용 인스턴스로 지정되므로 인스턴스에 대한 쓰기를 수행할 수 없습니다. RDS 프록시는 항상 클라이언트를 현재 기본 서버에 연결하므로 이러한 오류를 제거합니다.
활성 모니터링 및 계획되지 않은 장애 조치
RDS 프록시는 페일오버를 위해 DNS 전파에 의존하지 않기 때문에 페일오버 개선이 가능합니다. RDS 프록시는 Aurora 클러스터 클라이언트에 대한 리더 및 라이터 전환 문제를 제거합니다. 클라이언트 대신 장애 조치 중에 빠르게 작동하도록 Aurora 데이터베이스 클러스터의 각 데이터베이스 인스턴스를 능동적으로 모니터링합니다.
지금까지 이 게시물에서는 계획 / 관리 장애 조치 시나리오의 가장 기본적인 시나리오에 대해 설명했습니다. Aurora의 경우 이러한 장애 조치는 AWS Management Console, API 또는 AWS CLI (AWS Command Line Interface)를 통해 인스턴스 크기를 변경하기 위해 주문형으로 시작하거나 Amazon이 사용자가 예약한 유지 관리 작업에 대해 장애 조치를 수행할 때 발생합니다. 이러한 모든 경우에 데이터베이스 프로세스가 준비되지 않은 경우 데이터베이스 호스트는 연결을 정상적으로 닫고 새 연결을 거부할 수 있습니다. 이는 클라이언트 또는 RDS 프록시가 문제를 쉽게 감지하고 다시 시도할 수 있음을 의미합니다.
하지만 호스트에 갑자기 연결할 수 없는 계획되지 않은 장애 조치 시나리오 또한 고려하셔야 합니다. 기존 클라이언트 TCP 연결은 열린 상태로 유지되며 클라이언트는 응답 부족으로 인해 연결이 끊어졌음을 감지해야 합니다. 이러한 시나리오를 처리하려면 소켓 제한 시간, 연결 제한 시간 및 TCP 연결 유지 구성에 대한 다음 우수 사례가 필요합니다. RDS 프록시는 계획되지 않은 장애 조치로 클라이언트를 지원할 수 있습니다.
RDS 프록시는 모든 데이터베이스 인스턴스를 모니터링하고 몇 초 내에 장애를 감지할 수 있습니다. 실패를 감지하면 RDS 프록시가 실패한 데이터베이스 인스턴스로 새 쿼리를 보내는 것을 중지합니다. RDS 프록시는 장애 조치 중에 트랜잭션 도중에 있지 않은 유휴 클라이언트 연결을 유지합니다. 즉, 풀에 비활성 연결이 있는 클라이언트 연결 풀은 모든 연결을 다시 만들지 않고도 장애 조치를 훨씬 더 정상적으로 처리할 수 있습니다. 이는 많은 유휴 TLS 연결을 다시 작성하는 오버 헤드로부터 클라이언트를 절약합니다. 또한 RDS 프록시는 실패한 데이터베이스 인스턴스에서 트랜잭션을 실행하는 도중에 있던 모든 클라이언트 연결을 사전에 종료하므로 클라이언트가 시간 초과를 기다리지 않고 빠르게 재 시도할 수 있습니다.
RDS 프록시는 항상 새 연결을 수락하고 새 기본을 사용할 수 있을 때까지 쿼리 전달을 지연시킵니다. RDS 프록시가 없으면 장애 조치가 발생하면 클라이언트는 기본 데이터베이스 인스턴스를 사용할 수 없음을 감지하고 즉시 다시 연결을 시도 할 수 있습니다. 기본 연결이 복구 중일 수 있으므로 이러한 재 연결 시도가 성공하지 못할 수 있습니다. 기본 복구로 다시 연결하려는 시도가 너무 많으면 다시 실패할 수 있습니다. 결과적으로 클라이언트는 적절한 대기 시간으로 재시도 로직을 구축해야 합니다. RDS 프록시를 사용하면 복잡한 재시도 로직을 구축해야 합니다.
Amazon RDS 다중 AZ
계획되지 않은 장애 조치의 영향을 완화하는 데 도움이 되는 RDS의 기능 중 하나는 Amazon RDS용 다중 AZ입니다. RDS MySQL에 대한 다중 AZ 구성을 사용하면 기본 데이터베이스 인스턴스는 하나의 가용 영역에 존재하고 동기 대기 인스턴스는 두 번째 가용 영역에 있습니다. 클라이언트 응용 프로그램이 데이터베이스에 연결하는 데 사용하는 기본 인스턴스를 가리키는 호스트 이름이 하나 있습니다. 장애가 발생하면 RDS 서비스는 기본 및 보조 인스턴스의 역할을 전환합니다. 또한 RDS 서비스는 데이터베이스 호스트 이름의 기본 IP 주소를 변경하여 클라이언트 응용 프로그램이 장애 조치 중에 연결 설정을 변경할 필요가 없도록 합니다.
Amazon RDS 다중 AZ를 사용하면 장애 조치 시 원래 기본 서버가 TCP 연결을 닫지 않습니다. 장애 조치가 시작된 후 클라이언트는 데이터베이스에서 더 이상 TCP 트래픽을 받지 않습니다. 대신 시간이 초과되는 것은 클라이언트에게 달려 있습니다. 모든 장애 조치에서 원래 기본 데이터베이스의 하드 펜싱을 고의적으로 선택하면 클라이언트는 계획된 장애 조치 및 계획되지 않은 장애 조치 중에 유사한 동작을 기대할 수 있습니다. 이는 Amazon RDS API 또는 CLI 를 통해 단순히 관리 페일 오버를 수행하여 계획된 페일 오버 시나리오와 계획되지 않은 페일 오버 시나리오를 모두 쉽게 테스트할 수 있다는 실질적인 이점이 있습니다. 그러나 많은 운영 체제뿐만 아니라 MariaDB 드라이버의 기본 설정이 이 시나리오를 처리하기에 부적절합니다. 기본적으로 MariaDB 드라이버는 응답 대기 시간을 초과하지 않으며 특정 운영 체제의 TCP 연결 유지 설정은 2 시간을 초과할 수 있습니다. 그러나 좋은 소식은 RDS 프록시를 사용하면 호스트 이름 (이 경우 RDS 프록시)의 기본 DNS 구성이 절대 변경되지 않기 때문에 이러한 설정이 더 이상 중요하지 않다는 것입니다.
RDS 다중 AZ 장애 조치 복구 벤치마킹
아래 결과는 MariaDB 드라이버를 사용하여 데이터베이스에 직접 및 RDS 프록시를 통해 삽입 쿼리를 실행하는 동안 결과 50 페일 오버를 보여줍니다. 다음 표는 결과를 밀리 초 단위로 요약합니다.
| 테스트 | 최소 | 맥스 | 평균 | 프록시 장점 |
| 프록시 다중 AZ (MariaDB 드라이버) | 21,485 | 29,176 | 25,075 | 32 % |
| 직접 다중 AZ (MariaDB 드라이버) | 27,240 | 52,234 | 36,849 |
요약하자면, Amazon RDS 다중 AZ 데이터베이스와 함께 RDS 프록시를 사용하면 평균 25 초 내에 복구된 것으로 나타났지만 데이터베이스에 대한 직접 연결은 37-40 초의 다운 타임을 경험했습니다.
Amazon RDS 다중 AZ 복구는 25 초인 반면, Aurora는 db.r5.large 인스턴스에서 3 초 이내에 복구를 제공했습니다.
결론
이 게시물에서는 RDS 프록시의 다음과 같은 이점을 보여줍니다.
- 테스트 워크로드에서 Aurora MySQL 장애 조치 시간을 최대 79 % 단축
- 테스트 워크로드에 대해 RDS MySQL 다중 AZ 장애 조치 시간을 최대 32 % 단축
- 특별한 클라이언트 로직없이 다른 클라이언트 드라이버와 동일하게 작동
- Aurora 리더 및 라이터 전환에서 클라이언트를 격리
- 계획되지 않은 장애 조치를 포함하여 각 데이터베이스를 능동적으로 모니터링
- 장애 조치 중에 유휴 연결을 끊지 않으므로 클라이언트 연결 풀에 대한 영향 감소
- 항상 연결을 허용하여 연결 시간 초과로부터 클라이언트를 격리
RDS 프록시는 사용하기 간편합니다. RDS 프록시 엔드 포인트에서 MySQL과 PostgreSQL 클라이언트 드라이버 장점 모두 누릴 수 있습니다. 지금 바로 응용 프로그램에 RDS 프록시를 사용해보세요.
원문URL: https://aws.amazon.com/ko/blogs/database/improving-application-availability-with-amazon-rds-proxy/
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.