검색 한 번에 디스크 260MB: 데이터가 쌓이면 느려지는 화면을 고친 기록

검색 한 번에 디스크를 약 260MB 읽었습니다. 보드게임 기록 앱 RankBoard에서 두 글자짜리 검색이 반복되자 데이터베이스의 입출력 한도가 바닥났고, 서비스 전체가 멈췄습니다. 데이터가 쌓일수록 느려지는 화면은 대부분 "조회 한 번에 읽는 양"이 데이터와 함께 늘어나는 구조에서 생깁니다.

두 글자 검색이 서비스를 멈춘 과정

RankBoard에는 보드게임 17.3만 건을 검색하는 기능이 있습니다. 사용자가 게임 이름을 두 글자쯤 입력하면 결과가 나옵니다. 이 검색이 실행될 때마다 데이터베이스는 17.3만 행을 처음부터 끝까지 읽고 있었습니다. 개발자들은 이것을 풀스캔이라고 부릅니다.

행이 적을 때는 문제가 드러나지 않았습니다. 검색이 반복되자 디스크 읽기량이 클라우드 데이터베이스의 입출력 한도를 다 써 버렸습니다. 그 순간부터 검색과 상관없는 기능까지 함께 멈췄습니다.

무엇을 바꿨나요?

처음에는 검색 조건을 바꾸는 쪽을 생각하기 쉽습니다. 실제로 효과가 컸던 것은 한 번에 읽는 대상을 얇게 만든 일입니다.

• 먼저 조건에 맞는 게임의 번호(id)만 뽑습니다. 번호만 담긴 작은 색인에서 찾기 때문에 디스크를 거의 읽지 않습니다.
• 그다음 뽑힌 번호에 해당하는 행만 가져와 화면에 필요한 정보를 채웁니다.
• 검색에 필요한 칸만 모아 둔 색인을 따로 만들었습니다. 개발자들은 이것을 커버링 인덱스라고 부릅니다. 책 전체를 넘기지 않고 뒤쪽 찾아보기만 보고 답을 찾는 것과 비슷합니다.

디스크 읽기가 0이 된 것은 필요한 정보가 이미 메모리에 올라와 있는 작은 색인에서 검색이 끝나기 때문입니다.

TIP빠르다는 시연을 볼 때 "지금 데이터가 몇 건인가요?"를 함께 물어보세요. 100건에서 빠른 검색과 10만 건에서 빠른 검색은 다른 이야기입니다.

업무 자동화에서는 어디서 이런 일이 생기나요?

회사 업무 자동화에도 계속 늘어나는 표가 있습니다. 품목 마스터, 거래처 목록, 주문 이력, 처리 기록 같은 것들입니다. 처음 만들 때는 몇천 건이라 어떤 구조로 만들어도 빠릅니다. 1~2년 쓰면 주문 이력은 수십만 건이 됩니다.

발주서 → ERP 전표 데모를 예로 들면, 발주서의 품목명을 품목 마스터에서 찾아 코드를 맞추는 단계가 있습니다. 발주서 한 장에 줄이 20개라면 검색이 20번 일어납니다. 하루 발주서가 50장이면 1,000번입니다. 검색 한 번이 표 전체를 읽는 구조라면 품목이 늘어날수록 처리가 눈에 띄게 느려집니다.

만들 때 미리 확인하는 것

루코 웍스는 자동화를 만들 때 다음을 확인합니다.

늘어나는 표를 먼저 표시합니다. 어떤 표가 매일 늘고, 1년 뒤 몇 건쯤 될지 대략 적어 둡니다. 품목 마스터처럼 잘 늘지 않는 표와 주문 이력처럼 매일 늘어나는 표는 다르게 다룹니다.

자주 찾는 칸에 색인을 둡니다. 품목코드, 주문번호, 거래처코드처럼 매번 찾는 칸에는 처음부터 색인을 만듭니다.

큰 데이터로 한 번 돌려 봅니다. 실제 데이터의 몇 배를 넣고 같은 처리를 돌려 시간을 잽니다. 이때 느리다면 데이터가 실제로 쌓이기 전에 고칠 수 있습니다.

오래된 기록은 따로 둡니다. 매일 보는 화면은 최근 몇 달 치만 읽고, 오래된 기록은 따로 보관해 필요할 때만 꺼냅니다.

정리하면

RankBoard의 검색 장애는 "1년 뒤에도 같은 속도인가요?"라는 질문을 늦게 던져서 생긴 일이었습니다.