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

전자 상거래 애플리케이션용 Amazon ElastiCache(Valkey)

전자 상거래 애플리케이션은 애플리케이션 서버와 데이터베이스 간의 인 메모리 캐시 계층의 이점을 누릴 수 있습니다. Valkey를 실행하는 Amazon ElastiCache는 제품 카탈로그 항목, 인벤토리 수, 검색 결과, 사용자 세션 등 자주 액세스하는 데이터에 대해 밀리초 미만의 읽기 지연 시간을 제공하여 데이터베이스 로드를 줄이고 트래픽이 급증하는 동안 응답 시간을 개선합니다.

클러스터 구성

데이터 볼륨, 처리량 요구 사항 및 운영 기본 설정에 따라 클러스터 유형을 선택합니다.

대부분의 전자 상거래 애플리케이션에서 Serverless는 프로덕션을 위한 가장 간단한 경로를 제공합니다. 예측 가능한 트래픽 기준이 있고 클러스터 토폴로지, 노드 유형 및 조정 동작을 더 잘 제어해야 하는 경우 노드 기반 클러스터로 마이그레이션합니다.

제품 데이터의 주요 설계

데이터 유형 간 충돌을 방지하기 위해 예측 가능하고 디버깅 가능하며 범위가 지정되도록 캐시 키를 설계합니다.

주요 설계 모범 사례:

데이터 유형별 TTL 전략

고객 경험에 영향을 주지 않고 데이터 변경 빈도와 기한 경과를 기준으로 TTL(time-to-live) 값을 설정합니다.

캐시 어사이드 패턴

캐시 어사이드 패턴(지연 로딩이라고도 함)은 전자 상거래 애플리케이션의 가장 일반적인 캐싱 전략입니다. 애플리케이션은 먼저 캐시를 확인하고 캐시 누락 시에만 데이터베이스를 쿼리합니다.

읽기 경로(의사 코드)

FUNCTION getProduct(productId):
    cacheKey = "product:" + productId

    // Step 1: Check the cache
    cachedValue = cache.GET(cacheKey)

    IF cachedValue exists:
        RETURN deserialize(cachedValue)    // Cache hit — sub-millisecond

    // Step 2: Cache miss — query database
    product = database.query("SELECT * FROM products WHERE id = ?", productId)

    IF product not found:
        RETURN null

    // Step 3: Write to cache with TTL
    cache.SET(cacheKey, serialize(product), EXPIRE = 300)    // 5 minutes

    RETURN product

쓰기 경로(의사 코드)

FUNCTION updateProduct(productId, updatedFields):
    // Step 1: Update the database (source of truth)
    database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)

    // Step 2: Invalidate the cache (don't update it)
    cache.DELETE("product:" + productId)

    // Next read will trigger a cache miss and repopulate from database

캐시 실패 처리

FUNCTION getProductWithFallback(productId):
    TRY:
        RETURN getProduct(productId)    // Normal cache-aside path
    CATCH cacheConnectionError:
        // Cache is unavailable — fall back to database directly
        RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
        // Log the error, trigger an alarm, but don't fail the request

캐시 실패로 인해 성능이 저하되지만(응답 속도가 느림) 기능을 손상시키지 않도록 애플리케이션을 설계합니다. 데이터베이스는 대체 역할을 합니다.

캐시 무효화 전략

무효화를 통해 사용자는 업데이트 후 현재 데이터를 볼 수 있습니다. 변경 사항을 얼마나 빨리 표시해야 하는지에 따라 전략을 선택합니다.

Amazon CloudFront를 CDN 계층으로 사용하는 마켓플레이스 애플리케이션의 경우 두 계층에서 무효화를 조정합니다. 즉, ElastiCache 키를 삭제하고 CloudFront 캐시 무효화(또는 캐시 태그 무효화)를 전송하여 사용자가 애플리케이션과 엣지 계층 모두에서 업데이트된 콘텐츠를 볼 수 있도록 합니다.

연결 관리

모니터링할 주요 지표

자주 묻는 질문(FAQ)

서버리스와 노드 기반은 언제 사용해야 하나요?

트래픽이 예측할 수 없는 경우(새로운 마켓플레이스, 계절별 급증), 용량 계획을 피하려는 경우 또는 팀에 캐싱 운영 전문 지식이 없는 경우 Serverless를 사용합니다. 트래픽 패턴이 안정적이거나, 샤딩을 세밀하게 제어해야 하거나, 지속적인 처리량으로 인해 노드 기반이 비용 효율적일 때 노드 기반 로 전환합니다.

Valkey 또는 Redis OSS를 사용해야 합니까?

새 배포에는 Valkey를 사용합니다. Valkey는 새로운 ElastiCache 클러스터의 기본 엔진으로, Redis OSS 명령 및 데이터 구조와 완벽하게 호환되며 지속적인 개발을 받습니다. 기존 Redis OSS 클러스터는 계속 작동합니다. 인플레이스 엔진 업그레이드를 사용하여 편리한 경우 Valkey로 마이그레이션하세요.

캐시를 사용할 수 없는 경우 어떻게 되나요?

애플리케이션은 캐시를 종속성이 아닌 최적화로 취급해야 합니다. 캐시를 사용할 수 없는 경우 데이터베이스 직접 쿼리로 돌아갑니다. 응답 시간은 더 길지만 애플리케이션은 계속 작동합니다. 다중 AZ를 활성화하면 전체 캐시를 사용할 수 없는 경우는 드뭅니다. 복제본으로의 장애 조치는 일반적으로 30초 이내에 완료됩니다.

필요한 메모리를 어떻게 추정하나요?

계산: (캐싱할 고유 항목 수) × (항목당 평균 크기) × (Valkey 데이터 구조의 오버헤드 계수 1.2). 오버헤드는 객체 크기와 데이터 유형에 따라 다릅니다. 작은 객체는 비례적으로 오버헤드가 높습니다. 예를 들어, 각각 1.2x 오버헤드 = 약 240MB인 2KB의 제품 100,000개. 세션 데이터, 검색 결과 및 인벤토리 수를 추가합니다. 헤드룸(사용 가능한 메모리의 60%를 대상으로 사용)으로 시작하고 DatabaseMemoryUsagePercentage 지표를 모니터링하여 조정합니다.