상황현재 서비스에서, 레디스에는 많은 종류의 데이터가 저장되어있다.각 게시글에 대한 락정보인기 게시글 정보유저-좋아요 정보게시글의 좋아요 카운팅하나의 레디스 서버에서 4개의 역할을 수행하기 때문에 서로간의 영향력이 존재하며 한꺼번에 많은 요청을 부담해야 하기 때문에 응답이 느려질 수 있다. 각각의 서비스를 서로 다른 레디스 서버로 분리하여 담당하면 좋겠지만, 스케일 아웃을 하기 이전에 최대한 많은 트래픽을 견뎌보고 싶었다. 가정한 상황에 대한 문제 원인 분석 : 현재 상황에서 Latency의 원인이 될 수 있는 것들1. 메모리 사용량의 증가메모리 사용량이 증가하면 latency의 원인이 될 수 있다.메모리 초과시, 페이지 스왑으로 디스크 I/O 발생RDB, AOF의 백그라운드 스레드가 fork() 등으로..

이전 글. https://loftspace.tistory.com/46 인기 게시글 도입을 위한 과정 - 자료구조의 선택 그리고 추가적인 고민좋아요 수, 유저-좋아요, 인기 게시글 목록을 저장할 자료구조레디스의 공식문서를 보았을 때 다음과 같은 방식을 고안했다. 방법 1. 좋아요 수 카운팅을 HashSet으로 관리, 랭킹 목록은 List로 저장loftspace.tistory.com Redis에 캐싱되어 있는 인기 게시글 기본 정보(제목,인원 수 등) 변경에 대해 write through 방식을 채택하였다. 서비스 상황 : 인기 게시글 목록에서는 각 게시글의 기본 정보만 표시가 되어있고 이 정보를 Redis에 적재한 상태다. 이번에는 다음 문제 상황에 대해 고민해 보았다. 캐시에 write후 DB에 writ..

이전에 포스팅에서 트랜잭션 데드락을 여러 이유로 레디스를 활용하여 해결하였다.예외 상황에 대해서 고민을 해보았다. 레디스 서버가 다운 된다면만약에 레디스 서버가 다운된다면 락 기능을 활용하지 못한다. 만약에 서버를 증설할 수 있다면, 레디스 서버를 늘려서 처리하는 방법이 있다. 여러개의 레디스 서버를 어떻게 활용할까만약 락을 관리하는 레디스 서버가 여러대라면 크게 다음과 같이 두가지 방식으로 나눌 수 있겠다.모든 레디스 서버가 하나의 key에 대해 락을 공유하는 방식각각의 레디스가 서로 다른 key를 관리하는 방식 1. 모든 레디스 서버가 하나의 key에 대해 락을 공유하는 방식이 방법은 RedLock 알고리즘을 사용하는 방식이 있었으나, 다음 상황에 대해 문제가 있어 deprecated 되었다. "G..

문제예측되는 상황 : 같은 게시글에 대해 동시에 좋아요를 하는 테스트시, 트랜잭션에서 데드락이 발생하였다.문제의 원인 파악하기해당 로직에서 사용되는 쿼리를 순서대로 적용해가며 단계별로 테이블에서 획득한 락을 분석하여 외래키 제약조건으로 인한 공유락이 원인임을 파악했다.해당 플랫폼의 요구사항 고려해보기유사한 서비스(ex 에브리타임)을 보았을 때, 비인기 게시글에 대한 좋아요의 동시접근의 확률은 낮아 보인다.인기 게시글은 Redis에 캐싱되어있는 상태이다. 구동 환경 : MySQL 8.0 (innoDB)이며, 트랜잭션 격리 레벨은 디폴트 값인 Repeatable Read로직 : 좋아요 대상 게시글 조회 → 이미 좋아요 했는지 조회 → 좋아요-게시글 테이블에 추가 → 게시글의 좋아요 수 업데이트 해결 방안 ..

좋아요 수, 유저-좋아요, 인기 게시글 목록을 저장할 자료구조레디스의 공식문서를 보았을 때 다음과 같은 방식을 고안했다. 방법 1. 좋아요 수 카운팅을 HashSet으로 관리, 랭킹 목록은 List로 저장. 일정 주기마다 디비에서 랭킹 갱신이 방법은 좋아요 증가가 빠르다. 즉 M개의 요청에 대해 O(1).단점은 랭킹 주기가 일정 주기에 의존한다는 것. 방법 2. 좋아요 수를 SortedSet으로 저장하여 인덱스처럼 사용하는 것이다.(인기 게시글 목록은 hash로 저장) 물론 갑작스럽게 인기가 상승한 비 인기 게시글 까지의 고려를 위해 일정 주기로 디비로부터 갱신은 불가피하다.이 방법은 실시간 정렬이 가능하다는 것이다. 단 고정된 인기 게시글 목록 내부에서. 단점은 조회시 추가적인 redis 호출이 필요..

상황 및 기술의 필요성 인식이 API는 좋아요 수를 기준으로 10개의 인기 여행 계획 게시글을 선정하며, 서비스 내에서 가장 많이 요청되는 API 중 하나다.기존에는 데이터베이스에 DESC 인덱스를 생성하여 조회 속도를 높였으나, 부하 테스트 결과 여전히 DB 부하가 존재한다. 1초에 2천명 동시 요청 테스트시, 평균 좋아요 기능의 api 콜 대기 시간이 write는 7556ms, read 속도는 500ms 이다. 따라서 새로운 해결 방식 필요함을 느꼈다. 새로운 해결 방식을 찾기 위해 다루는 데이터의 특성부터 다시 파악하였다. 위의 API에서 다루는 데이터는 크게 두가지로, 좋아요 정보와 게시글 내용이다. 이 데이터에 대해, 다음과 같이 가정하였다.데이터 : 게시글 좋아요 수Workload : 자주 조..