Aurora 읽기 전용 복제본을 사용해 본 적이 있다면 여러 엔드포인트를 사용할 수 있다는 사실을 눈치채셨을 것입니다. 클러스터 엔드포인트 , 리더 엔드포인트 및 인스턴스 엔드포인트 ... 이러한 모든 옵션을 사용하여 언제 어떤 옵션을 사용해야 하는지 어떻게 알 수 있습니까? 중요하지 않은 시스템과 마찬가지로 답은... 상황에 따라 다릅니다. 이 블로그 게시물에서는 다양한 엔드포인트, 해당 사용 사례 및 이러한 설계 결정과 함께 발생하는 절충점을 살펴보겠습니다.
먼저 Amazon Aurora에서 사용할 수 있는 다양한 엔드포인트를 살펴보겠습니다.
-
클러스터 엔드포인트 – 클러스터 엔드포인트 해당 DB 클러스터의 현재 기본 DB 인스턴스에 애플리케이션을 연결합니다. 애플리케이션은 이 인스턴스를 읽고 쓸 수 있습니다.
-
리더 엔드포인트 – 리더 엔드포인트 사용 가능한 읽기 전용 복제본 풀 전체에서 연결 로드 밸런싱 여기에서 읽기 쿼리를 오프로드하여 기본 DB 인스턴스의 부하를 줄입니다.
-
인스턴스 엔드포인트 – 인스턴스 엔드포인트 클러스터의 특정 인스턴스에 연결합니다. 클라이언트는 Amazon Aurora가 연결 배포를 처리하도록 하는 대신 쿼리 할당을 세부적으로 제어할 수 있습니다.
무슨 생각을 하는지 알고 있습니다... 그냥 클러스터 엔드포인트에 연결하겠습니다. forwrites, 리더 엔드포인트 모든 읽기에 대해 그리고 내장된 내결함성을 우회하고 문제를 요구하는 특정 인스턴스에 연결해야 하는 이유는 무엇입니까? 이전에 다루지 못한 것처럼 애플리케이션과 Aurora와의 상호 작용은 복잡한(또는 최소한 사소하지 않은) 시스템을 만듭니다. 복잡한 시스템을 사용하면 한밤중에 통화를 즐기지 않는 한 획일적인 방식으로 모든 것을 해결할 수 있습니다.
몇 가지 시나리오를 살펴보고 다양한 엔드포인트를 언제 어디서 사용해야 하는지 살펴보겠습니다.
즉각적인 일관성
일부 응용 프로그램은 데이터가 즉시 일관성이 있을 것으로 기대합니다. 이러한 응용 프로그램이 데이터를 쓸 때 "로컬 데이터가 아닌 모델에 의존"하는 많은 디자인 패턴을 엄격하게 준수하여 데이터를 즉시 읽습니다. Amazon Aurora는 ACID를 준수합니다. 클러스터 엔드포인트에서 읽기 성공적인 쓰기 커밋 직후에 예상 데이터를 검색합니다(다른 트랜잭션이 후속 읽기 전에 데이터를 수정하지 않았다고 가정).
문제가 발생하는 경우는 쓰기가 클러스터 엔드포인트로 전송될 때입니다. andreads는 리더 엔드포인트에 만들어집니다. . 이는 데이터 쓰기와 독자에게 표시되는 시간 사이의 대기 시간 때문입니다. 복제 대기 시간은 100밀리초 미만이지만 즉각적이지 않아 경합 상태가 발생합니다. 쓰기 후 즉시 데이터를 읽어야 하는 시나리오가 있는 경우 클러스터 엔드포인트를 사용하세요. 읽기와 쓰기 모두에 대해. 추가 성능이 필요한 경우 기본 인스턴스의 크기를 늘려야 합니다.
그러나 최종 일관성이 허용되고 애플리케이션이 이를 지원하는 경우 Reader Endpoint를 사용하여 기본 인스턴스의 로드를 줄이는 좋은 방법입니다.
오프로드 읽기
쓰기 후 즉시 읽기가 좋지 않다면 리더 엔드포인트를 따로 따로 두는 것이 무슨 의미가 있습니까? ? 약간 일치하지 않는 데이터가 문제가 되지 않는 많은 사용 사례가 있습니다. 예:일일 보고. 어제 데이터에서 보고서를 생성하기 위해 일괄 작업을 실행할 때 100밀리초의 복제 지연은 중요하지 않습니다. 전자 상거래 사이트의 제품 설명과 같은 다른 시나리오는 쉽게 상상할 수 있습니다. 복제 지연의 영향을 받기보다 사용자 브라우저에 오래된 데이터가 있을 가능성이 더 큽니다.
일반적으로 즉각적인 일관성에 의존하지 않는 읽기 집약적인 워크로드는 Reader Endpoint 사용을 고려해야 합니다. .
불균일한 작업 부하
인스턴스 엔드포인트를 사용하는 것이 합리적인 상황이 있습니다. . Elastic Load Balancer 뒤에 여러 상태 비저장 마이크로서비스가 있는 애플리케이션이 있다고 가정해 보겠습니다. 이 상황에서는 쿼리가 클라이언트 전체에 고르게 분포되어 있다고 가정하는 것이 합리적입니다. 따라서 Reader Endpoint를 사용할 때 읽기 전용 복제본 전체에 걸쳐 .
그러나 각 클라이언트의 작업량이 균일하게 분배되지 않는 상황은 어떻습니까? 보고 서비스가 혼합에 추가되면 하나의 읽기 전용 복제본은 다른 것에 비해 불균형적으로 높은 로드를 갖습니다. 앞서 언급한 마이크로서비스도 이 읽기 전용 복제본을 사용하는 경우 보고 서비스에서 사용하는 인스턴스를 쿼리할 때 쿼리 성능이 저하될 가능성이 높습니다. 이를 피하기 위한 한 가지 접근 방식은 Amazon Aurora가 자동으로 수행하도록 하는 대신 클라이언트 측에서 연결 배포를 관리하는 것입니다. 운 좋게도 인스턴스 엔드포인트를 사용하면 이 작업을 쉽게 수행할 수 있습니다. 리더 엔드포인트 대신 .MySQL용 Aurora용 MariaDB 커넥터/J 또는 AmazonAurora PostgreSQL을 통한 빠른 장애 조치를 통해 드라이버가 읽기 전용 복제본으로 사용하려는 개별 인스턴스를 인식하도록 할 수 있으므로 드라이버가 쿼리가 개별 인스턴스에 배포되는 방식을 직접 관리할 수 있습니다.
DNS 캐싱 관리
워크로드의 특성을 이해하는 것 외에도 Aurora의 고가용성 및 리더 엔드포인트를 제공하기 위해 연결이 할당되는 방식을 이해하는 것이 중요합니다. 로드 밸런싱.
자동 클러스터 엔드포인트 관리 장애 조치 및 리더 엔드포인트 로드 밸런싱은 IP, TCP 또는 데이터베이스 클라이언트 프로토콜 계층이 아닌 DNS(Amazon Route 53)를 통해 처리됩니다. DNS를 통한 연결 배포를 처리한다는 것은 애플리케이션이 각각의 새로운 연결 요청에 대해 DNS 쿼리를 만들어야 한다는 것을 의미합니다. DNS 캐싱을 사용하는 애플리케이션은 Amazon Aurora에 대한 DNS 레코드 TTL과 일치하도록 캐시 제한 시간을 조정해야 합니다. Aurora DNS 레코드 TTL보다 긴 DNS 응답을 캐싱하면 몇 가지 오류 조건이 발생합니다. 고가용성(HA) 장애 조치 이벤트가 있는 경우, 즉 읽기 전용 복제본이 기본으로 승격되는 경우 캐시된 DNS 응답은 애플리케이션이 실패한 이전 인스턴스에 다시 연결을 시도함을 의미합니다. 리더 엔드포인트의 경우 , DNS 응답을 캐싱하면 여러 연결이 사용 가능한 읽기 전용 복제본에 분산되지 않고 특정 읽기 전용 복제본으로 연결됩니다.
마무리
우리가 볼 수 있듯이, 사소한 프로덕션 워크로드와 관련하여 만능 솔루션은 없습니다. 애플리케이션에 즉각적인 일관성이 필요한 경우 읽기와 쓰기가 모두 클러스터 엔드포인트로 전송되는지 확인하세요. . 읽기 쿼리가 약간의 복제 지연을 처리할 수 있으면 읽기 쿼리를 리더 엔드포인트로 오프로드합니다. .읽기 전용 복제본을 사용할 수 있지만 쿼리가 모든 클라이언트에 균일하게 분산되지 않은 경우 인스턴스 엔드포인트를 사용하세요. 클라이언트 측에서 연결 배포를 관리합니다. 애플리케이션이 DNS 레코드 TTL보다 긴 캐시 시간 초과로 DNS 캐싱을 사용하는 경우 엔드포인트가 클러스터 엔드포인트 동안 예상대로 작동하지 않는 것으로 나타납니다. HA 장애 조치 또는 리더 엔드포인트 사용 시 .
애플리케이션의 특성, Aurora 엔드포인트가 어떻게 작동하는지 이해하고 해당 지식을 올바르게 적용하면 귀사와 귀사의 고객에게 매우 중요한 보다 강력한 애플리케이션 환경으로 이어질 것입니다. 아무도 한밤중에 정전 전화를 원하지 않습니다.
피드백 탭을 사용하여 의견을 남기거나 질문하십시오.