DVA-C02 시험에서 데이터 저장소 문제는 크게 두 가지를 묻습니다. 첫째, 상황에 맞는 저장소를 올바르게 선택할 수 있는가? 둘째, 캐싱을 통해 애플리케이션 성능을 어떻게 개선할 수 있는가?
저장소 선택 — 상황에 맞는 데이터베이스 고르기
데이터베이스는 용도에 따라 여러 종류가 있습니다. 마치 물건을 보관할 때 냉장고, 창고, 금고 중 상황에 맞게 고르듯이, 데이터의 특성과 사용 패턴에 따라 적합한 저장소를 선택해야 합니다.
| 요구사항 | 추천 서비스 | |---------|------| | 관계형 데이터, SQL 쿼리 | RDS / Aurora | | 키-값 구조, 밀리초 응답 속도 | DynamoDB | | 인메모리 캐시 (빠른 임시 저장) | ElastiCache | | 전문 검색, 로그 분석 | Amazon OpenSearch | | 파일, 이미지, 대용량 객체 저장 | S3 |
캐싱이란 무엇인가요?
캐싱(Caching)은 자주 사용하는 데이터를 빠른 저장소(메모리)에 미리 저장해두는 기법입니다. 쉽게 말하면, 자주 먹는 음식을 냉장고에 보관하는 것과 같습니다. 슈퍼마켓(데이터베이스)까지 매번 나가는 것보다 냉장고(캐시)에서 꺼내 먹는 것이 훨씬 빠릅니다.
캐싱을 잘 활용하면 데이터베이스의 부하를 줄이고, 사용자에게 훨씬 빠른 응답 속도를 제공할 수 있습니다.
캐싱 전략 3가지
Lazy Loading (Cache-Aside, 지연 로딩)
가장 널리 사용되는 전략입니다. 동작 방식은 다음과 같습니다.
사용자가 데이터를 요청합니다. 먼저 캐시를 확인합니다. 캐시에 데이터가 있으면(Cache Hit) 즉시 반환합니다. 캐시에 없으면(Cache Miss) 데이터베이스에서 조회합니다. 조회한 데이터를 캐시에 저장하고 사용자에게 반환합니다.
장점: 실제로 요청된 데이터만 캐싱하므로 메모리를 효율적으로 사용합니다.
단점: Cache Miss가 발생하면 첫 요청이 느립니다. 또한 오래된 데이터가 캐시에 남아 있을 수 있습니다.
해결책: TTL(Time To Live)을 설정합니다. TTL은 캐시 데이터의 유효 기간입니다. 설정한 시간이 지나면 자동으로 캐시가 삭제되어 다음 요청 시 새로운 데이터를 불러옵니다.
Write-Through (쓰기 투과)
데이터베이스에 데이터를 쓸 때 캐시에도 동시에 씁니다.
장점: 캐시의 데이터가 항상 최신 상태입니다. Cache Miss가 매우 드뭅니다.
단점: 실제로 한 번도 읽히지 않을 데이터도 캐시에 저장됩니다. 메모리를 불필요하게 낭비할 수 있습니다.
Write-Back (Write-Behind, 쓰기 후 처리)
데이터를 먼저 캐시에만 쓰고, 나중에 일정 간격으로 데이터베이스에 일괄 저장합니다.
장점: 쓰기 작업이 매우 빠릅니다. 대량의 쓰기가 발생하는 시스템에 적합합니다.
단점: 캐시가 갑자기 장애가 나면 아직 데이터베이스에 저장되지 않은 데이터가 손실될 수 있습니다.
!캐싱 전략 3가지: Lazy Loading, Write-Through, Write-Back
ElastiCache — AWS의 인메모리 캐시 서비스
Amazon ElastiCache는 Redis와 Memcached 두 가지 엔진을 제공합니다. 둘 다 메모리에 데이터를 저장해 매우 빠른 속도를 제공하지만, 기능에 차이가 있습니다.
| 항목 | ElastiCache for Redis | ElastiCache for Memcached | |------|----------------------|--------------------------| | 저장 가능한 데이터 형태 | 다양 (문자열, 해시, 목록, 집합 등) | 문자열만 가능 | | 복제 (읽기 전용 복사본) | 지원 | 미지원 | | 데이터 영속성 (재시작 후 유지) | 지원 | 미지원 | | 다중 가용 영역 (Multi-AZ) 자동 장애 조치 | 지원 | 미지원 | | 멀티스레드 처리 | 미지원 | 지원 |
대부분의 경우 ElastiCache for Redis를 선택합니다. 복제, 데이터 영속성, Multi-AZ 지원 덕분에 더 안정적이고 다양한 용도로 사용할 수 있습니다.
ElastiCache for Memcached는 단순한 캐싱이 필요하고, 멀티스레드 처리 성능이 중요할 때 선택합니다.
데이터 직렬화 — 데이터를 주고받는 형식
ElastiCache나 다른 서비스와 데이터를 주고받을 때, 데이터를 특정 형식으로 변환(직렬화)하고 다시 원래 형태로 복원(역직렬화)하는 과정이 필요합니다. 마치 편지를 봉투에 넣고 꺼내는 것처럼 말이죠.
주로 사용되는 형식으로는 JSON(사람이 읽기 쉬움), Protobuf(빠르고 효율적), Avro(대용량 데이터) 등이 있습니다. 어떤 형식을 선택하느냐에 따라 성능과 다른 시스템과의 호환성이 달라집니다.
시험 핵심 정리
"요청 시 캐시 확인 → 없으면 DB 조회 → 캐시에 저장" -- Lazy Loading (Cache-Aside)
"DB 쓰기 시 캐시도 동시 업데이트" -- Write-Through
"오래된 캐시 자동 만료" -- TTL 설정
"복제, 지속성, 멀티 AZ 필요" -- ElastiCache for Redis
"단순 캐싱, 멀티스레드 필요" -- ElastiCache for Memcached
"전문 검색, 로그 분석" -- Amazon OpenSearch
"캐시 데이터 항상 최신 유지" -- Write-Through
Redis vs Memcached: 대부분 Redis 선택. Memcached는 단순 캐싱 + 멀티스레드가 필요한 특수한 경우만.