Cache & Redis
DB의 부하를 줄이기 위해 캐시 사용 할 수 있음
캐시: 데이터나 값을 미리 복사해놓는 임시 저장소(Memcached, Redis, Local Memory cache 등 구현)
활용: Dynamic Programming(이 전의 값을 저장), JPA의 영속성 컨텍스트
파레토의 법칙에 의해 자주 사용되는 내용의 20%를 캐싱해두면 성능 증가를 이룰 수 있다
Cache Hit: 캐시에 데이터가 존재, 해당 데이터를 바로 반환
Cache Miss: 원하는 데이터가 존재x, db에 찾아가서 반환
캐싱 전략 패턴
읽기 전략
Look Aside(옆을 보다): 캐시에 데이터가 없을 때 db에 요청
장점: 캐시에 문제가 생기는 경우 DB로 요청을 위임
단점: 캐시와 DB의 데이터 정합성 유지 어려움, 첫 조회 시 DB 부하 발생
Read Through: (항상 캐시를 읽는 전략) 캐시에 데이터가 없으면 DB에서 캐시에 값을 가져오고 서버가 읽음
장점: 데이터 정합성 보장
단점: 캐시가 죽으면 애플리케이션 문제 발생
쓰기 전략
Write Around (쓰기 우회) DB에 바로 데이터를 씀
장점: 성능 좋음 빠름
단점: 캐시, DB 데이터 정합성 유지 어려움
Write Back(나중에 쓰기) 캐시에 데이터를 밀어놓고 한번에 쓰기
캐시에 먼저 많은 양의 데이터를 써 둡니다
일정 시간이 지난 뒤에 한꺼번에 많은 양의 데이터를 밀어 넣음 => 쓰기 횟수 비용을 줄일 수 있음(스케줄링 기법)
(insert문을 하나로 묶어서 성능적으로 이점을 가져가게 만들어야함)
단점: 캐시의 데이터 유실 문제(캐시가 죽을 시 데이터가 유실 될 수 있음)
Write Through 항상 캐시를 거치고 쓰게 됨
장점: 데이터의 정합성이 보장
단점: 두 번의 쓰기가 항상 진행되기 때문에 성능 고려
캐시 사용 시 주의사항
자주 사용되면서 변경이 되지 않는 데이터
유실되어도 크게 문제가 없는 데이터
DB와 함께 사용할 때 데이터 정합성 문제 고려
Redis: Remote Dictionary Server(외부 사전 형태 저장하는 서버), 캐시 구현 방법 중 한가지
key-value 구조
메모리에 저장하는 Key-Value 기반 NoSQL DBMS
캐싱, 임시 작업 큐, 실시간 채팅, 메세지 브로커 등 활용 가능
특징:
Performance: 메모리에 저장되기에 빠른 속도로 접근 가능
Data Structure: 다양한 자료구조 제공
Single Thread: 한번에 하나의 명령만을 처리, Race Condition이 거의 발생하지 않음(두 개 이상의 프로세스 동시적 하나의 리소스로 경쟁하는 상태)
Persistence: 메모리에 저장된 데이터를 디스크에 영속화 가능, 서버에 문제가 발생하더라도 복구 가능
RDB: 특정한 간격으로 현재 Redis의 메모리에 존재하는 데이터의 스냅샷을 남김
장점: 압축하여 저장하기 때문에 AOF보다 크기가 작음, 로딩/복구 속도가 빠름
단점: 백업 중 서버가 다운될 경우 최신 데이터 유실 가능(특정 간격으로 저장하기에)
AOF: 데이터 변경 시 (CUD) 로그 파일에 기록
장점: 저장 속도 빠름, 실시간 데이터 백업 가능, 데이터 손실 거의 없음
단점: 명령 실행 기록을 모두 기록, 파일 크기가 크고 복원 소요기간 김
Redis를 우아하게
1. 데이터 타입에 따른 적절한 자료구조 사용
2. O(N)명령어 주의: KEYS/ FLUSHALL, FLUSHDB, Delete Collections/ Get ALL Collections
해당 명령어 모두 처리 된 후 다른 명령어 실행되기에 시간이 오래걸리는 명령어 사용 시 주의
3. 메모리 관리, 메모리 단편화 발생
메모리가 작은 공간으로 나뉘어져 관리되어 사용 가능한 공간이 충분함에도 해당 메모리를 할당 할 수 없음
=> 실제 물리 메모리 사용량을 나타내는 RSS 값을 모니터링하여 메모리 관리를 해주어야 함
4. Redis 목적성: 캐시용, 저장소용으로 사용할지에 대한 목적 분명히 하기
Persistence기능 => 장애 발생 가능성 높음