💻STUDY/AWS SAA STUDY

[SAA] 2. 로드 밸런싱, RDS와 Aurora, ElastiCache

coldNoodlePigeon 2024. 11. 21.

udemy 강의 기준 sec08-10까지의 내용 정리
전체 내용을 정리하기보단, 몰랐었던 내용과 정리하고 싶은 부분들을 중점으로 정리합니다
공부하면서 들었던 짧은 생각과 고민도 정리합니다
틀린 내용이 있다면 댓글로 알려주세요 감사합니다

section 08.

확장성(scalability)과 가용성(availability)?

확장성(scalability)

수직 확장성(vertical scalability): 인스턴스의 사이즈를 늘리는 것 -> scale up/down
- 분배 시스템 x (ex. 데이터베이스)
- RDS, ElastiCache에서 수직적으로 확장될 수 있음
- 무한히 수직적 확장이 가능한 것은 아님 (하드웨어적인 한계 때문)
수평 확장성(horizontal scalability): 인스턴스들이나 시스템들의 개수를 늘리는 것 -> scale out/in
- 분배 시스템에서 많이 사용됨
- Auto scaling group, Load Balancer

가용성(availability)

고가용성 (High Availability)
- 수평적 확장과 종종 함께 쓰이는 개념
- 애플리케이션/시스템이 적어도 2개 이상의 데이터 센터(=AZ)에서 실행됨
- 고가용성은 수동적(RDS Multi AZ)일수도 있고, 활성형(수평 확장)이 될수도 있음
- Auto scaling group multi AZ, Load Balancer multi AZ

'고가용성은 수동적(RDS Multi AZ)일수도 있고, 활성형(수평적 확장)이 될수도 있다' 라는 문장이 잘 이해가 되질 않았다. 각각 괄호에 적어둔 예시를 살펴보면,

RDS Multi AZ의 경우 primary db(AZ-1에서 실행중)와 standby db(AZ-2에서 대기중-passive)가 존재한다. 만약 primary db에서 장애가 발생하면, 자동으로 standby db를 활성화시킨다. 따라서 대기중인 standbdy db를 수동적(passive)라고 표현한 듯 하다.
수평적 확장의 경우, 예를 들어 ALB가 여러 활성상태(active)인 EC2 인스턴스에 트래픽을 전달하고 있을때, 만약 인스턴스들 중 하나에서 장애가 발생하면 나머지 정상 인스턴스들은 계속 작동하고 서비스를 멈추지 않는다. 계속 활성상태(active)에 있어서 활성형(active)라고 표현한 듯 하다.

로드 밸런싱(Load Balancing)

로드밸런서는 다수의 서버들로 트래픽을 전달하는 역할을 하는 서버 혹은 서버 세트이다. EC2 인스턴스로 가는 부하를 줄이기 위해 자주 사용되는 기술이고, 다들 한번쯤은 들어봤을 이름이다.

로드 밸런스에는 여러가지 종류가 존재하는데, 이제는 사용되지 않는 CLB를 제외한 3가지 종류에 대해 간략히 정리해보겠다.

ALB(Application Load Balancer)
- 마이크로서비스와 컨테이너 기반의 애플리케이션에 적합
- HTTP, HTTPS, WebSocket 지원
- target group 레벨에서 Health check 이루어짐
- hostname 고정됨
- 클라이언트의 IP는 X-Forwarded-For라는 헤더에 담겨서 오게 됨
  - X-Forwarded-Port와 X-Forwarded-Proto로부터 포트번호와 proto 알수 있음
NLB(Network Load Balancer)
- 초저지연, 고성능, TCP나 UDP 트래픽을 관리할때 유용
- 각 AZ마다 하나의 고정 IP 할당 가능
- 고정 IP(elastic IP) 할당 지원
  - 따라서 특정 IP들로만 액세스할 수 있는 애플리케이션을 만들때 유용함
