AWS Aurora DB 클러스터 엔드포인트 연결 종류 4가지

Lecture de 6 minute(s)
Niveau du contenu : Intermédiaire
1

AWS Aurora 데이터베이스 클러스터에서 제공하는 엔드포인트의 종류 및 특징에 대해서 알아보고, 서비스 특성에 따라 적합한 엔드포인트를 사용하여 서비스 안정성 및 장애조치 가용성을 높일 수 있습니다.

Aurora DB 클러스터 엔드포인트 연결 종류 4가지

Author : Sungwook Kang(강성욱), AWS Solutions Architect

Amazon Aurora DB Cluster는 하나 이상의 DB 인스턴스와 이 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. Aurora 클러스터 볼륨은 다중 가용 영역을 아우르는 가상 데이터베이스 스토리지 볼륨으로 각 가용 영역에는 DB 클러스터 데이터의 사본이 있습니다.

  • 기본 DB 인스턴스 : 읽기 및 쓰기 작업을 지원하고 클러스터 볼륨의 모든 데이터 수정을 실행합니다. Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 있습니다.
  • Aurora 복제본 : 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원 합니다. 각 Aurora DB 클러스터는 기본 DB 인스턴스에 대해 최대 15개 까지의 Aurora 복제본을 구성할 수 있습니다. Aurora DB 기본 인스턴스를 사용할 수 없는 경우 자동으로 Aurora 복제본으로 자동 장애조치 합니다. Amazon DB Cluster

Amazon Aurora는 일반적으로 단일 인스턴스 대신에 DB 인스턴스 클러스터와 관련됩니다. 각 연결은 특정 DB 인스턴스에서 처리합니다. Aurora 클러스터에 연결하면 지정한 호스트 이름과 포트가 엔드포인트(endpoint)라는 중간 핸들러를 가리킵니다. Aurora는 엔드포인트 메커니즘을 사용하여 연결을 추상화 합니다. 따라서 일부 DB 인스턴스를 사용할 수 없을 때 모든 호스트 이름을 하드코딩 하거나, 연결을 다시 라우팅하고 로드 밸런싱을 하기 위한 자체 로직을 작성할 필요가 없습니다.

Aurora 엔드포인트 유형에는 클러스터 엔드포인트, 리더 엔드포인트, 커스터머 지정 엔드포인트, 인스턴스 엔드포인트로 네 가지 종류가 있습니다. 각 엔드포인트에 대한 특징을 살펴보겠습니다.

클러스터 엔드포인트 (Cluster endpoint)

Aurora DB 클러스터의 클러스터 엔드포인트(또는 Writer endpoint)는 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결됩니다. DDL 문 등의 쓰기 작업을 수행할 수 있는 유일한 엔드포인트 입니다. 각 Aurora DB클러스터에는 클러스터 엔드포인트 하나와 기본 DB 인스턴스 하나가 있습니다. 삽입, 업데이트, 삭제 및 DDL 변경을 비롯하여 DB의 모든 쓰기 작업에 대해 클러스터 엔드포인트를 사용합니다. 또한 읽기 작업에도 클러스터 엔드포인트를 사용할 수 있습니다. 클러스터 엔드포인트는 장애조치를 지원합니다. 아래는 Aurora MySQL DB 클러스터의 엔드포인트를 나타낸 예제입니다.

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306

장애조치 메커니즘에서 새 DB 인스턴스가 클러스터의 읽기/쓰기 기본 인스턴스가 되도록 승격하면 클러스터 엔드포인트가 가리키는 물리적 IP 주소가 변경됩니다. 어떤 형식의 연결 풀링이나 기타 멀티플렉싱을 사용하는 경우, 캐싱된 DNS 정보의 TTL(Time To Live)을 플러시 하거나 줄이도록 준비합니다. 이렇게 하면 사용할 수 없게 되었거나 장애 조치 후 이제 읽기 전용인 DB 인스턴스에 읽기/쓰기 연결 설정을 시도하지 않아도 됩니다.

리더 엔드포인트 (Reader endpoint)

