구글 스프레드시트 업데이트 요청의 timeout

2024년 11월 28일 목요일

Today I Learned

날짜

2024년 11월 28일 목요일

내용

중복

잘 되는 줄 알았는데… 중복 데이터가 나타난다는 테스터의 제보를 받았다. 딱 데이터 생성시점을 기준으로 30일 전 ~ 40일 전이 문제가 되었다.

아임리포트에서 데이터를 업데이트할 때는, 최근 30일 데이터만 가져오고 나머지는 S3에서 가져온다. 이걸 40일로 수정했는데 혹시나 S3에 누락된 데이터가 발생할 수 있기 때문이다. 그래서 40일치를 가져오고, 그중 30~40일 사이 데이터를 S3에 저장해서 혹시나 빈 것이 있더라도 잘 채워지도록 해놨다.

이 코드가 문제가 되었는데 (네이버 에서 가져온 1~40일차 데이터) + (S3에서 가져온 31~365일차 데이터)가 합쳐지면서 31~40일 차가 데이터가 두번 들어가게 되었던 것.. S3에서 가져올 때, 30~41일차의 데이터는 빼도록 바꿔져서 해결했다.

구글도 버겁다.

구글이 말을 듣지 않는 케이스가 발생했다.. 데이터 처리에는 이상이 없는데, 마지막 스프레드시트에 삽입할 때 자꾸 timeout이 발생한다.

1

이 문제를 한참 겪을때, 지연시간이 무려 3.5분으로 치솟는 이 그래프를 보면 어처구니가 없다.. 도대체 원인이 뭘까! 하고 찾다가 스택 오버플로우에서 누군가가 “난 시트가 좀 크면 항상 그러더라?”라는 댓글을 봤다. 아차 싶어 보니 문제가 되는 스프레드시트는 무려 행이 40만이었다.. 데이터가 없이 빈 셀이더라도 시트 입장에선 어쩄든 용량이다. 혹시나 싶어 스프레드시트에 비어있는 행을 30만개 가까이 삭제하고 재시도하니 무슨일이 있었냐는 듯 잘 된다.

혹시 종종 업데이트가 너무 느려지는 게 이 원인은 아닐까 싶다! 그동안 “행을 초기화”하는 로직은 없었다. 어제 데이터 7만개 생성 ⇒ 7만행 추가 ⇒ 다음날 데이터 다 지우고 7만행 생성 ⇒ 7만행 추가 의 반복이었다. 따라서 시트 전체의 행은 7만, 14만, 21만 점차 늘어났을테고, 지연시간은 점차 늘어났을 것이다.이 부분이 꼭 해결책이었으면 좋겠다..

회고

  • 목요일 배준수 출근 1인칭 시점

    2

눈이 많이 왔다. 5시 20분에 집에서 나왔다. 회사에 도착하니 9시 5분이었다. 얏호