Java 대용량 엑셀 업로드

티몬에서 엑셀 업로드로 서버가 다운된 장애를 겪고 POI Workbook 방식에서 SAX 방식으로 바꾼 기록이다. 요청이 많아야 2~3만 건이라 그 규모로 테스트하고 운영했는데, 연말에 요구사항이 쌓이면서 담당자가 50만 건짜리 파일을 업로드했고 엑셀을 읽던 중 서버가 죽었다. 소량 처리에만 신경 쓰다 대량이 들어오니 드러난 문제였다.

핵심 포인트

Workbook은 전체 데이터를 한 번에 읽어 처리하므로 Row 수 기준 제한을 걸 수 없고, 용량으로만 제한할 수 있는 상황이었다.
3~5만 건을 기준으로 처리 속도가 급격히 떨어져, 최대 10만 건까지 문제없이 처리하려면 다른 방법이 필요했다.
문제는 매일 3~5천 건, 많아야 2~3만 건만 들어와서 건수에 따라 느릴 뿐 서버가 죽는 일이 없었던 것이지, 문제점 자체는 계속 안고 있었다는 점이다.
SAX 방식은 데이터를 순차적으로 읽어 내려가며 노드의 시작과 끝에서 이벤트를 발생시킨다.
문서 전체를 메모리에 올리지 않아 메모리 사용량이 적고 단순 읽기에서 빠른 속도를 보인다.

상세 정리

기능의 배경: 하루에도 몇십만 건씩 늘어나는 상품 정보를 관리자 사이트로 처리하기 힘들다는 문의를 받아, 엑셀 템플릿에 맞춰 업로드하면 일괄 처리되는 기능을 개발해 제공했다.
장애의 경위: 몇 달을 문제없이 쓰다가 연말에 쌓인 요구사항 때문에 한 번에 50만 건이 들어오면서 서버가 다운됐다.
원인 진단: POI 라이브러리의 Workbook으로 업로드된 엑셀 데이터를 변환하는 방식이 소량에서는 약간의 속도 차이만 있었지만, 대량에서는 변환 작업 중 문제를 일으켰다.
첫 대안의 좌절: 입력 가능 건수 제한을 걸어 그 이상이면 나눠 처리하도록 유도하려 했으나, Workbook 구조상 Row 수 기준 제한이 적용되지 않았다.
정리한 요건 셋: 엑셀 파일 정보를 2차원 데이터로 전환할 것, 최대 10만 건까지 처리 가능할 것, 최대 Row 수 제한을 걸 수 있을 것.
해법 발견: SAX 방식으로 엑셀 파일을 XML처럼 다루면 세 요건을 모두 충족할 수 있다는 점을 알게 돼 적용하기로 했다.
웹 서비스에서 중복된 유형의 데이터를 대량으로 입력받을 때 엑셀 파일 업로드가 흔히 쓰이는 방법이라는 전제에서 출발한다.

왜 읽나엑셀 업로드 기능을 소량 기준으로 만들어 두고 대량 입력에 노출된 백엔드 개발자에게, Workbook 방식의 구조적 한계와 SAX 전환의 근거를 실제 장애와 함께 보여준다.

티몬 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청