쓰기 통과와 쓰기 지연

읽기는 끝났다. 이제 쓰기다

앞의 두 강의는 전부 읽기였습니다. 읽기는 쉽습니다. 몇 번을 읽어도 세상은 변하지 않으니까요.

쓰기는 다릅니다. 쓰기는 세상을 바꿉니다. 그리고 캐시가 옆에 있으면 즉시 질문이 생깁니다.

사용자가 상품 42번의 가격을 바꿨다. 그럼 캐시에 적어둔 옛날 가격은 어쩌지?

선택지는 셋입니다.

세 가지 정책

쓰기 통과 — 둘 다 쓰고 나서 대답한다

가장 정직합니다. 캐시와 원본 양쪽에 다 쓰고 나서 "저장했습니다"라고 말합니다. 캐시는 항상 최신이고, 방금 쓴 값을 바로 읽어도 맞습니다.

대가는 속도입니다. 두 곳에 다 쓸 때까지 사용자가 기다립니다. 그리고 거의 안 읽히는 항목까지 캐시에 밀어 넣습니다. 로그성 데이터를 쓰기 통과로 캐시하면 캐시가 쓰레기로 가득 찹니다.

쓰기 우회 — 지우고 원본에만 쓴다

실무에서 가장 흔한 기본값입니다. 캐시의 해당 항목을 지우고, 원본에만 씁니다.

캐시에 틀린 값을 남기지 않고(지웠으니까), 안 읽힐 데이터를 캐시에 넣지도 않습니다. 대신 방금 쓴 항목을 다음에 읽으면 반드시 미스입니다. 그건 대체로 감당할 만합니다.

쓰기 지연 — 일단 접수하고 나중에 기록한다

여기가 이 강의의 진짜 주제입니다.

캐시(또는 빠른 어딘가)에만 쓰고 즉시 "저장했습니다"라고 답합니다. 원본에는 나중에, 여유가 있을 때 씁니다.

압도적으로 빠릅니다. 사용자는 느린 데이터베이스를 기다리지 않습니다. 그런데 "저장했습니다"가 거짓말이 될 수 있는 창이 생깁니다. 그 사이에 캐시가 죽으면 데이터는 그냥 사라집니다. 사용자는 저장됐다고 믿고 있는데요.

두 개의 다른 약속

이 강의에서 하나만 가져간다면 이것입니다.

"접수했습니다"  ≠  "처리했습니다"

택배 접수증과 배송 완료 문자는 다른 약속입니다. 접수증은 즉시 나오지만 물건이 도착했다는 뜻은 아닙니다.

쓰기 지연은 사용자에게 접수증을 주는 것입니다. 그게 나쁜 게 아닙니다. 많은 경우에 그게 옳습니다. 문제는 접수증을 주면서 배송 완료라고 말하는 것입니다.

어디에 무엇을 쓰나

이 표를 채우는 건 기술자가 아니라 업무 담당자입니다. "이 데이터가 사라지면 얼마나 큰일인가"는 기술 질문이 아니기 때문입니다.

시스템 규모의 쓰기 지연

쓰기 지연의 아이디어는 캐시 안에만 있지 않습니다. 같은 생각을 시스템 전체로 키우면 이렇게 됩니다.

사용자 → 서버 → [접수함] → (나중에) 처리 담당 → 데이터베이스
                   ↑
            여기서 "접수했습니다" 응답

접수함에 넣는 것은 매우 빠릅니다. 그래서 몰리는 순간을 흡수합니다. 초당 200건이 갑자기 들어와도, 데이터베이스가 초당 133건밖에 못 써도, 접수함이 받아 두고 천천히 흘려보내면 아무도 오류를 보지 않습니다.

대신 접수함에 쌓인 일이 처리되기까지 시간이 걸립니다. 화면은 멀쩡한데 실제 처리가 몇 분 밀려 있을 수 있습니다. 이 밀림을 지켜보지 않으면 조용히 사고가 납니다.

직접 해보세요

아래 과제는 이 아이디어를 시스템 규모로 옮긴 것입니다. 쓰기가 몰리는 구간에서 데이터베이스가 감당하지 못해 요청이 버려집니다. 접수함과 처리 담당을 두어 몰리는 구간을 흡수하세요. 그리고 통과한 뒤에는 접수함에 얼마나 쌓였는지 꼭 확인해 보세요. 그것이 이 구조의 진짜 대가입니다.