소개
상품 애플리케이션은 요청마다 DynamoDB에서 카탈로그를 읽습니다. Valkey를 실행하는 Amazon ElastiCache 노드를 추가하여 같은 상품 값을 재사용합니다. 응답 출처와 실제 원본 읽기 횟수를 비교하여 변화를 확인합니다.
먼저 AWS Foundations for Beginners와 AWS DynamoDB for Beginners의 기본 항목 작업을 학습하세요. 독립적인 환경에 애플리케이션, 카탈로그와 네트워크가 제공됩니다. Terminal에서 명령을 실행하고 AWS View에서 노드, 원본 레코드와 응답을 관찰합니다. AWS CLI는 이미 설정되어 있으며 개인 AWS 계정이나 이전 실습의 리소스는 필요하지 않습니다.
자격증 관련 내용
| 자격증 | 시험 과제 | 실습 |
|---|---|---|
| Cloud Practitioner (CLF-C02) | Task 3.4 | 메모리 캐시와 원본 데이터를 구분하고 애플리케이션 동작을 관찰합니다. |
상품 원본 관찰하기
캐시는 재사용할 데이터를 메모리에 보관합니다. 데이터베이스는 여전히 기준이 되는 원본입니다. 캐시 값이 사라져도 카탈로그 레코드는 사라지면 안 됩니다. 먼저 캐시를 사용하지 않는 애플리케이션을 관찰합니다.
프로젝트 디렉터리로 이동하고 설정된 신원을 확인합니다.
cd /home/labex/project
aws sts \
get-caller-identity
ARN은 labex-ca01-operator로 끝나며 조회할 환경을 나타냅니다. DynamoDB에서 상품 101을 직접 읽습니다. S는 문자열, N은 숫자를 나타냅니다.
aws dynamodb \
get-item \
--table-name product-catalog \
--key '{"product_id":{"S":"101"}}' \
--consistent-read
Travel mug의 가격은 20.00입니다. 별도 상품 202, Notebook은 실습 중 변경하지 않습니다. HTTP 애플리케이션은 상품 JSON을 반환합니다. 같은 상품을 두 번 요청합니다.
curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101
두 응답 모두 "served_from":"source"를 포함합니다. AWS View의 원본 읽기 횟수는 2 증가하고 ElastiCache 카드에는 아직 클러스터가 없습니다. 읽기는 실제 DynamoDB 요청을 의미하며 AWS 청구 금액을 측정하지 않습니다. Send request도 실제 요청을 보내므로 횟수가 달라질 수 있습니다. 고정된 최종 숫자 대신 횟수가 증가하는지 비교합니다.
Valkey 캐시 노드 만들기
Amazon ElastiCache는 메모리 캐시 엔진을 관리합니다. Valkey는 키별로 값을 저장하며 여기서는 상품 ID가 캐시 값을 식별합니다. 독립된 단일 노드를 사용합니다. 제공된 서브넷 그룹은 준비된 네트워크 위치를 나타내고 보안 그룹은 네트워크 설정입니다. 네트워크 규칙 설계는 VPC 과정에서 다룹니다.
이 새 환경의 네트워크 식별자를 읽습니다.
cat resources.json
보안 그룹 ID를 저장하고 출력합니다. $(...)는 다음 작업에 사용할 명령 출력을 저장합니다.
CACHE_GROUP_ID=$(jq -r .security_group_id resources.json)
echo "$CACHE_GROUP_ID"
작은 단일 노드 캐시를 만듭니다. product-cache는 클러스터 식별자이며 엔진과 노드 수가 과정의 Valkey 구성을 선택합니다.
aws elasticache \
create-cache-cluster \
--cache-cluster-id product-cache \
--engine valkey \
--engine-version 7.2 \
--cache-node-type cache.t3.micro \
--num-cache-nodes 1 \
--cache-subnet-group-name product-cache-network \
--security-group-ids "$CACHE_GROUP_ID"
CacheClusterStatus를 관찰하고 연결 주소와 포트인 엔드포인트를 조회합니다.
aws elasticache \
describe-cache-clusters \
--cache-cluster-id product-cache \
--show-cache-node-info \
--query 'CacheClusters[0].{Status:CacheClusterStatus,Nodes:CacheNodes}'
클러스터가 available이고 노드 0001에 엔드포인트가 있을 때 계속합니다. 아직 생성 중이면 잠시 기다렸다가 같은 조회를 반복합니다. 실제 주소를 저장하고 출력합니다.
CACHE_HOST=$(aws elasticache \
describe-cache-clusters \
--cache-cluster-id product-cache \
--show-cache-node-info \
--query 'CacheClusters[0].CacheNodes[0].Endpoint.Address' \
--output text)
echo "$CACHE_HOST"
제공된 Valkey 클라이언트로 실제 연결을 테스트합니다.
valkey-cli -h "$CACHE_HOST" -p 6379 PING
PONG은 캐시 엔진이 응답했다는 증거지만 애플리케이션의 사용 여부까지 증명하지는 않습니다. AWS View에 실제 노드와 엔드포인트가 표시됩니다.
애플리케이션 연결과 캐시 적중 관찰하기
cache-aside는 먼저 캐시에서 product:101을 찾습니다. 키가 없으면 미스로, DynamoDB를 읽고 상품을 저장합니다. 이후 적중에서는 원본을 다시 읽지 않고 저장된 값을 반환합니다.
app.json은 일반적인 애플리케이션 설정입니다. jq로 모드와 엔드포인트를 바꾸고 임시 파일을 쓴 뒤 설정 파일을 교체합니다.
jq --arg host "$CACHE_HOST" \
'.mode = "cache-aside" | .cache_host = $host' \
app.json > app.next.json
mv app.next.json app.json
새 설정을 확인합니다.
cat app.json
애플리케이션은 요청마다 설정을 읽으므로 재시작할 필요가 없습니다. ttl_seconds는 캐시 값의 수명이며 다음 실습에서 만료와 최신성을 다룹니다. 상품을 한 번 요청합니다.
curl -sS http://127.0.0.1:8080/api/products/101
새 캐시에는 값이 없으므로 처음에는 served_from: source가 나옵니다. AWS View의 읽기 횟수를 보고 요청을 반복합니다.
curl -sS http://127.0.0.1:8080/api/products/101
같은 ID, 이름, 가격과 함께 served_from: cache가 나오고 읽기 횟수는 늘지 않습니다. AWS View에서 먼저 요청했다면 첫 Terminal 요청도 적중할 수 있습니다. 캐시를 채운 후 연속된 요청을 비교하세요. 실제 저장된 값을 읽습니다.
valkey-cli -h "$CACHE_HOST" -p 6379 GET product:101
JSON은 Travel mug 원본과 일치합니다. 반복 조회에서 원본 접근 감소를 확인한 것이며 운영 환경의 지연 시간, 용량이나 가용성을 증명하지는 않습니다. 검증을 위해 애플리케이션과 노드를 유지하세요. 이 환경은 일회용입니다. 실제 AWS 계정에서는 불필요한 캐시를 삭제하여 지속적인 리소스 비용을 중단합니다.
요약
Valkey 단일 노드를 만들고 애플리케이션을 연결하여 cache-aside의 미스와 적중을 관찰했습니다. 캐시 JSON은 DynamoDB 원본과 일치하고 반복 적중은 원본 읽기를 피합니다. 다음에는 TTL과 명시적 무효화로 최신성을 유지합니다.
자세한 내용은 AWS 공식 문서를 참고하세요: 캐시 어사이드 데이터 흐름; 캐시 연결 엔드포인트 선택.
