ElastiCache 작동 방식 - Amazon ElastiCache

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

ElastiCache 작동 방식

다음은 ElastiCache 배포의 주요 구성 요소를 개괄적으로 설명한 것입니다.

캐시 및 캐싱 엔진

캐시는 캐시된 데이터를 저장하는 데 사용할 수 있는 인메모리 데이터 저장소입니다. 일반적으로 애플리케이션은 응답 시간을 최적화하기 위해 자주 액세스하는 데이터를 캐시에 캐시합니다. ElastiCache는 서버리스 클러스터와 자체 설계된 클러스터라는 2가지 배포 옵션을 제공합니다. 배포 옵션 간 선택을(를) 참조하세요.

참고

Amazon ElastiCache는 Valkey, Memcached 및 Redis OSS 엔진과 함께 작동합니다. 사용하고 싶은 엔진을 결정하기 어렵다면 이 가이드의 Valkey, Memcached 및 Redis OSS 자체 설계된 캐시 비교 섹션을 참조하세요.

ElastiCache 작동 방식

ElastiCache 서버리스

ElastiCache 서버리스를 사용하면 용량 계획, 하드웨어 관리 또는 클러스터 설계에 대한 걱정 없이 캐시를 생성할 수 있습니다. 캐시 이름을 제공하면 Valkey, Memcached, Redis OSS 클라이언트에서 캐시 액세스를 시작하도록 구성할 수 있는 단일 엔드포인트가 수신됩니다.

참고
  • ElastiCache Serverless는 클러스터 모드에서 Valkey, Memcached 또는 Redis OSS를 실행하며 TLS를 지원하는 클라이언트와만 호환됩니다.

주요 이점

  • 용량 계획 없음: ElastiCache 서버리스를 사용하면 용량을 계획할 필요가 없습니다. ElastiCache 서버리스는 캐시의 메모리, 컴퓨팅 및 네트워크 대역폭 사용률을 지속적으로 모니터링하고 수직 및 수평으로 규모를 조정합니다. 이렇게 하면 캐시 노드의 크기를 늘리는 동시에 스케일 아웃 작업을 시작하여 항상 애플리케이션 요구 사항에 맞게 캐시 규모를 조정할 수 있습니다.

  • 종량제: ElastiCache 서버리스를 사용하면 캐시에 저장된 데이터와 워크로드에서 사용한 컴퓨팅에 대한 비용을 지불합니다. 차원 사용을(를) 참조하세요.

  • 고가용성: ElastiCache 서버리스는 고가용성을 위해 여러 가용 영역(AZ)에 데이터를 자동으로 복제합니다. 기본 캐시 노드를 자동으로 모니터링하고 장애 발생 시 이를 대체합니다. 여기서는 모든 캐시에 대해 99.99%의 가용성 SLA를 제공합니다.

  • 자동 소프트웨어 업그레이드: ElastiCache 서버리스는 애플리케이션의 가용성에 영향을 주지 않고 캐시를 최신 마이너 및 패치 소프트웨어 버전으로 자동 업그레이드합니다. 새로운 메이저 버전이 사용 가능하면 ElastiCache에서 알림을 보냅니다.

  • 보안: 서버리스는 전송 중 데이터와 저장된 데이터를 항상 암호화합니다. 서비스 관리형 키를 사용하거나 자체 고객 관리형 키를 사용하여 저장 데이터를 암호화할 수 있습니다.

다음 다이어그램은 ElastiCache 서버리스 작동 방식을 보여 줍니다.

가용 영역에서 고객 VPC까지, 그런 다음 서비스 VPC까지 이어지는 ElastiCache 서버리스 캐시 작업의 다이어그램입니다.

새 서버리스 캐시를 생성하면 ElastiCache는 VPC에서 선택한 서브넷에 Virtual Private Cloud(VPC) 엔드포인트를 생성합니다. 애플리케이션은 이러한 VPC 엔드포인트를 통해 캐시에 연결할 수 있습니다.

