무료로 AWS 시작하기

무료 계정 생성
또는 콘솔에 로그인

AWS 프리 티어에는 Amazon ElastiCache와 함께 750시간의 마이크로 캐시 노드가 포함되어 있습니다.

AWS 프리 티어 세부 정보 보기 »


Q: Amazon ElastiCache란 무엇입니까?

Amazon ElastiCache는 클라우드에서 Memcached 또는 Redis 프로토콜과 호환되는 서버 노드를 쉽게 배포 및 실행할 수 있도록 해주는 웹 서비스입니다. Amazon ElastiCache는 더 느린 디스크 기반 데이터베이스에 전적으로 의존하기보다는 신속한 관리형 인 메모리 시스템에서 정보를 검색할 수 있는 기능을 지원함으로써 웹 애플리케이션의 성능을 향상합니다. 또한, 인 메모리 환경의 관리, 모니터링 및 운영을 간소화하여 부담을 덜어주므로 애플리케이션 개발에 엔지니어링 리소스를 집중할 수 있습니다. 게다가 Amazon ElastiCache을 사용하면 사용자 작업과 쿼리에 대한 로드 및 응답 시간이 향상될 뿐 아니라 웹 애플리케이션 확장에 따른 비용도 절감됩니다.

Amazon ElastiCache는 분산 인 메모리 키 값 환경을 운영하는 데 필요한 일반 관리 작업을 자동화합니다. Amazon ElastiCache를 이용하면 AWS Management Console에서 클릭 몇 번으로 몇 분 만에 애플리케이션 아키텍처에 캐싱 또는 인 메모리 계층을 추가할 수 있습니다. 클러스터가 프로비저닝되면 Amazon ElastiCache가 장애가 발생한 노드를 자동으로 감지 및 교체하여, 데이터베이스 과부하 때문에 웹 사이트와 애플리케이션 로드 시간이 길어지는 위험을 줄일 수 있는 복원력이 뛰어난 시스템을 제공합니다. Amazon ElastiCache는 Amazon CloudWatch 모니터링 기능과 통합되어 노드와 관련된 주요 성능 지표에 대한 향상된 가시성을 제공합니다. Amazon ElastiCache는 Memcached 및 Redis와 호환되는 프로토콜이므로 기존 Memcached 또는 Redis 환경에서 현재 사용하는 코드, 애플리케이션 및 주요 도구를 Amazon ElastiCache에서 문제없이 사용할 수 있습니다. Amazon ElastiCache에서는 클러스터형 구성을 지원하므로 가장 까다로운 애플리케이션의 요구를 충족할 수 있는 빠르고 확장 가능하며 사용이 간편한 관리형 서비스의 이점을 누릴 수 있습니다. 모든 Amazon Web Services와 마찬가지로 사전 투자가 필요 없으며 사용한 리소스에 대해서만 요금을 지불하면 됩니다.

Q: 인 메모리 캐싱이란 무엇이며, 애플리케이션을 어떻게 지원합니까?

Amazon ElastiCache의 인 메모리 캐싱 기능을 이용하면 많은 읽기 중심의 애플리케이션 워크로드(소셜 네트워킹, 게임, 미디어 공유, Q&A 포털 등) 또는 컴퓨팅 중심의 워크로드(추천 엔진 등)의 지연 시간과 처리량이 비약적으로 향상됩니다. 핵심 데이터 조각을 메모리에 저장해 액세스 지연 시간을 줄여주기 때문에 애플리케이션 성능도 향상됩니다. 캐싱된 정보에는 I/O 중심의 데이터베이스 쿼리 결과 또는 컴퓨팅 중심의 계산 결과가 포함될 수 있습니다.

Q: 캐싱 이외에 다른 사용 사례에도 Amazon ElastiCache를 사용할 수 있습니까?

A: 예 Redis용 ElastiCache를 기본 인 메모리 키 값 데이터 스토어로 사용하여 빠른 데이터 성능(1밀리초 미만), 고가용성 및 확장성(최대 16개의 노드와 최대 5개의 읽기 전용 복제본, 각각 최대 3.55TiB의 인 메모리 데이터)을 제공할 수 있습니다. 리더보드, 속도 제한, 대기열, 채팅 등 다른 사용 사례는 여기를 참조하십시오.

Q: AWS CloudFormation을 통해 Amazon ElastiCache를 사용할 수 있습니까?

AWS CloudFormation은 서비스 또는 애플리케이션의 빠르고 안정적인 프로비저닝을 위해 AWS CloudFormation 템플릿을 제공하여 프로비저닝과 관리를 간소화합니다. AWS CloudFormation은 클러스터(MemCached와 Redis 둘 다) 및 복제 그룹을 생성하는 템플릿을 통해 Amazon ElastiCache에 대한 포괄적인 지원을 제공합니다. 이 템플릿에는 클러스터형 Redis 구성에 대한 ElastiCache Redis 최근 발표 내용이 적용되어 있으며 Amazon ElastiCache 고객에게 유연성과 사용 편의성을 제공합니다.

Q: Amazon ElastiCache에서 자동으로 수행하는 관리 작업은 무엇입니까?

Amazon ElastiCache는 사용자가 요청한 서버 리소스를 프로비저닝하는 것부터 소프트웨어를 설치하는 것까지 분산 인 메모리 환경 설정과 관련된 작업을 관리합니다. 환경이 시작 및 실행되면 서비스에서 장애 감지 및 복구, 소프트웨어 패치 등의 일반적인 관리 작업을 자동으로 처리합니다. Amazon ElastiCache는 노드와 관련된 세부 모니터링 지표도 제공하므로 문제를 아주 신속하게 진단하고 대응할 수 있습니다. 예를 들면, 노드 중 하나에 요청 과부하가 걸리면 경보를 받을 수 있도록 임계값을 설정해 둘 수 있습니다.

Q: Amazon ElastiCache 노드, 샤드 및 클러스터란 무엇입니까?

노드는 Amazon ElastiCache 배포에서 가장 작은 빌딩 블록으로, 안전하고 네트워크에 연결된 RAM의 크기가 고정된 청크입니다. 각 노드는 Memcached 또는 Redis 프로토콜 호환 서비스의 인스턴스를 실행하고, 고유한 DNS 이름과 포트를 갖고 있습니다. 여러 유형의 노드가 지원되며, 연결된 메모리 양은 노드별로 다릅니다. Redis 샤드는 클러스터 키 공간의 하위 집합으로서, 기본 노드와 0개 이상의 읽기 전용 복제본을 포함할 수 있습니다. Redis 배포에 대한 자세한 내용은 아래 Redis 섹션을 참조하십시오. 샤드가 모여 클러스터가 형성됩니다.

Q: Amazon ElastiCache에서 지원하는 엔진은 무엇입니까?

Memcached용 Amazon ElastiCache는 현재 Memcached 1.4.5, 1.4.14, 1.4.24, 1.4.33 및 1.4.34을 지원합니다

Redis용 Amazon ElastiCache는 현재 Redis 2.8.21, 2.8.22, 2.8.23, 2.8.24, 3.2.4, 3.2.6 및 3.2.10을 지원합니다.

Q: Amazon ElastiCache는 어떻게 시작합니까?

아직 Amazon ElastiCache에 가입하지 않았다면 Amazon ElastiCache 세부 정보 페이지에서 "가입" 버튼을 클릭하고 가입 절차를 진행하면 됩니다. 이 서비스에 액세스하려면 Amazon Web Services 계정이 있어야 합니다. 아직 계정이 없는 경우 Amazon ElastiCache 가입 프로세스를 시작하면 계정을 생성하라는 메시지가 표시됩니다. ElastiCache에 가입한 후에는 시작 안내서가 포함된 Amazon ElastiCache 설명서를 참조하십시오.

Amazon ElastiCache에 익숙해지고 나면 AWS Management Console 또는 Amazon ElastiCache API를 사용해 몇 분 만에 클러스터를 시작할 수 있습니다.

Q: 클러스터는 어떻게 생성합니까?

클러스터는 AWS Management Console, Amazon ElastiCache API 또는 명령줄 도구를 사용하여 쉽게 생성할 수 있습니다. AWS Management Console을 사용하여 클러스터를 시작하려면 "Memcached" 또는 "Redis" 탭에서 "Create" 버튼을 클릭합니다. 그런 다음 클러스터 식별자, 노드 유형, 노드 개수만 지정하면 메모리가 필요한 만큼 할당된 클러스터를 생성할 수 있습니다. 아니면 CreateCacheCluster API 또는 elasticache-create-cache-cluster 명령을 사용하여 클러스터를 생성할 수도 있습니다. 클러스터를 생성할 때 가용 영역을 지정하지 않으면 AWS에서 사용자의 메모리 요구 사항과 가용 용량을 기준으로 자동으로 이를 지정합니다.

Q: 선택할 수 있는 노드 유형에는 어떤 것이 있습니까?

Amazon ElastiCache는 다음과 같은 유형의 노드를 지원합니다.

현재 세대 노드:

  • cache.m3.medium: 2.78GB
  • cache.m3.large: 6.05GB
  • cache.m3.xlarge: 13.3GB
  • cache.m3.2xlarge: 27.9GB
  • cache.m4.large: 6.42GB
  • cache.m4.xlarge: 14.28GB
  • cache.m4.2xlarge: 29.7GB
  • cache.m4.4xlarge: 60.78GB
  • cache.m4.10xlarge: 154.64GB
  • cache.r3.large: 13.5GB
  • cache.r3.xlarge: 28.4GB
  • cache.r3.2xlarge: 58.2GB
  • cache.r3.4xlarge: 118GB
  • cache.r3.8xlarge: 237GB
  • cache.t2.micro: 555MB
  • cache.t2.small: 1.55GB
  • cache.t2.medium: 3.22GB
 
이전 세대 노드:
 
  • cache.m1.small: 1.3GB
  • cache.m1.medium: 3.35GB
  • cache.m1.large: 7.1GB
  • cache.m1.xlarge: 14.6GB
  • cache.m2.xlarge: 16.7GB
  • cache.m2.2xlarge: 33.8GB
  • cache.m2.4xlarge: 68GB
  • cache.t1.micro: 213MB
  • cache.c1.xlarge: 6.6GB

위에 나열된 각 노드 유형은 Amazon ElastiCache 시스템 소프트웨어 오버헤드까지 고려한 다음, Memcached 또는 Redis에 사용할 수 있는 메모리입니다. 클러스터의 총 메모리 양은 각 샤드에서 사용할 수 있는 메모리를 모두 더한 정숫값입니다. 예를 들어, 6GB 샤드 10개로 구성된 클러스터의 총 메모리는 60GB가 됩니다.

Q: 내 노드에 액세스하려면 어떻게 해야 합니까?

클러스터가 생성되면 AWS Management Console에서 다음 단계에 따라 노드 엔드포인트를 검색할 수 있습니다.

  • "Amazon ElastiCache" 탭으로 이동합니다.
  • "(Number of) Nodes" 링크를 클릭하고 "Nodes" 탭으로 이동합니다.
  • "Copy Node Endpoint(s)" 버튼을 클릭합니다.

DescribeCacheClusters API를 이용해 엔드포인트 목록을 찾아도 됩니다.

그런 다음 이 엔드포인트 목록을 사용하여 Memcached 또는 Redis 클라이언트를 구성하고, 즐겨 사용하는 프로그래밍 언어를 사용하여 ElastiCache 노드에 데이터를 추가하거나 삭제할 수 있습니다. 사용자의 노드에 대한 네트워크 요청을 허용하려면 액세스 권한을 부여해야 합니다. 자세한 시작 방법은 시작 안내서를 참조하십시오.

Q: 유지 관리 기간이란 무엇입니까? 소프트웨어 유지 관리 기간에도 내 노드를 사용할 수 있습니까?

Amazon ElastiCache 유지 관리 기간은 직접 요청하든 필요에 따라 수행되든 상관없이 소프트웨어 패치를 언제 진행할지를 제어할 수 있는 기회라고 생각하면 됩니다. “유지 관리” 작업이 특정 주에 예정된 경우, 사용자가 지정하는 60분의 유지 관리 기간 중 특정 시점에 시작되고 완료됩니다.

소프트웨어 패치가 예정되어 있다면 유지 관리 기간에 노드를 잠시 사용하지 못할 수도 있습니다. 자세한 내용은 엔진 버전 관리를 참조하십시오. 소프트웨어 패치는 캐시 소프트웨어 업그레이드처럼 사용자가 요청할 수도 있고, 당사가 시스템이나 캐시 소프트웨어에서 어떤 보안 취약점을 감지한 경우처럼 필요에 따라 정해질 수도 있습니다. 이러한 패치는 대개 몇 달에 한 번 정도로 자주 있는 것은 아니며, 유지 관리 기간에서 차지하는 비중도 매우 적습니다. 클러스터를 생성할 때 기본 주별 유지 관리 기간을 지정하지 않으면 60분이 기본값으로 지정됩니다. 유지 관리가 수행되는 기간을 변경하려면 AWS Management Console에서 DB 인스턴스를 수정하거나 ModifyCacheCluster API를 사용하면 됩니다. 원하는 경우 클러스터별로 기본 유지 관리 기간을 다르게 설정할 수 있습니다.


Q: Amazon ElastiCache의 사용료는 어떻게 과금 및 청구됩니까?

요금은 사용량에 따라 지불하고 최소 요금이 없습니다. 각 노드 유형별로 소비한 노드 시간당 요금이 부과됩니다. 노드 시간이 1시간 미만이어도 1시간 사용 금액이 청구됩니다. 동일한 가용 영역 내의 Amazon EC2와 Amazon ElastiCache 간의 데이터 전송 요금은 없습니다. 반면 동일한 리전의 서로 다른 가용 영역에서 Amazon EC2 인스턴스와 Amazon ElastiCache 노드 간에 데이터를 전송할 경우에는 표준 Amazon EC2 리전 데이터 전송 요금이 적용되고, 사용자에게는 Amazon EC2 인스턴스에서 송수신한 데이터 전송 요금만 청구됩니다. Amazon ElastiCache 노드 자체에서 송수신한 트래픽에 대해서는 Amazon ElastiCache 데이터 전송 요금이 부과되지 않습니다. 자세한 내용은 요금 페이지를 참조하십시오.

Q: Amazon ElastiCache 노드는 언제부터 언제까지 사용한 요금이 청구됩니까?

노드 사용을 시작한 순간부터 노드를 삭제하여 사용이 종료된 순간까지 요금이 계산됩니다.

Q: 청구되는 ElastiCache 노드 시간은 어떻게 정해집니까?

노드 시간은 노드가 "가용" 상태로 실행되는 시간에 대해 청구됩니다. 더는 노드 비용을 지불하지 않으려면 추가 노드 시간이 청구되지 않도록 노드를 종료해야 합니다.

Q: 요금에 세금이 포함되어 있습니까?

별도의 언급이 없는 한, 요금에는 VAT 및 해당 판매세를 비롯한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우 AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보기.


Q: Amazon ElastiCache 예약 노드란 무엇입니까?

예약 노드에서는 한 번의 선결제로 특정 리전에서 노드를 1년 또는 3년 동안 실행하도록 예약하고 시간당 사용 요금을 대폭 할인받을 수 있습니다. 세 가지 예약 노드 유형(Light, Medium 및 Heavy 사용률 예약 노드)이 있으므로 실질 시간당 요금으로 선결제로 지불한 금액을 상쇄할 수 있습니다.

Q: 예약 노드는 온디맨드 노드와 어떻게 다릅니까?