- health check할때 TCP, HTTP, HTTPS 프로토콜도 지원함
- 타겟 그룹에 ALB가 들어갈 수 있음
GWLB(Gateway Load Balancer)
- 방화벽, 침입 탐지, 예방 시스템 등에 활용함
- IP 패킷의 네트워크 계층인 L3에서 동작함
- 트래픽이 들어가면, 서드파티인 보안 가상 어플라이언스(타겟그룹)가 방화벽이나 침입 탐지와 같은 작업 수행 -> 이상이 없으면 GWLB로 다시 보낸 후 애플리케이션으로 트래픽이 보내지도록 함

고정 세션 활성화하기

어떤 클라이언트가 로그인을 하고, 그 세션을 일정기간 동안 유지하거나 항상 똑같은 인스턴스로 연결되도록 하고 싶다면 고정 세션 활성화를 해야한다. ALB, NLB에서 사용 가능한 기능이며 고정세션을 활성화 하면 인스턴스들 간의 부하 불균형이 발생할 수 있다는 사실을 유의하자.

쿠키 이름들은 application 기반, 지속시간 기반으로 만들 수 있다. AWSALB, AWSELB, AWSALBAPP, AWSALBTG라는 이름은 AWS에서 사용하는 쿠키이름들이기 때문에 사용하지 말자.

교차 영역 로드 밸런싱(Cross-Zone Load Balancing)

ALB에서는 기본적으로 활성화되어있어서 요금이 부과되지 않고, NLB와 GWLB에서는 활성화시 비용이 부과되는 기능이다. 말그대로 트래픽이 들어온다면 트래픽을 AZ에 상관없이 분배해주는 기능이다.

SSL(TLS) 인증서와 로드밸런서

SSL(Secure Sockets Layer)은 아는데 TLS는 뭐지? 했었다. TLS(Transport Layer Security)는 SSL의 새로운 버전이라고 하며, TLS를 그냥 SSL로 부르는 경우도 많다고 한다. 요새는 TLS를 주로 사용한다. 로드밸런서에 SSL 인증서(혹은 여러개)를 사용할 수 있으며, SNI(Server Name Indicator)를 사용하면 여러 도메인의 웹사이트들(그리고 해당하는 SSL 인증서)을 클라이언트에게 제공할 수 있다. SNI는 참고로 ALB, NLB에서만 지원하는 기능이다. 인증서들은 ACM(AWS Certificate Manager)라는 것을 통해 관리가 가능하다니 기억해두자.

Deregistration Delay (등록취소지연)이 뭘까?

강의 슬라이드 제목은 Connection draining이나, CLB가 이제 사용되지 않는 관계로 ALB와 NLB에서 사용하는 등록취소지연(deregistration delay)를 제목으로 가져와봤다. 만약 로드밸런서와 연결되어있는 인스턴스들 중 하나가 unhealthy한 상태여서 취소시키는 중(draining)이라면 보내지고 있었던 요청들을 마무리하는 시간을 의미한다. 그 이후에 오는 요청들은 거부되고 다른 인스턴스들로 연결된다. 만약 요청들이 짧은 편이라면, 이 시간을 짧게 설정하면 좋다.

Auto Scaling Group(ASG)

ASG는 사실 처음 들어본 기술이다. 어떤 기술이냐하면, 만약 부하가 많이 발생하면 EC2 인스턴스들을 늘려주고(=scale out), 부하가 줄어든다면 EC2 인스턴스들 개수를 자동으로 줄여주는(=scale in) 기능이다. 자동적으로 로드 밸런서에 연결해주고, 만약 인스턴스가 unhealthy하여 종료되면 인스턴스를 새로 재성성해주기도 한다. ASG는 무료이며, 비용은 새로 생성된 EC2 인스턴스들에 대해서만 지불하면 된다.

스케일링 정책을 정할 수가 있는데, 크게 3가지의 방법이 있다.

