본문 바로가기
Project/명지대학교-입학관리팀챗봇-MARU_EGG

maru-egg 프로젝트 개발일지 - APIs 개선 & crontab으로 ec2에서 파일 파싱 자동화 스크립트 작성 & 스왑진행 & 도메인, https적용 & swagger오류 해결

by 지식을 쌓는 개구리 2024. 8. 11.

여는 글

꽤나 오랜 기간 개발을 쭉 진행하고 변경사항이 많이 쌓여, 어떤 점을 보완하고 어떤 기능을 개발했는지 기록하려 이 글을 쓰게 되었다.

기존의 수많은 retrieve, delete api들을 각각 1개씩으로 줄여 APIs개선을 진행하였고, maru-egg 프로젝트의 배포한 프론트 쪽과 통신하기 위해 maru-egg-llm 서버 역시 도메인을 구매해 적용하고 https적용을 진행하였다.

추가로 스왑도 진행하였다.

 

또한 https를 적용하는 가운데 swagger에서 오류가 발생하여 이를 해결하고 블로그로 포스팅해두었으며,

(아래 포스팅 참고)

https://choiet.tistory.com/70

 

배포한 프로젝트 https적용 후 swagger작동이 안되는 문제 해결방법

여는 글프로젝트 진행 중 배포한 리액트 쪽과 api테스트를 진행하기 위해서 프로젝트에 도메인 & https를 적용하였다.(리액트가 배포될 때 https로 진행되기에 백엔드도 https로 진행해야 통신이 가

choiet.tistory.com

=> 문제를 해결하면서 스웨거의 대한 작동방식, 구조를 더 자세히 알 수 있었다...

 

또한 파일을 업로드하고 이를 파싱 하는 과정이 도메인 특성상 양이 많고 복잡하여 오래 걸리기에,,

기존의 방식이었던, 파일을 올리면 그 즉시 파싱하여 데이터를 db에 저장하던 것에서 파일을 올리면 따로 파일을 저장해 두고

EC2의 crontab을 활용해 새벽 1시마다 파일이 존재할 경우 스케줄러로 자동 파싱되게 로직과 프로젝트 구조를 완전히 뜯어고쳤으며,

자동화 스크립트를 작성하였다.

 

위의 과정을 간략하게나마 소개하려 이 글을 기록한다.

 

APIs 개선

=> 다음과 같이 retrieve, delete api들을 각각 하나씩 통합하고 파라미터로 조절 가능하게 하여 api의 개수를 1/3로 줄였다...

기존에는 너무 효율적이지 못한 방식으로 진행했다.. 각각 3개씩 모두 만듦..

=> 이제는 type, category의 파라미터를 넣고 안 넣고의 차이로 데이터를 모두 삭제 or 가져오던지 특정 부분만 삭제 or 가져오는 게 가능해졌다.

 

스왑진행

=> 서버가 종종 다운되는 경우가 있어 스왑도 진행해 주었다.

=> 스왑 진행에 대해서는 이전에 따로 블로그를 작성해 두었기에 아래 포스팅을 참고 바란다.

https://choiet.tistory.com/67

 

스프링부트 EC2 배포 종결 + EC2 스왑적용으로 안전하게 build

여는 글멋쟁이사자처럼 해커톤을 준비하면서 스프링부트 프로젝트를 ec2-리눅스, 우분투 환경에서 여러번 & 다양한 방식으로 배포하다가가장 효율적이고, 안정적이며 쉽게 배포할 수 있는 방법

choiet.tistory.com

 

=> 잘 추가된 모습!

 

도메인 & https적용

=> 라우트53에서 도메인 구매 및 호스팅 영역설정을 진행해 주고,, 엔진엑스 설정을 진행하고,,

 

=> 렛츠인크립트로 ssl인증서 발급까지 완료했다.

 

최종, 도메인과 https를 작 적용하였다.

 

swagger오류 해결

위에서 기술했듯 https를 적용하고 스웨거가 작동하지 않는 오류가 발생해서

이를 해결하고 그 해결방법과 원인을 블로그로 따로 기술해 두었다.

이유가 궁금하면 아래 게시글을 방문해 보자.

https://choiet.tistory.com/70

 

배포한 프로젝트 https적용 후 swagger작동이 안되는 문제 해결방법

여는 글프로젝트 진행 중 배포한 리액트 쪽과 api테스트를 진행하기 위해서 프로젝트에 도메인 & https를 적용하였다.(리액트가 배포될 때 https로 진행되기에 백엔드도 https로 진행해야 통신이 가

choiet.tistory.com

 

crontab으로 ec2에서 파일 파싱 자동화 스크립트 작성

위에서 설명했듯 기존의 방식이었던, 파일을 올리면 그 즉시 파싱하여 데이터를 db에 저장하던 방식을 버리고

파일을 올리면 따로 파일을 저장해 두고 EC2의 crontab을 활용해 새벽 1시마다 파일이 존재할 경우 스케줄러로 자동 파싱되게 진행하였다.

=> 다음과 같이 로직 & 프로젝트 구조를 완전히 뜯어고쳤다. -> 기존의 파싱처리 부분은 views.py에서 분리되어 tasks.py로 옮겼고

자동화 스크립트를 앱 루트 > scripts > process_files.py에 두어 자동화 스케줄러가 이 파일을 주기적으로 실행할 수 있게 하였다.

 

위 파일을 새벽 1시를 기준으로 ec2에서 자동 실행하기 위해 crontab설정을 진행해 주었다.

=> 다음과 같이 위의 경로에서 process_files.py을 새벽 1시에 실행하도록 하고 logs폴더에 로그가 찍힐 수 있도록 세팅하였다.(사진에는 테스트한다고 2분마다 실행으로 설정함)

=> 2분 경과,,, 테스트 파일을 자동으로 해당 시간에 맞추어 한 페이지씩 파싱 하는 모습이다!

 

=> DB에도 파싱 한 데이터가 잘 들어가는 모습!

 

 

마치며

이렇게 여러 태스크를 잘 개발 완료하고 마지막 개발 완료 시점을 앞에 두고 있다.

10일 후면 sw경진대회 마감일이고, 그 이후로는 마루에그 프로젝트를 명지대 입학관리팀 입학처 홈페이지에 게시하게 된다.

하지만 서비스하기에는 아직까지 많이 부족한 상태이기에,, 대회와 서비스를 진행할 일자 전까지 최대한 파싱과 임베딩 문제를 해결하고

로직을 개선할 수 있도록 마지막까지 방법을 찾아보고 적용하며 최선을 다해야겠다.