들어가며

REST API 를 깊이 공부하며 RESTful 아키텍처 제약사항에 대해서 알게되었다. 그 중 Cacheable 조건에 대해서 처음 알게 되었는데, 요청에 대한 서버의 응답에 데이터가 캐시 가능한지 불가능한지 명시해야 하는 조건이다. HTTP 헤더 중 Cache-Control 이라는 헤더를 활용하면 되는데, 브라우저가 캐시를 저장하고 활용할 수 있도록 도와주는 표준 헤더이다. 이걸로 브라우저가 알아서 캐싱할 수 있도록 설정할 수 있다.

브라우저 캐시와 ETag

웹 브라우저의 캐시는 처음 구현해 보기 때문에 정리해보았다. HTTP 헤더 중 Cache-Control 이라는 헤더를 활용하면 캐시를 제어할 수 있다. 그렇지만 데이터를 잘못 캐시하게 되면 데이터의 불일치가 발생할 수 있으므로 캐시 검증도 같이 수행해야 한다. 검증을 위한 헤더가 ETag 이다.

• Cache-Control 헤더 : 캐시의 유효기간을 명시하는 응답 헤더.

• ETag 헤더 : 특정 버전의 리소스를 식별하는 고유 식별자. 서버는 데이터가 변경될 때 마다 새 ETag 를 생성한다.

ETag 만드는 방법

ETag 는 응답 데이터의 내용이 바뀌면 새로운 값을 생성하도록 해야 한다. (그래야 데이터가 변경되었는지 여부를 쉽게 판단할 수 있다) 따라서, ETag 는 다음 요소를 기반으로 생성할 수 있다.

1. 응답 데이터 자체

   • 예 : products.toString()

2. 데이터의 마지막 수정 시각

   • 예 : products.getUpdatedAt()

3. 데이터 자체를 해시화한 값

   • 예 : MD5, SHA-256 등 해싱 알고리즘 사용

이 중에서 해시값을 사용하는 것이 ETag 를 짧고 효율적으로 운용할 수 있어 3번을 선택했다. (참고로… MD5 와 SHA-256 의 차이는 해당 글을 참고하도록 하자…) 일반적으로 MD5 보다 SHA 방식이 속도는 느리지만 안전하므로, SHA 를 활용하여 해싱해보자 !

@GetMapping("/products")
public ResponseEntity<List<Products>> getAllProducts(HttpHeaders headers) {
    try {
        // 1️⃣ 조회할 데이터
        List<Products> products = productsService.findAll();

        // 2️⃣ ETag 생성 (SHA-256 해싱)
        String data = objectMapper.writeValueAsString(products);
        String etag = "\"" + generateSHA256ETag(data) + "\"";

        // 3️⃣ If-None-Match 헤더와 비교하여 304 응답
        if (etag.equals(headers.getFirst(HttpHeaders.IF_NONE_MATCH))) {
            return ResponseEntity
                    .status(HttpStatus.NOT_MODIFIED)
                    .eTag(etag)
                    .cacheControl(CacheControl.maxAge(10, TimeUnit.MINUTES))
                    .build();
        }

        // 4️⃣ 새로운 데이터를 반환
        return ResponseEntity.status(200)
                .eTag(etag)
                .cacheControl(CacheControl.maxAge(10, TimeUnit.MINUTES))
                .body(products);

    } catch (JsonProcessingException e) {
        e.printStackTrace();
        return ResponseEntity.status(500).build();
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
        return ResponseEntity.status(500).build();
    }
}

이렇게 했을 때, 데이터에 변경이 없다면 브라우저는 304 응답을 반환한다.

웹 캐시의 한계 ?

그런데 조금 거슬리는 부분이 있었는데, 브라우저 캐시를 설정해놔도 서버 입장에서는 캐시된 데이터에 변경이 있는지 알아보려면 결국 DB 를 또 조회해서 ETag 를 생성해 비교해야 한다. DB 조회를 최대한 줄이기 위해 캐시를 사용하는 것인데, 이렇게 되면 도루묵 아닌가? 싶었다… 그래서 웹 캐시를 운용함과 동시에 redis 를 활용한 서버 캐시도 같이 운용하면 완벽할 것 같다는 생각이 들었다. 다음 시간에 계속 알아보자 !

🔖 참고자료

웹 브라우저의 Cache 전략 & 헤더 다루기