동적 스케일링
1. 목표 추적 스케일링
  - 설정하기 간단함
  - 예시) ASG의 평균 CPU 사용률이 40% 넘어가지 않도록 설정
2. 단계별/단순한 스케일링
  - CloudWatch 경보를 사용하여 설정 가능
스케줄 스케일링
- 알려진 사용패턴을 기반으로 예약하는 스케일링
- 예시) 매주 금요일 오후 5시에 최소 용량을 10으로 올리기
예측 스케일링
- 반복되는 패턴이 있는 경우 좋음
- 지속적으로 부하를 예측한 다음 미리 예약을 시작하는 경우

스케일링 정책을 정할때는, metric을 종종 사용한다. 주로 CPU활용도, 타겟당요청수, (애플리케이션이 네트워크에 의존적인 경우) 평균 네트워크 in/out, 아니면 다른 커스텀 메트릭을 사용해도 좋다.

ASG- Scaling Cooldown?

ASG에서는 scaling cooldown이라는 것이 존재한다. ASG에서 스케일링이 발생하면, 쿨다운 기간동안은 추가적인 인스턴스를 시작하거나 종료하지 않는 것이다. 이는 스케일링을 했었을때 메트릭이 어떻게 변화하는지 지켜보는 시간이 필요하기 때문에 갖게 되는 시간이다. 준비된 AMI를 사용한다면, 설정 시간을 줄임으로써 요청을 더 빠르게 처리하고 이러한 쿨다운 시간을 감소시킬 수 있으니 참고하자.

section 09.

RDS?

RDS(Relational Database Service)는 AWS에 의해서 관리되는 DB 서비스로, 클라우드에서 데이터베이스를 만들 수 있도록 한다. 관리형 서비스로 자동화된 프로비저닝, OS 패칭, 연속적인 백업/복구 기능, 모니터링, 읽기 복제본, 재해 복구를 위한 multi AZ, 스케일링, EBS를 통한 스토리지 백업 등을 지원해준다. 참고로 SSH를 사용한 접속은 불가능하니 참고하자.

RDS에도 auto scaling 기능이 존재한다. 만약 RDS에 용량이 부족하거나, 줄여야하는 상황이라면(여유공간이 10% 미만이거나,저용량 상태가 적어도 5분 지속되고 있거나, 마지막 수정으로부터 6시간이 지났다면..) 자동적으로 용량을 늘리고 줄이는 것이 가능하다. 따라서 이는 예측 불가능한 워크로드일때 매우 유용하다.

Read Replicas

읽기 확장성을 위해 최대 15개의 read replicas(읽기 전용 복제본)을 만들 수 있다.

단일 AZ, 교차 AZ, 교차 리전에 생성할 수 있음
읽기전용 복제본들은 비동기식(ASYNC)이므로 읽기 일관성 유지가 가능하다
읽기 전용 복제본이 독립형 데이터베이스로 승격될 수 있음 -> 그러나 승격 이후 원본 db와 복제 관계가 끊어지게 됨
애플리케이션들이 읽기전용 복제본으로부터 읽기 작업을 수행하고자 한다면, 연결 string을 수정하여 읽어올 수 있도록 업데이트해야함! (여기서 연결 스트링은 엔드포인트를 포함하고 있다는 것으로 이해하면 좋을 것 같다)

추가로, 네트워크 전송 비용을 절약할 수 있다. 다른 AZ에 속해있을 경우 데이터를 주고받을때 네트워크 비용이 발생하는데, 만약 읽기 전용 복제본들과 원본 DB가 같은 리전 내에만 속하면 다른 AZ에 속하더라도 비용을 지불하지 않아도 좋다.

RDS Multi AZ

재해 복구를 위해 Multi 가용영역 설정이 가능하다. 이는 auto scaling을 위한 것이 아닌, 재해 복구를 위한 기능이라는 것을 기억하자. (읽기 전용 복제본들을 재해복구를 위해 multi AZ에 위치시키는 방법도 가능하다)