예약 노드와 온디맨드 노드는 기능 면에서 전혀 차이가 없습니다. 유일한 차이점은 노드 비용의 청구 방식입니다. 예약 노드의 경우 한 번의 선결제로 약정 기간 동안 온디맨드 노드보다 저렴한 시간당 사용료가 적용됩니다.

Q: 예약 노드를 구매 및 생성하려면 어떻게 해야 합니까?

AWS Management Console의 "Purchase Reserved Nodes" 옵션을 사용하면 됩니다. 또는 API 도구를 사용해 DescribeReservedCacheNodesOfferings API 메서드로 구입 가능한 예약 목록을 표시한 다음 PurchaseReservedCacheNodesOffering 메서드를 호출해 캐시 노드 예약을 구매할 수 있습니다.

예약 노드 생성 방법은 온디맨드 노드 시작 방법과 동일합니다. 예약한 노드 클래스 및 리전을 지정하기만 하면 됩니다. 예약 구매가 완료되면 Amazon ElastiCache는 할인된 시간당 요금을 새 노드에 적용합니다.

Q: 항상 예약을 구입할 수 있습니까?

예. 예약 노드는 가용 영역이 아니라 리전별로 판매됩니다. 즉, 한 가용 영역에서 용량이 제한된 경우에도 해당 리전에서 예약 노드를 구매하고 해당 리전 내 다른 가용 영역에서 사용할 수 있습니다.

Q: 예약 캐시를 몇 개까지 구매할 수 있습니까?

예약 노드는 최대 20개까지 구매할 수 있습니다. 21개 이상의 노드를 실행하려면 Amazon ElastiCache 노드 요청 양식을 작성하십시오.

Q: 기존 노드를 예약 노드로 변환하려면 어떻게 합니까?

현재 실행하고 있고 예약하고자 하는 노드와 동일한 리전 내에 있는 동일한 노드 클래스를 사용하여 노드 예약을 구매하면 됩니다. 예약을 구매하면 Amazon ElastiCache가 기존 노드에 새로운 시간당 사용 요금을 자동으로 적용합니다.

Q: 예약 노드에 가입하면 약정 기간은 언제부터 시작됩니까? 약정 기간이 종료되면 내 노드는 어떻게 됩니까?

결제 승인이 처리되는 중에 사용자의 요청이 접수되면 예약 노드와 관련된 요금 변경 사항이 적용됩니다. AWS 계정 활동 페이지 또는 DescribeReservedCacheNodes API를 사용하여 예약 상태를 확인할 수 있습니다. 다음 청구 기간에 일시불 결제가 승인되지 않는 경우는 할인 요금이 적용되지 않습니다.

예약 기간이 지나면 예약 노드는 노드 클래스와 리전에 해당하는 온디맨드 시간당 사용료로 전환됩니다.

Q: 어느 노드에 예약 노드 요금을 적용할지 제어하려면 어떻게 해야 합니까?

노드를 생성, 수정 및 삭제하기 위한 Amazon ElastiCache API는 온디맨드 노드와 예약 노드를 구분하지 않으므로 둘 다 원활하게 사용할 수 있습니다. 요금을 계산할 때 AWS 시스템이 사용자의 예약 상태를 자동으로 적용하므로 해당하는 모든 노드에 저렴한 시간당 예약 캐시 노드 요금이 부과됩니다.

Q: 리전 또는 가용 영역 간에 예약 노드를 이동할 수 있습니까?

각 예약 노드는 특정 리전과 연결되어 있으며 이는 예약의 수명 기간 동안 고정되어 변경할 수 없습니다. 그러나 각 예약은 연결된 리전 내의 모든 가용 영역에서 사용할 수 있습니다.

Q: 예약을 취소할 수 있습니까?

예약 노드에 대해 일시불로 결제한 비용은 환불되지 않습니다. 하지만 언제든지 노드를 종료하도록 선택할 수 있으며, Light 및 Medium 사용률 예약 노드를 사용하고 있는 경우 종료를 선택한 시점부터 시간당 사용 요금이 더는 부과되지 않습니다.


Q: Amazon ElastiCache 액세스를 어떻게 제어합니까?

VPC를 사용하지 않는 경우 Amazon ElastiCache를 사용하면 캐시 보안 그룹을 통해 클러스터에 대한 액세스를 제어할 수 있습니다. 보안 그룹은 클러스터에 대한 네트워크 액세스를 제어하는 방화벽 역할을 합니다. 기본적으로 클러스터에 대한 네트워크 액세스는 비활성화되어 있습니다. 애플리케이션이 클러스터에 액세스할 수 있도록 하려면 특정 EC2 보안 그룹에 있는 호스트에서 액세스를 명시적으로 활성화해야 합니다. 이 프로세스를 수신이라고 합니다.

클러스터에 대한 네트워크 액세스를 허용하려면 보안 그룹을 생성하고, 해당 보안 그룹에 원하는 EC2 보안 그룹을 연결하십시오(이를 통해 허용할 EC2 인스턴스를 지정). 보안 그룹은 클러스터를 생성할 때 연결하거나, AWS Management Console의 "Modify" 옵션을 이용해 연결할 수 있습니다.

현재 IP 범위 기반 액세스 제어는 클러스터에 사용할 수 없습니다. 클러스터에 액세스하는 모든 클라이언트는 EC2 네트워크 내에 있어야 하며 위에 설명한 보안 그룹을 통해 승인을 받아야 합니다.

VPC를 사용할 경우, 자세한 내용은 여기를 참조하십시오.

Q: 자체 데이터 센터에 있는 서버에서 실행 중인 프로그램이 Amazon ElastiCache에 액세스할 수 있습니까?

아니요. 현재로서는 캐시 클러스터에 액세스하는 모든 클라이언트가 Amazon EC2 네트워크에 위치해야 하며, 여기에서 설명한 대로 보안 그룹을 통해 인증되어야 합니다.

Q: VPC의 EC2 인스턴스에서 실행 중인 프로그램이 Amazon ElastiCache에 액세스할 수 있습니까?

예, Amazon ElastiCache 클러스터가 VPC 내에 만들어지지 않은 경우 VPC의 EC2 인스턴스는 Amazon ElastiCache에 액세스할 수 있습니다. VPC 내에 Amazon ElastiCache 클러스터를 만드는 방법에 대한 자세한 내용은 여기를 참조하십시오.

Q: Amazon Virtual Private Cloud(VPC)란 무엇이며 Amazon ElastiCache와 함께 사용해야 하는 이유는 무엇입니까?

Amazon VPC를 사용하면 Amazon Web Services(AWS) 클라우드의 격리된 프라이빗 공간에 가상 네트워킹 환경을 만들 수 있습니다. 이 환경에서 프라이빗 IP 주소 범위, 서브넷, 라우팅 테이블, 네트워크 게이트웨이 등 다양한 사항을 완벽하게 제어할 수 있습니다. Amazon VPC를 사용하여 가상 네트워크 토폴로지를 정의하고 자체 데이터 센터에서 운영하는 IP 네트워크와 흡사하게 네트워크 설정을 사용자 정의할 수 있습니다.

VPC에서 Amazon ElastiCache를 사용하는 사례로, 퍼블릭 웹 애플리케이션을 실행하는 동시에 프라이빗 서브넷에서는 공개적으로 액세스할 수 없는 벡엔드 서버를 유지 관리하는 경우를 들 수 있습니다. 인터넷에 액세스할 수 있는 웹 서버에 퍼블릭 서브넷을 만들고 인터넷에 액세스할 수 없는 프라이빗 서브넷에 벡엔드 인프라를 배포할 수 있습니다. 백엔드 인프라에는 인 메모리 계층을 제공하는 Amazon ElastiCache 클러스터와 RDS DB 인스턴스가 포함될 수 있습니다. Amazon VPC에 대한 자세한 내용은 Amazon Virtual Private Cloud User Guide를 참조하십시오.

Q: VPC에 Amazon ElastiCache 클러스터 인스턴스를 생성하려면 어떻게 해야 합니까?

VPC에 Amazon ElastiCache 클러스터를 만드는 방법은 Amazon ElastiCache User Guide를 참조하십시오.

다음은 VPC 내에 클러스터를 생성하는 데 필요한 사전 조건입니다.

  • 최소한 하나 이상의 서브넷으로 설정된 VPC가 있어야 합니다. Amazon VPC 및 서브넷을 만드는 방법은 Amazon VPC 시작 안내서를 참조하십시오.
  • VPC에 서브넷 그룹을 정의해야 합니다.
  • VPC에 VPC 보안 그룹을 정의해야 합니다(또는 제공된 기본값을 사용할 수 있음).
  • 또한 각 서브넷에 올바른 크기의 CIDR 블록을 할당해야 합니다. 그래야 캐시 노드 대체 등의 유지 관리 작업 중에 Amazon ElastiCache가 사용할 수 있는 충분한 IP 주소가 확보됩니다.

Q: 기존 VPC에 Amazon ElastiCache 클러스터 인스턴스를 생성하려면 어떻게 합니까?

기존 VPC에 Amazon ElastiCache 클러스터를 만드는 것은 새로 만든 VPC에 해당 클러스터를 만드는 것과 같습니다. 자세한 내용은 여기를 참조하십시오.

Q: VPC의 ElastiCache 노드에 연결하려면 어떻게 합니까?

VPC에 배포된 Amazon ElastiCache 노드는 동일한 VPC에 배포된 EC2 인스턴스에서 액세스할 수 있습니다. 이러한 EC2 인스턴스가 엘라스틱 IP가 연결된 퍼블릭 서브넷에 배포된 경우 인터넷을 통해 EC2 인스턴스에 액세스할 수 있습니다.

인터넷 또는 VPC 외부의 EC2 인스턴스로부터 VPC 내부에 배포된 Amazon ElastiCache Nodes에 액세스하려면 여기에 있는 지침을 참조하십시오.

기본 IP 주소가 변경될 수 있으므로(예: 캐시 노드 대체 후) ElastiCache 노드에 연결할 때 DNS 이름을 사용하는 것이 좋습니다.

Q: 서브넷 그룹이란 무엇이며 왜 필요합니까?

서브넷 그룹은 VPC의 Amazon ElastiCache 클러스터에 대해 지정해야 하는 서브넷의 집합입니다. 서브넷 그룹은 Amazon ElastiCache Console을 사용하여 생성합니다. 각 서브넷 그룹은 하나 이상의 서브넷을 포함해야 합니다. Amazon ElastiCache는 서브넷 그룹을 사용하여 서브넷을 선택합니다. 그러면 선택한 서브넷의 IP 주소가 노드 엔드포인트에 연결됩니다. 또한, Amazon ElastiCache는 탄력적 네트워크 인터페이스를 만든 후 앞서 언급한 IP 주소가 지정된 노드에 이를 연결합니다.

기본 IP 주소가 변경될 수 있으므로(예: 캐시 노드 교체 후) 노드에 연결할 때 DNS 이름을 사용하는 것이 좋습니다.

Q: 내 ElastiCache 클러스터의 서브넷 그룹을 변경할 수 있습니까?

기존 서브넷 그룹을 업데이트하여 기존 가용 영역 또는 ElastiCache 클러스터를 만든 후 새로 만든 가용 영역에 서브넷을 추가할 수 있습니다. 그러나 배포된 클러스터의 서브넷 그룹 변경은 현재 허용되지 않습니다.

Q: VPC에서 Amazon ElastiCache를 사용하는 경우와 VPC 외부에서 사용하는 경우의 차이점은 무엇입니까?

Amazon ElastiCache의 기본 기능은 VPC 사용 여부와 관계없이 동일합니다. Amazon ElastiCache는 ElastiCache 클러스터가 VPC 내부 또는 외부 중 어디에 있든 관계없이 자동 고장 감지, 복구, 조정, 자동 검색 및 소프트웨어 패칭을 관리합니다.

VPC 내의 ElastiCache 클러스터 노드만 프라이빗 IP 주소(정의한 서브넷 내)를 갖습니다. VPC 외부에서는 여기 설명된 대로 보안 그룹을 사용하여 ElastiCache 클러스터에 대한 액세스를 제어할 수 있습니다.

Q: VPC 외부의 기존 ElastiCache 클러스터를 내 VPC로 이동할 수 있습니까?

아니요, 기존 Amazon ElastiCache 클러스터를 VPC 외부에서 내부로 이동할 수 없습니다. VPC 내에 새 Amazon ElastiCache 클러스터를 만들어야 합니다.

Q: 기존 ElastiCache 클러스터를 VPC 내부에서 외부로 이동할 수 있습니까?

현재 ElastiCache 클러스터를 VPC 내부에서 외부로 직접 마이그레이션하는 기능은 지원되지 않습니다. VPC 외부에 새 Amazon ElastiCache 클러스터를 만들어야 합니다.

Q: 내 클러스터에 대한 네트워크 액세스를 제어하려면 어떻게 해야 합니까?

Amazon ElastiCache를 사용하면 VPC 외부 배포의 경우에 보안 그룹을 사용하여 클러스터, 즉 노드에 대한 액세스를 제어할 수 있습니다. 보안 그룹은 노드에 대한 네트워크 액세스를 제어하는 방화벽 역할을 합니다. 기본적으로 노드에 대한 네트워크 액세스는 비활성화되어 있습니다. 애플리케이션이 노드에 액세스할 수 있도록 하려면 특정 EC2 보안 그룹 멤버십 또는 IP 범위에 해당하는 EC2 인스턴스에서만 액세스할 수 있도록 보안 그룹을 설정하면 됩니다. 이 프로세스를 수신이라고 합니다. 보안 그룹에 수신이 설정되면 동일한 규칙이 해당 보안 그룹에 연결된 모든 노드에 적용됩니다. 보안 그룹은 AWS ElastiCache Console의 “Security Groups” 섹션 또는 Amazon ElastiCache API를 사용하여 설정할 수 있습니다.

VPC 배포의 경우에는 VPC 보안 그룹과 서브넷 그룹을 사용하여 노드에 대한 액세스를 제어합니다. VPC 보안 그룹은 VPC에서 사용하는 보안 그룹입니다.

Q: 애플리케이션이 VPC에 있는 ElastiCache 노드에 액세스할 수 있도록 하려면 어떤 점에 주의해야 합니까?

라우팅 테이블과 VPC의 네트워킹 ACL을 변경하여, VPC의 클라이언트 인스턴스에서 ElastiCache 노드에 도달할 수 있도록 해야 합니다. 자세한 내용은 Amazon ElastiCache 설명서를 참조하시기 바랍니다.

Q: 보안 그룹을 사용하여 내 VPC의 일부인 클러스터를 구성할 수 있습니까?

아니요, 보안 그룹은 VPC에서 운영할 때는 사용하지 않습니다. 대신에 VPC가 아닌 설정에서 사용합니다. VPC에서 클러스터를 만들 때는 VPC 보안 그룹을 사용해야 합니다.

Q: 일반 EC2 보안 그룹을 VPC 내에서 시작되는 클러스터에 연결할 수 있습니까?

아니요. 클러스터와 동일한 VPC에 있는 VPC 보안 그룹만 연결할 수 있습니다.

Q: ElastiCache 클러스터의 노드를 여러 서브넷으로 확장할 수 있습니까?

예. 생성 시에 ElastiCache 클러스터와 연결된 동일한 서브넷 그룹의 서브넷에 한해서 Amazon ElastiCache 클러스터의 노드를 여러 서브넷으로 확장할 수 있습니다.


Q: 파라미터 그룹이란 무엇입니까? 어떤 면에서 유용합니까?