Aurora DB 클러스터의 리더 엔드포인트는 DB 클러스터에 대한 읽기 전용 연결시 로드 밸런싱을 지원합니다. 읽기 작업에 대한 요청을 복제본에서 처리하기 때문에 기본 인스턴스에 대한 오버헤드를 줄일 수 있습니다. 또한 클러스터의 Aurora 복제본 수에 비례하여 동시에 SELECT 쿼리를 처리할 수 있도록 용량을 확장할 수 있습니다. 각 Aurora DB 클러스터에는 리더 엔드포인트가 1개씩 있습니다. 클러스터에 하나 이상의 Aurora 복제본이 포함된 경우 리더 엔드포인트는 Aurora 복제본 사이의 각 연결 요청을 로드 밸런싱 합니다. 이 경우 해당 세션의 SELECT 와 같은 읽기만 실행할 수 있습니다. 클러스터에 기본 인스턴스만 있고 Aurora 복제본이 없는 경우 리더 엔드포인트는 기본 인스턴스에 연결합니다. 이 경우 엔드포인트를 통해 쓰기 작업을 수행할 수 있습니다. 아래는 Aurora MySQL DB 클러스터의 리더 엔드포인트를 나타낸 예제입니다.

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306

RDS Proxy를 통해서도 Aurora 클러스터용 추가 읽기 전용 엔드포인트를 생성할 수 있습니다. 이러한 엔드포인트는 Aurora 리더 엔드포인트와 동일한 종류의 로드밸랜싱을 수행합니다.

Aurora DB Cluster2

커스터머 지정 엔드포인트 (Customer endpoint)

Aurora 클러스터의 커스터머 지정 엔드포인트는 선택한 DB 인스턴스 집합을 나타냅니다. 엔드포인트에 연결하면 Aurora가 로드 밸런싱을 수행하고 그룹에서 연결을 처리할 인스턴스 중 하나를 선택합니다. 이 엔드포인트가 참조하는 인스턴스를 정의하고, 이 엔드포인트가 어떤 목적으로 사용되는지 결정합니다. 커스터머 지정 엔드포인트는 클러스터를 생성할 때 자동으로 생성되지 않으며, 프로비저닝된 각 Aurora 클러스터에 대해 최대 5개의 커스터머 지정 엔드포인트를 만들 수 있습니다. Aurora Serverless 클러스터에는 커스터머 지정 엔드포인트를 사용할 수 없습니다. 커스터머 지정 엔드포인트는 DB 인스턴스의 읽기 전용 기능 또는 읽기/쓰기 기능 이외의 다른 조건을 기반으로 로드 밸런싱된 데이터베이스 연결을 제공합니다. 예를 들어 특정 AWS 인스턴스 클래스 또는 특정 DB 파라메터 그룹을 사용하는 인스턴스에 연결할 커스터머 지정 엔드포인트를 정의할 수 있습니다. 또는 보고서 생성 등과 같은 일회성 쿼리 같은 것을 저용량의 내부 서버로 보내고, 고용량 인스턴스로는 프로덕션 트래픽을 보낼 수 있습니다. 커스터머 지정 엔드포인트와 연결된 모든 DB인스턴스로 연결이 이동할 수 있기 때문에 해당 그룹내의 모든 DB 인스턴스가 일부 유사한 특성을 공유하는지 확인하는 것이 좋습니다. 그렇게 하면 성능, 메모리 용량 등이 해당 엔드포인트에 연결하는 모든 사람에게 일관되도록 보장할 수 있습니다. 이 기능은 모든 Aurora 복제본을 동일한 클러스터에 유지하는 것이 적절하지 않은 특수한 종류의 워크로드가 있는 고급 사용자를 위한 것으로 커스터머 지정 엔드포인트를 통해 각 연결에 사용되는 DB 인스턴스를 예측할 수 있습니다. 커스터머 지정 엔드포인트를 사용할 경우 일반적으로 해당 클러스터에 리더 엔드포인트를 사용하지 않습니다. 아래는 Aurora MySQL DB 클러스터의 커스터머 지정 엔드포인트를 나타낸 예제입니다.

