조회수 중복 증가 방지 및 일괄 업데이트

😐정리

• 사용자 구분은 viewCount라는 이름으로 브라우저별 random 값을 가진 쿠키를 이용
• 상품에 대한 중복 접근 체킹은 브라우저별 랜덤 값을 Key로 Redis의 SET이용(itemId저장)
• 사용자 구분을 위한 쿠키와 중복 접근에 대한 내용을 저장하는 set의 Key값은 자정에 만료
  Redis에서 itemId로 조회수를 저장 -> 일정 시간 후 DB반영 

 

1. 저는 혹시 모를 상황에 대해 구현에서의 편의성을 가져가기 위해 Redis로 중복접근을 체킹했습니다.

하나의 쿠키에 중복접근에 대한 정보를 담았을 때 사용자가 게시글 1000개 이상을 읽는다면 문제 발생
-> 쿠키를 여러 개 이용하는 방식으로 확장해야 함 

그러나 하루에 1000개 이상의 게시글을 읽는 경우가 생각보다 많이 발생하지 않을것이고 그렇다면 서버에서 굳이 자원을 소모할 필요가 없긴합니다..!! 

2. 많은 사용자들이 이용할 것으로 예상하고 일괄 업데이트를 진행했습니다.
10000명의 사용자가 10분 동안 게시글을 100개씩 조회하면 10분동안 100만번의 업데이트 쿼리가 나가겠네!?

사용자가 적다면 중복 접근을 제거한 마당에 큰 문제가 발생하지 않을 수 있습니다. 특히 중복 조회를 제한한 순간부터는 불필요한 과정이라고 생각합니다 Redis의 메모리를 잡아먹기도 할거구요

 

😐목표

제가 이루고자 했던 목표는 아래와 같았습니다.

 

1. 00:00 분을 기준으로 하루 동안 한 명의 사용자는 하나의 조회수만 올린다.

2. 상품 별 조회수는 특정 시간마다 일괄 반영한다.

 

 

😐사용자는 어떻게 구분하지?

굳이 서버 자원을 쓰면서 유지할 데이터는 아니라고 판단했고 IP와 쿠키 중에 고민했고 조작의 위험성 보다는 정확한 식별에 더 중점을 두어 쿠키를 사용하기로 했습니다.

쿠키	IP
조작 가능	사용자가 같은 IP주소 공유하는 경우(학교, 공공장소, 회사 등) 식별이 어려움

 

😐사용자만 구별하는게 아니라 사용자의 상품 별 접근을 구분해야 하네!?

IP를 이용   -  IP + itemId정보를 저장(서버에 저장해야함)

cookie이용 -  Random값 + itemId의 형태로 저장

 

😐쿠키...너 좋은 방법 맞냐고

IP는 서버에 저장이 불가피했지만 쿠키는 선택지가 존재했습니다. 고민 과정을 정리하자면 아래와 같습니다.

 

하나의 브라우저는 300개의 쿠키를 저장할 수 있고 하나의 도메인 당 20개의 값만 가질 수 있다.

 

 

-> 즉, cookie_item_1과 같이 여러 개의 쿠키로 나눠서 관리하는 것은 불가능할 뿐더러 가능해봤자 비효율적

-> 그렇다면 하나의 쿠키로 여러개의 id를 관리해야하면 되겠다!

-> 쿠키의 용량은 4KB이기 때문에 1/2/3/4/5/6/7/8/9/ 와 같은 형태로 저장한다면 숫자도 자리수가 늘어나고 / 도 포함해야해서 1500개정도..?

 

실제로 로직을 작성해보지는 않았지만 구현 과정에서 고려해야 할 부분들이 꽤 보였고 성능적인 부분이나 조금 더 간단한 구현이 가능한 Redis의 set을 이용하기로 결정했습니다.  

• 매번 쿠키 값을 split한 List에 접근하려는 상품의 id가 있는지 확인 및 없으면 쿠키에 입력 
• 한 사용자가 1500개 이상을 볼 일은 거의 없겠지만 넘어간다면 쿠키를 늘려야 하고 이 때부터 이에 대한 추가적인 확인이 필요 

 

😐구현 방식

사용자의 구분만 쿠키로 진행하고 이후 중복에 대한 체킹을 Redis의 Set을 이용했습니다. 구현 방식은 다음과 같습니다. 

 

 