파라미터 그룹은 엔진 구성 값의 “컨테이너” 역할을 하며 하나 이상의 클러스터에 적용할 수 있습니다. 파라미터 그룹을 지정하지 않고 클러스터를 생성하는 경우 기본 파라미터 그룹이 사용됩니다. 이 기본 그룹에는 실행하는 클러스터에 최적화된 엔진 기본값과 Amazon ElastiCache 시스템 기본값이 포함됩니다. 그러나 사용자 정의 엔진 구성 값을 사용해 클러스터를 실행하려면 새 파라미터 그룹을 만들고, 원하는 파라미터를 수정하고, 새 파라미터 그룹을 사용하도록 클러스터를 수정하기만 하면 됩니다. ++연결이 이루어지면 특정 파라미터 그룹을 사용하는 모든 클러스터가 해당 파라미터 그룹에 대한 모든 파라미터 업데이트를 가져옵니다. 파라미터 그룹 구성에 대한 자세한 내용은 Amazon ElastiCache User Guide를 참조하십시오.

Q: 내 클러스터에 적합한 구성 파라미터를 선택하려면 어떻게 해야 합니까?

Amazon ElastiCache는 기본적으로 노드 유형의 메모리/컴퓨팅 리소스 용량을 고려해 클러스터에 최적인 구성 파라미터를 선택합니다. 하지만 파라미터를 변경하고 싶다면 구성 관리 API를 사용하면 됩니다. 다만 구성 파라미터를 권장값에서 변경하면 성능 저하에서 시스템 작동 중단에 이르기까지 예기치 않은 결과가 발생할 수 있으므로, 이러한 위험을 충분히 인식하고 있는 고급 사용자만 이 작업을 시도하는 게 좋습니다. 파라미터 변경에 대한 자세한 내용은 Amazon ElastiCache User Guide를 참조하십시오.

Q: 특정 파라미터 그룹에 대한 내 파라미터의 현재 설정을 보려면 어떻게 해야 합니까?

AWS Management Console, Amazon ElastiCache API 또는 명령줄 도구를 사용하여 파라미터 그룹 및 해당 파라미터 설정 정보를 확인할 수 있습니다.


Q: Memcached용 Amazon ElastiCache를 사용해 무엇을 캐싱할 수 있습니까?

영구 데이터 스토어(Amazon RDS, DynamoDB 또는 EC2에 호스팅된 자가 관리형 데이터베이스 등)에 저장된 콘텐츠부터 동적으로 생성된 웹 페이지(예: Nginx로 생성한 웹 페이지) 또는 영구 백업 스토어가 필요 없는 일시적 세션 데이터까지 매우 다양한 객체를 캐싱할 수 있습니다. 또한, 이 서비스로 고빈도 카운터를 구현하여 대용량 웹 애플리케이션에 허용 제어 기능을 배포할 수 있습니다.

Q: Memcached용 Amazon ElastiCache를 Amazon RDS 또는 Amazon DynamoDB 같은 AWS 영구 데이터 스토리지와 함께 사용할 수 있습니까?

예. Amazon ElastiCache는 Amazon RDS 또는 Amazon DynamoDB와 같은 데이터 스토리지에 적합한 프런트 엔드로서, 매우 높은 요청 비율 및/또는 짧은 지연 시간이 필요한 애플리케이션에 고성능 미들 티어를 제공합니다.

Q: 현재 Memcached를 이용 중입니다. Amazon ElastiCache로 어떻게 마이그레이션합니까?

Amazon ElastiCache는 Memcached와 프로토콜이 호환됩니다. 그래서 기존 Memcached에서 하던 것과 똑같이 get, set, incr, decr 등의 표준 Memcached 작업을 이용하면 됩니다. Amazon ElastiCache는 텍스트 프로토콜과 바이너리 프로토콜을 모두 지원합니다. 대부분의 표준 통계 결과도 CloudWatch에서 그래프로 볼 수 있도록 지원하고 있습니다. 덕분에 애플리케이션을 재컴파일하거나 재링크할 필요 없이 Amazon ElastiCache로 쉽게 이전할 수 있습니다. 물론 기존 라이브러리도 그대로 사용 가능합니다. 애플리케이션이 액세스하는 캐시 서버를 구성하려면, AWS가 프로비저닝한 서버(노드)의 엔드포인트가 포함되도록 애플리케이션의 Memcached config 파일을 업데이트하기만 하면 됩니다. 엔드포인트 목록은 AWS Management Console의 "Copy Node Endpoints" 옵션 또는 "DescribeCacheClusters" API를 이용하면 쉽게 받을 수 있습니다. 다른 마이그레이션 프로세스와 마찬가지로, 현재 솔루션으로부터의 이전을 완료하기 전에 새 Amazon ElastiCache 배포를 철저히 테스트하는 것이 좋습니다.

Amazon ElastiCache에서는 현재 Amazon EC2 네트워크를 통한 액세스만 허용하므로, 서비스를 사용하려면 애플리케이션 서버가 Amazon EC2에 있어야 합니다.

Amazon ElastiCache는 DNS 항목을 통해 클라이언트 애플리케이션이 서버(노드)를 찾을 수 있도록 지원합니다. 노드의 DNS 이름은 그대로 유지됩니다. 하지만 예를 들어 VPC 외 설치에서 장애가 발생한 후에는 노드가 자동으로 교체되므로 IP 주소는 시간이 지나면서 바뀔 수 있습니다. 노드 장애에 대처하는 방법에 대한 권장 사항은 이 FAQ를 참조하십시오.


Q: 내 애플리케이션에 적합한 노드 유형을 선택하려면 어떻게 해야 합니까?

이 질문에는 정확한 답을 드리기 어렵지만, Amazon ElastiCache의 경우 언제든 손쉽게 노드를 추가하거나 제거할 수 있으므로 정확히 몇 개의 노드를 사용해야 하는지 고민하지 않아도 됩니다. 최초 구성 시에는 다음과 같은 서로 관련된 두 가지 측면을 고려해 선택할 수 있습니다.

  • 목표 캐시 적중률을 달성하는 데 필요한 총 메모리
  • 노드 장애가 발생하더라도 데이터베이스 백엔드에 과부하가 걸릴 염려 없이 원하는 애플리케이션 성능을 유지하는 데 필요한 노드 수

필요한 메모리 양은 데이터 세트 크기와 애플리케이션의 액세스 패턴에 따라 달라집니다. 내결함성을 높이려면 필요한 총 메모리를 대강 계산한 다음, 노드 한두 개에 장애가 생기더라도 애플리케이션 작동에 문제가 없을 만큼 충분한 수의 노드로 총 메모리를 나누십시오. 예를 들어, 필요한 메모리가 13GB라면 cache.m4.xlarge 노드 하나보다는 cache.m4.large 노드 두 개를 사용하는 것이 좋습니다. 노드 한두 개의 장애 복구 때문에 캐시 적중률이 잠깐 떨어지더라도 데이터베이스 등의 기타 시스템에 과부하가 걸리지 않게 하는 것이 중요합니다. 자세한 내용은 Amazon ElastiCache User Guide를 참조하십시오.

Q: 클러스터를 여러 가용 영역으로 확장할 수 있습니까?

예. 클러스터를 생성하거나 기존 클러스터에 노드를 추가할 때 새로운 노드에 대한 가용 영역을 선택할 수 있습니다. 각 가용 영역에서 요청 노드 수를 지정하거나 '영역에 걸쳐 노드를 분산'하도록 선택할 수 있습니다. 클러스터가 VPC에 있는 경우 선택한 캐시 서브넷 그룹 일부분인 가용 영역 내에만 노드를 배치할 수 있습니다. 자세한 내용은 ElastiCache VPC 설명서를 참조하십시오.

Q: Amazon ElastiCache Memcached에서는 리전당 몇 개의 노드를 실행할 수 있습니까?

리전당 최대 100개까지 노드를 실행할 수 있습니다. 노드가 더 필요하면 ElastiCache 한도 증가 요청 양식을 작성해 주십시오.

Q: Amazon ElastiCache는 노드 장애에 어떻게 대응합니까?

Amazon ElastiCache에서 노드 장애를 감지하면 다음과 같이 자동으로 대응합니다.

  • Redis용 Amazon ElastiCache가 새 서비스 리소스를 확보하여 노드를 복구한 다음, 해당 노드의 기존 DNS 이름을 새 서비스 리소스로 리디렉션합니다. VPC 설치의 경우, 노드가 장애에서 복구될 때 ElastiCache는 DNS 이름과 IP 주소가 모두 그대로 유지되도록 해줍니다. VPC 외 설치의 경우, ElastiCache는 노드의 DNS 이름이 그대로 유지되도록 해주지만, 노드의 해당 IP 주소는 변경될 수 있습니다.
  • 클러스터에 SNS 주제를 연결해 둔 경우 새 노드를 구성해 사용할 준비가 되면 Amazon ElastiCache가 SNS 알림을 보내 노드 복구가 진행되었음을 알려줍니다. 원한다면 Memcached 클라이언트 라이브러리가 복구된 노드로 다시 연결되도록 애플리케이션을 설정할 수도 있는데, 이는 서버와의 커뮤니케이션 오류나 제한 시간 초과가 발생할 경우 간혹 Memcached 라이브러리가 서버(노드) 사용을 무기한으로 중단할 수도 있으므로 중요합니다.

Q: 애플리케이션을 지원할 메모리가 더 필요한 경우 Amazon ElastiCache의 총 메모리를 늘리려면 어떻게 해야 합니까?

AWS Management Console에서 사용 중인 캐시 클러스터에 대한 "Nodes" 탭의 "Add Node" 옵션을 사용하거나 ModifyCacheCluster API를 호출해 기존 Memcached 클러스터에 노드를 더 추가하면 됩니다.


Q: Amazon ElastiCache는 다른 Amazon Web Services와 어떻게 상호 작용합니까?

Amazon ElastiCache는 Amazon RDS 및 Amazon DynamoDB와 같은 Amazon Web Services의 프런트 엔드로 매우 적합하며, 고성능 애플리케이션에 매우 짧은 지연 시간을 제공하고 요청 볼륨의 부담을 일부 줄여줍니다. 반면에 이러한 서비스는 지속적인 데이터 내구성을 제공합니다. Amazon EC2 및 EMR과 함께 애플리케이션 성능을 개선하는 데에도 유용합니다.

Q: Amazon ElastiCache에 더 적합한 특정 프로그래밍 언어가 있습니까?

Memcached 클라이언트 라이브러리는 모두는 아니지만 대부분 주요 프로그래밍 언어에서 사용할 수 있습니다. Memcached 클라이언트에 대한 자세한 내용은 여기를 참조하십시오. Amazon ElastiCache를 사용하는 중 특정 Memcached 클라이언트에 문제가 생기면 Amazon ElastiCache 커뮤니티 포럼을 통해 당사에 알려 주시기 바랍니다.

Q: Amazon ElastiCache와 호환되는 주요 Memcached 라이브러리는 무엇입니까?

Amazon ElastiCache는 특정 클라이언트 라이브러리를 요구하지 않고, 재컴파일 또는 애플리케이션 재링크 없이도 기존 Memcached 클라이언트 라이브러리와 이상 없이 작동합니다. 호환되는 라이브러리의 예로는 libMemcached(C) 및 이를 기반으로 한 라이브러리(예: PHP, Perl, Python), spyMemcached(Java), 그리고 fauna(Ruby)가 있습니다.


Q: 자동 검색이란 무엇이며 이 기능으로 무엇을 할 수 있습니까?

자동 검색은 개발자의 시간과 노력을 덜어주고 동시에 애플리케이션의 복잡성을 줄여주는 기능입니다. 자동 검색을 사용하면 Amazon ElastiCache 클러스터에서 노드를 추가하거나 삭제할 때 클라이언트별로 캐시 노드를 자동 검색할 수 있습니다. 현재까지는 개발자가 캐시 노드 엔드포인트의 목록을 수동으로 업데이트해야 클러스터 멤버십 변경 사항을 처리할 수 있습니다. 클라이언트 애플리케이션이 설계된 방식에 따라 대개 애플리케이션을 종료했다가 다시 시작하는 클라이언트 초기화 과정이 필요하고, 이로 인해 가동 중지 시간이 발생하게 됩니다. 하지만 자동 검색을 통해 이러한 복잡성이 제거되었습니다. 또한 자동 검색을 사용하면 Memcached 프로토콜의 이전 버전 프로토콜과 호환될 뿐 아니라 Amazon ElastiCache가 캐시 클러스터 멤버십에 대한 정보를 클라이언트에 제공합니다. 추가 정보를 처리할 수 있는 클라이언트는 초기화하지 않고도 Amazon ElastiCache 클러스터의 최신 노드를 사용하도록 스스로 재구성됩니다.

Q: 자동 검색은 어떻게 작동합니까?

Amazon ElastiCache 클러스터는 여러 노드와 함께 생성될 수 있으며 각 노드는 이름이 지정된 엔드포인트를 통해 주소가 지정됩니다. 또한 자동 검색을 사용하는 경우에는 Amazon ElastiCache 클러스터에 클러스터가 존재하는 동안 유효한 DNS 레코드인 고유한 구성 엔드포인트가 지정됩니다. 이 DNS 레코드에는 클러스터에 속한 노드의 DNS 이름이 포함됩니다. Amazon ElastiCache는 구성 엔드포인트가 항상 이러한 “대상” 노드를 하나 이상 가리키도록 합니다. 대상 노드를 쿼리하면 해당 클러스터의 모든 노드에 대한 엔드포인트가 반환됩니다. 그런 다음 이전과 동일하게 클러스터 노드에 연결할 수 있고 get, set, incr 및 decr과 같은 Memcached 프로토콜 명령을 사용할 수 있습니다. 자세한 내용은 여기를 참조하십시오. 자동 검색을 사용하려면 자동 검색이 지원되는 클라이언트가 필요합니다. Java 및 PHP용 자동 검색 클라이언트는 Amazon ElastiCache 콘솔에서 다운로드할 수 있습니다. 초기화하는 동안 해당 클라이언트는 구성 엔드포인트를 사용하여 Amazon ElastiCache 클러스터의 현재 구성원을 자동으로 확인합니다. 노드를 추가 또는 삭제하여 캐시 클러스터를 변경하거나 장애 발생으로 노드가 대체되는 경우 자동 검색 클라이언트가 자동으로 변경 사항을 확인하므로 클라이언트를 수동으로 초기화할 필요가 없습니다.

Q: 자동 검색은 어떻게 시작합니까?

시작하려면 Amazon ElastiCache 콘솔에서 “ElastiCache 클러스터 클라이언트 다운로드” 링크를 클릭하여 Amazon ElastiCache 클러스터 클라이언트를 다운로드합니다. 다운로드하려면 Amazon ElastiCache 계정이 있어야 합니다. 아직 계정이 없으면 Amazon ElastiCache 세부 정보 페이지에서 가입할 수 있습니다. 클라이언트를 다운로드한 다음 Amazon ElastiCache 콘솔로 이동하여 Amazon ElastiCache 클러스터를 설정하고 활성화할 수 있습니다. 자세한 내용은 여기에서 확인할 수 있습니다.

Q: 내 ElastiCache 클러스터에서 내 Memcached 클라이언트를 계속 사용하는 경우 이 기능을 사용할 수 있습니까?

아니요, 기존 Memcached 클라이언트로는 자동 검색 기능을 사용할 수 없습니다. 자동 검색 기능을 사용하려면 클라이언트가 구성 엔드포인트를 사용하여 클러스터 노드 엔드포인트를 확인할 수 있어야 합니다. Amazon ElastiCache 클러스터 클라이언트를 사용하거나 기존 Memcached 클라이언트를 확장하여 자동 검색 명령 세트를 포함할 수 있습니다.

