같은 데이터를 두 번 읽어보세요.

01

없으면 가져와서 넣어 둡니다.

조회했을 때 캐시에 값이 없으면 원본에서 읽어 온 뒤 캐시에 저장하고 돌려줍니다. 다음 조회부터는 원본까지 가지 않으므로 훨씬 빠릅니다. 화면이 첫 조회와 재조회의 경로를 다르게 그리는 것이 이 차이이고, 응답 시간 표시도 함께 달라집니다.

02

빠른 이유는 저장 위치입니다.

캐시가 빠른 것은 알고리즘이 특별해서가 아니라 값을 메모리에 두기 때문입니다. 디스크를 거치지 않으므로 조회 한 번에 드는 시간이 크게 줄어듭니다. 대신 담을 수 있는 양이 제한되고, 전원이 꺼지면 사라지므로 원본을 대신할 수는 없습니다.

03

값이 바뀌면 어긋납니다.

원본을 고쳤는데 캐시에 예전 값이 남아 있으면 조회는 옛 값을 돌려줍니다. 오류가 아니라 캐시가 원래 그렇게 동작하는 것인데, 이 구간이 얼마나 길어도 되는지를 정하는 일이 캐시 설계의 핵심입니다. 화면에서 값을 바꾼 직후 조회해 보면 이 상황을 바로 만들 수 있습니다.

04

만료 시간이 어긋남의 상한입니다.

저장할 때 유효 시간을 함께 정해 두면 그 시간이 지난 뒤에는 캐시가 답하지 않고 다시 원본을 읽습니다. 그래서 원본과 어긋나 있을 수 있는 최대 시간이 이 값으로 정해집니다. 짧게 잡으면 어긋남은 줄지만 원본에 가는 횟수가 늘고, 길게 잡으면 반대가 됩니다.

05

고칠 때 지우는 방법도 있습니다.

만료를 기다리는 대신 원본을 고치는 시점에 캐시를 지워 버리면 다음 조회가 곧바로 새 값을 가져옵니다. 어긋나는 구간이 훨씬 짧아지지만, 고치는 코드가 캐시의 존재를 알아야 하고 지우는 것을 빠뜨리면 문제가 다시 생깁니다. 화면에서 두 방식을 모두 실행해 볼 수 있습니다.

06

명령을 그대로 보여줍니다.

화면의 동작이 버튼 뒤에 숨어 있으면 실제 코드로 어떻게 옮기는지 연결되지 않습니다. 그래서 각 단계에 대응하는 명령을 그대로 노출하고 직접 입력할 수도 있게 했습니다. 여기서 익힌 명령 이름과 순서가 실제 사용 환경에서 그대로 쓰입니다.

07

동시 요청도 재현합니다.

캐시가 비어 있는 순간에 요청이 여러 개 몰리면 모두 원본으로 가게 됩니다. 값이 하나만 필요한데 원본을 여러 번 읽는 셈이고, 원본이 감당하기 어려운 상황이면 이것 자체가 사고가 됩니다. 화면에서 이 상황을 만들어 볼 수 있게 해 둔 것은 캐시가 항상 부담을 줄여 주지는 않는다는 점을 보이기 위해서입니다.

08

적중률이 효과를 정합니다.

캐시에서 답한 비율이 높아야 실제로 빨라집니다. 같은 값을 반복해서 조회하는 경우에는 효과가 크지만, 매번 다른 값을 찾는다면 캐시를 채우기만 하고 쓰지는 못합니다. 화면에서 같은 키를 반복 조회할 때와 다른 키를 조회할 때의 경로가 어떻게 달라지는지 비교해 보면 이 차이가 드러납니다.

09

원본이 진실입니다.

캐시에 있는 값과 원본의 값이 다를 때 맞는 것은 언제나 원본입니다. 캐시는 원본을 빠르게 다시 보여주기 위한 사본일 뿐이고, 사라져도 서비스가 동작해야 합니다. 캐시가 없으면 조회가 실패하도록 만들어 두면 그 순간부터 캐시가 장애 지점이 되므로, 비어 있을 때도 원본으로 갈 수 있는 경로를 남겨 두어야 합니다.

10

무엇을 담을지가 먼저입니다.

모든 것을 캐시에 넣으면 메모리가 금세 차고 정작 자주 쓰는 값이 밀려납니다. 자주 조회되면서 자주 바뀌지 않는 것이 캐시에 가장 잘 맞고, 반대로 매번 달라지는 값은 넣어 봐야 도움이 되지 않습니다. 화면에서 시나리오를 몇 가지로 나눠 둔 것도 대상에 따라 결과가 달라진다는 점을 보이기 위한 것입니다.