ElastiCache 서버리스를 사용하면 애플리케이션이 연결되는 단일 DNS 엔드포인트를 수신합니다. 엔드포인트에 대해 새 연결을 요청하면 ElastiCache 서버리스가 프록시 계층을 통해 모든 캐시 연결을 처리합니다. 프록시 계층을 사용하면 기본 클러스터가 변경될 경우 클라이언트가 클러스터 토폴로지를 재검색할 필요가 없으므로 복잡한 클라이언트 구성을 줄일 수 있습니다. 프록시 계층은 Network Load Balancer를 사용하여 연결을 처리하는 프록시 노드 집합입니다.

애플리케이션이 새 캐시 연결을 생성하면 Network Load Balancer가 요청을 프록시 노드로 보냅니다. 애플리케이션이 캐시 명령을 실행하면 애플리케이션에 연결된 프록시 노드가 캐시의 캐시 노드에서 요청을 실행합니다. 프록시 계층은 클라이언트의 캐시 클러스터 토폴로지와 노드를 추상화합니다. 따라서 ElastiCache는 애플리케이션의 가용성에 영향을 미치거나 연결을 재설정하지 않고도 지능적으로 로드 밸런싱을 수행하고, 캐시 노드를 스케일 아웃하여 새 캐시 노드를 추가하고, 장애 발생 시 캐시 노드를 교체하고, 캐시 노드의 소프트웨어를 업데이트할 수 있습니다.

자체 설계된 ElastiCache 클러스터

클러스터의 캐시 노드 패밀리, 크기 및 노드 수를 n개 선택하여 자체 ElastiCache 클러스터를 설계할 수 있습니다. 클러스터를 직접 설계하면 보다 세밀하게 제어할 수 있으며 캐시의 샤드 수와 각 샤드의 노드 수(기본 및 복제본)를 선택할 수 있습니다. 여러 샤드로 클러스터를 생성하여 클러스터 모드에서 Valkey 또는 Redis OSS를 작동시키거나 단일 샤드를 사용하는 비클러스터 모드에서 작동시킬 수 있습니다.

주요 이점

  • 자체 클러스터 설계: ElastiCache를 사용하면 자체 클러스터를 설계하고 캐시 노드를 배치할 위치를 선택할 수 있습니다. 예를 들어 고가용성을 낮은 지연 시간과 절충하려는 애플리케이션을 보유하고 있는 경우 단일 AZ에 캐시 노드를 배포하도록 선택할 수 있습니다. 또는 다중 AZ에 노드가 있는 클러스터를 설계하여 고가용성을 달성할 수도 있습니다.

  • 세밀한 제어: 자체 클러스터를 설계할 때 캐시의 설정을 더 세밀하게 조정할 수 있습니다. 예를 들어 Valkey 및 Redis OSS 파라미터 또는 Memcached 특정 파라미터를 사용하여 캐시 엔진을 구성할 수 있습니다.

  • 수직 및 수평으로 규모 조정: 필요할 때 캐시 노드 크기를 늘리거나 줄여 수동으로 클러스터 규모를 조정하도록 선택할 수 있습니다. 새 샤드를 추가하거나 샤드에 복제본을 추가하여 수평적으로 규모를 조정할 수도 있습니다. 또한 오토 스케일링 기능을 사용하여 일정에 따라 규모 조정을 구성하거나 캐시의 CPU 및 메모리 사용량과 같은 지표를 기반으로 규모 조정을 구성할 수 있습니다.

다음 다이어그램은 ElastiCache의 자체 설계된 클러스터의 작동 방식을 보여 줍니다.

가용 영역에서 고객 VPC, ElastiCache 관리형 캐시 노드에 이르기까지 ElastiCache가 자체 설계한 클러스터 운영의 다이어그램입니다.

차원 사용

2가지 배포 옵션으로 ElastiCache를 배포할 수 있습니다. ElastiCache 서버리스를 배포할 때는 GB-시간 단위로 저장된 데이터에 대한 사용량을 지불하고 ElastiCache 처리 장치(ECPU)에서 컴퓨팅합니다. 자체 ElastiCache 클러스터를 설계하기로 한 경우 캐시 노드 사용량을 시간당으로 지불합니다. 요금 관련 세부 사항은 여기를 참조하세요.