Q: 자동 검색을 사용하기 위한 최소 하드웨어/소프트웨어 요구 사항은 무엇입니까?

자동 검색을 이용하려면 자동 검색이 지원되는 클라이언트를 사용하여 Amazon ElastiCache 클러스터에 연결해야 합니다. 현재 Amazon ElastiCache는 Java와 PHP 모두에 대해 자동 검색 사용 클라이언트를 지원합니다. 이러한 클라이언트는 Amazon ElastiCache 콘솔에서 다운로드할 수 있습니다. Amazon 고객은 사용 가능한 주요 Memcached 클라이언트를 구축하여 다른 언어용 클라이언트를 생성할 수 있습니다.

Q: 자동 검색을 지원하도록 내 Memcached 클라이언트를 수정 또는 작성하려면 어떻게 해야 합니까?

Memcached 클라이언트 라이브러리를 받아서 자동 검색에 대한 지원을 추가할 수 있습니다. 자동 검색을 사용하도록 자체 클라이언트를 추가 또는 수정하려면 자동 검색 명령 세트 설명서를 참조하시기 바랍니다.

Q: 자동 검색 기능이 필요하지 않은 경우 기존 Memcached 클라이언트를 계속 사용할 수 있습니까?

예, Amazon ElastiCache는 계속 Memcached 프로토콜과 호환되며 클라이언트를 변경할 필요가 없습니다. 하지만 자동 검색 기능을 이용하기 위해 Memcached 클라이언트 성능을 강화해야 했습니다. Amazon ElastiCache 클러스터 클라이언트를 사용하지 않는 경우 자체 클라이언트를 계속 사용할 수 있습니다. 그렇지 않으면 자동 검색 명령 세트를 이해하도록 자체 클라이언트 라이브러리를 수정하십시오.

Q: 다른 종류의 클라이언트에서도 자동 검색을 사용할 수 있습니까?

예, 자동 검색이 지원되는 클라이언트와 기존 Memcached 클라이언트를 통해 동시에 같은 Amazon ElastiCache 클러스터에 연결할 수 있습니다. Amazon ElastiCache는 Memcached와 100% 호환됩니다.

Q: 자동 검색의 사용을 중지할 수 있습니까?

예, 언제든지 자동 검색의 사용을 중지할 수 있습니다. Amazon ElastiCache 클러스터 클라이언트를 초기화하는 동안 운영 모드를 지정하여 자동 검색의 사용을 중지할 수 있습니다. 또한 Amazon ElastiCache가 계속 Memcached를 100% 지원하므로 이전과 마찬가지로 모든 Memcached 프로토콜 호환 클라이언트를 사용할 수 있습니다.


Q: Amazon ElastiCache 클러스터를 지원하는 엔진 버전을 새 지원 버전으로 업그레이드할지와 그 시기를 제어할 수 있습니까?

Amazon ElastiCache를 사용하면 클러스터를 지원하는 Memcached 프로토콜 호환 소프트웨어를 Amazon ElastiCache가 지원하는 새 버전으로 업그레이드할지와 그 시기를 제어할 수 있습니다. 이런 유연성 덕분에 특정 Memcached 버전과의 호환성은 그대로 유지하면서 프로덕션 환경에 배포하기 전에 애플리케이션에서 새 버전을 테스트해 보고, 원하는 조건과 일정에 맞춰 버전 업그레이드를 수행할 수 있습니다. 버전 업그레이드는 몇 가지의 호환성 위험이 있어 자동으로 이루어지지 않으며, 사용자가 직접 시작해야 합니다. 이 방식의 소프트웨어 패치에서는 버전 업그레이드를 사용자가 주도해서 관리해야 하지만 Amazon ElastiCache에 대한 패치 애플리케이션의 작업 부담은 크게 줄어듭니다. 버전 관리에 대한 자세한 내용은 해당 FAQ를 참조하십시오. Amazon ElastiCache User Guide를 참조해도 됩니다. 엔진 버전 관리 기능은 사용자에게 패치 진행 방법에 대해 최대한의 제어 권한을 주지만 시스템이나 캐시 소프트웨어에서 보안 취약성이 감지되는 경우에는 AWS에서 클러스터를 자동으로 패치할 수도 있습니다.

Q: 지원되는 Memcached 버전 중 클러스터를 어느 버전에서 실행할지 어떻게 지정합니까?

현재 지원되는 버전(부 및/또는 주 버전) 중 어느 버전으로 할지는 새 클러스터를 생성할 때 지정할 수 있습니다. 지원되는 엔진 버전 릴리스로 업그레이드를 시작하려면 클러스터의 "Modify" 옵션을 사용하면 됩니다. "Cache Engine Version" 필드에서 원하는 업그레이드 버전을 지정하기만 하면 됩니다. 그러면 업그레이드가 즉시("Apply Immediately" 옵션을 선택한 경우) 진행되거나 클러스터에 대해 예약된 다음 유지 관리 기간 동안 진행됩니다.

Q: 업그레이드하기 전에 새 버전에 대해 내 클러스터를 테스트할 수 있습니까?

예. 새 클러스터를 새 엔진 버전으로 생성하면 됩니다. 개발/스테이징 애플리케이션을 이 클러스터로 연결해 놓고 테스트한 다음, 기존 클러스터를 업그레이드할지 결정할 수 있습니다.

Q: Amazon ElastiCache는 새로운 버전 릴리스 지원에 대한 지침과 현재 지원되고 있는 Memcached 버전의 폐지에 대한 지침을 제공합니까?

앞으로 주 버전과 부 버전 모두 더 많은 Memcached 버전을 Amazon ElastiCache에서 지원하도록 할 계획입니다. 특정 연도에 몇 개의 새 버전 릴리스를 지원할지는 Memcached 버전 릴리스의 빈도와 내용, 그리고 당사 엔지니어링 팀의 철저한 릴리스 검사 결과에 따라 달라질 수 있습니다. 그러나 일반적인 기준으로는 정식 출시 후 3~5개월 이내에 새로운 Memcached 버전을 지원하는 것이 목표입니다.

Q: Amazon ElastiCache에서 지원하는 Memcached 전송 프로토콜 버전은 무엇입니까?

Amazon ElastiCache는 Memcached 버전 1.4.5, 1.4.14, 1.4.24, 1.4.33 및 1.4.34의 Memcached 텍스트 및 바이너리 프로토콜을 지원합니다.

Q: 최신 Memcached 버전으로 업그레이드하려면 어떻게 해야 합니까?

Modify 프로세스를 사용하면 기존 Memcached 클러스터를 업그레이드할 수 있습니다. 이전 버전의 Memcached에서 Memcached 버전 1.4.33 이상으로 업그레이드할 때는 기존 매개변수인 max_chunk_size 값이 slab_chunk_max 매개변수에 필요한 조건을 만족하는지 확인하시기 바랍니다. 업그레이드 전제 조건은 여기에서 살펴보시기 바랍니다.


Q: Redis용 Amazon ElastiCache란 무엇입니까?

Redis용 Amazon ElastiCache는 클라우드에서 Redis 프로토콜 호환 서버 노드를 쉽게 배포 및 실행할 수 있도록 하는 웹 서비스입니다. 이 서비스를 통해 Redis 노드 관리, 모니터링 및 작업을 수행할 수 있으며 ElastiCache 콘솔, 명령줄 인터페이스 또는 웹 서비스 API를 통해 노드 만들기, 삭제 및 수정을 수행할 수 있습니다. Redis용 Amazon ElastiCache는 Redis 마스터/슬레이브 복제를 지원합니다.

Q: Redis용 Amazon ElastiCache는 오픈 소스 Redis 프로토콜과 호환됩니까?

예, Redis용 Amazon ElastiCache는 오픈 소스 Redis 프로토콜과 호환됩니다. 현재 고객이 기존 독립 실행형 데이터 스토리지에서 사용하는 코드, 애플리케이션, 드라이버 및 도구를 계속해서 Redis용 ElastiCache에서 사용할 수 있으므로 별도로 언급하지 않는 한 Redis용 ElastiCache로 마이그레이션되는 기존 Redis 배포에서 코드를 변경할 필요가 없습니다. Amazon ElastiCache는 현재 Redis 2.8.21, 2.8.22, 2.8.23, 2.8.24 및 3.2.4를 지원합니다.

Q: Redis용 Amazon ElastiCache 노드 및 샤드란 무엇입니까?

Amazon ElastiCache 노드는 Redis용 ElastiCache 클러스터 배포의 가장 작은 빌딩 블록입니다. 각 노드는 Amazon이 제공하는 향상된 Redis 프로토콜을 지원하며, 자체 엔드포인트와 포트가 있습니다. 다양한 유형의 노드가 지원되며, 유형별로 CPU 용량과 메모리 용량이 다릅니다.

샤드는 논리적 키 공간의 파티션 역할을 하는 하나 이상의 노드로 구성된 집합입니다. 샤드 내에서 노드는 별도로 존재하거나 다른 노드와 기본/복제 관계로 존재할 수 있습니다. 샤드 내에 여러 개의 노드가 있는 경우 노드 중 하나가 읽기/쓰기 기본 역할을 수행하고 모든 다른 노드는 읽기 전용 복제본 역할을 합니다.

Q: Redis용 Amazon ElastiCache가 Redis 지속성을 지원합니까?

예. 백업 및 복원 기능을 사용하여 Redis 데이터의 스냅샷을 생성함으로써 지속성을 유지할 수 있습니다. 자세한 내용은 여기를 참조하십시오.

Q: Memcached용 Amazon ElastiCache에서 Redis용 Amazon ElastiCache로 또는 그 반대로 마이그레이션할 수 있습니까?

현재, Memcached에서 Redis로 또는 그 반대로 자동 마이그레이션을 지원하지 않습니다. 그러나 Memcached 클라이언트를 사용하여 Memcached 클러스터에서 읽고 Redis 클라이언트를 사용하여 Redis 클러스터에 쓸 수 있습니다. 마찬가지로 Redis 클라이언트를 사용하여 Redis 클러스터에서 읽고 Memcached 클라이언트를 사용하여 Memcached 클러스터에 쓸 수 있습니다. 이때, 데이터 형식의 차이와 두 엔진 간의 클러스터 구성을 고려해야 합니다.

Q: Redis용 Amazon ElastiCache가 다중 AZ 작업을 지원합니까?

예, Redis용 Amazon ElastiCache를 사용하면 다른 AWS 가용 영역에서 읽기 전용 복제본을 만들 수 있습니다. 기본 노드에서 오류가 발생하면 새로운 기본 노드가 프로비저닝됩니다. 기본 노드를 프로비저닝할 수 없는 시나리오에서는 새 기본 노드로 승격할 읽기 전용 복제본을 결정할 수 있습니다. 노드 오류를 처리하는 방법에 대한 자세한 내용은 여기를 참조하십시오.

Q: Redis용 Amazon ElastiCache에서는 노드 오류에 대해 어떤 옵션을 제공합니까?

Redis용 Amazon ElastiCache가 새 서비스 리소스를 획득해 캐시 노드를 복구한 다음, 해당 노드의 기존 DNS 이름을 새 서비스 리소스로 리디렉션합니다. 그렇기 때문에 Redis 노드의 DNS 이름은 항상 그대로지만 Redis 노드의 IP 주소는 수시로 바뀔 수 있습니다. 하나 이상의 읽기 전용 복제본이 포함된 복제 그룹이 있고 다중 AZ가 활성화된 상태에서 기본 노드 오류가 발생하면 ElastiCache가 오류를 자동으로 감지하고 복제본을 하나 선택하여, 이 복제본을 새로운 기본 복제본으로 승격시킵니다. 또한 기본 엔드포인트를 계속 사용할 수 있도록 DNS를 전파하고, 승격 이후에는 승격된 새 기본 복제본을 가리킵니다. 자세한 내용은 본 FAQ의 다중 AZ 섹션을 참조하십시오. 다중 AZ가 비활성화된 상태로 Redis 복제 옵션을 선택한 경우 기본 노드 오류가 발생하면 읽기 전용 복제본 노드로 장애 조치를 시작할 수 있는 옵션이 제공됩니다. 장애 조치 대상은 동일한 영역 또는 다른 영역입니다. 원래 영역으로 장애 복구하려면 원래 영역에서 읽기 전용 복제본을 기본 노드로 승격합니다. Redis 클라이언트 라이브러리가 복구된 Redis 서버 노드에 강제로 다시 연결하도록 애플리케이션을 설계할 수 있습니다. 그러면 일부 Redis 라이브러리에서 통신 오류 또는 제한 시간 초과가 발생한 경우 서버 사용을 무한정으로 중지하도록 할 때 유용할 수 있습니다.

Q: 장애 조치는 어떤 기능을 합니까?

다중 AZ가 활성화된 복제 그룹에 대한 장애 조치 작업은 본 FAQ의 다중 AZ 섹션에서 설명합니다.

다중 AZ를 활성화하지 않기로 한 상태에서 Amazon ElastiCache가 기본 노드를 모니터링하는데 기본 노드가 사용할 수 없게 되거나 응답하지 않으면 Redis용 Amazon ElastiCache가 새로운 서비스 리소스를 획득해 노드를 복구한 다음 새 서비스 리소스를 가리키도록 노드의 기존 DNS 이름을 리디렉션합니다. 그렇기 때문에 Redis 노드의 DNS 이름은 항상 그대로지만 Redis 노드의 IP 주소는 수시로 바뀔 수 있습니다. 그러나 기본 노드를 복구할 수 없는 경우(또한 다중 AZ가 비활성화된 경우) 읽기 전용 복제본 중 하나를 새로운 기본 복제본으로 승격할 수 있습니다. 새로운 기본 복제본을 선택하는 방법은 여기를 참조하십시오. 기본 노드 엔드포인트의 DNS 레코드는 승격된 읽기 전용 복제본 노드를 가리키도록 업데이트됩니다. 그런 다음 원래 기본 노드의 AZ에 있는 읽기 전용 복제본 노드가 샤드의 읽기 전용 복제본으로 생성된 후, 이어서 기본 노드가 새로 생성됩니다. 

Q: 기본 노드 오류 중 읽기 전용 복제본을 사용할 수 있습니까?

예, 기본 노드 오류 중 읽기 전용 복제본에서는 계속해서 요청을 제공합니다. 기본 노드가 복구된 노드 또는 승격된 읽기 전용 복제본으로 복원되면 읽기 전용 복제본이 기본 노드에서 캐시 정보를 동기화할 때 잠깐 읽기 전용 복제본이 어떠한 요청도 제공하지 않습니다.

Q: Redis용 Amazon ElastiCache 노드의 파라미터는 어떻게 구성합니까?

파라미터 그룹을 사용하여 Redis 설치를 구성할 수 있으며, 이러한 그룹은 Redis 클러스터에 대해 지정되어 있어야 합니다. 모든 읽기 전용 복제본 클러스터에서는 기본 클러스터의 파라미터 그룹을 사용합니다. Redis 파라미터 그룹은 하나 이상의 Redis 기본 클러스터에 적용 가능한 Redis 구성 값의 “컨테이너” 역할을 합니다. 파라미터 그룹을 지정하지 않고 Redis 기본 클러스터를 생성하면 기본 파라미터 그룹이 사용됩니다. 이 기본 그룹에는 실행하려는 노드 유형의 기본값이 들어 있습니다. 그러나 지정된 구성 값을 사용해 Redis 기본 클러스터를 실행하려면 새 캐시 파라미터 그룹을 만들고, 원하는 파라미터를 수정하고, 새 파라미터 그룹을 사용하도록 기본 Redis 클러스터를 수정하기만 하면 됩니다.

