기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # ElastiCache 작동 방식 작동 방식 다음은 ElastiCache 배포의 주요 구성 요소를 개괄적으로 설명한 것입니다. ## 캐시 및 캐싱 엔진 캐시 및 캐싱 엔진 캐시는 캐시된 데이터를 저장하는 데 사용할 수 있는 인메모리 데이터 저장소입니다. 일반적으로 애플리케이션은 응답 시간을 최적화하기 위해 자주 액세스하는 데이터를 캐시에 캐시합니다. ElastiCache는 서버리스 캐시와 노드 기반 클러스터의 두 가지 배포 옵션을 제공합니다. [배포 옵션 간 선택](WhatIs.deployment.md) 섹션을 참조하세요. **참고** Amazon ElastiCache는 Valkey, Memcached 및 Redis OSS 엔진 모두와 함께 작동합니다. 사용하고 싶은 엔진을 결정하기 어렵다면 이 가이드의 [노드 기반 Valkey, Memcached 및 Redis OSS 클러스터 비교](SelectEngine.md) 섹션을 참조하세요. **Topics** + [ ### ElastiCache 작동 방식 ](#WhatIs.HowELCworks) + [ ### 차원 사용 ](#WhatIs.ELCpricing) + [ ### ElastiCache 백업 ](#WhatIs.corecomponents.backups-redis) ### ElastiCache 작동 방식 ElastiCache 작동 방식 **ElastiCache 서버리스** ElastiCache 서버리스를 사용하면 용량 계획, 하드웨어 관리 또는 클러스터 설계에 대한 걱정 없이 캐시를 생성할 수 있습니다. 캐시 이름만 입력하면 Valkey, Memcached 또는 Redis OSS 클라이언트에서 캐시 액세스를 시작하도록 구성할 수 있는 단일 엔드포인트를 받게 됩니다. **참고** ElastiCache Serverless는 클러스터 모드에서 Valkey, Memcached 또는 Redis OSS를 실행하며 TLS를 지원하는 클라이언트와만 호환됩니다. **주요 이점** + **용량 계획 없음:** ElastiCache 서버리스를 사용하면 용량을 계획할 필요가 없습니다. ElastiCache 서버리스는 캐시의 메모리, 컴퓨팅 및 네트워크 대역폭 사용률을 지속적으로 모니터링하고 수직 및 수평으로 규모를 조정합니다. 이렇게 하면 캐시 노드의 크기를 늘리는 동시에 스케일 아웃 작업을 시작하여 항상 애플리케이션 요구 사항에 맞게 캐시 규모를 조정할 수 있습니다. + **종량제:** ElastiCache 서버리스를 사용하면 캐시에 저장된 데이터와 워크로드에서 사용한 컴퓨팅에 대한 비용을 지불합니다. [차원 사용](#WhatIs.ELCpricing)을(를) 참조하세요. + **고가용성:** ElastiCache 서버리스는 고가용성을 위해 여러 가용 영역(AZ)에 데이터를 자동으로 복제합니다. 기본 캐시 노드를 자동으로 모니터링하고 장애 발생 시 이를 대체합니다. 여기서는 모든 캐시에 대해 99.99%의 가용성 SLA를 제공합니다. + **자동 소프트웨어 업그레이드:** ElastiCache 서버리스는 애플리케이션의 가용성에 영향을 주지 않고 캐시를 최신 마이너 및 패치 소프트웨어 버전으로 자동 업그레이드합니다. 새로운 메이저 버전이 사용 가능하면 ElastiCache에서 알림을 보냅니다. + **보안:** 서버리스는 전송 중 데이터와 저장된 데이터를 항상 암호화합니다. 서비스 관리형 키를 사용하거나 자체 고객 관리형 키를 사용하여 저장 데이터를 암호화할 수 있습니다. 다음 다이어그램은 ElastiCache 서버리스 작동 방식을 보여 줍니다. ![\[가용 영역에서 고객 VPC까지, 그런 다음 서비스 VPC까지 이어지는 ElastiCache 서버리스 캐시 작업의 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ELC-serverless-works1.png) 새 서버리스 캐시를 생성하면 ElastiCache는 VPC에서 선택한 서브넷에 Virtual Private Cloud(VPC) 엔드포인트를 생성합니다. 애플리케이션은 이러한 VPC 엔드포인트를 통해 캐시에 연결할 수 있습니다. ElastiCache 서버리스를 사용하면 애플리케이션이 연결되는 단일 DNS 엔드포인트를 수신합니다. 엔드포인트에 대해 새 연결을 요청하면 ElastiCache 서버리스가 프록시 계층을 통해 모든 캐시 연결을 처리합니다. 프록시 계층을 사용하면 기본 클러스터가 변경될 경우 클라이언트가 클러스터 토폴로지를 재검색할 필요가 없으므로 복잡한 클라이언트 구성을 줄일 수 있습니다. 프록시 계층은 Network Load Balancer를 사용하여 연결을 처리하는 프록시 노드 집합입니다. 애플리케이션이 새 캐시 연결을 생성하면 Network Load Balancer가 요청을 프록시 노드로 보냅니다. 애플리케이션이 캐시 명령을 실행하면 애플리케이션에 연결된 프록시 노드가 캐시의 캐시 노드에서 요청을 실행합니다. 프록시 계층은 클라이언트의 클러스터 토폴로지와 노드를 추상화합니다. 따라서 ElastiCache는 애플리케이션의 가용성에 영향을 미치거나 연결을 재설정하지 않고도 지능적으로 로드 밸런싱을 수행하고, 캐시 노드를 스케일 아웃하여 새 캐시 노드를 추가하고, 장애 발생 시 캐시 노드를 교체하고, 캐시 노드의 소프트웨어를 업데이트할 수 있습니다. **노드 기반 클러스터** 클러스터의 캐시 노드 패밀리, 크기 및 노드 수를 선택하여 노드 기반 ElastiCache 클러스터를 생성할 수 있습니다. 노드 기반 클러스터를 직접 생성하면 보다 세밀하게 제어할 수 있으며 캐시의 샤드 수와 각 샤드의 노드 수(기본 및 복제본)를 선택할 수 있습니다. 여러 샤드로 클러스터를 생성하여 클러스터 모드에서 Valkey 또는 Redis OSS를 작동시키거나 단일 샤드를 사용하는 비클러스터 모드에서 작동시킬 수 있습니다. **주요 이점** + **노드 기반 클러스터 생성:** ElastiCache를 사용하면 노드 기반 클러스터를 생성하고 캐시 노드를 배치할 위치를 선택할 수 있습니다. 예를 들어 고가용성을 낮은 지연 시간과 절충하려는 애플리케이션을 보유하고 있는 경우 단일 AZ에 캐시 노드를 배포하도록 선택할 수 있습니다. 또는 다중 AZ에 노드가 있는 노드 기반 클러스터를 생성하여 고가용성을 달성할 수도 있습니다. + **세밀한 제어:** 노드 기반 클러스터를 생성할 때 캐시의 설정을 더 미세 조정할 수 있습니다. 예를 들어 [Valkey 및 Redis OSS 파라미터](ParameterGroups.Engine.md#ParameterGroups.Redis) 또는 [Memcached 특정 파라미터](ParameterGroups.Engine.md#ParameterGroups.Memcached)를 사용하여 캐시 엔진을 구성할 수 있습니다. + **수직 및 수평으로 규모 조정:** 필요할 때 캐시 노드 크기를 늘리거나 줄여 수동으로 클러스터 규모를 조정하도록 선택할 수 있습니다. 새 샤드를 추가하거나 샤드에 복제본을 추가하여 수평적으로 규모를 조정할 수도 있습니다. 또한 오토 스케일링 기능을 사용하여 일정에 따라 규모 조정을 구성하거나 캐시의 CPU 및 메모리 사용량과 같은 지표를 기반으로 규모 조정을 구성할 수 있습니다. 다음 다이어그램은 ElastiCache의 노드 기반 클러스터의 작동 방식을 보여 줍니다. ![\[가용 영역에서 고객 VPC, ElastiCache 관리형 캐시 노드에 이르기까지 ElastiCache가 노드 기반 클러스터 운영의 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ELC-serverless-works2.png) ### 차원 사용 가격 책정 2가지 배포 옵션으로 ElastiCache를 배포할 수 있습니다. ElastiCache 서버리스를 배포할 때는 GB-시간 단위로 저장된 데이터에 대한 사용량을 지불하고 ElastiCache 처리 장치(ECPU)에서 컴퓨팅합니다. 노드 기반 클러스터를 생성할 때 캐시 노드 사용량에 대해 시간당 요금을 지불합니다. 요금 관련 세부 사항은 [여기](https://aws.amazon.com/elasticache/pricing/)를 참조하세요. **데이터 스토리지** 기가바이트-시간(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 명령](https://valkey.io/commands/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를 사용하면 언제든지 데이터를 백업하거나 자동 백업을 설정할 수 있습니다. 백업을 사용하여 기존 캐시를 복원하거나 새 캐시를 시드할 수 있습니다. 백업은 캐시의 모든 데이터와 일부 메타데이터로 구성됩니다. 자세한 내용은 [스냅샷 및 복원](backups.md) 섹션을 참조하세요. # 배포 옵션 간 선택 배포 옵션 간 선택 Amazon ElastiCache에는 다음과 같은 2가지 배포 옵션이 있습니다. + 서버리스 캐시 + 노드 기반 클러스터 둘 다에 대해 지원되는 명령 목록은 [지원 및 제한된 Valkey, Memcached 및 Redis OSS 명령](SupportedCommands.md) 섹션을 참조하세요. **서버리스 캐시** Amazon ElastiCache 서버리스는 캐시 생성을 간소화하고 고객의 가장 까다로운 애플리케이션을 지원하도록 즉시 규모를 조정할 수 있습니다. ElastiCache Serverless를 사용하면 클러스터 용량을 프로비저닝, 계획 및 관리할 필요 없이 1분 이내에 가용성과 확장성이 뛰어난 캐시를 생성할 수 있습니다. ElastiCache 서버리스는 3개의 가용 영역에 데이터를 자동으로 중복 저장하고 99.99%의 가용성 서비스 수준에 관한 계약(SLA)을 제공합니다. Valkey 또는 Redis OSS 노드 기반 클러스터의 백업을 서버리스 구성으로 복원할 수 있습니다. **노드 기반 클러스터** Valkey, Memcached 또는 Redis OSS 클러스터를 세밀하게 제어해야 하는 경우 ElastiCache를 사용하여 노드 기반 클러스터를 생성할 수 있습니다. 클러스터의AWS가용 영역에서 노드 유형, 노드 수 및 노드 배치를 선택합니다. ElastiCache는 완전 관리형 서비스이므로 클러스터의 하드웨어 프로비저닝, 모니터링, 노드 교체 및 소프트웨어 패치를 관리하는 데 유용합니다. 노드 기반 클러스터는 최대 99.99%의 가용성 SLA를 제공하도록 설계할 수 있습니다. 서버리스 Valkey 또는 Redis OSS 캐시의 백업을 노드 기반 클러스터로 복원할 수 있습니다. **배포 옵션 간 선택** 다음과 같은 경우 서버리스 캐싱을 선택합니다. + 새롭거나 예측하기 어려운 워크로드에 대한 캐시를 생성하고 있는 경우 + 애플리케이션 트래픽이 예측 불가능한 경우가 있습니다. + 캐시를 가장 쉽게 시작하는 방법을 찾고 있는 경우 다음에 해당하면 자체 노드 기반 클러스터를 생성합니다. + 이미 ElastiCache Serverless를 실행하고 있으며 Valkey, Memcached 또는 Redis OSS를 실행하는 노드 유형, 노드 수 및 해당 노드의 배치를 보다 세밀하게 제어하고자 합니다. + 애플리케이션 트래픽은 비교적 예측 가능하며 성능, 가용성 및 비용에 대한 세분화된 제어가 필요합니다. + 비용 제어를 위해 용량 요구 사항을 예측할 수 있는 경우 ## 서버리스 캐싱과 노드 기반 클러스터 비교 기능 비교 | 기능 | 서버리스 캐시 | 노드 기반 클러스터 | | --- | --- | --- | | 캐시 설정 | 1분 이내에 이름만 있는 캐시 생성 | 클러스터 설계를 세밀하게 제어할 수 있습니다. 사용자는 노드 유형, 노드 수 및AWS가용 영역 간 배치를 선택할 수 있습니다. | | 지원되는 ElastiCache 버전 | Valkey 7.2 이상, Redis OSS 버전 7.1 이상, Memcached 1.6.21 이상 | Valkey 7.2 이상, Redis OSS 버전 4.0 이상, Memcached 1.4 이상 | | 클러스터 모드(Valkey 및 Redis OSS) | 엔진은 `cluster mode enabled`에서만 작동합니다. 클라이언트는 `cluster mode enabled`를 지원해야 ElastiCache 서버리스에 연결할 수 있습니다. | 클러스터 모드가 활성화되거나 클러스터 모드가 비활성화된 상태에서 작동하도록 구성할 수 있습니다. | | 스케일링 | 용량 관리 없이 수직적 및 수평적으로 엔진을 자동으로 확장할 수 있습니다. | 확장에 대한 제어 기능을 제공하는 동시에 현재 용량이 수요를 적절히 충족하는지 모니터링해야 합니다. Valkey 및 Redis OSS의 경우 필요한 경우 캐시 노드 크기를 늘리거나 줄여 수직적으로 확장하도록 선택할 수 있습니다. 새 샤드를 추가하거나 샤드에 복제본을 추가하여 수평적으로 규모를 조정할 수도 있습니다. Memcached에서는 이 기능을 사용할 수 없습니다. Auto-Scaling 기능을 사용하면 일정에 따라 규모 조정을 수동으로 구성하거나 캐시의 CPU 및 메모리 사용량과 같은 지표를 기반으로 규모 조정을 구성할 수 있습니다. | | 클라이언트 연결 | 클라이언트는 단일 엔드포인트에 연결됩니다. 이렇게 하면 기본 캐시 노드 토폴로지(규모 조정, 교체 및 업그레이드)가 클라이언트 연결을 해제하지 않고 변경될 수 있습니다. | 클라이언트는 각 개별 캐시 노드에 연결됩니다. 노드를 교체하면 클라이언트가 클러스터 토폴로지를 다시 검색하고 연결을 다시 설정합니다. | | 구성 가능성 | 세분화된 구성을 사용할 수 없습니다. 고객은 캐시에 액세스할 수 있는 서브넷, 자동 백업이 켜져 있는지 또는 꺼져 있는지 여부, 최대 캐시 사용량 제한을 포함한 기본 설정을 구성할 수 있습니다. | 노드 기반 클러스터는 세분화된 구성 옵션을 제공합니다. 고객은 파라미터 그룹을 사용하여 세분화된 제어를 수행할 수 있습니다. 노드 유형별 파라미터 값의 표는 [엔진별 파라미터](ParameterGroups.Engine.md) 섹션을 참조하세요. | | Multi-AZ | 데이터는 가용성을 높이고 읽기 지연 시간을 개선하기 위해 여러 가용 영역에 비동기적으로 복제됩니다. | 단일 가용 영역 또는 다중 가용 영역(AZ)에서 클러스터를 생성하는 옵션을 제공합니다. Valkey 또는 Redis OSS를 사용하는 경우 다중 가용 영역에 비동기적으로 복제된 데이터를 다중 AZ 클러스터에 제공하여 가용성을 높이고 읽기 지연 시간을 개선합니다. | | 저장 시 암호화 | 항상 활성화됨. 고객은AWS 관리형 키또는 고객 관리형 키를에서 사용할 수 있습니다AWS KMS. | 저장 중 암호화를 활성화 또는 비활성화하는 옵션입니다. 활성화하면 고객은AWS 관리형 키또는 고객 관리형 키를 사용할 수 있습니다AWS KMS. | | 전송 중 암호화(TLS) | 항상 활성화됨. 클라이언트는 TLS 연결을 지원해야 합니다. | 활성화 또는 비활성화하는 옵션입니다. | | 백업 | 성능에 영향을 주지 않고 캐시의 자동 및 수동 백업을 지원합니다. Valkey 및 Redis OSS 백업은 교차 호환되며 ElastiCache Serverless 캐시 또는 노드 기반 클러스터로 복원할 수 있습니다. | Valkey 및 Redis OSS에 대한 자동 및 수동 백업을 지원합니다. 클러스터는 사용 가능한 예약 메모리에 따라 성능에 약간의 영향을 받을 수 있습니다. 자세한 내용은 [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md) 단원을 참조하십시오. Valkey 및 Redis OSS 백업은 교차 호환되며 ElastiCache Serverless 캐시 또는 노드 기반 클러스터로 복원할 수 있습니다. | | 모니터링 | 캐시 적중률, 캐시 누락률, 데이터 크기 및 사용된 ECPU와 같은 캐시 수준 지표를 지원합니다. ElastiCache 서버리스는 캐시에서 중요한 이벤트가 발생할 때 EventBridge를 사용하여 이벤트를 전송합니다. Amazon EventBridge를 사용하여 ElastiCache 이벤트를 모니터링하고, 수집하고, 변환하고, 조치를 취하도록 선택할 수 있습니다. 자세한 내용은 [서버리스 캐시 이벤트](serverless-metrics-events-redis.md#serverless-events) 단원을 참조하십시오. | ElastiCache 노드 기반 클러스터는 호스트 수준 지표와 캐시 지표를 모두 포함하여 각 노드 수준에서 지표를 내보냅니다. 노드 기반 클러스터는 중요한 이벤트에 대한 SNS 알림을 내보냅니다. [Memcached 지표](CacheMetrics.Memcached.md) 및 [Valkey 및 Redis OSS에 대한 지표](CacheMetrics.Redis.md) 섹션을 참조하세요. | | 가용성 | 99.99% 가용성 [서비스 수준 계약(SLA)](https://aws.amazon.com/elasticache/sla/) | 노드 기반 클러스터는 구성에 따라 최대 99.99% 가용성 [서비스 수준 계약(SLA)](https://aws.amazon.com/elasticache/sla/)을 달성하도록 설계할 수 있습니다. | | 소프트웨어 업그레이드 및 패치 적용 | 애플리케이션에 영향을 주지 않고 캐시 소프트웨어를 최신 마이너 및 패치 버전으로 자동 업그레이드합니다. 고객은 메이저 버전 업그레이드에 대한 알림을 받으며 원하는 경우 최신 메이저 버전으로 업그레이드할 수 있습니다. | 노드 기반 클러스터는 마이너 및 패치 버전 업그레이드와 메이저 버전 업그레이드를 위한 고객 지원 셀프 서비스를 제공합니다. 관리 업데이트는 고객이 지정한 유지 관리 기간 동안 자동으로 적용됩니다. 고객은 마이너 또는 패치 버전 업그레이드를 온디맨드로 적용하도록 선택할 수도 있습니다. | | 글로벌 데이터 저장소 | 지원되지 않음 | 단일 리전 쓰기 및 다중 리전 읽기로 리전 간 복제를 지원하는 글로벌 데이터 저장소 지원 | | 데이터 계층화 | 지원되지 않음 | r6gd 패밀리의 노드를 사용하고 있는 생성된 클러스터는 메모리와 로컬 SSD(솔리드 스테이트 드라이브) 스토리지 간에 데이터를 계층화합니다. 데이터 계층화는 데이터를 메모리에 저장하는 것 외에도 각 클러스터 노드에서 저렴한 SSD(Solid State Drive)를 활용하여 Valkey 및 Redis OSS 워크로드에 대한 가격 대비 성능 옵션을 제공합니다. | | 요금 모델 | 종량제 과금: GB-시간 단위로 저장된 데이터와 ElastiCache 처리 장치(ECPU)의 요청을 기반으로 한 요금입니다. 요금 관련 세부 사항은 [여기](https://aws.amazon.com/elasticache/pricing/)를 참조하세요. | 시간당 과금: 캐시 노드 사용량에 따른 요금입니다. 요금 관련 세부 사항은 [여기](https://aws.amazon.com/elasticache/pricing/)를 참조하세요. | 관련 항목: + [노드 기반 ElastiCache 클러스터 생성 및 관리노드 기반 ElastiCache 클러스터 생성 및 관리](designing-elasticache-cluster.md) # 처음 사용할 경우를 위한 Amazon ElastiCache 리소스 ElastiCache 리소스 처음 사용할 경우 먼저 다음 섹션을 읽고 필요에 따라 참조하는 것이 좋습니다. + **서비스 하이라이트 및 요금** - [제품 세부 정보 페이지](https://aws.amazon.com/elasticache/)는 일반적인 ElastiCache 제품 개요, 서비스 하이라이트 및 요금 정보를 제공합니다. + **ElastiCache 동영상** - [ElastiCache 동영상](Tutorials.md#tutorial-videos) 섹션에는 Amazon ElastiCache를 소개하는 동영상이 있습니다. 이 동영상에서는 ElastiCache에 대한 일반 사용 사례를 다루며, ElastiCache를 사용하여 지연 시간을 줄이고 애플리케이션의 처리량을 향상하는 방법을 설명합니다. + **시작하기** - [Amazon ElastiCache 시작하기](GettingStarted.md) 섹션에는 캐시 생성에 대한 정보가 나와 있습니다. 여기에는 클러스터에 액세스할 수 있는 권한을 부여하는 방법과 캐시 노드에 연결하고 캐시를 삭제하는 방법도 포함되어 있습니다. + **규모에 따른 성능** - [Amazon ElastiCache의 규모에 따른 성능](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf) 백서에서는 규모에 따라 애플리케이션이 원활하게 수행할 수 있도록 지원하는 캐싱 전략에 대해 설명합니다. 이전 섹션을 완료한 후에는 다음 섹션을 읽어 보십시오. + [노드 크기 선택](CacheNodes.SelectSize.md) 캐시하려는 모든 데이터를 수용할 만큼의 충분한 노드를 원하며, 동시에 필요한 것보다 더 많은 캐시의 비용을 지불하고 싶지 않은 경우 이 항목을 사용하여 최적의 노드 크기를 선택할 수 있습니다. + [ElastiCache 모범 사례 및 캐싱 전략](BestPractices.md) 클러스터의 효율성에 영향을 줄 수 있는 문제를 확인하고 해결하세요. AWS Command Line Interface(AWS CLI)를 사용하려면 다음 문서를 사용하여 시작할 수 있습니다. + [AWS Command Line Interface설명서](https://docs.aws.amazon.com/cli/) 이 섹션에서는 다운로드AWS CLI, 시스템에서AWS CLI작업 가져오기,AWS자격 증명 제공에 대한 정보를 제공합니다. + [AWS CLI ElastiCache 설명서](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html) 이 별도의 문서에서는 구문 및 예제AWS CLI를 포함하여 ElastiCache용 명령을 모두 다룹니다. ElastiCache API를 널리 사용되는 다양한 프로그래밍 언어로 사용하도록 애플리케이션 프로그램을 작성할 수 있습니다. 다음과 같은 몇 가지 리소스가 있습니다. + [Amazon Web Services용 도구](https://aws.amazon.com/tools/) Amazon Web Services는 ElastiCache에 대한 지원과 더불어 다양한 SDK(소프트웨어 개발 키트)를 제공합니다. Java, .NET, PHP, Ruby 및 기타 언어를 사용하여 ElastiCache에 대해 코딩할 수 있습니다. 이러한 SDK는 ElastiCache에 대한 요청을 포맷하고 응답을 분석하며 재시도 논리 및 오류 처리를 제공함으로써 애플리케이션 개발을 상당히 간소화할 수 있습니다. + [ElastiCache API 사용](ProgrammingGuide.md) AWS SDKs를 사용하지 않으려면 쿼리 API를 사용하여 ElastiCache와 직접 상호 작용할 수 있습니다. 이 섹션에서 요청 생성과 인증 및 응답 처리에 대한 정보와 문제 해결 팁을 찾을 수 있습니다. + [Amazon ElastiCache API 참조](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/) 이 별도의 문서는 구문 및 예제를 포함한 모든 ElastiCache API 작업을 다룹니다. # AWS 리전 및 가용 영역 AWS 리전 및 가용 영역 Amazon 클라우드 컴퓨팅 리소스는 전 세계 여러 리전의 가용성이 높은 데이터 센터 시설에 하우징됩니다(예: 북미, 유럽 또는 아시아). 각 데이터 센터 위치를 AWS 리전이라고 합니다. AWS 리전마다 가용 영역 또는 AZ라는 고유한 위치가 여러 개 포함됩니다. 각 가용 영역은 다른 가용 영역에서 발생한 장애에서 격리되도록 설계되었습니다. 각 가용 영역은 같은 AWS 리전에 있는 다른 가용 영역에 대해 저렴하고 지연 시간이 짧은 네트워크 연결을 제공하도록 설계되었습니다. 별도의 가용 영역에서 인스턴스를 시작함으로써 단일 위치에서 장애가 발생할 경우 애플리케이션을 보호할 수 있습니다. 자세한 내용은 [리전 및 가용 영역 선택](RegionsAndAZs.md) 섹션을 참조하세요. 여러 가용 영역에서 클러스터를 생성할 수 있습니다. 다중 AZ 배포라는 옵션입니다. 이 옵션을 선택하면 Amazon은 다른 가용 영역에서 보조 예비 노드 인스턴스를 자동으로 프로비저닝하고 유지합니다. 기본 노드 인스턴스는 가용 영역 전체에서 보조 인스턴스로 비동기식으로 복제됩니다. 이 접근 방식을 통해 데이터 중복 및 장애 조치 지원을 제공하고, I/O 중지를 없애고, 시스템 백업 중에 지연 시간 스파이크를 최소화할 수 있습니다. 자세한 정보는 [다중 AZ로 ElastiCache for Valkey 및 Redis OSS의 가동 중지 시간 최소화](AutoFailover.md)를 참조하세요. # 일반적인 ElastiCache 사용 사례 및 ElastiCache 활용 방법 사용 사례 최신 뉴스, 10대 리더보드, 제품 카탈로그를 게재할 때나 이벤트 티켓을 판매할 때 가장 중요한 것은 속도입니다. 웹 사이트와 비즈니스의 성공 여부는 콘텐츠를 제공하는 속도에 상당한 영향을 받습니다. 뉴욕 타임즈의 "[For Impatient Web Users, an Eye Blink Is Just Too Long to Wait(참을성 없는 웹 사용자에게는 눈 깜박하는 시간조차 너무 길게 느껴져)](http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?pagewanted=all&_r=0)"라는 기사에 따르면 사용자는 경쟁 사이트 간의 250밀리초(4/4초) 차이를 인지합니다. 사용자는 결국 속도가 느린 사이트를 떠나 빠른 사이트로 이동합니다. [How Webpage Load Time Is Related to Visitor Loss](http://pearanalytics.com/blog/2009/how-webpage-load-time-related-to-visitor-loss/)에 따르면 Amazon에서 실시한 테스트에서 로드 시간이 100밀리초(10/10초) 증가할 때마다 매출이 1% 감소하는 결과가 나왔습니다. 다른 사용자가 데이터를 원할 경우 캐시된 데이터를 훨씬 더 빠르게 제공할 수 있습니다. 웹 페이지든 비즈니스 결정을 주도하는 보고서용이든 이는 동일하게 적용되는 사실입니다. 귀사에서는 웹 페이지를 캐시하지 않고 지연 시간을 최소화하여 제공할 여유가 있습니까? 가장 많이 요청되는 항목을 캐시하려 할 것이라는 사실은 어쩌면 자명한 것일 수 있습니다. 요청 빈도가 낮은 항목을 캐시하려고 하지 않는 이유는 무엇입니까? 가장 최적화된 데이터베이스 쿼리나 원격 API 호출이라 할지라도 인 메모리 캐시에서 플랫 키를 검색하는 것보다 현저히 느려집니다. *현저히 느려지면* 고객이 다른 곳으로 떠나는 경향이 있습니다. 다음 예제에서는 ElastiCache를 사용하여 애플리케이션의 전반적인 성능을 개선할 수 있는 몇 가지 방법을 보여줍니다. **Topics** + [ ## 인 메모리 데이터 스토어 ](#elasticache-use-cases-data-store) + [ ## 게임 리더보드 ](#elasticache-for-redis-use-cases-gaming) + [ ## 메시징(Pub/Sub) ](#elasticache-for-redis-use-cases-messaging) + [ ## 권장 데이터(해시) ](#elasticache-for-redis-use-cases-recommendations) + [ ## 생성형 AI 애플리케이션을 위한 의미 체계 캐싱 ](#elasticache-for-redis-use-cases-semantic-caching) + [ ## ElastiCache 고객 추천사 ](#elasticache-use-cases-testimonials) ## 인 메모리 데이터 스토어 인 메모리 키-값 스토어의 주된 목적은 지연 시간이 1밀리초 미만인 매우 빠른 속도와 저렴한 비용으로 데이터 복사본에 액세스할 수 있게 하는 것입니다. 대부분의 데이터 스토어에는 자주 액세스하지만 거의 업데이트하지 않는 데이터 영역이 있습니다. 또한 데이터베이스를 쿼리하면 키-값 페어 캐시에서 키를 찾는 것에 비해 확실히 속도가 느리고 비용이 많이 듭니다. 일부 데이터베이스 쿼리는 특히 수행하는 데 있어 많은 비용이 듭니다. 예로는 여러 표에 걸친 조인이나 복잡한 계산이 포함된 쿼리를 들 수 있습니다. 이러한 쿼리 결과를 캐시하여 쿼리 가격을 한 번만 지불합니다. 그런 다음 쿼리를 다시 실행할 필요 없이 여러 번 데이터를 빠르게 검색할 수 있습니다. ### 어떻게 캐시해야 합니까? 캐시할 데이터를 결정할 때 다음과 같은 요인을 고려합니다. **속도 및 비용** - 캐시가 아닌 데이터베이스에서 데이터를 얻는 것이 항상 더 느리고 비용도 많이 듭니다. 다른 데이터베이스 쿼리에 비해 원래 느리고 비용이 많이 드는 데이터베이스 쿼리도 있습니다. 예를 들어, 여러 테이블에서 조인을 수행하는 쿼리는 간단한 싱글 테이블 쿼리에 비해 훨씬 더 느리고 비용이 많이 소요됩니다. 속도가 느리고 비용이 많이 드는 쿼리를 통해서만 얻을 수 있는 데이터라면 캐시가 필요합니다. 비교적 빠르고 간단한 쿼리로 얻을 수 있는 데이터라도 다른 요인에 따라 캐싱이 필요할 수 있습니다. **데이터 및 액세스 패턴** - 캐시할 항목을 결정할 때는 데이터 자체와 액세스 패턴을 이해해야 합니다. 예를 들어, 빠르게 변하거나 거의 액세스하지 않는 데이터는 캐시할 필요가 없습니다. 캐시를 통해 실질적인 이점을 누리려면 비교적 정적이고 자주 액세스하는 데이터여야 합니다. 소셜 미디어 사이트의 개인 프로필을 예로 들 수 있습니다. 반대로, 캐시해도 속도나 비용이 나아지지 않는다면 데이터를 캐시할 필요가 없습니다. 예를 들어 검색 결과를 반환하는 웹 페이지의 쿼리와 결과는 대부분 고유하기 때문에 그러한 웹 페이지를 캐시하는 것은 의미가 없습니다. **기한 경과** - 정의하자면 캐시된 데이터는 기한이 경과한 데이터입니다. 경우에 따라 데이터 기한이 지나지 않았더라도 언제나 기한이 지난 데이터로 간주하고 취급해야 합니다. 데이터를 캐시할지 여부를 결정할 때는 애플리케이션의 데이터 기한 경과 허용 범위를 확인해야 합니다. 애플리케이션에서 기한이 지난 데이터를 허용할 수 있는 상황도 있고 그렇지 않은 상황도 있습니다. 예를 들어 사이트에서 공개적으로 거래된 주가를 제공한다고 가정합니다. 고객이 가격이 *n*분 지연될 수 있다는 고지 사항과 함께 어느 정도의 기한이 경과할 수 있음을 받아들일 수 있습니다. 하지만 주식을 매각하거나 매입하는 중개인에게 주식의 가격을 제공할 때는 실시간 데이터가 필요합니다. 다음에 해당하는 경우 데이터 캐시를 고려하세요. + 캐시 검색에 비해 느린 속도와 높은 비용으로 데이터를 얻습니다. + 사용자가 자주 데이터에 액세스합니다. + 데이터가 비교적 동일하게 유지되거나 빠르게 변경되어도 기한 경과가 큰 문제가 되지 않습니다. 자세한 내용은 [Memcached에 대한 캐싱 전략](Strategies.md) 섹션을 참조하세요. ## 게임 리더보드 Valkey 또는 Redis OSS 정렬 세트를 사용하면 리더보드의 컴퓨팅 복잡성을 애플리케이션에서 클러스터로 옮길 수 있습니다. 게임의 상위 10개 점수와 같은 리더보드는 계산적으로 복잡합니다. 이는 특히 동시 플레이어가 많고 점수가 지속적으로 바뀌는 경우에 그렇습니다. Valkey 및 Redis OSS 정렬 세트는 고유성 및 요소 순서를 둘 다 보장합니다. 정렬 세트를 사용하면 정렬 세트에 새 요소가 추가될 때마다 실시간으로 순위를 다시 매깁니다. 그다음에 올바른 숫자 순서의 세트에 해당 요소가 추가됩니다. 다음 다이어그램을 통해 ElastiCache 게임 리더보드가 어떻게 작동하는지 알 수 있습니다. ![\[\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Gaming.png) **Example Valkey 또는 Redis OSS 리더보드** 이 예제에서는 `ZADD`를 사용하여 게이머 4명과 이들의 점수를 정렬 목록에 입력합니다. `ZREVRANGEBYSCORE` 명령이 높은 점수에서 낮은 점수 순서로 플레이어를 나열합니다. 그런 다음 `ZADD`를 사용해 기존의 항목을 덮어써 June의 점수를 업데이트합니다. 마지막으로, `ZREVRANGEBYSCORE`에서 높은 점수에서 낮은 점수 순서로 플레이어를 나열합니다. 이 목록에서는 June이 순위가 상승했음을 알 수 있습니다. ``` ZADD leaderboard 132 Robert ZADD leaderboard 231 Sandra ZADD leaderboard 32 June ZADD leaderboard 381 Adam ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) Sandra 3) Robert 4) June ZADD leaderboard 232 June ZREVRANGEBYSCORE leaderboard +inf -inf 1) Adam 2) June 3) Sandra 4) Robert ``` 다음 명령을 통해 June은 모든 플레이어 중 자신의 순위를 알 수 있습니다. 순위는 0부터 시작하므로 *ZREVRANK*가 두 번째 위치에 있는 June에 대해 1을 반환합니다. ``` ZREVRANK leaderboard June 1 ``` 자세한 내용은 정렬 세트에 대한 [Valkey 설명서](https://valkey.io/topics/sorted-sets/)를 참조하세요. ## 메시징(Pub/Sub) 이메일 메시지를 보낼 때 지정된 수신자 한 명 이상에게 메시지가 전송됩니다. Valkey 및 Redis OSS pub/sub 패러다임에서는 메시지를 받을 사람을 모르는 상태에서 특정 채널로 메시지를 보냅니다. 메시지를 받는 사람은 채널을 구독하는 사람입니다. 예를 들어 *news.sports.golf* 채널을 구독한다고 가정해 보겠습니다. *news.sports.golf* 채널을 구독하는 모든 사람이 *news.sports.golf*에 게시되는 메시지를 받게 됩니다. Pub/sub 기능은 키 스페이스와 아무 관계가 없으므로 어떤 수준에서도 간섭이 발생하지 않습니다. 다음 다이어그램에서 Valkey 및 Redis OSS를 사용한 ElastiCache 메시징의 일러스트레이션을 확인할 수 있습니다. ![\[\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-PubSub.png) ### 구독 채널의 메시지를 받으려면 해당 채널을 구독합니다. 단일 채널, 지정된 여러 채널 또는 패턴에 맞는 모든 채널을 구독할 수 있습니다. 구독을 취소하려면 구독할 때 지정한 채널에서 구독을 취소해야 합니다. 또는 패턴 일치를 사용하여 구독한 경우 이전에 사용했던 패턴과 동일한 패턴으로 구독을 취소합니다. **Example - 단일 채널 구독** 단일 채널을 구독하려면 구독할 채널을 지정하는 SUBSCRIBE 명령을 사용하세요. 다음 예제에서는 클라이언트가 *news.sports.golf* 채널을 구독합니다. ``` SUBSCRIBE news.sports.golf ``` 얼마 후 클라이언트가 구독을 취소할 채널을 지정하는 UNSUBSCRIBE 명령을 사용하여 채널 구독을 취소합니다. ``` UNSUBSCRIBE news.sports.golf ``` **Example - 지정된 여러 채널 구독** 특정한 여러 채널을 구독하려면 SUBSCRIBE 명령으로 채널을 나열하세요. 다음 예제에서는 클라이언트가 *news.sports.golf*, *news.sports.soccer* 및 *news.sports.skiing* 채널을 구독합니다. ``` SUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing ``` 특정 채널 구독을 취소하려면 UNSUBSCRIBE 명령을 사용하고 구독을 취소할 채널을 지정합니다. ``` UNSUBSCRIBE news.sports.golf ``` 여러 채널의 구독을 취소하려면 UNSUBSCRIBE 명령을 사용하고 구독을 취소할 채널을 지정합니다. ``` UNSUBSCRIBE news.sports.golf news.sports.soccer ``` 모든 구독을 취소하려면 `UNSUBSCRIBE`를 사용하고 각 채널을 지정합니다. 또는 `UNSUBSCRIBE`를 사용하고 채널을 지정하지 않습니다. ``` UNSUBSCRIBE news.sports.golf news.sports.soccer news.sports.skiing ``` 또는 ``` UNSUBSCRIBE ``` **Example - 패턴 일치를 사용하는 구독** 클라이언트는 PSUBSCRIBE 명령을 사용하여 패턴과 일치하는 모든 채널을 구독할 수 있습니다. 다음 예제에서는 클라이언트가 모든 스포츠 채널을 구독합니다. `SUBSCRIBE`를 사용할 때처럼 모든 스포츠 채널을 개별적으로 나열하는 것은 아닙니다. 대신 `PSUBSCRIBE` 명령을 사용하여 패턴 일치를 사용합니다. ``` PSUBSCRIBE news.sports.* ``` **Example 구독 취소** 이 채널의 구독을 취소하려면 `PUNSUBSCRIBE` 명령을 사용하세요. ``` PUNSUBSCRIBE news.sports.* ``` + [P]SUBSCRIBE 명령과 [P]UNSUBSCRIBE 명령에 보낸 채널 문자열이 일치해야 합니다. *news.\$1*에 `PSUBSCRIBE`한 후 *news.sports.\$1*에서 `PUNSUBSCRIBE`하거나 *news.sports.golf*에서 `UNSUBSCRIBE`할 수 없습니다. + `PSUBSCRIBE` 및 `PUNSUBSCRIBE`는 ElastiCache Serverless에서 사용할 수 없습니다. ### 게시 채널의 모든 구독자에게 메시지를 보내려면 채널과 메시지를 지정하는 `PUBLISH` 명령을 사용하세요. 다음 예제에서는 "It’s Saturday and sunny. I’m headed to the links." 메시지를 *news.sports.golf* 채널에 게시합니다. ``` PUBLISH news.sports.golf "It's Saturday and sunny. I'm headed to the links." ``` 클라이언트는 구독한 채널에 게시할 수 없습니다. 자세한 내용은 Valkey 설명서의 [Pub/Sub](https://valkey.io/topics/pubsub)을 참조하세요. ## 권장 데이터(해시) Valkey 또는 Redis OSS의 INCR 또는 DECR을 사용하면 컴파일 권장 사항이 단순화됩니다. 사용자가 제품을 "좋아할" 때마다 *item:productID:like* 카운터가 증가하고 "싫어할" 때마다 *item:productID:dislike* 카운터가 증가합니다. 해시를 사용하여 제품을 좋아하거나 싫어한 모든 사람의 목록을 보존할 수도 있습니다. **Example - 호불호** ``` INCR item:38923:likes HSET item:38923:ratings Susan 1 INCR item:38923:dislikes HSET item:38923:ratings Tommy -1 ``` ## 생성형 AI 애플리케이션을 위한 의미 체계 캐싱 대규모 언어 모델(LLM)에 대한 추론 직접 호출과 관련된 비용과 지연 시간 때문에 생성형 AI 애플리케이션을 대규모로 운영하는 것은 어려울 수 있습니다. 생성형 AI 애플리케이션에서 의미 체계 캐싱에 ElastiCache를 사용하면 LLM 추론 직접 호출의 비용과 지연 시간을 줄일 수 있습니다. 의미 체계 캐싱을 사용하면 벡터 기반 일치를 사용하여 현재 프롬프트와 이전 프롬프트 간의 유사성을 찾아 캐시된 응답을 반환할 수 있습니다. 사용자의 프롬프트가 이전 프롬프트와 의미상 유사한 경우 새 LLM 추론 직접 호출 대신 캐시된 응답이 반환되어 생성형 AI 애플리케이션의 비용을 줄이고 사용자 경험을 개선하는 더 빠른 응답을 제공합니다. 프롬프트에 대한 유사성 임곗값을 구성하고 태그 또는 숫자 메타데이터 필터를 적용하여 캐시로 라우팅되는 쿼리를 제어할 수 있습니다. ElastiCache에 대한 벡터 검색에서 제공하는 인라인 실시간 인덱스 업데이트는 사용자 프롬프트 및 LLM 응답이 유입될 때 캐시가 지속적으로 업데이트되도록 하는 데 도움이 됩니다. 이 실시간 인덱싱은 캐시된 결과의 최신성과 캐시 적중률을 유지하는 데 매우 중요합니다. 특히 급증하는 트래픽의 경우 더욱 그렇습니다. 또한 ElastiCache는 키별 TTL, 구성 가능한 제거 전략, 풍부한 데이터 구조 및 스크립팅 지원과 같은 성숙한 캐시 프리미티브를 통해 의미 체계 캐싱 작업을 간소화합니다. **생성형 AI 어시스턴트 및 에이전트를 위한 메모리** ElastiCache를 사용하면 세션 간 대화 기록을 LLM에 표시하는 메모리 메커니즘을 구현하여 더욱 개인화되고 상황에 맞는 응답을 제공할 수 있습니다. 대화 메모리를 사용하면 생성형 AI 어시스턴트와 에이전트가 과거 상호 작용을 유지하고 사용하여 응답을 개인화하고 관련성을 개선할 수 있습니다. 그러나 관련 없는 추가 토큰으로 인해 비용이 증가하고 응답 품질이 저하되며 LLM의 컨텍스트 기간을 초과할 위험이 있으므로 이전의 모든 상호 작용을 프롬프트에 집계하는 것만으로는 효과가 없습니다. 대신 벡터 검색을 사용하여 각 LLM 간접 호출의 컨텍스트에서 가장 관련성이 높은 데이터만 검색하고 제공할 수 있습니다. ElastiCache for Valkey는 오픈 소스 메모리 계층과의 통합을 제공하여 LLM 애플리케이션 및 에이전트에 대한 메모리를 저장하고 검색할 수 있는 내장 커넥터를 제공합니다. ElastiCache에 대한 벡터 검색은 빠른 인덱스 업데이트를 제공하여 메모리를 최신 상태로 유지하고 새 메모리를 즉시 검색할 수 있도록 합니다. 지연 시간이 짧은 벡터 검색을 사용하면 메모리 조회가 빨라지므로 백그라운드 작업뿐만 아니라 모든 요청의 온라인 경로에서 구현할 수 있습니다. 벡터 검색 외에도 ElastiCache for Valkey는 세션 상태, 사용자 기본 설정 및 기능 플래그에 대한 캐싱 프리미티브를 제공하여 하나의 데이터 저장소에 단기 세션 상태 및 장기 ‘기억’을 저장하는 단일 서비스를 제공합니다. **검색 증강 생성(RAG)** RAG는 응답의 관련성을 개선하기 위해 프롬프트에 최신 정보를 LLM에 제공하는 프로세스입니다. RAG는 실제 데이터 소스로 출력을 기반으로 할루시네이션을 줄이고 사실적 정확도를 개선합니다. RAG 애플리케이션은 벡터 검색을 사용하여 지식 기반에서 의미적으로 관련된 콘텐츠를 검색합니다. ElastiCache에서 제공하는 지연 시간이 짧은 벡터 검색을 사용하면 수백만 개 이상의 벡터가 있는 대규모 데이터세트가 있는 워크로드에서 RAG를 구현하는 데 적합합니다. 또한 온라인 벡터 인덱스 업데이트를 지원하므로 ElastiCache는 업로드된 데이터를 즉시 검색해야 하는 업로드 워크플로가 있는 어시스턴트에게 적합합니다. 에이전틱 AI 시스템의 RAG를 사용하면 에이전트가 정확한 작업을 위해 최신 정보를 얻을 수 있습니다. 저지연 벡터 검색은 단일 쿼리가 여러 LLM 직접 호출을 트리거하고 기본 벡터 검색에서 지연 시간을 누적할 수 있는 에이전틱 AI 시스템의 RAG에도 중요합니다. 다음 다이어그램은 ElastiCache를 사용하여 의미 체계 캐시, 메모리 메커니즘 및 RAG를 구현하여 프로덕션 환경에서 생성형 AI 애플리케이션을 개선하는 아키텍처의 예를 보여줍니다. ![\[생성형 AI 어시스턴트가 수행하는 시맨틱 검색 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/dg/images/vector-search-gen-ai1.png) **시맨틱 검색** 벡터 검색은 의미나 특징의 근접성을 기반으로 가장 관련성이 높은 텍스트, 음성, 이미지 또는 비디오 데이터를 검색합니다. 이 기능을 사용하면 추천 엔진, 이상 탐지, 개인화, 지식 관리 시스템 등 다양한 데이터 양식에서 유사성 검색을 사용하는 기계 학습 애플리케이션을 사용할 수 있습니다. 권장 시스템은 벡터 표현을 사용하여 사용자 동작 및 항목 특성의 복잡한 패턴을 캡처하므로 가장 관련성이 높은 콘텐츠를 제안할 수 있습니다. ElastiCache에 대한 벡터 검색은 실시간에 가까운 업데이트와 짧은 지연 시간으로 인해 이러한 애플리케이션에 매우 적합하므로 실시간 사용자 상호 작용을 기반으로 관련성이 높은 즉각적인 권장 사항을 제공하는 유사성 비교가 가능합니다. ## ElastiCache 고객 추천사 Airbnb, PBS, Esri 등의 기업이 어떻게 Amazon ElastiCache를 활용해 고객 환경을 개선하여 비즈니스 성장을 도모하고 있는지에 관해서는 [Amazon ElastiCache 추천사](https://aws.amazon.com/elasticache/testimonials/)를 참조하세요. 다른 ElastiCache 고객 사용 사례는 [튜토리얼 동영상](Tutorials.md#tutorial-videos)에서 보실 수 있습니다.