myendpoint.cluster-custom-123456789012.us-east-1.rds.amazonaws.com:3306

사용지 지정 엔드포인트의 이름은 최대 63글자 까지 가능합니다. 커스터머 지정 엔드포인트 이름에는 클러스터 이름이 포함되지 않기 때문에, 클러스터 이름을 바꿀 경우 엔드포인트 이름을 변경할 필요가 없습니다. 동일한 리전에 있는 둘 이상의 클러스터에 동일한 커스터머 지정 엔드포인트 이름을 재사용할 수 없습니다. 각 커스터머 지정 엔드포인트에 특정 리전 내의 사용자 ID가 소유한 클러스터 전체에서 고유한 이름을 부여합니다. 장애 조치 또는 승격으로 인해 DB 인스턴스가 기본 인스턴스와 Aurora 복제본 간에 역할을 변경해도 Aurora는 정적 목록 또는 제외 목록에 지정된 DB 인스턴스를 변경하지 않습니다. 예를 들어 READER 유형의 커스터머 지정 엔드포인트에는 Aurora 복제본 이었다가 이후 기본 인스턴스로 승격된 DB 인스턴스가 포함될 수 있습니다. 커스터머 지정 엔드포인트 유형 (READER, WRITER 또는 ANY)에 따라 해당 엔드포인트를 통해 수행할 수 있는 작업의 종류가 결정됩니다. Aurora 복제본을 사용할 수 없게 된 경우에도 커스터머 지정 엔드포인트와는 연결된 상태로 유지됩니다. 예를 들어 이상이 있거나, 중지되었거나, 재부팅 되더라도 커스터머 지정 엔드포인트의 일부로 유지됩니다. 그러나 클러스터가 다시 사용할 수 있게 될 때까지 기존 엔드포인트를 통해 연결할 수 없습니다.

인스턴스 엔드포인트 (Instnace endpoint)

인스턴스 엔드포인트는 Aurora 클러스터에 있는 특정 DB 인스턴스에 연결됩니다. DB 클러스터의 DB 인스턴스에는 각각 고유한 인스턴스 엔드포인트가 있습니다. 그러므로 DB 클러스터의 현재 기본 DB 인스턴스에 대해 인스턴스 엔드포인트 하나가 있고, DB 클러스터의 각 Aurora 복제본마다 인스턴스 엔드포인트 하나가 있습니다. 클러스터 엔드포인트 또는 리더 엔드포인트의 사용이 부적합한 시나리오에서 인스턴스 엔드포인트가 DB 클러스터에 대한 연결을 직접 제어 합니다. 예를 들어 어플리케이션에서 워크로드 유형에 따라 더욱 세분화된 로드 밸런싱이 필요할 경우 각 애플리케이션 속성에 따라 각기 다른 Aurora 복제본에 연결한 후 읽기 워크로드를 분산 시킬 수 있습니다. 아래는 Aurora MySQL DB 클러스터의 DB 인스턴스 엔드포인트 예제 입니다.

mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306

고가용성이 중요한 클러스터의 경우 라이터 엔드포인트를 읽기/쓰기 또는 범용 연결에 사용하고 리더 엔드포인트를 읽기 전용 연결에 사용합니다. 라이터 및 리더 엔드포인트는 인스턴스 엔드포인트보다 DB 인스턴스 장애조치를 더 잘 관리합니다. 인스턴스 엔드포인트와 달리 라이터 및 리더 엔드포인트는 클러스터의 DB 인스턴스를 사용할 수 없게 되면 연결된 DB 인스턴스를 자동으로 변경합니다. 인스턴스 엔드포인트 연결을 관리하는 자체 애플리케이션 로직을 설계하는 경우, DB 인스턴스의 결과 집합을 수동으로 또는 프로그래밍 방식으로 가져올 수 있습니다. 그런 다음 장애 조치 이후 인스턴스 클래스를 확인하고 해당 인스턴스 엔드포인트에 연결하면 됩니다.

Reference