DAX 클러스터 구성 요소

Amazon DynamoDB Accelerator(DAX) 클러스터는 AWS 인프라 구성 요소로 이루어져 있습니다. 이 단원에서는 이러한 구성 요소 및 이들이 함께 작동하는 방법에 대해 설명합니다.

Nodes(노드)

노드는 DAX 클러스터의 가장 작은 빌딩 블록입니다. 각 노드는 DAX 소프트웨어의 인스턴스를 실행하고, 캐시된 데이터의 단일 복제본을 유지합니다.

DAX 클러스터는 다음 두 가지 방법 중 하나로 크기를 조정할 수 있습니다.

• 추가 노드를 클러스터에 추가하는 방법. 이 방법을 사용하면 클러스터의 전체 읽기 처리량이 증가합니다.

• 대형 노드 유형을 사용하는 방법. 대형 노드 유형은 용량이 더 크며 처리량이 늘어날 수 있습니다. (새로운 노드 유형으로 새 클러스터를 생성해야 한다는 점에 유의하세요.)

클러스터 내 모든 노드는 노드 유형이 동일하며, 동일한 DAX 캐싱 소프트웨어를 실행합니다. 이용 가능한 노드 유형의 목록은 Amazon DynamoDB 요금을 참조하세요.

클러스터

클러스터는 DAX가 단위로 관리하는 하나 이상 노드의 논리적 그룹입니다. 클러스터의 노드 중 하나는 기본 노드로 지정되며, 다른 노드들(있는 경우)은 읽기 전용 복제본이 됩니다.

기본 노드는 다음을 담당합니다.

• 캐시된 데이터에 대한 애플리케이션 요청 이행

• DynamoDB에 대한 쓰기 작업 처리

• 클러스터의 제거 정책에 따라 캐시에서 데이터 제거.

프라이머리 노드의 캐시된 데이터가 변경되면 DAX는 복제 로그를 사용하여 모든 읽기 전용 복제본 노드에 변경 내용을 전파합니다. DynamoDB는 모든 읽기 전용 복제본에서 확인을 받은 후 프라이머리 노드에서 복제 로그를 삭제합니다.

읽기 전용 복제본은 다음을 담당합니다.

• 캐시된 데이터에 대한 애플리케이션 요청 이행

• 클러스터의 제거 정책에 따라 캐시에서 데이터 제거.

하지만 프라이머리 노드와 달리 읽기 전용 복제본은 DynamoDB에 쓰지 않습니다.

읽기 전용 복제본은 다음과 같은 2가지 역할을 추가로 수행합니다.

• 확장성. 동시 액세스가 필요한 클라이언트가 많은 경우 읽기 확장을 위해 복제본을 더 추가할 수 있습니다. DAX는 클러스터의 모든 노드에 균일하게 로드를 분산합니다. (처리량을 늘리는 또 다른 방법은 더 큰 캐시 노드 유형을 사용하는 것입니다.)

• 고가용성. 프라이머리 노드에 장애가 발생하면 DAX가 자동으로 읽기 전용 복제본으로 장애 조치하고 이를 새로운 프라이머리 노드로 지정합니다. 복제본 노드가 실패하면 실패한 노드가 복구될 때까지 DAX 클러스터의 다른 노드가 계속 요청을 수행할 수 있습니다. 내결함성을 최대화하려면 별도의 가용 영역에 읽기 전용 복제본을 배포해야 합니다. 이렇게 구성하면 전체 가용 영역을 사용할 수 없게 되는 경우에도 DAX 클러스터가 계속 작동할 수 있습니다.

DAX 클러스터는 클러스터당 최대 11개까지 노드를 지원할 수 있습니다(프라이머리 노드와 최대 10개의 읽기 전용 복제본).

중요

프로덕션 용도로는 각 노드가 서로 다른 가용 영역에 있는 최소 3개 노드로 구성된 DAX를 사용할 것을 적극 권장합니다. DAX 클러스터를 내결함성(fault-tolerant)으로 구성하려면 3개의 노드가 필요합니다.

개발 또는 테스트 워크로드를 위해 DAX 클러스터를 1개 또는 2개의 노드에 배포할 수 있습니다. 1개 및 2개 노드 클러스터는 내결함성 구성이 아니므로 프로덕션 용도로는 최소 3개 이상의 노드를 사용하세요. 1개 또는 2개 노드 클러스터에서 소프트웨어 오류나 하드웨어 오류가 발생할 경우, 클러스터를 사용할 수 없게 되거나 캐시된 데이터가 손실될 수 있습니다.

