Back-End/Redis (4) 썸네일형 리스트형 레디스와 분산락 들어가기 전에 대규모 서비스 개발에 대한 경험이 없다면, 여러 서버를 운영하는 분산환경에서 락 처리에 관한 고민을 할 필요를 느끼지 못한다. ( 물론 내가 부족한 개발 실력을 가지고 있어서도 그렇지만... ) 많은 트래픽을 받는 경우 당연히 수평적 확장이 용이해야 하고, 여러 대의 서버로 API가 분산 호출된다. 서비스 특성 상 트랜잭션이 많이 일어나는 상황이면 동기화된 처리가 필요하고, 여러 서버에 공통된 락을 적용해야 하기 때문에 레디스를 이용하여 분산락을 이용한다. 분산 락은 데이터베이스 등 공통된 저장소를 이용하여 자원이 사용 중인지를 체크한다. 그래서 전체 서버에 동기화된 처리가 가능해진다. 간단한 분산 락 구현하기 setnx 명령어를 통해 "락이 존재하지 않는다", "존재하지 않는다면 락을 획.. Redis란? Redis란 Remote Dictionary Server의 약자이다. Redis의 특징 - 다양한 Collection 지원 Redis는 In-memory 데이터베이스이다 디스크 접근인 RDBMS 속도 개발 편의성 이렇게만 봐서는 뭔가 와닿지가 않는다. 예를 들어, 실시간 랭킹 서버를 구현한다면? 1) RDBMS를 이용하여 구현한 경우 저장된 SCORE를 정렬하여 가져오는 과정 필요 개수 많아지면 느려짐 트랜잭션 문제도 신경 써야함 2) Redis를 이용하여 구현한 경우 Redis의 Sorted Set을 사용하기 때문에 정렬이 필요 없음 ( 다양한 Collection의 장점 ) 모든 자료구조는 Atomic 하기 때문에 데이터 정합성 보장이 쉬움 Redis Key Redis 키를 잘 설계 하는것도 중요하다... 레디스(Redis)의 다양한 활용 사례 들어가기 전에 나는 아직 실력이 부족한 개발자여서 레디스=캐시 로의 의미로만 이해하고 있었다. 대부분의 서비스에서 단순 캐시용도로만 사용하기도 한다. 레디스에 대해 정확히 이해를 하지 않으면 성능이 제대로 나오지 않을 수도 있고, 제대로 활용하지도 못할 수도 있다. 레디스를 어떻게 배치할까? 캐싱 전략? 단순 캐시용도말고 다른 용도로는 어떻게 쓸까? 그래서 나의 부족한 지식을 채우기 위해 해당 포스팅을 작성하게 되었다. 캐싱 전략 - Look Aside ( = Lazy Loading ) 캐시를 옆에 두고 필요할 때만 데이터를 캐시에 로드하는 전략이다. ( key-value 형태로 저장됨 ) 데이터 가져오는 요청 Redis에 먼저 요청 -> 있으면 반환 없으면 데이터베이스에 데이터 요청 이 데이터를 레디스.. Redis Spring Boot에 설정하기 및 개요 Redis, Cache 는 왜 사용하는걸까? 백앤드 개발을 하다보면 가끔 조회하는 시간 때문에 API 응답이 너무 느릴 때가 있다. 이럴 때 캐시를 사용하면 응답시간이 많이 줄어든 경험이 있을 것이다. ( 인메모리에 올려서 한 경우도 있지만?... ) 그렇다고 무조건 캐시를 사용하면 될까? 남용하게 되면 서비스의 신뢰성이 떨어지는 경우가 발생할 수도 있다. Cache 도입할때 고려사항 - 1. 정보가 잘 변경되지 않는 경우 + 처리 시간이 긴 경우 이를 고려하지 않고 도입을 한다면 데이터가 맞지 않아 서비스의 신뢰성이 떨이지게 된다 Cache 도입할때 고려사항 - 2. 빈번한 동일 요청 빈번하게 동일한 검색 요청을 하게 된다면 Cache 도입을 고려해볼 수 있다. 디스크에서 읽어오는 것 보다 서버의 메모.. 이전 1 다음