읽기 전용 복제본들과 달리, 동기식(SYNC) 복제가 일어난다.

만약 장애가 발생 시, 다른 AZ에 있는 standby(대기) RDS DB가 자동으로 활성화된다.

하나의 DNS 이름을 가지고 있기 때문에, 애플리케이션에서 추가적인 다른 수정을 하지 않더라도 자동으로 standby(대기) RDS DB를 가리키게 된다.

그렇다면, multi AZ 설정은 어떻게 할 수 있을까? single AZ에서 multi AZ로 설정을 변경하는 동안은 DB를 멈출 필요가 없다. 즉 downtime이 발생하지 않는다. 내부적으로는 DB의 스냅샷이 생성되고, 새로운 DB가 스냅샷으로부터 새로운 AZ에 생성된다. 그 후, 원본 DB와 대기 DB(새로 생성됨) 사이에서 동기식 복제(SYNC)가 일어남으로써 multi AZ 설정이 가능해진다.

RDS Custom

RDS는 AWS에 의해 완전 관리되므로 기저 OS나 사용자 지정 기능에 full admin 액세스가 불가능하지만, RDS Custom은 가능하다. RDS Custom은 Managed Oracle, Microsoft SQL Server Database (with OS, db)만 가능하다. RDS Custom은 사용자 지정 설정, 패치 설치, native features 활성화, 기저 EC2 instance에 SSH or SSM Session Manager에 접근할 수 있도록 한다.

그러나 RDS Custom은 기저하는 OS, Ec2에 접근이 가능하기 때문에 에러가 발생할 가능성이 높으므로 DB snapshot을 미리 만들어두는 것이 좋다. 또한, 사용자가 직접 커스터마이징을 해야하기 때문에 automation mode를 비활성화한다.

Amazon Aurora

오로라는 AWS가 고유로 개발한 기술이다. (오픈 소스가 아님) AWS Cloud 최적화 데이터베이스이며, MySQL RDS보다 5배 정도의 성능을 보여주며, Postgres RDS보다 3배정도의 성능을 보여준다. 특징들은 다음과 같다.

Postgres, MySQL이 Aurora DB와 호환이 가능하다.
- Aurora DB를 사용하는데 MySQL이나 Postgres 드라이버와 연결된다면, MySQL이나 Postgres처럼 사용이 가능하다는 의미이다
용량은 자동으로 키울 수 있으며, 최소 크기는 10GB, 최대 128TB까지 가능하다
오로라는 최대 15개의 복제본을 가질 수 있고, 복제 과정은 MySQL보다 빠르다
장애조치가 즉각적으로 이루어진다. 평균 30초 이내로 이루어진다.
cloud native이기 때문에 고가용성이다
RDS보다 비용이 비싸지만, 효율적이다
교차 리전 간 복제를 지원한다
3개(최대)의 AZ에 걸쳐서 총 6개의 복제본(master를 포함하여)이 존재한다.
- 쓰기작업을 할때 6개 복제본들중 최소 4개 이상이 복제에 성공해야 쓰기가 완료된다
- 읽기작업을 할때 6개 복제본 중 최소 3개 이상의 복제본이 같은 데이터일때 읽기작업이 완료된다
- 1개의 오로라 인스턴스(master) 만이 쓰기 작업을 한다.
- P2P(peer-to-peer)복제를 통해 자가복구가 가능
- 용량은 100개가 넘는 볼륨들에 stripe형식으로 저장이 된다. 단일 볼륨에 의존하지 않는 구조.
writer endpoint는 master에만 연결되어있다
로드 밸런싱이 connection level에서 이루어진다. 읽기전용 복제본들은 자동으로 scaling이 되며, reader endpoint와 복제본들이 연결되어 있기 때문에 로드 밸런싱이 되는 것이다.
Backtrack: 어떤 시점의 데이터라도 백업을 하지 않고도 복구가 가능하다