Q: Amazon ElastiCache 콘솔을 통해 Redis에 액세스할 수 있습니까?

예, Redis는 ElastiCache 콘솔에서 엔진 옵션으로 나타납니다. Redis 엔진을 선택하여 시작 마법사를 통해 새 Redis 캐시 클러스터를 만들 수 있습니다. ElastiCache 콘솔을 사용하여 기존 Redis 클러스터를 수정하거나 삭제할 수도 있습니다.

Q: Amazon VPC에서 Redis용 Amazon ElastiCache 클러스터를 만들 수 있습니까?

예, VPC 내에서 Memcached 클러스터를 만들 수 있는 것처럼 VPC 내에서 Redis 클러스터도 만들 수 있습니다. 사용자의 계정이 기본적으로 VPC 계정이면 Redis 클러스터가 사용자의 계정과 연결된 기본 VPC 내에 생성됩니다. ElastiCache 콘솔을 사용하면 클러스터를 만들 때 다른 VPC를 지정할 수 있습니다.

Q: Redis 암호 기능이 Redis용 Amazon ElastiCache에서 지원됩니까?

아니요, Redis용 Amazon ElastiCache는 Redis 암호를 지원하지 않습니다. 이는 구성 파일에 저장된 암호에 대한 고유한 제한 사항 때문입니다. Redis 암호를 사용하는 대신 Redis용 ElastiCache 클러스터는 EC2 보안 그룹과 연결되어 이 보안 그룹 내의 클라이언트만 Redis 서버에 액세스할 수 있습니다.

Q: 새로운 버전의 엔진으로 업그레이드하려면 어떻게 해야 합니까?

ModifyCacheCluster 또는 ModifyReplicationGroup API를 사용하여 엔진 버전 파라미터를 원하는 엔진 버전으로 지정하면 손쉽게 새로운 버전의 엔진으로 업그레이드할 수 있습니다. ElastiCache 콘솔에서, 클러스터를 선택한 후 "Modify"를 클릭합니다. "Modify" 창에서 제공된 옵션 중 원하는 엔진 버전을 선택합니다. 엔진 업그레이드 프로세스는 가능한 한 기존 데이터를 유지하도록 설계되었으며 Redis 복제가 성공해야 합니다. 자세한 내용은 여기를 참조하십시오.

Q: 이전 엔진 버전으로 다운그레이드할 수 있습니까?

아니요. 이전 엔진 버전으로 다운그레이드는 지원되지 않습니다.

Q: 더 큰 노드 유형으로 확장하려면 어떻게 해야 합니까?

ModifyCacheCluster 또는 ModifyReplicationGroup API를 사용하여 CacheNodeType 파라미터를 원하는 노드 유형으로 지정하면 손쉽게 더 큰 노드 유형으로 확장할 수 있습니다. ElastiCache 콘솔에서, 캐시 클러스터 또는 복제 그룹을 선택한 후 "Modify"를 선택합니다. "Modify" 창에서 제공된 옵션 중 원하는 노드 유형을 선택합니다. 확장 프로세스는 가능한 한 기존 데이터를 유지하도록 설계되었으며 Redis 복제가 성공해야 합니다. 자세한 내용은 여기를 참조하십시오.

Q: 더 작은 노드 유형으로 축소할 수 있습니까?

현재 더 작은 노드 유형으로 전환은 지원되지 않습니다.


Q: Redis 노드를 읽기 전용 복제본으로 실행한다는 것은 어떤 의미입니까?

Redis에서 읽기 전용 복제본은 다음 두 가지 용도로 사용됩니다.

  • 오류 처리
  • 읽기 조정

읽기 전용 복제본이 있는 노드를 실행하면 "기본 노드"는 쓰기 및 읽기 기능을 둘 다 제공합니다. 읽기 전용 복제본은 장애 조치 시나리오에서 "승격"되는 "예비" 복제본의 역할을 합니다. 장애 조치 후 예비 복제본이 기본 복제본이 되어 캐시 작업을 수락합니다. 또한, 읽기 전용 복제본을 사용하면 단일 노드의 용량 한도 이상으로 탄력적으로 확장할 수 있어 읽기 중심의 캐시 워크로드를 쉽게 처리할 수 있습니다.

Q: Redis 읽기 전용 복제본은 언제 사용하는 것이 좋습니까?

특정 기본 노드가 제대로 작동하기 위해 읽기 전용 복제본을 하나 이상 배포하는 위치는 다양합니다. 읽기 전용 복제본을 배포하는 일반적인 이유는 다음과 같습니다.

  • 읽기 중심의 워크로드를 위해 단일 기본 노드의 컴퓨팅 파워 또는 I/O 용량을 확장합니다. 이 과도한 읽기 트래픽을 하나 이상의 읽기 전용 복제본으로 이동할 수 있습니다.
  • 기본 복제본을 사용할 수 없을 때 읽기 트래픽을 제공합니다. 기본 노드가 I/O 요청을 처리하지 못할 경우(예: 백업 또는 예약된 유지 관리를 위한 I/O 중단) 읽기 트래픽을 읽기 전용 복제본으로 보낼 수 있습니다. 이 사용 사례의 경우 기본 인스턴스를 사용할 수 없으므로 읽기 전용 복제본의 데이터가 “무효”일 수 있다는 점에 유의하십시오. 또한 읽기 전용 복제본을 사용하여 실패한 기본 복제본을 다시 시작할 수 있습니다.
  • 데이터 보호 시나리오: 예기치 않은 경우나 기본 노드 오류, 기본 노드가 있는 가용 영역을 사용할 수 없는 경우가 발생하면 다른 가용 영역에 있는 읽기 전용 복제본을 새로운 기본 복제본으로 승격할 수 있습니다.

Q: 특정 기본 노드에 대한 읽기 전용 복제본 노드를 배포하려면 어떻게 해야 합니까?

CreateReplicationGroup API를 사용하거나 Amazon ElastiCache Management Console에서 클릭 몇 번으로 몇 분 내에 읽기 전용 복제본을 생성할 수 있습니다. 클러스터를 생성할 때 MasterCacheClusterIdentifier를 지정합니다. MasterCacheClusterIdentifier는 복제하려고 하는 "기본" 노드의 캐시 클러스터 식별자입니다. 그런 다음 마스터 노드의 ReplicationGroupIdentifier 및 CacheClusterIdentifier를 지정하는 CreateCacheCluster API를 호출하여 샤드 내에 읽기 전용 복제본 클러스터를 생성합니다. 표준 클러스터와 마찬가지로 가용 영역을 지정할 수도 있습니다. 읽기 전용 복제본 생성을 시작하면 Amazon ElastiCache가 샤드에 있는 기본 노드의 스냅샷을 생성하고 복제를 시작합니다. 이에 따라 스냅샷이 생성되는 동안 기본 노드의 I/O가 잠시 중단됩니다. 일반적으로 I/O 중단은 약 1분간 지속됩니다.

읽기 전용 복제본은 만드는 것만큼 쉽게 삭제할 수 있습니다. Amazon ElastiCache Management Console을 사용하거나 DeleteCacheCluster API(삭제할 읽기 전용 복제본에 대해 CacheClusterIdentifier 지정)를 호출하면 됩니다.

Q: 기본 복제본과 읽기 전용 복제본을 동시에 생성할 수 있습니까?

예. CreateReplicationGroup API를 사용하거나 Amazon ElastiCache Management Console에서 "Create" 마법사를 사용하여 "Multi-AZ Replication"을 선택하면 몇 분 만에 읽기 전용 복제본과 함께 새로운 캐시 클러스터를 생성할 수 있습니다. 클러스터를 생성할 때 식별자, 원하는 클러스터 내 총 샤드 수, 샤드당 읽기 전용 복제본 수, 캐시 생성 파라미터(노드 유형, 엔진 버전 등)를 지정합니다. 클러스터에 있는 각 샤드에 대한 가용 영역도 지정해야 합니다.

Q: 내 읽기 전용 복제본에 어떻게 연결합니까?

기본 캐시 노드에 연결할 때와 마찬가지로 읽기 전용 복제본에 연결할 수 있습니다. DescribeCacheClusters API 또는 AWS Management Console을 사용하여 읽기 전용 복제본의 엔드포인트를 검색하면 됩니다. 읽기 전용 복제본이 여러 개인 경우 애플리케이션이 읽기 전용 복제본에 읽기 트래픽을 분산하는 방법을 결정합니다.

Q: 특정 기본 노드에 대한 읽기 전용 복제본을 몇 개나 만들 수 있습니까?

현재, Amazon ElastiCache에서는 특정 기본 노드에 대해 읽기 전용 복제본을 최대 5개까지 만들 수 있습니다.

Q: 장애 조치가 발생하면 읽기 전용 복제본은 어떻게 됩니까?

장애 조치가 발생할 경우 장애 조치가 완료되면 연결된 사용 가능한 읽기 전용 복제본이 복제를 자동으로 재개합니다(새로 승격된 읽기 전용 복제본에서 업데이트를 가져옴).

Q: 다른 읽기 전용 복제본의 읽기 전용 복제본을 만들 수 있습니까?

다른 읽기 전용 복제본의 읽기 전용 복제본을 만들 수 없습니다.

Q: 내 읽기 전용 복제본을 “독립 실행형” 기본 노드로 승격할 수 있습니까?

아니요. 지원되지 않습니다. 그 대신, Redis용 ElastiCache 노드의 스냅샷을 생성할 수 있습니다(기본 또는 읽기 전용 복제본을 선택할 수 있음). 그런 다음 해당 스냅샷을 사용하여 새로운 Redis용 ElastiCache 주 캐시 노드에 시드할 수 있습니다.

Q: 내 읽기 전용 복제본이 해당 기본 노드와 함께 최신 상태로 유지됩니까?

기본 노드에 대한 업데이트는 모든 관련 읽기 전용 복제본에 자동으로 복제됩니다. 그러나 Redis의 비동기 복제 기술을 사용하면 다양한 이유로 읽기 전용 복제본이 기본 캐시 노드보다 지연될 수 있습니다. 대표적인 이유는 다음과 같습니다.

  • 기본 캐시 노드에 대한 쓰기 I/O 볼륨이 변경 내용이 읽기 전용 복제본에 적용될 수 있는 비율 초과
  • 네트워크 파티션이나 기본 캐시 노드와 읽기 전용 복제본 간의 지연 시간

읽기 전용 복제본은 Redis 복제의 장단점을 가지고 있습니다. 읽기 전용 복제본을 사용하는 경우는 읽기 전용 복제본과 기본 캐시 노드 사이에 지연이나 “불일치”가 발생할 수 있다는 점을 인식해야 합니다. "복제 지연" CloudWatch 측정치를 통해 잠재적으로 발생하는 이러한 지연을 모니터링할 수 있습니다. 이 측정치는 CloudWatch 서비스의 콘솔 및 API는 물론 ElastiCache 콘솔 및 API를 통해서도 액세스할 수 있습니다.

Q: 활성 읽기 전용 복제본에 대한 가시성은 어떻게 확보합니까?

표준 DescribeCacheClusters API를 사용하여 배포한 모든 캐시 클러스터의 목록(읽기 전용 복제본 포함)을 반환하거나 Amazon ElastiCache Management Console의 "Redis" 탭을 클릭하기만 하면 됩니다.

Amazon ElastiCache는 읽기 전용 복제본의 복제 상태를 모니터링하여 어떠한 이유로든 복제가 중지된 경우 Replication State 필드를 Error로 업데이트합니다. 사용자는 Replication Error 필드를 확인하여 Redis 엔진에서 보낸 관련 오류의 상세 정보를 검토하고 오류를 복구하기 위한 적절한 조치를 취할 수 있습니다. 복제 문제 해결에 대한 자세한 내용은 Amazon ElastiCache User Guide의 Troubleshooting a Read Replica problem 섹션을 참조하십시오. 복제 문제가 해결되면 Replication State가 Replicating으로 변경됩니다.

Amazon ElastiCache에서는 AWS Management Console 또는 Amazon CloudWatch API를 통해 사용할 수 있는 Amazon CloudWatch 지표("복제본 지연")으로 읽기 전용 복제본이 해당 기본 복제본보다 얼마나 지연되었는지 확인할 수 있습니다.

Q: 내 읽기 전용 복제본이 해당 기본 노드보다 상당히 지연되었습니다. 어떻게 해야 합니까?

이전 질문에서 설명한 대로 읽기 전용 복제본과 기본 노드 간의 “불일치” 또는 지연은 Redis 비동기 복제에서 흔히 발생하는 문제입니다. 요구 사항을 충족하기에는 기존 읽기 전용 복제본이 너무 지연된 경우 해당 읽기 전용 복제본을 다시 부팅하십시오. 복제본 지연은 기본 노드의 정상 사용 패턴에 따라 시간이 지나면서 늘어나거나 감소한다는 점에 유의하십시오.

Q: 읽기 전용 복제본을 삭제하려면 어떻게 해야 합니까? 기본 노드를 삭제하면 자동으로 삭제됩니까?

AWS Management Console을 몇 번 클릭하거나 캐시 클러스터 식별자를 DeleteCacheCluster API에 전달하여 쉽게 읽기 전용 복제본을 삭제할 수 있습니다. 기본 캐시 노드 이외에 읽기 전용 복제본을 삭제하려면 DeleteReplicationGroup API 또는 AWS Management Console을 사용해야 합니다.

Q: 읽기 전용 복제본의 요금은 얼마입니까? 언제부터 언제까지 사용한 요금이 청구됩니까?

읽기 전용 복제본은 표준 노드와 동일한 요금이 청구됩니다. 표준 노드와 마찬가지로 읽기 전용 복제본의 “노드 시간”당 요금은 읽기 전용 복제본의 노드 클래스에 의해 결정됩니다. 최신 요금 정보는 Amazon ElastiCache 세부 정보 페이지를 참조하십시오. 기본 캐시 노드와 읽기 전용 복제본 간에 데이터를 복제할 때 발생한 데이터 전송에는 요금이 부과되지 않습니다. 읽기 전용 복제본의 요금 청구는 읽기 전용 복제본이 성공적으로 생성된 직후에 시작됩니다(상태가 “활성”으로 표시되는 경우). 사용자가 삭제 명령을 실행할 때까지 읽기 전용 복제본에는 표준 Amazon ElastiCache 캐시 노드 시간 요금이 청구됩니다.

Q: 장애 조치 진행 시 어떤 일이 발생하며 얼마나 오래 걸립니까?

Amazon ElastiCache에서는 시작된 장애 조치를 지원하므로 가능한 한 빨리 작업을 재개할 수 있습니다. 장애 조치 시, Amazon ElastiCache가 노드의 DNS 레코드가 읽기 전용 복제본을 가리키도록 변경하기만 하면 이 읽기 전용 복제본이 승격되어 새 기본 노드가 됩니다. 모범 사례에 따라 애플리케이션 계층에서 캐시 노드 연결을 다시 시도하는 것이 좋습니다. 장애 조치의 전 과정은 일반적으로 3~6분 이내에 완료됩니다.

Q: 다른 리전의 읽기 전용 복제본을 기본 복제본으로 만들 수 있습니까?

아니요. 읽기 전용 복제본은 기본 캐시 노드와 동일한 리전의 동일하거나 다른 가용 영역에서만 프로비저닝할 수 있습니다.

Q: 내 기본 복제본이 현재 위치한 가용 영역을 알 수 있습니까?

예, AWS Management Console 또는 DescribeCacheClusters API를 사용하여 기본 복제본의 현재 위치를 알 수 있습니다.

