로컬 캐시 vs 분산 캐시

데이터의 성격으로 나눕니다.

마지막 줄을 자주 놓칩니다. 사용자별 데이터를 로컬에 두면, 그 사용자가 다른 서버로 가는 순간 캐시가 없습니다. 서버가 10대면 적중률이 10분의 1이 됩니다.

로컬의 값은 네트워크 왕복이 없다는 것이고 대가는 서버마다 다를 수 있다는 것입니다. 분산은 반대입니다. 그래서 질문은 늘 같습니다. 이 데이터가 서버마다 잠깐 달라도 되는가.

흔한 실수: 빠르다는 이유로 로컬을 기본값으로 두는 것. 같은 사용자가 새로고침할 때마다 값이 오가는 증상이 나오고, 원인을 찾기 어렵습니다. 어긋나도 되는지를 먼저 정하고 그 다음에 속도를 봅니다.

로컬 캐시는 원격에서 지울 수 없습니다. 그래서 셋 중 하나를 고릅니다.

첫 번째가 기본값이어야 합니다. 가장 단순하고 실패할 부품이 없습니다. 수명을 몇 초로 잡으면 대부분의 경우 충분합니다.

알림 방식은 발행 구독 통로를 씁니다. 다만 알림이 유실되면 그 인스턴스만 옛 값을 계속 들고 있습니다. 그래서 알림을 쓰더라도 수명을 함께 두어야 합니다. 알림은 빠르게 맞추는 수단이고, 수명은 최악을 막는 안전장치입니다.

배포도 고려해야 합니다. 인스턴스가 새로 뜨면 캐시가 비어 있어서, 배포 직후에 원본으로 요청이 몰립니다. 인스턴스를 한 번에 다 바꾸지 않는 것으로 완화합니다.

흔한 실수: 알림만 믿고 수명을 길게 잡는 것. 알림 한 번이 유실되면 그 인스턴스는 수명이 다할 때까지 틀린 값을 줍니다. 유실을 전제로 상한을 둡니다.

로컬을 짧게, 공용을 길게 둡니다. 역할이 다르기 때문입니다.

로컬 수명이 곧 사용자가 볼 수 있는 최대 지연입니다. 값이 바뀐 뒤 로컬 수명만큼은 옛 값이 나올 수 있습니다. 그래서 그 데이터가 몇 초까지 틀려도 되는지가 그대로 숫자가 됩니다.

공용을 길게 두는 이유는 원본 보호입니다. 로컬이 만료돼도 공용이 받아 주면 원본까지 안 갑니다. 두 계층이 동시에 만료되면 그 보호가 사라지므로, 로컬 수명이 공용 수명의 약수가 되지 않게 하고 약간의 무작위를 섞습니다.

값을 고칠 때는 공용을 먼저 지우고 로컬은 수명에 맡깁니다. 순서를 뒤집으면 로컬이 지워진 직후 공용의 옛 값을 다시 읽어 와 로컬이 옛 값으로 채워집니다.

흔한 실수: 두 계층에 같은 수명을 주는 것. 그러면 함께 만료돼 원본으로 한꺼번에 몰리고, 2단계로 나눈 이득이 사라집니다.

로컬 캐시는 오래 살아남는 객체를 많이 만듭니다. 그래서 수집기가 가장 싫어하는 모양입니다.

마지막 줄이 가장 흔한 사고입니다. 크기 상한이 없는 캐시는 캐시가 아니라 메모리 누수입니다. 개수든 용량이든 상한을 반드시 둡니다.

정지 시간이 문제라면 캐시 크기를 줄이는 것이 먼저입니다. 수집기 옵션을 만지는 것보다 살아 있는 객체를 줄이는 쪽이 확실합니다. 큰 데이터를 굳이 로컬에 둘 이유가 있는지 다시 봅니다.

만료가 몰리는 것은 수명에 무작위를 섞어 흩습니다. 같은 순간에 채워진 항목이 같은 순간에 버려지면 그때 부담이 집중됩니다.

흔한 실수: 힙이 남으니 캐시를 크게 잡아도 된다고 보는 것. 힙이 커질수록 한 번의 수집이 훑을 것이 늘어 정지 시간이 길어집니다. 응답 지연의 상위 구간이 그 시간에 그대로 얹힙니다.