Aurora Custom Endpoints

오로라는 reader endpoint, writer endpoint 말고도 커스텀한 엔드포인트를 만들 수 있다. 커스텀 엔드포인트를 사용할 경우 기존의 reader endpoint는 일반적으로는 사용되지 않는다. (reader endpoint가 사라지는 것은 아니다!)

예를 들어, 특정 복제본들에 대해 분석 쿼리를 실행한다고 하자. 분석 쿼리는 사이즈가 더 큰 일부 복제본들에 대해서만 실행되도록 하고자 한다면, 커스텀 엔드포인트를 만들어 분석 쿼리를 실행할때 이 엔드포인트로 연결하여 해당하는 큰 복제본들에 연결되도록 해야한다. (물론 기존의 reader endpoint를 사용할 수 있고, 사라지는 것이 아니다)

Aurora Serverless

기존의 오로라는 용량을 미리 설정하는 등의 용량 플래닝이 필요하며, 사용하지 않더라도 비용이 계속 부과된다. 반면 서버리스를 사용하면 이러한 단점들을 극복할 수 있다.

서버리스는 용량을 미리 설정하지 않아도 사용량에 따라 자동으로 scaling이 된다. 사용한 만큼 지불하면 되므로 비용 효율적이다. 빈번하지 않고 간헐적이거나 혹은 워크로드가 예측 불가능할때 사용하면 좋다.

Global Aurora

재해 복구를 위해 교차 리전을 통해 읽기전용 복제본들을 만드는 방법과 달리, Aurora Global Database를 만드는 방법도 있다.
하나의 주 리전(읽기/쓰기 가능)과, 최대 5개정도의 보조 리전(읽기만 가능)들을 가질 수 있다. 리전간 복제 시간은 1초 이하로 걸린다. (전형적인 교차 리전 복제 과정은 1초 이하로 소요된다!)

보조 리전당 최대 16개의 읽기 전용 복제본들을 생성 가능하다.

전세계에서의 latency를 줄일 수 있는 장점이 있다.

만약 재해가 발생 시, 보조 리전에 있는 db를 primary로 승격시키는 것이 가능하다. 이를 복구하는 시간은 (RTO)는 1분 이하로 걸린다.

Aurora Machine Learning

AWS ML 서비스들과 Aurora 를 통합시킬 수 있다. SQL 쿼리 인터페이스를 통해 머신러닝 예측을 애플리케이션에게 가능토록 할 수 있으며, SageMaker와 Comprehend(감정분석에 사용됨)이 지원된다.

Backup & Restore

먼저 오로라의 백업과 복구에 대해 설명하겠다.

오로라는 백업이 자동화되어 있으며, 비활성화가 불가능하다. 1일부터 35일까지 보관이 가능하며, 5분 단위 시점으로 복구가 가능하다.

수동으로 스냅샷을 만들어 백업을 진행할 수 있는데, 유저가 직접 수동으로 백업을 진행해야하지만 백업 보유 기간을 원하는 만큼 사용자가 설정 가능하다.

복구는 앞서 설명했듯이 5분 시점마다 복구가 가능하거나, 만약 수동으로 백업을 만들었거나 온프레미스에 있는 MySQL 데이터베이스를 Aurora로 복구하고자 하는 경우(MySQL과 Aurora는 호환가능하다는 점을 기억하자) S3에 백업을 만들어(Percona XtraBacktup 소프트웨어 사용) 저장 후 그 백업으로부터 새로운 aurora 클러스터 생성(복구)가 가능하다.

RDS의 경우에도 마찬가지로 S3에 온프레미스의 데이터베이스 백업을 저장 후, 그 백업으로부터 새로운 RDS instance 생성이 가능해진다.

Aurora Database Cloning

