250422 - aws database elasticache for valkey

실시간 애플리케이션을 위한 실시간 성능 엘라스틱캐시

• 오픈소스연동이 매우 용이하다
• 레디스 엔진 : 다양한 자료형, 싱글스레드, 스케일링가능, 샤딩도 지원
• 멤캐시드 엔진: 단순한 lru 캐시, 복잡한건 못쓰고 단순한거만, 문자열과 객체만 지원, 멀티스레드 지원, 데이터 영속성 지원
• valkey : 요번에 공식 지원 추가됨. redis 의 포크버전(라이센스땜시)
• 열두달 공짜임

valkey

• 성능개선. 멀티스레드!! 성능 매우 개선, 지연시간 감소 매우
• 메모리 사용량 감소 클러스터모드 도입을 위한 아키텍쳐 개선
• 클러스터 유무에 따라 스토리지 확장성 성능에서 차이가 난다(당연한얘기..)
• 클러스터키면 고려를 안해도 되지만 켜지 않으면 프라이머리와 레플리카 구조가 됨
• 클러스터 모드 활성화시에 페일오버는 자동이고 복원도 자동이라 별도의 dns 전파가 없음
• 교차 리전 복제도 지원. db들과 유사함

elasticache serveless

• 용량관리 불필요, 초 저지연, 종량제, 가용성, 단일 엔드포인트, 보안규정준수

사용사례

• 실시간 캐싱, 세션스토어, 비용최적화성능분석, 실시간 지리데이터, 리더보드, 채팅메시징, 머신러닝 피쳐스토어

메모리 db

• 캐시는 "캐시" 고 메모리db 는 "db"다
• 무슨말이냐면 내구성과 가용성의 목표지향점이 다르다. 컨셉부터가 최종일관성

벡터서치 for memorydb

• 벡터저장, 검색,인덱싱, 조회 기능 제공
• 알고 있는 그거.. 추천시스템, 검색엔진, aiml워크로드. 특히 99% 이상의 재현율

자료구조

• 다양한 자료구조를 지원하며 적절한 자료구조를 잘 쓰는것이중요하다 성능과 리소스 낭비때문에
• 긴 key값을 쓴다면 성능이슈가 있다 차라리 해싱을 해라
• 자료형별로 되게 많은 명령어가 있다 key는 scan을 쓴다던가
• ttl을 초단위로 설정가능
• json을 str로 박아서 쓰지말아라, 원자성에 문제가 있다..
• geospatial 와 이거 좋다.
• 커넥션풀을 활용하자. 새연결은 비용이 많이 듬..
• 타임아웃 설정을 하자 너무 많이 사용하면 비용이 또 많이 듬.

캐싱전략

• 레이지 로딩과 라이트쓰루

그외

• 메모리가 풀찼을때 다양한 방식의 정책이 있다 이건 문서보는게 나을듯 오래된거, 빈번하지않은거 등등을 날려서 메모리 확보
• keys 말고 scan을 쓰자..