주먹구구식 개발 일기

한국기상산업기술원의 2020 기상기후 청년창업지원사업에 선정되어 현재 프로젝트를 진행하고 있는데

인턴하랴 한이음하랴 도무지 제대로 집중할 시간이 안나지만

그래도 팀장이기 때문에 어떻게든 완성시켜야한다

 

프로젝트 기한이 8/20까지 인지라 개발은 끝마쳐야겠고...

지금까지 만든 것도 거의 없는지라 

설계고 뭐고 그냥 생산성에 몰빵한 개발을 진행중

필요할 때마다 그때 그때 모듈과 함수를 만들어서 사용하고 있다.

 

서버 프레임워크는 역시 생산성의 쟝고를

DB로는 MySQL과 기상데이터 저장은 별개로 MongoDB를 이용해 저장하고 있다.

 

기상청의 Open API 전국 도시(육상지점코드)의 날씨를 데이터로 받아와

이를 이쁘게 잘 만들어서 저장을 해야하는데

 

1일 단위, 2~3일, 그 이후부터 ~10일까지 모두 다른 API를 통해 얻을 수 있기 때문에 

각각, 동네예보, 동네예보통보문, 중기예보 API를 이용하여 날씨 데이터를 받아온다.(아닐수도 있음)

 

CSV로 미리 이쁘게 만들어놓은 지점코드 리스트를 통해 API를 호출하는데

또 여기서 문제가

중기예보의 경우에는 날씨정보와 기온정보를 별도의 API 서비스로 제공하고

또 날씨 지점코드와 별개로 몇몇 지점코드가 통합되어진 기온 지점코드를 통해 해당 데이터를 얻을 수 있다.;;;;;

(예를 들어 서울+인천+경기권이 통합되어 하나의 기온 지점코드로 통용)

 

그렇기에 해당 날씨 지점코드에 따른 기온 지점코드를 리턴해주는 변환 함수도 만들어주고....

이를 통해 중기 날씨 데이터를 만들고 있다.

 

근데 여기서 날씨 지점코드는 통용되기 때문에 중복해서 API를 호출하는 문제가 발생

 

-> 날씨 지점코드는 통합되어있어서 저장하는데 많은 메모리를 필요로 하지 않기 때문에

간단한 dict개체를 이용해서 캐싱을 구현했다.(이렇게 막 해도 되는지는 모르겠지만 일단 잘 된다.)

이를 통해서 조금이라도 Network I/O를 줄일 수 있지 않을까..?

 

그냥 cache.get(지점코드, None)을 이용해서 None이 아니면 Cache Hit한 걸로 치고 API를 호출하지 않는다.

 

이렇게 힘들게 만들어낸 전국의 날씨 레코드를 MongoDB에다가 bulk_write를 이용해서 한번에 저장시킨다.

여기서 날씨 데이터는 날씨 예보가 갱신되는 시간마다 갱신되기 때문에 upsert연산을 이용했다.

 

해당 코드를 모두 작성하고 나서

테스트를 위해 mongo콘솔에 해당 컬렉션에 대해서 전체 find()를 했더니 엥?

초기 레코드 몇개만 출력되고 끝

 

대체 뭐가 문젠지 이리저리 로그도 찍어보고 테스트도 했지만 

도무지 문제를 찾을 수 없었다.

30분 정도 씨름하고 나서야 그냥 너무 레코드가 많아 잘려서 출력된 것임을 깨달을 수 있었다.

 

정말 멍청했던 하루...

 

이러한 작업은 매 예보의 갱신시간마다 진행되기 때문에

crontab으로 등록해서 해당 시간마다 자동적으로 호출되게끔 등록해주면 끝

 

별거 아닌 작업이지만 주먹구구식으로 개발하려다 보니 오히려 더 오래걸린 것 같다