위에서 말했던 읽기전용 복제본을 만드는 것과 같은 것이 아니라, 새로운 Aurora DB 클러스터를 원본 클러스터로부터 복제함으로써 생성하는 것이다. 스냅샷을 만들어서 복구하는 방법보다 훨씬 빠른데, 그 이유는 copy-on-write 프로토콜을 사용하기 때문이다.

처음에는, 새로 만들어진 클러스터는 원본 클러스터와 같은 데이터 볼륨을 사용한다. 따라서 복사가 필요되지 않으므로 빠르고 효율적이다
새 클러스터로 업데이트가 이루어질때, 추가 스토리지가 할당되고 데이터는 분리되어 복사된다.

이 과정은 매우 빠르고, 비용 효율적이며 production 데이터베이스로부터 production database에 영향을 주지 않도록 staging 데이터베이스(test를 하고 싶어서 데이터를 복사해야할때) 를 만들때 유용하다.

RDS & Aurora 보안

at-rest 암호화
- master&replicas 가 시작할때 보안설정 정의하여 AWS KMS로 암호화 가능
- master가 암호화되지 않으면, replicas도 암호화될 수 없음
- 암호화되지 않은 데이터베이스를 암호화하려면, 데이터베이스 스냅샷을 만든 후 -> 복구할때 암호화해야한다
in-flight 암호화: TLS(default), AWS TLS root certificate(client측에서)
IAM 인증
보안 그룹 설정
SSH는 RDS Custom만 가능!
감사 로그 활성화 -> 로그들이 CloudWatch에 장기 보관될 수 있음

Amazon RDS Proxy

RDS Proxy는 pool(풀)을 만들어 DB에의 연결을 공유하도록 함으로써 데이터베이스 리소스들에 대한 트래픽 등을 줄이고, 시간초과와 열려있는 연결들을 줄임으로써 효율을 개선한다. 장애가 발생했을때 장애 복구 조치의 속도를 높일 수 있고, 애플리케이션들이 일일히 db에 연결해야하는 수고로움을 덜어준다. 즉, 프록시가 하나의 pool에 연결들을 모아서 RDS DB 인스턴스로 가는 연결들을 줄여준다. 예를 들어, 앱1이 DB연결 요청을 하면 proxy는 연결 1을 생성하여 풀에 유지한다. 그 이후 앱2가 DB 연결 요청을 하며 새로운 연결2를 만드는 것이 아닌, 연결1을 활용하여 연결이 가능하다는 의미다.

서버리스이며, 오토 스케일링이 가능하고, 다중 AZ가 가능하여 고가용성이다. RDS를 지원하고 있다. 또한, IAM 인증을 통해서만 RDS DB로 연결이 가능하다. RDS Proxy는 VPC 내에서만 접근이 가능하지 때문에 퍼블릭하게 접근이 불가능하다.

Amazon ElastiCache?

ElastiCache는 Redis or Memcached와 같은 캐싱 기술을 관리하는 기술이다. 캐시는 고성능, 낮은 지연속도를 가진 인메모리 데이터베이스이며 집중적인 읽기 발생 워크로드에서 데이터베이스에 대한 부하를 줄이는데 도움을 준다. 이는 추가적으로, 애플리케이션이 statelss하도록 해준다. (상태를 elasticache에 저장하므로 애플리케이션에 상태를 저장할 필요가 없어지도록 함)

ElastiCache는 애플리케이션 코드를 많이 변경해야한다. 캐시를 그냥 껐다/켰다할 수 있는것이 아니라, 데이터베이스에 쿼리하기 전/후에 캐시를 쿼리하도록 애플리케이션의 코드를 변경해야하기 때문이다.

캐싱 기술의 기본적인 원리는 이미 알고 있어서 중요한 용어 몇가지만 짚어보자면, 애플리케이션이 쿼리를 할때 먼저 elasticache에 이미 원하는 쿼리가 발생했었는지 확인을 한다. 만약 elasticache에 있다면(이미 예전에 쿼리가 발생했었다면) 이를 cache hit라고 한다. 만약 없다면 이를 cache miss라고 하며 db로부터 해당 쿼리에 대한 내용을 가져와 elasticache에 write한다.