Controller

    @GetMapping("/{itemId}")
    public Response<ItemDetailResponse> getItemDetail(@Valid @PathVariable(value = "itemId") Long itemId, HttpServletRequest request, HttpServletResponse response) {
        ItemDetailResponse itemDetailResponse = itemService.getItemDetail(itemId);

        /**
         * @Description
         * 1. 쿠키가 없다면 만들고 있다면 value Return
         * 2. 사용자의 아이템에 대한 접근 흔적이 없다면 조회수 증가
         */
        String viewCountCookieValue = CookieUtils.getViewCountCookieValue(request, response);
        itemService.handleViewCount(itemId, viewCountCookieValue);


        return Response.success(HttpStatus.OK, String.format("%d번 상품 정보입니다.",itemId), itemDetailResponse);
    }

• 사용자가 첫 접근했을 때 viewCount 쿠키 발행해 줍니다(사용자 구분을 위함)

 

CookieUtils, TimeUtils

@Component
public class CookieUtils {

    public static String getViewCountCookieValue(HttpServletRequest request, HttpServletResponse response) {
        Cookie[] cookies = request.getCookies();
        if (cookies != null) {
            Optional<Cookie> viewCountCookie = Arrays.stream(cookies)
                    .filter(cookie -> cookie.getName().equals("viewCountCookie"))
                    .findFirst();
            if(viewCountCookie.isPresent())
                return viewCountCookie.get().getValue();
        }
        return createAndAddViewCountCookie(response);
    }

    private static String createAndAddViewCountCookie(HttpServletResponse response) {
        String randomCookieValue = UUID.randomUUID().toString();
        ResponseCookie cookie = ResponseCookie.from("viewCountCookie", randomCookieValue)
                .path("/")
                .sameSite("None")
                .httpOnly(true)
                .secure(true)
                .maxAge(60 * 60 * 24) 
                .build();

        response.addHeader("Set-Cookie", cookie.toString());
        return randomCookieValue;
    }
}

public class TimeUtils {

    public static long getRemainingTimeUntilMidnight() {
        LocalDateTime now = LocalDateTime.now();

        // 현재 시간부터 내일 00:00:00까지의 남은 시간 계산
        Duration duration = Duration.between(now, now.plusDays(1).withHour(0).withMinute(0).withSecond(0));

        // 계산된 시간을 초로 변환
        return duration.getSeconds();
    }
}

• 사용자 구분을 위한 쿠키는 00:00 마다 만료되도록 구현(사용자의 접근 기록 초기화)
  -> 자정이 넘어갔는데 쿠키가 남아있다면 조회수 중복체킹에 영향을 주기 때문에 자정마다 만료되도록 구현했습니다!

 

ItemRedisService, RedisService

@Service
@RequiredArgsConstructor
public class ItemRedisService {
    private final RedisService redisService;

    // @Description 중복된 접근이 아니라면 조회수를 증가시키고 접근 처리
    public void handleViewCount(String cookieValueOfViewer, Long itemId) {
        if (!redisService.isExistInSet(cookieValueOfViewer, itemId))
        {
            redisService.increaseData("viewCount_item_" + itemId);
            redisService.addToSet(cookieValueOfViewer, itemId);
        }
    }
}

@RequiredArgsConstructor
@Service
public class RedisService {

    private final RedisTemplate<String, Object> redisTemplate;

    public void increaseData(String key) {
        redisTemplate.opsForValue().increment(key);
    }

    public void addToSet(String key, Long itemId){
        if(!redisTemplate.hasKey(key)) {// 키가 없다면(set이 없다면)
            redisTemplate.opsForSet().add(key, String.valueOf(itemId)); // set생성
            redisTemplate.expire(key, TimeUtils.getRemainingTimeUntilMidnight(), TimeUnit.SECONDS); // 만료기간 설정
        }
        else // 기존 키 값으로 된 set에 추가
            redisTemplate.opsForSet().add(key,String.valueOf(itemId));

    }
    public boolean isExistInSet(String key, Long itemId){
        return Boolean.TRUE.equals(redisTemplate.opsForSet().isMember(key, String.valueOf(itemId)));
    }

}

 

-> 쿠키 값을 키 값으로 Set에 itemId를 저장  이후 쿠키를 이용해 중복 접근 체킹 및 조회수 증가 진행

 

 - 서버에 저장되있던 쿠키에 대한 set 초기화(사용자의 아이템 별 접근 기록 초기화)

 

 

😐조회수 매번 업데이트 시켜야할까요?

중복 접근은 제거했지만 이제 성능적인 문제를 야기할 수 있는 게시글이 조회될 때마다 업데이트 쿼리가 나간다는 문제점이 남아있습니다. 제가 선택한 방법은 아래와 같습니다. 

 

- Redis에서 itemId로 조회수를 저장 -> 일정 시간 후 DB반영 

 

😐최종 흐름