캐시 key 구성 변경으로 오버엔지니어링 줄이기

왜 지금까지 이 생각을 못했지? 싶을 정도로 당연하고 별 거 아닌 일이지만, 조금만 꼬아 생각해도 큰 차이가 생긴다는 깨달음을 얻은 경험이므로 짧은 글로 남겨보았다.

아래 사진은 이전에 작성했던 medium 글이다.

위 내용을 위해 날씨 데이터 조회 횟수가 많은 지역의 정보가 필요했다. 이를 위해서는 호출 위치 로그를 수집해야 했다.

뿐만 아니라 데이터 변경 시간 이후 불일치 문제를 해결하기 위해, 기상청 데이터 업데이트 시간에 맞추어 스케줄러로 캐시 데이터를 업데이트해주는 작업도 필요했다.

hit될지도 모르는 데이터를, 아직 캐시에 남아있다는 이유만으로 외부 서버에 재요청하여 업데이트하는 것이 지금 생각해보면 매우 비효율적인 작업이었다.

이런 비효율적인 작업들을 단순히 key 구성을 변경함으로서 깔끔하게 정리할 수 있었다.

api 호출 baseTime을 key에 추가하여 hit될 경우 무조건 최신 데이터임을 보장할 수 있도록 했다.

이전에는 ultraSrtNcst:55,123 이라는 key를 가진 데이터가 11시 40분의 데이터였다면, 11시 50분 이후에 사용하기 위해서 50분에 해당 데이터를 업데이트해주어야 했다.

변경된 방식에서는 baseTime을 추가하여 ultraSrtNcst:55,123:1150이라는 key를 사용하므로, 11시 40분에 생성된 데이터를 가져올 일이 없다. 11 50분에 생성된 해당 지역의 최신 데이터가 캐시에 없다면 새로 조회하여 저장한다.

key에 baseTime만 추가하는 아주 사소한 작업으로 스케줄링, 호출 횟수 카운팅, 캐시 업데이트 작업을 모두 생략할 수 있었다.