리전 및 가용성 영역

AWS 리전에 있는 DAX 클러스터는 동일한 리전에 있는 DynamoDB 테이블과만 상호 작용할 수 있습니다. 이러한 이유로 올바른 리전에서 DAX 클러스터를 시작하도록 주의해야 합니다. 다른 리전에 DynamoDB 테이블이 있는 경우에는 해당 리전에서도 DAX 클러스터를 시작해야 합니다.

각 리전은 다른 리전에서 완전히 격리되도록 설계되었습니다. 각 리전 안에는 가용 영역이 여러 개 있습니다. 서로 다른 가용 영역에서 노드를 시작하면 가능한 최고 수준의 내결함성을 갖출 수 있습니다.

중요

하나의 가용 영역에 클러스터 노드를 모두 두지는 마세요. 이렇게 구성하면 가용 영역에 장애가 발생한 경우 DAX 클러스터를 사용할 수 없게 됩니다.

프로덕션 용도로는 각 노드가 서로 다른 가용 영역에 있는 최소 3개 노드로 구성된 DAX를 사용할 것을 적극 권장합니다. DAX 클러스터를 내결함성(fault-tolerant)으로 구성하려면 3개의 노드가 필요합니다.

개발 또는 테스트 워크로드를 위해 DAX 클러스터를 1개 또는 2개의 노드에 배포할 수 있습니다. 1개 및 2개 노드 클러스터는 내결함성 구성이 아니므로 프로덕션 용도로는 최소 3개 이상의 노드를 사용하세요. 1개 또는 2개 노드 클러스터에서 소프트웨어 오류나 하드웨어 오류가 발생할 경우, 클러스터를 사용할 수 없게 되거나 캐시된 데이터가 손실될 수 있습니다.

파라미터 그룹

파라미터 그룹은 DAX 클러스터의 런타임 설정을 관리하는 데 사용됩니다. DAX에는 성능을 최적화하는 데 사용할 수 있는 파라미터가 여러 개 있습니다(예: 캐시된 데이터에 대한 TTL 정책 정의). 파라미터 그룹이란 클러스터에 적용할 수 있는 이름이 지정된 파라미터 모음을 말합니다. 따라서 해당 클러스터에 있는 모든 노드가 정확히 동일한 방법으로 구성되게 할 수 있습니다.

보안 그룹

DAX 클러스터는 Amazon Virtual Private Cloud(Amazon VPC) 환경에서 실행됩니다. 이 환경은 해당 AWS 계정 전용이며 다른 VPC와 분리되는 가상 네트워크입니다. 보안 그룹은 인바운드 및 아웃바운드 네트워크 트래픽을 제어할 수 있는 VPC에 대한 가상 방화벽 역할을 합니다.

VPC에서 클러스터를 시작할 경우 보안 그룹에 수신 규칙을 추가하여 수신 네트워크 트래픽을 허용할 수 있습니다. 수신 규칙은 클러스터에 대해 프로토콜(TCP)과 포트 번호(8111)를 지정합니다. 이 수신 규칙을 보안 그룹에 추가하면 VPC 내에서 실행 중인 애플리케이션에서 DAX 클러스터에 액세스할 수 있습니다.

클러스터 ARN

모든 DAX 클러스터에는 Amazon 리소스 이름(ARN)이 할당됩니다. ARN 형식은 다음과 같습니다.

arn:aws:dax:region:accountID:cache/clusterName

IAM 정책의 클러스터 ARN을 사용하여 DAX API 작업에 대한 권한을 정의합니다. 자세한 내용은 DAX 액세스 제어 섹션을 참조하세요.

클러스터 엔드포인트

모든 DAX 클러스터는 애플리케이션에서 사용할 클러스터 엔드포인트를 제공합니다. 애플리케이션에서 해당 엔드포인트를 사용하여 클러스터에 액세스하면 클러스터에 있는 개별 노드의 호스트 이름과 포트 번호를 알 필요가 없습니다. 읽기 전용 복제본을 추가하거나 제거하더라도 애플리케이션은 클러스터에 있는 모든 노드를 자동으로 "알게" 됩니다.

다음은 전송 중 암호화를 사용하도록 구성되지 않은 us-east-1 리전의 클러스터 엔드포인트 예제입니다.

dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

다음은 전송 중 암호화를 사용하도록 구성된 동일한 리전의 클러스터 엔드포인트 예제입니다.

daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