장애 조치 후에 내 기본 복제본이 다른 AWS 리소스(예: EC2 인스턴스)와 다른 가용 영역에 위치합니다.

Q: 지연 시간을 고려해야 합니까?

가용 영역은 같은 리전의 다른 가용 영역에 지연 시간이 짧은 네트워크 연결을 제공하도록 설계되었습니다. 또한 하나의 가용 영역에서 서비스 장애 발생 시, 애플리케이션이 회복력을 가질 수 있도록 여러 가용 영역 전체에 애플리케이션과 기타 AWS 리소스를 중복하여 저장할 수 있습니다.


Q: Redis용 ElastiCache의 다중 AZ란 무엇입니까?

Redis용 ElastiCache 샤드는 기본 노드와 최대 5개의 읽기 전용 복제본으로 구성되어 있습니다. Redis는 기본 노드의 데이터를 읽기 전용 복제본으로 비동기식으로 복제합니다. 특정 유형의 예정된 유지 관리를 수행하는 동안이나 ElastiCache 노드 오류 또는 가용 영역 오류와 같이 예기치 않은 상황이 발생하면 Amazon ElastiCache는 자동으로 기본 복제본의 오류를 감지하고 읽기 전용 복제본을 선택한 다음 이를 새로운 기본 복제본으로 승격합니다. 또한 ElastiCache는 승격된 읽기 전용 복제본의 DNS 변경 사항을 전파하므로 애플리케이션이 기본 노드 엔드포인트에 쓸 때 엔드포인트를 변경하지 않아도 됩니다.

Q: 다중 AZ를 사용하면 어떤 이점이 있습니까?

Redis용 ElastiCache를 다중 AZ 모드에서 실행하는 것의 가장 큰 이점은 가용성이 강화되며 관리의 필요가 줄어든다는 점입니다. Redis용 ElastiCache 기본 노드 오류가 발생하면 기본 노드로의 읽기/쓰기 기능에 미치는 영향은 자동 장애 조치가 완료될 때까지 소요되는 시간으로 제한됩니다. 다중 AZ가 활성화되어 있는 경우 ElastiCache 노드 장애 조치가 자동으로 수행되며 관리가 필요하지 않습니다. 그러므로 Redis 노드를 모니터링하고 기본 노드 중단 시 수동으로 복구를 시작해야 할 필요가 없어집니다.

Q: 다중 AZ의 작동 원리는 무엇입니까?

Redis용 ElastiCache를 사용하며 기본 노드와 1개 이상의 읽기 전용 복제본으로 구성된 샤드가 있는 경우 다중 AZ를 사용할 수 있습니다. 기본 노드에 장애가 발생하면 ElastiCache는 자동으로 장애를 감지하고, 사용 가능한 읽기 전용 복제본 중 하나를 선택한 다음, 이를 새로운 기본 노드로 승격합니다. cluster_mode 파라미터가 비활성화된 경우, ElastiCache는 애플리케이션이 계속 기본 엔드포인트에 쓸 수 있도록 승격된 복제본의 DNS 변경 사항을 전파합니다. cluster_mode 파라미터가 활성화되면 ElastiCache가 클러스터의 노드 맵을 업데이트합니다. 또한 ElastiCache는 오류가 발생한 기본 노드의 동일한 가용 영역에서 승격된 읽기 전용 복제본을 대체하도록 새로운 노드를 가동합니다. 일시적인 가용 영역 중단으로 인해 기본 노드에 오류가 발생한 경우 가용 영역이 복구되면 새로운 복제본이 시작됩니다.

Q: 동일한 가용 영역에 있는 복제본을 기본 복제본으로 사용할 수 있습니까?

예. 동일한 가용 영역에 기본 및 복제본을 모두 배치한다고 해서 Redis용 ElastiCache 복제 그룹이 가용 영역 중단에 대해 복원력을 가지는 것은 아니라는 점에 유의하십시오.

Q: Amazon ElastiCache가 읽기 전용 복제본으로 장애 조치를 수행하는 원인이 될 만한 경우는 무엇입니까?

Amazon ElastiCache는 다음과 같은 경우 읽기 전용 복제본으로 장애 조치를 수행합니다.

  • 기본 복제본 가용 영역의 가용성 손실
  • 기본 복제본에 대한 네트워크 연결 상실
  • 기본 복제본의 컴퓨팅 장치 장애

Q: 언제 다중 AZ를 사용해야 합니까?

Redis 복제를 다중 AZ와 함께 사용하면 가용성과 내결함성이 강화됩니다. 이러한 배포는 프로덕션 환경에서 사용하기에 매우 적합합니다. Redis용 ElastiCache 클러스터를 클러스터 모드가 활성화된 상태로 실행할 때 샤드에 하나 이상의 읽기 전용 복제본이 있으면 다중 AZ가 자동으로 활성화됩니다.

Q: Redis용 ElastiCache 복제 그룹을 다중 AZ가 활성화된 상태로 생성하려면 어떻게 해야 합니까?

ElastiCache Management Console에서 "Create"를 클릭하여 Redis용 ElastiCache 기본 및 읽기 전용 복제본을 생성할 수 있습니다. 또는 CreateReplicationGroup API를 호출해도 됩니다. 기존 클러스터의 경우(cluster_mode=disabled 상태인 Redis 2.8.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23, 2.8.24 및 3.2.4), ElastiCache Management Console에서 클러스터를 선택한 다음 Modify를 클릭하거나 ModifyReplicationGroup API를 사용하여 다중 AZ를 활성화할 수 있습니다. 복제 그룹을 다중 AZ로 전환한다고 해서 Redis 데이터에 부정적인 영향을 주는 것은 아니며, 노드가 요청을 처리하는 성능에 지장을 주지도 않습니다.

Q: 기본 노드에 오류가 발생하는 경우 어떤 읽기 전용 복제본이 승격됩니까?

읽기 전용 복제본이 1개 이상 있는 경우, 기본 복제본으로의 비동기식 복제 지연 시간이 가장 짧은 읽기 전용 복제본이 승격됩니다.

Q: 다중 AZ 사용료는 얼마나 됩니까?

다중 AZ는 무료입니다. 사용한 ElastiCache 노드에 대해서만 지불하면 됩니다.

Q: 다중 AZ가 성능에 미치는 영향은 무엇입니까?

ElastiCache는 현재 Redis 엔진의 기본 비동기식 복제를 사용하며 내구력과 제한에 영향을 받습니다. 특히 읽기 전용 복제본을 처음으로 기본 복제본에 연결하는 경우나 기본 복제본이 변경된 경우, 읽기 전용 복제본은 기본 복제본의 전체 데이터를 동기화하므로 해당 복제본 자체는 물론 기본 복제본에도 부하가 발생합니다. Redis 복제에 대한 자세한 내용은 여기를 참조하십시오. 

Q: 다중 AZ를 지원하는 노드 유형은 무엇입니까?

ElastiCache에서 제공하는 모든 노드 유형에서 다중 AZ를 지원하지만 한 가지 예외 사항이 있습니다. cluster_mode=disabled 상태로 Redis 2.8.x 또는 Redis 3.x를 사용하는 경우 T2 패밀리는 다중 AZ를 지원하지 않습니다.

Q: 자동 장애 조치가 수행될 때 알림을 받을 수 있습니까?

예. Amazon ElastiCache는 자동 장애 조치가 수행될 때 알려주는 이벤트를 생성합니다. DescribeEvents API를 사용하여 ElastiCache 노드와 관련된 이벤트에 대한 정보를 반환할 수 있습니다. 또는 AWS ElastiCache Management Console에서 'Events' 섹션을 클릭합니다.

Q: 장애 조치 이후 내 기본 복제본이 다른 AWS 리소스(예: EC2 인스턴스)와 다른 가용 영역에 위치합니다. 지연 시간을 고려해야 합니까?

가용 영역은 같은 리전의 다른 가용 영역에 지연 시간이 짧은 네트워크 연결을 제공하도록 설계되었습니다. 하나의 가용 영역이 중단되더라도 애플리케이션이 복원력을 가질 수 있도록 여러 가용 영역 전반에 애플리케이션과 다른 AWS 리소스가 중복되도록 설계할 수도 있습니다.

Q: 어디에서 다중 AZ에 대한 자세한 정보를 알아볼 수 있습니까?

다중 AZ에 대한 자세한 내용은 ElastiCache 설명서를 참조하십시오.

Q: 다중 AZ 기능을 테스트해 볼 수 있습니까?

예. 클러스터에 "다중 AZ" 기능이 설정되어 있거나 하나 이상의 읽기 전용 복제본이 있는 복제 그룹이 있는 경우, 장애 조치를 트리거할 수 있습니다. ElastiCache가 실제 장애 조치 시나리오와 같은 방법으로 응답합니다. 즉, 장애 조치를 탐지하고, 가장 최신의 읽기 전용 복제본을 새로운 기본으로 승격시키고, 오류가 발생한 기본을 바꾸고, 승격한 이전 읽기 전용 복제본 자리에 새로운 읽기 전용 복제본을 연결합니다. 장애 조치 테스트에 대한 자세한 내용은 설명서를 참조하십시오.


Q: 백업 및 복원이란 무엇입니까?

백업 및 복원이란 고객이 자신의 Redis용 ElastiCache 클러스터의 스냅샷을 생성할 수 있도록 하는 기능입니다. ElastiCache는 스냅샷을 저장하여 사용자가 이후 Redis 클러스터를 복원할 수 있도록 합니다.

Q: 스냅샷이란 무엇입니까?

스냅샷은 특정 시점의 전체 Redis 클러스터에 대한 사본입니다.

Q: 스냅샷이 필요한 이유는 무엇입니까?

스냅샷을 생성하면 노드 장애는 물론 하드웨어 장애와 같이 예기치 못한 상황으로 인해 데이터가 손실된 경우 유용하게 사용할 수 있습니다. 백업을 사용하는 또 다른 일반적인 이유는 아카이빙을 위해서입니다. 스냅샷은 내구성 있는 스토리지인 Amazon S3에 저장되므로 정전이 발생해도 데이터가 지워지지 않습니다.

Q: 스냅샷으로 어떤 작업을 할 수 있습니까?

스냅샷을 사용하여 사전 로드된 데이터와 함께 Redis용 ElastiCache 클러스터를 웜 스타트할 수 있습니다.

Q: 백업 및 복원은 어떻게 작동합니까?

백업이 실행되면 ElastiCache가 이후 복구 또는 아카이빙에 사용될 수 있는 특정 Redis 클러스터의 스냅샷을 생성합니다. 언제든지 원하는 때 백업을 실행할 수 있습니다. 또는 보존 기간을 최대 35일로 설정하여 매일 백업이 반복되도록 설정할 수도 있습니다.

복원할 스냅샷을 선택하면 새로운 Redis용 ElastiCache 클러스터가 생성되며 스냅샷의 데이터로 채워집니다. 이러한 방법으로 특정 스냅샷에서 Redis용 ElastiCache 클러스터를 여러 개 생성할 수 있습니다.

현재 ElastiCache에서는 Redis의 기본 메커니즘을 통해 RDB 파일을 스냅샷으로 생성하고 저장합니다.

Q: 내 스냅샷은 어디에 저장됩니까?

스냅샷은 S3에 저장됩니다.

Q: 백업 및 복원을 사용하여 시작하려면 어떻게 해야 합니까?

AWS Management Console, ElastiCache API(CreateCacheCluster, ModifyCacheCluster, ModifyReplicationGroup API), CLI를 통해 백업 및 복원 기능을 사용하도록 선택할 수 있습니다. 언제든지 해당 기능을 비활성화 및 재활성화할 수 있습니다.

Q: 백업할 Redis 클러스터 및 노드를 지정하려면 어떻게 해야 합니까?

백업 및 복원은 클러스터를 기반으로 스냅샷을 생성합니다. AWS Management Console, CLI 또는 CreateSnapshot API를 통해 백업할 Redis 클러스터용 ElastiCache를 지정할 수 있습니다. 복제 그룹에서는 주 클러스터 또는 읽기 전용 복제본 클러스터를 백업하도록 선택할 수 있습니다. Redis 기본 복제본에 지연 시간이 미치는 영향을 최소화할 수 있도록 읽기 전용 복제본 중 하나에서 백업을 활성화하는 것이 좋습니다.

Q: Memcached용 ElastiCache는 백업 및 복원을 지원합니까?

아니요. 스냅샷은 Redis용 ElastiCache에서만 사용할 수 있습니다.

Q: 언제 백업할지 지정하려면 어떻게 해야 합니까?

AWS Management Console, CLI 또는 API를 통해 언제 단일 백업 또는 반복 백업을 시작할지 지정할 수 있습니다. 사용자는 다음 중 선택할 수 있습니다.

  • 즉시 스냅샷을 생성합니다("Redis" 탭에서 "Backup" 콘솔 버튼 클릭 또는 CreateSnapshot API 사용).
  • 자동 일일 백업을 설정합니다. 기본 백업 기간에 백업이 이루어집니다. 콘솔 또는 CreateCacheCluster, ModifyCacheCluster, ModifyReplicationGroup API에서 클러스터를 생성/수정하여 설정할 수도 있습니다.

Q: 백업 기간은 무엇이고 왜 필요합니까?

기본 백업 기간이란 Redis용 ElastiCache 클러스터의 백업이 시작 및 수행될 수 있도록 사용자가 정의한 기간입니다. 백업이 특정한 시간에 수행되길 원하거나 클러스터가 특히 자주 사용되는 기간에는 백업이 수행되지 않기를 원하는 경우 유용한 기능입니다.

Q: 스냅샷을 생성하면 성능에 어떤 영향을 받습니까?

스냅샷을 생성하는 동안에는 노드에서의 지연 시간이 일시적으로 길어질 수 있습니다. 스냅샷은 Redis의 기본 BGSAVE를 사용하며 BGSAVE의 장점 및 제한 사항이 적용됩니다. 특히 Redis에서 분기를 처리하는 경우에 그러합니다. 이 경우 상위에서는 계속해서 요청을 처리하는 동시에 하위에서는 디스크에 데이터를 저장한 다음 종료합니다. 분기로 인해 스냅샷이 생성되는 동안에는 메모리 사용량이 증가합니다. 이 메모리 사용량이 노드에서 사용 가능한 메모리를 초과하는 경우 스왑이 트리거되어 노드가 더욱 느려질 수 있습니다. 이러한 이유로 기본 복제본 대신 읽기 전용 복제본 중 하나에서 스냅샷을 생성하는 것이 좋습니다. 또한, 스왑 사용률을 최소화하기 위해 예약 메모리 파라미터를 설정하기를 권장합니다. 자세한 내용은 여기를 참조하십시오.

Q: Redis용 ElastiCache 읽기 전용 복제본에서 스냅샷을 생성할 수 있습니까?

예. 읽기 전용 복제본에서 스냅샷을 생성하는 것은 성능에 미치는 영향을 최소화하면서 데이터를 백업하는 가장 좋은 방법입니다.

Q: 어느 리전에서 백업 및 복원 기능을 사용할 수 있습니까?

백업 및 복원 기능은 ElastiCache 서비스를 사용할 수 있는 모든 리전에서 사용할 수 있습니다.

Q: Redis용 ElastiCache 스냅샷을 내가 소유한 S3 버킷으로 내보낼 수 있습니까?

예. Redis용 ElastiCache 스냅샷을 클러스터와 같은 리전에 있는 승인된 S3 버킷으로 내보낼 수 있습니다. 스냅샷 내보내기와 필요한 권한 설정에 대한 자세한 내용은 여기를 참조하십시오.