데이터 스토리지

기가바이트-시간(GB-시간) 단위로 청구되는 ElastiCache 서버리스에 저장된 데이터에 대한 요금을 지불합니다. ElastiCache 서버리스는 캐시에 저장된 데이터를 지속적으로 모니터링하여 분당 여러 번 샘플링하고 시간당 평균을 계산하여 캐시의 데이터 스토리지 사용량을 GB-시간 단위로 결정합니다. 각 ElastiCache 서버리스 캐시는 저장된 최소 1GB의 데이터를 측정합니다.

ElastiCache 처리 단위(ECPU)

애플리케이션이 ElastiCache 처리 단위(ECPU)의 ElastiCache 서버리스에서 실행하는 요청에 대한 비용을 지불하면 됩니다. 이 단위에는 vCPU 시간과 전송된 데이터가 모두 포함됩니다.

  • 단순 읽기 및 쓰기에는 전송되는 데이터 1킬로바이트(KB)당 ECPU 1개가 필요합니다. 예를 들어 최대 1KB의 데이터를 전송하는 GET 명령은 1개의 ECPU를 사용합니다. 3.2KB의 데이터를 전송하는 SET 요청은 3.2ECPU를 사용합니다.

  • Valkey 및 Redis OSS를 사용하면 더 많은 vCPU 시간을 사용하고 더 많은 데이터를 전송하는 명령은 두 차원 중 더 높은 차원을 기반으로 ECPU를 사용합니다. 예를 들어 애플리케이션이 HMGET 명령을 사용하고 간단한 SET/GET 명령보다 vCPU 시간을 3배 더 사용하며, 3.2KB의 데이터를 전송한다면 3.2개의 ECPU가 사용됩니다. 또는 2KB의 데이터만 전송하는 경우 3개의 ECPU를 사용하게 됩니다.

  • Valkey 및 Redis OSS를 사용하면 vCPU 시간이 추가로 필요한 명령은 그에 비례하여 더 많은 ECPU를 사용합니다. 예를 들어 애플리케이션이 Valkey 또는 Redis OSS HMGET 명령을 사용하고 간단한 SET/GET 명령보다 vCPU 시간을 3배 더 사용한다면 3개의 ECPU가 사용됩니다.

  • Memcached를 사용하면 여러 항목에서 작동하는 명령은 그에 비례하여 더 많은 ECPU를 사용합니다. 예를 들어 애플리케이션이 항목 3개에 대해 멀티젯을 수행하는 경우 3개의 ECPU를 사용하게 됩니다.

  • Memcached를 사용하면 더 많은 항목에서 작동하고 더 많은 데이터를 전송하는 명령은 두 차원 중 더 높은 차원을 기준으로 ECPU를 사용합니다. 예를 들어 애플리케이션이 GET 명령을 사용하여 항목 3개를 검색하고 3.2KB의 데이터를 전송하는 경우 3.2ECPU를 사용하게 됩니다. 또는 2KB의 데이터만 전송하는 경우 3개의 ECPU를 사용하게 됩니다.

ElastiCache 서버리스는 워크로드에서 사용하는 ECPU를 이해하는 데 도움이 되는 새로운 ElastiCacheProcessingUnits 지표를 내보냅니다.

노드 시간

EC2 노드 패밀리, 크기, 노드 수, 가용 영역 전반의 배치를 선택하여 자체 캐시 클러스터를 설계할 수 있습니다. 클러스터를 자체 설계할 때는 각 캐시 노드에 대해 시간당 요금을 지불합니다.

ElastiCache 백업

백업은 서버리스 캐시 또는 Valkey 또는 Redis OSS 자체 설계 클러스터의 특정 시점 사본입니다. ElastiCache를 사용하면 언제든지 데이터를 백업하거나 자동 백업을 설정할 수 있습니다. 백업을 사용하여 기존 캐시를 복원하거나 새 캐시를 시드할 수 있습니다. 백업은 캐시의 모든 데이터와 일부 메타데이터로 구성됩니다. 자세한 내용은 스냅샷 및 복원 섹션을 참조하세요.