◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇
AWS ElastiCache
ElastiCache는 Fully managed 분산 인메모리(In-memory) 캐싱 서비스이다.
ElastiCache는 주로 성능을 중시하는 애플리케이션에서 사용된다.
데이터베이스나 다른 백엔드 스토리지에서 가져오는 데이터를 캐싱(Cache)하여 액세스 속도를 향상시키는 데 사용된다.
즉, ElastiCache는 쉽게 말해서 데이터를 더 빨리 가져오기 위한 메모리 기반의 저장소 서비스이다.
In-Memory DB
👩🏫 인메모리(In-memory) 데이터베이스란?
"인메모리"는 데이터를 메모리(RAM, 주 기억 장치)에 저장하고 처리하는 방식을 가리킨다.
- 🏛️ 전통적인 데이터베이스 시스템은 디스크에 데이터를 저장한다. 필요할 때마다 디스크에서 데이터를 읽고 쓴다.
- 🆕 하지만 인메모리 데이터베이스나 캐싱 시스템은 데이터를 디스크가 아닌 메모리에 저장하고 관리한다.
👍 인메모리 DB의 장점: 빠르다
- 메모리는 디스크에 비해 훨씬 빠르기 때문에 데이터를 메모리에 저장하면 읽기 및 쓰기 작업이 빠르다.
- 디스크 기반 DBMS 제품보다 100~1000배가 가량 빠르다고 한다.
👎 인메모리 DB의 단점: 메모리가 휘발성
DB 서버 전원이 갑자기 꺼져버리면 안에 있는 자료들이 즉시 삭제된다.
😎 인메모리 DB 종류:
- Redis(레디스): 오픈 소스로, String, Hash, List, Set, Sorted Set 등 다양한 데이터 형식을 제공하는 키-값(Key-Value) 데이터 저장소.
- Memcached(멤캐시드): 오픈 소스로, key-value 캐싱만을 제공한다..
ElastiCache 특징 ( ⚠ 캐시 엔진에 따라 다르다 )
- Fully managed (완전 관리형)
- AWS의 완전 관리형 서비스로, 데이터베이스 확장, 장애 감지 및 복구, 백업 등은 AWS에 의해 관리된다.
- 개발자 입장에서는 관리하기가 아주 쉽다.
- Scalable (확장 및 축소 능력): ⚠ 엔진에 따라 다르다.
- ElastiCache for Redis는 애플리케이션의 요구에 따라 클러스터 크기를 자동으로 확장하거나 축소가능하다.
- High availability (고가용성): ⚠ 엔진에 따라 다르다.
- ElastiCache for Redis는 Multi-AZ(Multi-Availability Zone) 설정을 사용할 경우 가용성이 99.99%이다.
https://aws.amazon.com/about-aws/whats-new/2023/01/amazon-elasticache-redis-service-level-agreement/
- ElastiCache for Redis는 Multi-AZ(Multi-Availability Zone) 설정을 사용할 경우 가용성이 99.99%이다.
- RDS나 Redshift와 같은 다른 데이터베이스 서비스와 연계하여 쿼리 결과를 ElastiCache에 캐시함으로써 전체적인 성능을 향상시키는 방식으로 활용할 수 있다.
ElastiCache이 지원하는 캐시 엔진 (2가지)
ElastiCache에는 "KVS"(Key-Value Store)형 데이터베이스 엔진이 2개 준비되어 있으며, 데이터베이스를 구축할 때 선택할 수 있다.
저장할 데이터(Value)와 그것을 특정하기 위한 키(Key)가 쌍을 이루는 구성의 데이터셋을 의미한다.
- Redis - (특징: 고급 기능 탑재)
- Memcached - (특징: 심플함)
Memcached: 심플한 기능
- Memcached는 심플한 캐싱 활용에 적합하다.
- Multi Thread로 작동한다. 즉, 여러 스레드가 동시에 요청을 처리할 수 있다.
- Redis와 달리 Memcached는 데이터의 영구 보존이나 백업 기능이 없다.
- 그렇기 때문에 장애나 재부팅이 발생하면 캐시 데이터가 남지 않고 사라진다.
- 계속 유지해야 하는 데이터는 스토리지나 다른 DB 서비스에 저장해두고, 애플리케이션의 속도를 높이기 위한 캐시로 사용하는 경우에 적합하다.
Redis: 고급 기능
- Redis는 Memcached보다 고기능의 데이터베이스 엔진이다.
- Single Thread로 작동한다. 즉, 한 번에 하나의 작업만 처리한다.
- Snapshot (Amazon S3에 저장) 기능을 통한 백업 및 복원이 가능하며, 데이터를 영구적으로 보존할 수 있다.
- "자동 페일오버"와 "Multi AZ"가 있다. (장애 대책 기능])
- 자동 페일오버: 프라이머리 노드에 장애가 발생하면 자동으로 레플리카 노드가 프라이머리 노드로 승격된다.
- Multi AZ: AZ를 넘나드는 복제가 가능하므로, 프라이머리 노드가 있는 AZ에 장애가 발생해도 다른 레플리카 노드를 승격시켜 운영을 지속할 수 있다.
- [보안 기능]: Redis는 Memcached에는 없는 보안 기능을 제공한다.
- 저장된 데이터의 암호화나 SSL/TLS를 통한 통신 암호화
- 클라이언트를 비밀번호로 인증하는 Redis 인증 등을 지원한다.
- 이러한 기능을 사용하려면, ElastiCache 데이터베이스를 생성할 때 Redis를 선택하고 암호화를 활성화해야 한다
Redis와 Memcached 공통점
- in-memory DB로써 속도가 빠르다.
- key-value 형태로 데이터를 저장
- 캐시나 새션, 상태 정보 저장에 최적화 되어 있다.
Redis와 Memcached 정리
특징 | Redis | Memcached |
Multi Thread (멀티스레드) | - (Single thread, 싱글 스레드) |
Yes (Multi thread, 멀티 스레드) |
고급 데이터 타입 지원 | Yes (lists, sets, sorted sets, hashes, bit arrays, hyperloglogs를 지원한다) |
- (주로 문자열 기반의 key와 value만 지원하며, 고급 데이터 구조는 지원하지 않는다) |
자동 페일오버 | Yes | - |
Multi AZ | Yes | - |
레플리케이션 | Yes | - |
백업 및 복원 | Yes | - |
보안 기능 | Yes | - |
Pub/Sub | Yes | - |
Use Case | ・복잡한 데이터 타입이 필요한 경우 ・영구화가 필요한 경우 ・페일오버가 필요한 경우 ・pub/sub가 필요한 경우 |
・심플한 데이터 타입(키-값)만으로 충분한 경우 ・멀티스레드가 필요한 경우 |
참고) https://aws.amazon.com/elasticache/redis-vs-memcached/
Caching patterns, Memcached , Redis
Caching Strategies (캐싱 전략)
ElastiCache는 애플리케이션 성능 향상을 위해 주로 사용된다.
데이터를 어떻게 저장할 것인가는 데이터의 일관성과 가용성을 유지하면서 성능을 최대화하는 데 중요하다.
이를 캐싱 전략이라고 하며 대표적인 2 가지 캐시 전략이 있다.
1. Write-Through : 바로 바로 업데이트
DB에 데이터를 업데이트(write)할 때마다, 동시에 캐시에도 데이터를 업데이트한다.
이 전략에서는 캐시의 데이터가 항상 최신 상태로 유지되므로, 데이터 일관성이 유지된다.
그러나 쓰기 성능이 약간 저하될 수 있으며, 액세스되지 않는 데이터가 캐시에 쌓이는 단점이 있다
2. Cache-Aside (Lazy loading) : 살짝 지연 but 효율적
- 요청 발생: 애플리케이션이 데이터를 DB 요청할 때 먼저 캐시(ElastiCache)를 확인한다.
- 만약 캐시에 그 데이터가 있다면, 애플리케이션에 보낸다.
- 만약 캐시에 그 데이터가 없다면, 데이터베이스(DB)에서 해당 데이터를 가져온다.
- 캐시에 저장: 가져온 데이터를 캐시(ElastiCache)에 저장해 둔다.
- 이후에 동일한 데이터 요청이 들어오면 캐시에서 빠르게 가져올 수 있게 됩니다.
이 방법에서는 요청된 데이터만 캐시되므로 리소스 낭비를 줄일 수 있지만, 캐시와 데이터베이스 간에 일시적인 데이터 불일치가 발생할 수 있는 가능성이 있다.
또한, cache miss(캐시 미스: 캐시에서 데이터를 가져올 수 없는 경우)가 발생하면 데이터 가져오는 데 시간이 걸릴 수 있다.
🤨 SAA-C03 문제
다음은 회사가 ALB 아래의 Auto Scaling 그룹에 속한 EC2 인스턴스에서 운영하는 EC 사이트에 대한 설명입니다. EC 사이트는 시간대에 따라 액세스 수가 변동하며, 하루에 여러 번 인스턴스의 스케일링이 발생하고 있습니다. 회사는 클라이언트와의 세션을 안정적으로 유지하고 세션 정보를 영구적으로 저장하기 위해 세션 관리를 최적화하려고 합니다. 적절한 솔루션을 2 가지 선택하십시오.
- Amazon ElastiCache의 Redis를 Multi-AZ로 설정하여 세션 정보를 저장한다.
- Amazon DynamoDB에 세션 정보를 저장한다.
- Amazon ElastiCache의 Memcached를 Multi-AZ로 설정하여 세션 정보를 저장한다.
- AWS Systems Manager Session Manager를 사용하여 세션 정보를 관리한다.
- AWS WAF의 Web ACL을 사용하여 세션 정보를 관리한다.
정답
1번. Amazon ElastiCache의 Redis를 Multi-AZ로 설정하여 세션 정보를 저장한다.
2번. Amazon DynamoDB에 세션 정보를 저장한다.
문제와 같이 인스턴스의 스케일링이 발생하는 시스템에서는, 클라이언트와의 세션을 유지하는 서버가 스케일 인될 때 세션 정보가 삭제될 수 있다. 세션을 안정적으로 유지하기 위해서는 세션 정보를 데이터베이스에 저장하여 인스턴스 간에 공유하는 것 필요하다.
세션 정보의 저장에는 NoSQL 데이터베이스로서 고성능 읽기/쓰기 작업이 가능한 Amazon DynamoDB와 Amazon ElastiCache가 적합합니다.
DynamoDB에 저장되는 데이터는 3개의 AZ에 자동으로 저장되므로 내구성이 뛰어나며 세션 정보를 영구적으로 저장할 수 있다.
또한, ElastiCache의 Redis 유형도 멀티 AZ를 지원하여 데이터를 영구적으로 유지할 수 있다.
오답
3번. Amazon ElastiCache의 Memcached를 멀티 AZ로 설정하여 세션 정보를 저장하는 경우:
ElastiCache의 Memcached은 세션 정보를 임시로 저장하는 데 적합하지만, 멀티 AZ나 영구 보존 기능이 없어 장애나 재시작이 발생하면 데이터가 사라질 수 있다. 세션 정보를 영구적으로 저장하려는 요구 사항에는 맞지 않으므로 오답이다.
4번. AWS Systems Manager Session Manager를 사용하여 세션 정보를 관리하는 경우:
Systems Manager Session Manager는 EC2 인스턴스에 브라우저(관리 콘솔)나 AWS CLI를 통해 안전하게 로그인할 수 있는 기능이다. 클라이언트와 서버 간의 세션 정보를 관리하는 기능은 없으므로 오답이다.
5번. AWS WAF의 Web ACL을 사용하여 세션 정보를 관리하는 경우:
AWS WAF는 웹 애플리케이션을 취약점 공격으로부터 보호하는 서비스이다. Web ACL이라는 액세스 제어 목록을 통해 IP 주소, HTTP 헤더, HTTP 본문, URI 문자열 등에 대해 필터링 조건을 설정한다. 클라이언트와 서버 간의 세션 정보를 관리하는 기능은 없으므로 오답이다.
🤔 DVA 문제
웹사이트의 페이지 로드 시간이 동시에 시스템에 접속하는 사용자가 많아질수록 점진적으로 증가하고 있습니다. 분석 결과, 모든 웹 페이지에서 사용자 프로필이 데이터베이스에서 로드되고 있으며, 이로 인해 데이터베이스 부하와 페이지 로드 지연 시간이 증가하고 있는 것으로 나타났습니다. 이 문제를 해결하기 위해 개발자는 사용자 프로필 데이터를 캐시하기로 결정했습니다. 이 상황에서 가장 효율적으로 문제를 해결할 수 있는 캐싱 전략은 무엇인가요?
- Amazon EC2 인스턴스를 새로 생성하고 NoSQL 데이터베이스를 실행하여 프로필 데이터를 Write-through 캐싱 전략으로 캐시합니다.
- Amazon ElastiCache 클러스터를 생성하여 사용자 프로필 데이터를 캐시하고, Cache-aside 캐싱 전략을 사용합니다.
- 전용 Amazon RDS 인스턴스를 사용해 프로필 데이터를 캐시하고, Write-through 캐싱 전략을 사용합니다.
- ElastiCache 클러스터를 생성하여 사용자 프로필 데이터를 캐시하고, Write-through 캐싱 전략을 사용합니다.
정답
정답. 2번