이러한 Elasticache를 활용하여 사용자의 세션을 저장할 수 있다. 이는 애플리케이션이 stateless(상태 비저장)을 유지할 수 있도록 해준다!

먼저 유저가 로그인을 하면, 해당 유저의 세션 정보가 elasticache에 저장이 되고, 유저가 다른 인스턴스에 접속하더라도 다른 인스턴스가 elasticache에서 해당 유저의 세션 정보를 검색해옴으로써 유저가 계속 로그인을 유지할 수 있도록 해준다.

Redis vs. Memcached

위에서 ElastiCache는 redis, memcached를 관리한다고 했다. 둘에는 어떤 차이가 있을까?

먼저 Redis다.

다중 AZ, 자동 장애 조치 가능
읽기전용 복제본을 생성하여 고가용성 확보
AOF 지속성을 사용한 데이터 내구성
백업과 복구
sets와 정렬된 sets를 지원

다음은 Memcached다.

데이터 분할을 위해 멀티 노드 사용 (sharding)
복제가 안되므로 가용성 좋지 않음
영구 캐시가 아님
백업과 복구 지원 x
멀티 스레드 아키텍처임

ElastiCache 보안

elasticache는 Redis에서만 IAM 인증을 지원한다. 그 외의 경우에는 사용자이름과 비밀번호를 통한 인증을 시행해야한다.

ElastiCache의 IAM 정책들은 AWS API 수준의 보안에만 사용이 된다.

먼저 Redis 인증(AUTH)는 기존의 보안그룹 보안설정에서 추가적인 보안조치라고 생각하면 된다. Redis 클러스터 생성 시에, 패스워드/토큰을 설정 가능하다. Redis AUTH는 전송중 암호화 SSL을 지원하기도 하니 참고하자.

Memcached의 경우, SASL 기반의 고급 메커니즘인 인증을 지원한다.

ElastiCache Patterns

그러면 이제 elasticache에 data를 어떻게 load하는지에 대해 여러 패턴들을 살펴보자. 크게 3가지 정도가 존재한다.

Lazy Loading
- 모든 읽기 데이터가 캐시되어 있고, 데이터가 캐시에서 지체될 수 있음
- 데이터가 캐시에 없으면 db에서 가져와 캐시에 저장하고, 있으면 캐시에서 읽어오는 형태
Write Through
- 데이터가 지체되지 않고, DB에 데이터가 쓰여질때 데이터가 캐시에 추가하거나 업데이트된다
Session Store
- 일시적인 세션 데이터를 캐시에 저장한다. TTL 기능 사용 가능하다.

Redis 사용 사례

대표적인 예시로 게임 리더보드가 있다. 앞서 Redis와 Memcached의 차이에 대해 설명했듯이, Redis는 sorted sets을 지원한다. 즉, 고유성과 요소들의 순서를 보장해줄 수 있다. 따라서 이러한 특성은 게임의 리더보드를 만드는데 활용될 수 있을 것이다. 매 새로운 요소가 추가되면, 실시간으로 랭킹에 올라가고, 올바른 순서(랭킹)에 따라 정렬되어 나타내어질 것이다.

바쁜 일들이 있어서 정리가 엄청 늦어졌다. 강의는 밀리지 않았으나, 정리해야할 것들이 산더미가 되어버렸다. 얼른 따라잡을 수 있도록 열심히 해야겠다..

'💻STUDY > AWS SAA STUDY' 카테고리의 다른 글

[SAA] 3. Route53 (0)	2024.12.05
[SAA] 1. 시작, IAM, EC2 (0)	2024.11.05
[SAA] 00. AWS SAA 스터디 시작 (2)	2024.11.03