Today I Learned
날짜
2024년 7월 10일 수요일
내용
데이터 상태 처리
가져올 데이터가 많다보니, 처리에 시간이 꽤 걸린다. 따라서 유저에게 요청에 대한 응답을 보낸 후, 백그라운드에서 처리되야 한다. 대신 계속 유저에게 상태값을 알려줘야 한다. 기존에는 로우데이터가 가지는 상태의 종류는 두 가지였다.
유저가 로우 데이터 포맷을 만들면, 즉시 데이터를 임포팅해온다. 유저는 이 임포팅 상태를 알아야 한다. 진행 중인지, 대기중인지, 뭔가 잘못되서 실패했는지, 완료했는지를 임포팅 상태라고 부르고 관리하기로 했다. 위에서 말했듯, 요청은 꽤 많은 데이터를 주고 받는 작업이기 떄문에 동시에 하나씩만 처리하기로 했다. 유저가 짧은 시간내에 여러개의 로우데이터 포맷을 만들더라도 하나만 진행하고 나머지는 대기열에 두어야 한다. 클라이언트는 서버에 어떤 로우데이터 포맷의 임포팅 상태를 묻고, 서버는 그 상태를 반환하되 대기열이 있다면 대기열을 보내주도록 구현했다.
또 하나의 상태는 업데이트 상태다. 각 로우데이터 포맷은 매일 오전에 자동으로 업데이트된다. 네이버 검색광고 데이터가 갱신되는 시점이 그때기 떄문이다. 최근 자동 업데이트가 제대로 진행됐는지, 문제가 있었는지를 말해주는 업데이트 상태도 표시해야 한다.
예상치 못한 부분이 있었는데, 스프레드시트를 생성하는 부분이다. 로우데이터 포맷을 생성하면 유저의 구글 드라이브에 스프레드 시트 파일을 생성해주어야 한다. 이 요청이 약 8초정도 소요된다. 우선 특정 이름으로 스프레드시트를 만들고, 내부에 시트파일을 생성한다. 필요한 열(보통 9~13열정도)을 제외하곤 삭제한뒤 행을 20만행으로 늘려주는 작업을 하다보니 8초가 걸린다. 우리가 설정한 행 제한이 20만이기 떄문이다. 기본 행의 갯수인 1000개로 두면 넣을 떄 자동으로 연장되지 않는다. 따라서 각 시트별로 180만~260만 셀을 가지게 된다. 하나의 스프레드시트에 있는 시트파일들의 셀 갯수는 총합이 1000만개를 넘을 수 없다.
따라서 우선 데이터를 생성하고, 스프레드시트 파일을 생성하는 작업도 백그라운드로 진행하기로 했다. 하지만 실패할 가능성도 있기 떄문에, 스프레드시트 와 관련된 상태도 추가해주었다. 파일 생성중인지, 파일 생성에 실패했는지, 잘 생성됐는지를 표시한다. 만약 생성에 실패했다면 유저가 재시도할 수 있게 해주어야 한다. 재시도 할 떄 다시 파일 위치를 설정하지 않도록, 데이터베이스에 유저가 저장하려고 한 구글 드라이브 폴더값을 저장해야 했다.
로직이 상당히 복잡하고, 생각하지 못한 로직상 구멍을 뒤늦게 꺠닫고 있어서 코드가 많이 복잡해지고 있다..
회고
나야 만든사람이지만, 다른사람이 이 코드를 이해할 수 있을까…? 리팩토링 필수.