Q: 스냅샷을 다른 리전으로 복사할 수 있습니까?

예. 먼저 같은 리전에 있는 승인된 S3 버킷 중 원하는 버킷으로 스냅샷을 복사한 다음, S3 PUT object- Copy API를 사용하여 다른 리전에 있는 버킷으로 복사해야 합니다. S3 객체를 복사하는 방법에 대한 자세한 내용은 여기를 참조하십시오.

Q: Redis용 ElastiCache를 사용하는 AWS 계정을 여러 개 보유하고 있습니다. 특정 계정에 있는 ElastiCache 스냅샷을 사용하여 다른 계정의 Redis용 ElastiCache 클러스터를 웜 스타트할 수 있습니까?

예. 먼저 같은 리전에 있는 승인된 S3 버킷 중 원하는 버킷으로 스냅샷을 복사한 다음, 다른 계정에 교차 계정 버킷 권한을 부여해야 합니다. S3 교차 계정 권한에 대한 자세한 내용은 여기를 참조하십시오. 마지막으로 CreateCacheCluster API 또는 콘솔에서 Launch Cache Cluster Wizard를 통해 클러스터를 생성하는 동안 RDB 파일이 있는 S3 위치를 지정할 수 있습니다.

Q: 백업 및 복원의 사용 비용은 얼마입니까?

Amazon ElastiCache는 활성화된 각 Redis용 ElastiCache 클러스터에 대해 스냅샷 하나만큼의 스토리지 공간을 무료로 제공합니다. 추가 스토리지는 스냅샷에서 사용한 공간에 따라 월별 1GB당 0.085 USD가 청구됩니다. 가격은 모든 리전에서 동일합니다. 스냅샷 사용을 위한 데이터 전송 요금은 무료입니다.

Q: 보존 기간이란 무엇입니까?

보존 기간이란 자동 스냅샷이 보존되는 기간을 뜻합니다. 예를 들어 보존 기간이 5로 설정된 경우 오늘 생성된 스냅샷은 5일 동안 보존된 뒤 삭제됩니다. 수동으로 하나 이상의 자동 스냅샷을 복사한 다음 저장하여 해당 스냅샷이 보존 기간 후에도 삭제되지 않도록 할 수 있습니다.

Q: 자동화된 스냅샷의 보존 기간을 관리하려면 어떻게 해야 합니까?

AWS Management Console 또는 ModifyClutster API를 사용하여 RetentionPeriod 파라미터를 수정하여 자동 백업이 보관되는 기간을 관리할 수 있습니다. 자동 백업을 완전히 비활성화하려는 경우 보존 기간을 0으로 설정합니다(권장하지 않음).

Q: Redis용 ElastiCache 클러스터를 삭제하면 스냅샷은 어떻게 됩니까?

Redis용 ElastiCache 클러스터를 삭제하는 경우 수동 스냅샷은 보존됩니다. 클러스터를 삭제하기 전에 최종 스냅샷을 생성할 수 있는 옵션도 있습니다. 자동 스냅샷은 보존되지 않습니다.

Q: 백업 및 복원 기능을 지원하는 노드 유형은 무엇입니까?

t1.micro 및 t2 패밀리를 제외한 모든 Redis용 ElastiCache 인스턴스 노드 유형이 백업 및 복원을 지원합니다.

현재 세대 노드:

  • cache.m3.medium
  • cache.m3.large
  • cache.m3.xlarge
  • cache.m3.2xlarge
  • cache.m4.large
  • cache.m4.xlarge
  • cache.m4.2xlarge
  • cache.m4.4xlarge
  • cache.m4.10xlarge
  • cache.r3.large
  • cache.r3.xlarge
  • cache.r3.2xlarge
  • cache.r3.4xlarge
  • cache.r3.8xlarge

이전 세대 노드:

  • cache.m1.small
  • cache.m1.medium
  • cache.m1.large
  • cache.m1.xlarge
  • cache.m2.xlarge
  • cache.m2.2xlarge
  • cache.m2.4xlarge
  • cache.c1.xlarge

Q: S3에 저장된 RDB 스냅샷을 사용하여 Redis용 ElastiCache 클러스터를 웜 스타트할 수 있습니까?

예. 콘솔의 "Create Cluster" 마법사 또는 CreateCacheCluster API를 통해 클러스터를 생성하는 동안 RDB 파일이 저장될 S3 위치를 지정할 수 있습니다.

Q: VPC에서 ElastiCache를 실행 중인 경우 백업 및 복원 기능을 사용할 수 있습니까?

예.


Q: Redis용 ElastiCache 클러스터란 무엇입니까?

Redis용 ElastiCache 클러스터를 사용하면 여러 개의 샤드로 이루어진 관리형 Redis 클러스터를 생성 및 실행할 수 있습니다. 이 클러스터는 오픈 소스 Redis 3.2와 호환 가능하며 몇 가지 향상된 기능이 지원되어 좀 더 안정적이고 강력한 경험을 제공합니다(이 향상된 기능에 대한 자세한 내용은 아래 "향상된 엔진" 섹션 참조).

Q: 스케일 아웃 Redis 환경이 필요한 이유는 무엇입니까?

스케일 아웃 Redis 환경을 실행해야 하는 경우가 크게 세 가지가 있습니다. 첫 번째는 Redis 데이터의 총 메모리 크기가 단일 VM의 메모리 용량을 초과하거나 초과할 것으로 예상되는 경우입니다. 두 번째는 Redis에 대한 애플리케이션의 쓰기 처리량이 단일 VM의 용량을 초과하는 경우입니다. 세 번째는 단일 노드에서 발생할 수 있는 잠재적 문제가 전제 Redis 환경에 미치는 영향을 최소화하기 위해 데이터를 여러 샤드에 분산하려는 경우입니다.

Q: 내 Redis 클러스터 워크로드를 Amazon ElastiCache에서 실행해야 하는 이유는 무엇입니까?

Amazon ElastiCache에서는 서버 리소스 프로비저닝에서부터 엔진 소프트웨어 설치, 선택하는 모든 구성 파라미터 적용에 이르기까지 완전 관리형 분산 인 메모리 Redis 환경을 제공합니다. Redis 엔진용으로 Amazon에서 개발한 향상된 기능을 사용하므로 좀 더 강력하고 안정적인 경험을 제공합니다(자세한 내용은 "향상된 엔진" 섹션 참조). Redis 환경이 시작 및 실행되면 서비스에서 장애 감지 및 복구, 백업 및 소프트웨어 패치 등의 일반적인 관리 작업을 자동으로 처리합니다. 또한, 자동 장애 조치로 강력한 다중 AZ 솔루션을 제공합니다. 클러스터에서 하나 이상의 기본 노드에 장애가 발생하는 경우 Amazon ElastiCache는 장애를 자동으로 감지하고 가장 최신의 복제본을 기본 노드로 승격하여 이를 처리합니다. 이 프로세스는 자동화되어 있으며 사용자가 해야 할 작업은 전혀 없습니다. 또한, Amazon ElastiCache는 ElastiCache 노드와 관련된 세부 모니터링 지표도 제공하기 때문에 문제를 아주 신속하게 진단해 대응할 수 있습니다.

Q: Redis용 ElastiCache 클러스터는 오픈 소스 Redis와 호환됩니까?

예. Redis용 Amazon ElastiCache 클러스터는 오픈 소스 Redis 3.2와 호환됩니다. 오픈 소스 Redis 클러스터 클라이언트를 사용하여 Redis용 ElastiCache의 스케일 아웃 클러스터에 액세스할 수 있습니다.

Q: 클러스터가 생성된 후에 샤드 수를 변경할 수 있습니까?

현재는 클러스터가 생성된 후에는 클러스터의 샤드 수를 변경할 수 없습니다.

Q: 현재 Redis용 ElastiCache 2.8.x에서 Redis용 ElastiCache 클러스터(버전 3.2.4)로 업그레이드하려면 어떻게 해야 합니까?

cluster_mode 파라미터가 비활성화된 상태로 Redis 3.2를 사용하고 있는 경우, 업그레이드하려는 노드 또는 클러스터를 선택하고 엔진 버전을 수정하기만 하면 됩니다. ElastiCache가 Redis 3.2.4 클러스터를 프로비저닝하고 데이터를 해당 클러스터로 마이그레이션합니다. 이때 엔드포인트는 그대로 유지됩니다.

cluster_mode 파라미터가 활성화된 상태로 Redis 3.2를 사용하고 있는 경우, Redis 클러스터로 마이그레이션하려면 먼저 백업 및 복구 기능을 사용하여 데이터의 스냅샷을 생성합니다. 그런 다음 생성된 스냅샷을 선택하고 "Restore Snapshot"을 클릭하여 스냅샷의 데이터로 Redis 3.2 클러스터를 생성합니다. 마지막으로 클라이언트의 새 엔드포인트를 업데이트합니다. Redis 3.2를 클러스터 모드로 사용하려면 Redis 클러스터 클라이언트로 전환해야 합니다.

Q: 클러스터형 구성 요금은 비클러스터형 구성 요금과 차이가 있습니까?

아니요. Redis용 Amazon ElastiCache는 클러스터형과 비클러스터형 구성을 동일한 요금으로 제공합니다. 이제 고객은 동일한 요금으로 Redis용 Amazon ElastiCache의 향상된 엔진 기능을 활용하고 클러스터형 구성과 확장성에 대한 모든 기능을 사용할 수 있습니다.  

Q: Redis용 ElastiCache 클러스터의 다중 AZ란 무엇입니까?

Redis용 ElastiCache 클러스터의 각 샤드는 기본 노드와 최대 5개의 읽기 전용 복제본으로 구성되어 있습니다. Redis는 기본 노드의 데이터를 읽기 전용 복제본으로 비동기식으로 복제합니다. 특정 유형의 예정된 유지 관리를 수행하는 동안이나 ElastiCache 노드 장애 또는 가용 영역 장애와 같이 예기치 않은 상황이 발생하면 Amazon ElastiCache는 자동으로 기본 노드의 장애를 감지하고 읽기 전용 복제본을 선택한 다음 이를 새로운 기본 노드로 승격합니다.

Redis용 ElastiCache 클러스터는 Redis 3.x 환경에 대한 관리와 향상된 기능을 제공합니다. 비관리형 Redis 환경에서 실행하면 기본 노드에 장애가 발생하는 경우 클러스터는 마스터 노드의 과반수에 의존하여 장애 조치를 결정하고 실행합니다. 이러한 과반수가 존재하지 않는 경우, 클러스터는 장애 상태로 전환되어 추가적인 읽기 및 쓰기를 거부하게 됩니다. 이는 애플리케이션에 대한 가용성에 큰 영향을 줄 수 있으며 사용자가 개입하여 클러스터를 수동으로 복구해야 할 수 있습니다. Redis용 ElastiCache 다중 AZ 기능은 Redis 클러스터에 대한 모든 장애 조치를 견고하게 효율적으로 처리할 수 있도록 구축되었습니다.

Q: Redis용 ElastiCache 클러스터의 다중 AZ와 Redis 버전 2.8.x용 ElastiCache의 차이점은 무엇입니까?

Redis 3.x는 모든 클러스터 노드의 엔드포인트가 담긴 노드 맵을 저장하는 지능적 클라이언트와 연동됩니다. 장애 조치 중에 클라이언트가 새 기본 노드의 IP 엔드포인트를 노드 맵에 업데이트합니다. 이를 통해 Redis 2.8.x용 ElastiCache보다 최대 4배 더 빠르게 장애 조치를 제공할 수 있습니다.

Q: Redis 클러스터에서 다중 AZ는 어떻게 작동합니까?

각 샤드에 1개 이상의 읽기 전용 복제본이 있는 구성으로 Redis용 ElastiCache 클러스터를 사용하고 있다면 다중 AZ를 사용할 수 있습니다. 샤드의 기본 노드에 장애가 발생하면 ElastiCache는 자동으로 장애를 감지하고 사용 가능한 읽기 전용 복제본 중 하나를 선택한 다음 이를 새로운 기본 노드로 승격합니다. Redis 3.x 클라이언트는 승격된 복제본을 기본 노드로 업데이트하며, 애플리케이션 변경은 필요 없습니다. 또한, ElastiCache는 장애가 발생한 기본 노드가 있는 가용 영역에서 승격된 읽기 전용 복제본을 대체하도록 새로운 노드를 가동합니다. 일시적인 가용 영역 장애로 인해 기본 노드에 장애가 발생한 경우 가용 영역이 복구되면 새로운 복제본이 시작됩니다.

Q: Redis용 ElastiCache 클러스터에서 백업이란 무엇입니까?

Redis용 ElastiCache 클러스터 백업은 클러스터 샤드의 일련의 스냅샷으로, 특정 기간의 전체 Redis 데이터 사본을 유지하기 위해 함께 저장됩니다.

Q: Redis용 ElastiCache 클러스터의 백업과 Redis용 ElastiCache의 스냅샷은 어떻게 다릅니까?

비클러스터형인 Redis용 ElastiCache 환경에는 기본 노드가 하나이므로, 백업은 Redis 데이터 사본이 포함된 단일 파일입니다. Redis용 ElastiCache 클러스터는 하나 이상의 샤드로 이루어질 수 있으므로, 백업에 여러 개의 파일이 포함될 수 있습니다.

Q: 각 샤드에서 백업할 Redis용 ElastiCache 노드를 지정하려면 어떻게 해야 합니까?

각 샤드에서 백업할 노드를 수동으로 지정할 수는 없습니다. 백업을 시작할 때 ElastiCache가 자동으로 각 샤드에서 가장 최신의 읽기 전용 복제본을 선택하고 해당 데이터의 스냅샷을 생성합니다.

Q: Redis용 ElastiCache 클러스터 백업 및 복원 작업은 어떻게 이루어집니까?

백업이 시작되면 ElastiCache가 지정된 클러스터의 백업을 생성하며, 이 백업은 나중에 복구 또는 아카이빙에 사용될 수 있습니다. 이 백업은 클러스터의 샤드별 사본을 포함하므로 전체 백업에는 일련의 파일이 포함되어 있습니다. 언제든지 원하는 때 백업을 실행할 수 있습니다. 또는 보존 기간을 최대 35일로 설정하여 매일 백업이 반복되도록 설정할 수도 있습니다.

복원할 스냅샷을 선택하면 새로운 Redis용 ElastiCache 클러스터가 생성되며 백업의 데이터로 채워집니다. 또한 이 기능을 사용하여 ElastiCache 기반 관리형 Redis 클러스터 환경으로 쉽게 마이그레이션할 수도 있습니다. EC2를 기반으로 자체 관리형 Redis를 실행하는 경우에는 RDB 스냅샷이나 기존 워크로드(Redis 클러스터 및 단일 샤드 Redis)를 생성하여 S3에 저장할 수 있습니다. 이후부터는 ElastiCache를 기반으로 샤딩된 Redis 클러스터와 원하는 수의 샤드를 생성하기 위한 입력 데이터로서 제공하기만 하면 됩니다. 나머지는 ElastiCache가 처리합니다.

현재 ElastiCache에서는 Redis의 기본 메커니즘을 사용하여 백업으로서 각 샤드에 대한 RDB 파일을 생성하고 저장합니다.

Q: Redis용 ElastiCache 클러스터의 백업은 특정 시점 스냅샷입니까?