노드 엔드포인트

DAX 클러스터의 각 개별 노드에는 자체 호스트 이름과 포트 번호가 있습니다. 다음은 노드 엔드포인트 예제입니다.

myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111

애플리케이션은 엔드포인트를 사용하여 직접 노드에 액세스할 수 있습니다. 그러나, DAX 클러스터를 단일 단위로 간주한 후 클러스터 엔드포인트를 대신 사용하여 액세스하는 것이 좋습니다. 클러스터 엔드포인트를 사용하면 애플리케이션이 노드 목록을 유지할 필요가 없고, 클러스터에서 노드를 추가하거나 삭제할 때 이 목록을 최신 상태로 업데이트할 필요가 없습니다.

서브넷 그룹 수

DAX 클러스터 노드에 대한 액세스는 Amazon VPC 환경 내의 Amazon EC2 인스턴스에서 실행되는 애플리케이션으로만 제한됩니다. 서브넷 그룹을 사용하여 특정 서브넷에서 실행 중인 Amazon EC2 인스턴스에서의 액세스 권한을 클러스터에 부여할 수 있습니다. 서브넷 그룹은 Amazon VPC 환경에서 실행 중인 클러스터에 대해 지정할 수 있는 서브넷(일반적으로 프라이빗 서브넷) 모음입니다.

DAX 클러스터를 생성할 때 서브넷 그룹을 지정해야 합니다. DAX는 해당 서브넷 그룹을 사용하여 노드에 연결된 서브넷 내의 서브넷 및 IP 주소를 선택합니다.

이벤트

DAX는 노드 추가 실패, 노드 추가 성공, 보안 그룹 변경과 같은 중요한 이벤트를 클러스터 내에 기록합니다. 주요 이벤트를 모니터링하면 클러스터의 현재 상태를 파악할 수 있으며, 이벤트에 따라 교정 작업을 수행할 수도 있습니다. DAX 관리 API의 AWS Management Console 또는 DescribeEvents 작업을 사용하여 이러한 이벤트에 액세스할 수 있습니다.

또한 해당 알림을 특정 Amazon Simple Notification Service(Amazon SNS) 주제에 전송하도록 요청할 수 있습니다. 이렇게 하면 DAX 클러스터에서 이벤트가 발생하는 경우 즉시 알 수 있습니다.

유지 관리 기간

모든 클러스터에는 시스템 변경 내용이 적용되는 주 단위 유지 관리 기간이 있습니다. 캐시 클러스터 생성하거나 수정할 때 기본 유지 관리 기간을 지정하지 않으면 DAX에서 임의로 선택한 요일에 60분의 유지 관리 기간을 배정합니다.

AWS 리전별로 8시간 블록 시간 중에서 60분 유지 관리 기간이 임의로 선택됩니다. 다음 표는 기본 유지 관리 기간이 할당된 각 리전의 시간 블록 목록입니다.

리전 코드	리전 이름	유지 관리 기간
ap-northeast-1	Asia Pacific (Tokyo) Region	13:00~21:00 UTC
ap-southeast-1	Asia Pacific (Singapore) Region	14:00~22:00 UTC
ap-southeast-2	아시아 태평양(시드니) 리전	12:00~20:00 UTC
ap-south-1	아시아 태평양(뭄바이) 리전	17:30~1:30 UTC
cn-northwest-1	중국(닝샤) 리전	23:00~07:00 UTC
cn-north-1	중국(베이징) 리전	14:00~22:00 UTC
eu-central-1	유럽(프랑크푸르트) 리전	23:00~07:00 UTC
eu-west-1	Europe (Ireland) Region	22:00~06:00 UTC
eu-west-2	유럽(런던) 리전	23:00~07:00 UTC
eu-west-3	유럽(파리) 리전	23:00~07:00 UTC
sa-east-1	남아메리카(상파울루) 리전	01:00~09:00 UTC
us-east-1	리전 - 미국 동부(버지니아 북부)	03:00~11:00 UTC
us-east-2	미국 동부(오하이오) 리전	23:00~07:00 UTC
us-west-1	미국 서부(캘리포니아 북부) 리전	06:00~14:00 UTC
us-west-2	미국 서부(오레곤) 리전	06:00~14:00 UTC

유지 관리 기간은 사용률이 가장 낮은 시간에 할당되어야 하므로 수시로 수정되어야 할 수 있습니다. 요청한 유지 관리 작업을 수행하는 기간을 최대 24시간까지 지정할 수 있습니다.