검색 결과와 DB가 다를 때

목록 검색이 느려서 검색 전용 색인을 따로 두고 검색은 그쪽에서 하게 했다. 빨라진 대신 같은 데이터가 두 곳에 있는 상태가 됐고 그때부터 다른 문제가 시작됐다.

Open Table of contents

어긋나는 세 순간

색인은 데이터베이스 변경을 따라 갱신되므로 그 사이에 틈이 생긴다. 상품을 등록하면 데이터베이스에는 바로 들어가는데 검색에는 몇 초 뒤에 나오므로 사용자는 등록했는데 안 보인다고 한다.

삭제는 더 곤란한데 검색 결과에는 나오는데 클릭하면 없는 상태가 된다. 색인 갱신이 실패하면 데이터베이스만 바뀐 채로 남는데 사용자 요청은 이미 성공으로 끝난 뒤라 그 실패가 사용자에게 안 보인다.

등록하고 목록으로 돌아가는 화면은 검색이 아니라 최근 등록 순이므로 색인이 필요 없어서 데이터베이스에서 조회하게 했다. 삭제만은 색인 갱신을 기다리게 했는데 나머지는 나중에 반영돼도 되지만 삭제된 것이 보이는 것은 곤란하기 때문이다.

검색으로 얻은 목록을 화면에 뿌리기 전에 데이터베이스에서 한 번 더 확인해 색인에 있는데 없는 것은 뺐다. 검색을 빠르게 하려고 색인을 뒀는데 결국 데이터베이스를 또 보는 셈이지만 확인만 하는 것이라 무겁지 않았다.

밀려 있다는 것을 알아야 대응할 수 있으므로 처리 대기 개수와 최근 갱신 시각 둘을 봤다. 두 번째가 더 정확했는데 개수가 적어도 오래된 것이 안 처리되면 문제이기 때문이다.

기준을 넘으면 알림이 오게 했는데 처음에 기준을 잘못 잡아서 새벽 배치가 돌 때마다 알림이 왔다. 배치는 원래 색인을 몰아서 갱신하므로 밀리는 것이 정상이라 정상적으로 밀리는 시간대를 빼고 기준을 다시 잡았다.

색인이 크게 어긋나면 다시 만들어야 하는데 처음에는 전체를 지우고 다시 넣었다가 그 사이 몇 분 동안 검색이 비었다. 지금은 새 색인을 따로 만들어 다 채운 뒤 가리키는 별칭을 바꾸고 옛 색인을 지운다.

별칭을 바꾸는 것이 순간적으로 일어나므로 사용자가 못 느낀다. 색인에 무엇을 넣을지도 정했는데 검색 조건에 쓰이는 것과 목록에 보이는 것만 넣고 상세 내용은 상세 화면에서 데이터베이스로 가져온다.

갱신 실패를 어떻게 복구할지가 아직 어렵다. 실패한 것을 기록해 두고 나중에 다시 넣는데 그것이 밀리면 어긋난 채로 오래 간다.

색인 구조를 바꾸려면 전체를 다시 만들어야 하는 것도 남아 있는데 필드 하나 추가에 몇 시간이 걸리기도 한다. 두 곳의 값이 다를 때 데이터베이스가 맞다는 것은 분명하지만 그러면 색인의 값 필드가 왜 필요한지가 애매하게 남았다.