백업을 시작하면 ElastiCache에서 동시에 클러스터에 있는 모든 샤드의 백업을 트리거합니다. 드문 경우지만 처음에 성공적으로 완료되지 않은 노드 스냅샷이 하나 이상 있다면 이를 다시 생성해야 할 수도 있습니다. ElastiCache에서 이를 자동으로 수행하므로 사용자는 개입할 필요가 없습니다. 하지만 이런 경우 모든 개별 스냅샷이 생성된 특정 시점의 노드를 나타내지만, 모든 클러스터 스냅샷이 동시에 생성되지는 않습니다.

Q: 언제 백업할지 지정하려면 어떻게 해야 합니까?

AWS Management Console, CLI 또는 API를 통해 언제 단일 또는 반복 백업을 시작할지 지정할 수 있습니다. 사용자는 다음 중 선택할 수 있습니다.

  • 즉시 백업을 생성합니다("Create Snapshot" 콘솔 버튼 또는 CreateSnapshot API 사용).
  • 자동 일일 백업을 설정합니다. 기본 백업 기간에 백업이 이루어집니다. 콘솔이나 CreateReplicationGroup 및 ModifyReplicationGroupAPI를 통해 클러스터를 생성/수정하여 백업을 설정할 수 있습니다.

Q: S3에 저장된 자체 RDB 스냅샷을 사용하여 스케일 아웃 Redis용 ElastiCache 클러스터 환경을 시작할 수 있습니까?

예. 콘솔의 Create Cluster 마법사나 CreateReplicationGroup API를 통해 클러스터를 생성하는 동안 RDB 파일이 있는 S3 위치를 지정할 수 있습니다. ElastiCache는 RDB 스냅샷의 Redis 키 공간을 자동으로 파싱하여 새로운 클러스터의 샤드에 이를 다시 배포합니다.


Q: Redis용 ElastiCache의 엔진과 오픈 소스 Redis의 엔진은 어떻게 다릅니까?

Redis용 ElastiCache의 엔진은 오픈 소스 Redis와 완벽하게 호환 가능할 뿐만 아니라 견고함과 안정성을 높여주는 향상된 기능도 함께 제공합니다. 다음은 향상된 기능 중 일부입니다.

  • 가용 메모리 추가: 이제 동기화 및 스냅샷이 진행되는 동안 스왑 사용량 증가에 대한 걱정 없이 애플리케이션에 더 많은 메모리를 안전하게 할당할 수 있습니다.
  • 동기화 개선: 부하가 높거나 연결이 끊긴 네트워크에서 복구할 때 좀 더 견고한 동기화를 지원합니다. 또한, 기본 노드와 읽기 전용 복제본이 이 작업을 수행하는 데 디스크를 사용하지 않으므로 동기화 속도가 더 빠릅니다.
  • 매끄러운 장애 조치: 장애 조치가 수행될 경우 이제 샤드가 더 빠르게 복구됩니다. 복제본에서 기본 노드와 전체 동기화를 다시 실행하기 위해 데이터를 보낼 필요가 없기 때문입니다.

Q: 향상된 엔진은 어떻게 사용합니까?

Amazon ElastiCache 관리 콘솔에서 향상된 엔진을 사용하려면 클러스터를 생성할 때 Redis 엔진 버전 2.8.22 이상과 호환되는 엔진을 선택하기만 하면 됩니다. 이때부터 향상된 엔진을 사용하게 됩니다. CreateCacheCluster API를 실행할 때 엔진 버전을 지정하면 ElastiCache API 또는 AWS CLI를 통해서도 향상된 엔진을 사용할 수 있습니다.

Q: ElastiCache에서 향상된 엔진을 사용하려면 내 애플리케이션 코드를 변경해야 합니까?

아니요. 향상된 엔진은 오픈 소스 Redis와 완벽하게 호환되므로, 애플리케이션 코드를 변경할 필요 없이 개선된 견고함과 안전성을 활용할 수 있습니다.

Q: 향상된 엔진을 사용하는 데 드는 비용은 얼마나 됩니까?

향상된 엔진 사용에 따르는 추가 요금은 없습니다. 늘 그렇듯 사용하는 노드에 대한 비용만 부과됩니다.



Q: 온라인 클러스터 크기 조정이란 무엇입니까?

Redis용 Amazon ElastiCache는 실행 중인 클러스터에 샤드를 추가 및 제거할 수 있는 기능을 제공합니다. 수요 변화에 맞춰 Redis 클러스터 워크로드를 동적으로 확장하거나 축소할 수 있습니다. ElastiCache는 샤드를 추가 또는 제거하고 새로운 샤드 구성 전체로 해시 슬롯을 균등하게 재분배하여 클러스터의 크기를 조정하며, 그동안 클러스터는 계속해서 온라인을 유지하고 요청을 처리합니다.

Q: 온라인 클러스터 크기 조정을 사용할 때의 이점은 무엇입니까?

클러스터를 동적으로 확장 및 축소하는 기능은 애플리케이션 가용성을 관리하고 변동이 심한 수요를 맞추는 데 도움이 될 수 있습니다. 샤드를 추가 또는 제거하여 클러스터의 크기를 적정하게 조정함으로써 성능과 인 메모리 용량을 조정할 수 있습니다. 이 기능을 사용하면 피크 수요를 기준으로 클러스터를 오버프로비저닝할 필요가 없으므로 효율성을 개선하고 비용을 절감할 수 있습니다.

Q: 온라인 클러스터 크기 조정 기능을 사용하려면 어떻게 해야 합니까?

온라인 클러스터 크기 조정 기능은 Redis 엔진 버전 3.2.10에서 사용할 수 있습니다. 클러스터를 리샤딩하려면 해당 클러스터를 선택하고 샤드를 추가할지 제거할지 지정합니다. 확장하도록 클러스터의 크기를 조정하면, ElastiCache가 샤드를 추가하고 기존 샤드에서 새로운 샤드로 슬롯을 마이그레이션하며, 이때 슬롯은 샤드 전체에 균등한 수로 분배됩니다. 마찬가지로 축소하도록 클러스터의 크기를 조정하면, ElastiCache가 남아있는 샤드로 슬롯을 마이그레이션하여 균등하게 분배하고 지정된 샤드를 삭제합니다.

Q: 온라인 클러스터 크기 조정에는 시간이 얼마나 걸립니까?

클러스터의 크기를 조정하는 데 걸리는 시간은 클러스터에서 샤드 전체로 마이그레이션해야 하는 슬롯의 수, 데이터 규모, 수신되는 요청 속도 등 다양한 요소에 따라 달라집니다. 하지만 워크로드가 최적화되어 슬롯 마이그레이션을 병렬로 진행하므로 샤드를 더 추가함에 따라 클러스터를 확장할 때 걸리는 시간이 개선됩니다.

Q: 클러스터 크기 조정이 진행되는 동안 해당 클러스터를 사용할 수 있습니까?

예. 리샤딩이 진행되는 동안 해당 클러스터는 계속해서 온라인을 유지하고 수신되는 요청을 처리합니다. 하지만, 클러스터에 추가 로드가 발생하는 것을 방지하기 위해 리샤딩이 진행되는 동안에는 스냅샷 생성 기능이 지원되지 않습니다.

Q: 이 작업이 클러스터의 성능에 영향을 줍니까?

온라인 클러스터 크기 조정 기능이 가동 중단 없이 확장/축소하는 이점을 제공하지만, 이는 컴퓨팅 집약적 작업이므로 클라이언트 연결 지연 시간이 길어질 수 있습니다. 작업 중에 클러스터에 대한 로드를 줄이려면 모범 사례를 따르는 것이 좋습니다(설명서 참조).

Q: 온라인 리샤딩 작업의 진행 상황을 추적하려면 어떻게 해야 합니까?

클러스터, 샤드 및 노드의 상태를 확인하면 작업 진행 상황을 추적할 수 있습니다. 작업 중에는 클러스터, 샤드 및 노드가 '변경 중' 상태를 유지합니다. 마찬가지로 샤드가 생성 또는 삭제되는 중이거나 샤드에 슬롯 마이그레이션이 진행되는 중이라면 개별 샤드 상태에 이러한 상태가 반영되어 진행 상황을 보여줍니다. 또한, 엔드 투 엔드 작업의 상태는 리샤딩 작업의 진행률 표시기를 사용해 추적할 수 있습니다. 진행률 표시기는 완료된 비율을 표시하며 남은 작업 시간에 대한 통찰력을 제공합니다. 마지막으로 이벤트 메시지는 전체 작업 중에 현재 수행 중인 작업(샤드 생성, 슬롯 마이그레이션 등)을 설명하여 진행 상황을 나타냅니다.

Q: Redis용 ElastiCache 클러스터의 리밸런싱 작업이란 무엇입니까?

리밸런싱 작업은 균등한 분배를 실현하기 위해 기존 샤드 간에 슬롯에 재분배하는 데 사용될 수 있습니다. 클러스터를 생성할 때 수동으로 지정하여 슬롯이 균등하지 않게 분배되거나, 확장/축소 작업으로 슬롯이 클러스터에 균등하지 않게 분배된 경우에 유용합니다. 슬롯의 메모리와 I/O 요구 사항이 동일하다고 가정하면, 균등한 수의 슬롯 분배가 샤드 간에 로드를 밸런싱하기에 쉬운 방법입니다.

Q: 클러스터 확장 시 태깅은 어떻게 작동합니까?

클러스터를 확장하도록 새로운 노드가 추가되면, 해당 노드는 모든 기존 노드에서 공통적으로 발견되는 것과 같은 태그 세트를 보유하게 됩니다. 또한, 사용자는 모든 노드의 태그를 수정하고 계속해서 전과 같은 태깅을 사용할 수 있습니다.

Q: 온라인 클러스터 크기 조정 기능을 사용하기 위해 클라이언트 또는 애플리케이션 측면에서 변경해야 하는 사항은 없습니까?

아니요. 클러스터 크기 조정 워크플로에 사용되는 향상된 슬롯 분배 기능은 Redis 클러스터 클라이언트 동작과 호환되며 애플리케이션을 변경할 필요가 없습니다. ElastiCache는 클러스터 엔드포인트를 유지하므로 기존 클라이언트를 변경할 필요 없이 계속 사용할 수 있습니다.

Q: 향상된 Redis 엔진을 사용하는 데 드는 비용은 얼마나 됩니까?

향상된 Redis 엔진을 사용하는 데 따르는 추가 요금은 없습니다. 늘 그렇듯 사용하는 노드에 대한 비용만 부과됩니다.


Q: Redis용 ElastiCache의 전송 중 암호화에서는 무엇을 제공합니까?

전송 중 암호화 기능을 사용하면 클라이언트와 Redis 서버 간 그리고 Redis 서버와 Redis 서버 간(기본 노드와 읽기 전용 복제본 노드) 모든 통신을 암호화할 수 있습니다.

Q: Redis용 ElastiCache의 저장 중 암호화에서는 무엇을 제공합니까?

저장 중 암호화는 백업과 복원 중 데이터 암호화를 허용합니다. 디스크와 Amazon S3를 통해 백업되고 복원된 데이터가 암호화됩니다.

Q: 전송 중 암호화, 저장 중 암호화 및 Redis AUTH를 사용하려면 어떻게 해야 합니까?

전송 중 암호화, 저장 중 암호화 및 Redis AUTH는 모두 옵트인 기능입니다. 콘솔이나 명령줄 인터페이스를 통해 Redis 클러스터를 생성할 때 암호화와 Redis AUTH를 활성화할지 지정할 수 있으며, 계속 진행하여 Redis 클러스터와 통신을 위한 인증 토큰을 제공할 수 있습니다. 암호화가 활성화된 상태로 클러스터가 설정되면, 애플리케이션에서 추가 작업을 할 필요 없이 ElastiCache가 인증서 만료 및 갱신을 원활하게 관리합니다. 또한, 암호화된 전송 트래픽을 활용하려면 Redis 클라이언트에서 TLS를 지원해야 합니다.

Q: 전송 중 또는 저장 중 암호화를 사용할 때 필요한 Redis용 Amazon ElastiCache가 있습니까?

아니요. 전송 중 암호화에서는 클라이언트가 TLS를 지원해야 합니다. 널리 사용되는 Redis 클라이언트(Lettuce, Predis, go-Redis 등) 대부분이 TLS에 대한 지원을 제공하며, 일부 구성을 설정하면 됩니다. 원하는 Redis 클라이언트가 TLS를 지원하고 이전과 마찬가지로 Redis용 ElastiCache를 계속 사용하도록 구성되는지 확인해야 합니다.

Q: 내 기존 Redis용 ElastiCache 클러스터에 전송 중 암호화와 저장 중 암호화를 활성화할 수 있습니까?

아니요. 전송 중 암호화와 저장 중 암호화는 새로운 클러스터에서만 사용할 수 있으며 기존 Redis용 ElastiCache 클러스터에서는 지원되지 않습니다. Redis용 ElastiCache 버전 3.2.6이 이 기능을 지원하는 초기 버전입니다.

Q: 인증서를 갱신하려면 수행해야 하는 작업이 있습니까?

아니요. ElastiCache가 백그라운드에서 인증서 만료와 갱신을 관리합니다. 인증서를 유지 관리하기 위해 사용자가 수행해야 하는 작업은 없습니다.

Q: 내 인증서를 암호화에 사용할 수 있습니까?

아니요. 현재 ElastiCache에서는 사용자가 인증서를 사용할 수 있는 기능은 제공하지 않습니다. ElastiCache가 사용자를 대신해 인증서를 투명하게 관리합니다.

Q: 전송 중 암호화와 저장 중 암호화를 지원하는 인스턴스 유형은 무엇입니까?

모든 현재 세대 인스턴스에서 전송 중 암호화와 저장 중 암호화를 지원합니다.

Q: 암호화를 사용할 때 부가되는 추가 비용이 있습니까?

암호화를 사용할 때 부가되는 추가 비용은 없습니다.


Q: Redis용 Amazon ElastiCache는 HIPAA 적격 서비스입니까?

예. Redis용 Amazon ElastiCache는 HIPAA 적격 서비스이며, AWS BAA(Business Associate Addendum)에 추가되어 있습니다. 즉, Redis용 ElastiCache를 사용하여 개인 건강 정보(PHI)를 처리, 유지 관리 및 저장하고 의료 서비스 애플리케이션을 지원할 수 있습니다.

Q: HIPAA 적격 서비스인 Redis용 ElastiCache를 사용하려면 어떻게 해야 합니까?

AWS와 BAA(Business Associate Agreement)가 체결되어 있다면 Redis용 ElastiCache를 사용하여 HIPAA 규정 준수 애플리케이션을 구축할 수 있습니다. BAA를 체결하지 않았거나 HIPAA 규정 준수 애플리케이션에 AWS를 사용하는 것과 관련하여 질문이 있는 경우 AWS에 문의하여 자세히 알아보시기 바랍니다. PHI를 저장, 처리, 전송하도록 Amazon HIPAA 적격 서비스를 구성하는 방법에 대한 자세한 내용은 Amazon Web Services에서 HIPAA 보안 및 규정 준수를 위한 아키텍처 설계 백서를 참조하십시오.

Q: Redis용 ElastiCache에서 지원하는 규정 준수 프로그램에는 어떤 것이 있습니까?

Redis용 ElastiCache는 SOC1, SOC 2, SOC 3, ISO, MTCS, C5 및 HIPAA와 같은 규정 준수 프로그램을 지원합니다. 현재 지원되는 규정 준수 프로그램의 목록은 AWS 규정 준수 프로그램 제공 범위 내 서비스 페이지를 참조하십시오.

Q: 규정 준수 기능을 사용하려면 추가 비용을 내야 합니까?

아니요. 규정 준수 기능을 사용하는 데 따른 추가 비용은 없습니다.