[빗썸테크아카데미] 백엔드 과정 5주차(팀프로젝트 2주차) 후기, 회고록

 

 

 

[빗썸테크아카데미] 백엔드 과정 5주차(팀프로젝트 2주차) 후기, 회고록

 

 

이번 시간에는

처음으로 mongoDB를 써보았고

그걸 또 처음으로 spring boot에서 reative하게 사용해보았다.

 

 

이제 진짜 한주남음

시간 미쳤다

 

 

5월도 벌써 중순이 다되어감

 

 

 

 

 

 

---

 

 

05.09(월)

 

뉴스 서비스를 위해

뉴스 데이터를 크롤링 해오기 위해

크롤링용 python 서버를 만들기로 했다.

 

혹여나 본문을 다 가져오면

저작권상 문제가 있을것 같아,

제목, 작성일, 작성자, summary, 썸네일uri, 뉴스기사 본문 uri를 가져와서

뉴스 리스트를 뿌려준 후

뉴스를 클릭하면 실제 뉴스 페이지로 라우팅 될 수 있도록 구현하기로 결정했다.

 

 

일단 파이썬 프로젝트를 하나 생성하고

CI/CD를 먼저 구현해야지 하고

파이썬 CI/CD에 대해 찾아봤는데,

 

크롤링 같은 경우는 웹서버랑 다르게 배포가 필요없고

gitActions의 cron으로 주기적으로 build 한 뒤

필요한 함수만 실행을 시키면 되는 것 같아서

처음에 낯선 방식에 약간 아리까리 했는데,

찾아보다보니 배포 필요가 없어서 오히려 편했다.

 

오늘은 로컬에서 크롤링만 구현했다.

크롤링에 사용되는 대표적인 라이브러리는

BeatifulSoup과 Selenium이 있어서

어떤 라이브러리를 사용해야 할지부터 선정하는게 첫번째 목표였다.

 

인터넷을 열심히 찾아봤는데

뭔가 다들 설명을 좀 어렵게 해서

그냥 스크래핑 회사에서 일하다가 온 옆옆 직원한테 물어봤다

 

BeatifulSoup은 복잡한 로그인이나 클릭 이벤트 없이 그냥 get으로 간단하게 조회할 수 있는 페이지를 크롤링 할때 사용할수 있고 selenium보다 빠른대신 할수 있는 일이 조금 작다

 

Selenium은 사용자가 브라우저에서 id를 입력하고 password를 입력해서 로그인을 하고, 버튼을 클릭해서 페이지 이동을 하는 것처럼 실제로 chrome 같은 브라우저를 띄워서 사용자의 행동을 그대로~ 따라가는 스크래핑 방식이라고 한다. 그래서 BeatifulSoup 보다는 할 수 있는 기능이 많지만, 실제로 브라우저 위에서 작동하는 만큼 많이 느리다고 했다.

 

 

근데 내가 하려는 곳 같은 경우,

로그인이 필요없고 url 이동으로 페이지 이동을 하면서 크롤링이 가능했기 때문에

BeatifulSoup이 더 적합하다고 판단해서 BeatifulSoup을 사용해 크롤링 기능을 구현했다.

 

 

 

---

05.10(화)

 

 

오늘은 어제 python에서 크롤링한 데이터를

DB에 저장하는 개발을 진행했다.

 

크롤링 데이터 같은 경우, 다른 table과 join을 하는등의 관계성이 없기 때문에

속도가 빠르고 가벼운 Nosql에 저장하기로 했고,

python은 mongoDB와 찰떡 궁합이라고 해서 mongoDB를 사용해서 구현하기로 했다.

 

 

mongoDB는 처음 사용해보는 DB라서

(사실 NoSQL이 아예 처음이다)

우선 로컬에 mongoDB를 설치해보고 이것저것 눌러보면서 사용법을 익혔다

그 후 파이썬이랑 연결해서 어떤식으로 데이터를 가져오고, 저장하는지 약간의 학습을 한 뒤

바로 개발을 진행했다.

 

 

로컬 python이랑 로컬 mongoDB랑 연동 테스트를 끝낸 후,

AWS에 실제로 DB를 올려야 했는데

aws mongoDB로 구글링을 하다 보니 예상치 못한 하나의 퀘스트가 더 생겼다.

 

 

바로 AWS는 mongoDB를 Database로 지원을 안해주는 것이었다.

 

찾아보니

 

1번 mongoDB -> mongoDB는 오픈소스라

aws에서 자체 데이터베이스로 관리가 안돼서 사용하려면 EC2를 생성해서 거기에 mongoDB를 다운받아 포트 오픈등의 설정을 직접 전부 해준 뒤 사용해야함 

2번 AWS의 serverless DynamoDB를 사용

3번 AWS의 mongoDB와 호환되는 DocumentDB를 사용

세가지의 선택지가 있었다.

 

 

 

고민을 해보다가 처음에는 아래의 이유로 1번으로 가기로 결정했다.

1번  mongoDB -> EC2 생성하고, 또 pem key 등록해서 ssh 접속하고, 그 안에 mongoDB 설치하고, 통신 열어주고 등등.... -> 귀찮아서 탈락
2번 DynamoDB -> 서버리스를 경험해 볼 수 있다는 점은 매우 매력적이나, mongoDB랑 테이블 생성이나 메소드가 살짝 달라 다이나모를 사용하려면 코드를 고쳐야 함 -> 귀찮아서 탈락
3번 documentDB -> mongoDB의 코드를 고대로 가져와 사용할 수 있으면서도 aws 자체 데이터 베이스 기능으로 구현됨 -> 합격

 

 

 

그래서 DocumentDB를 사용하려고 보니 얘는 EC2나 S3랑은 다르게 프리티어 기간이 한달밖에 안되는데, 혹시나 내가 올려두고 까먹었다가 과금폭탄 맞을까봐 무서워서 다시 선정을 했다.

 

DynamoDB는 프리티어가 아예 없는것 같아서

어쩔수 없이 경제적인 문제로 EC2에 mongoDB를 쓰게 되었다..

 

이노무 돈이 문제야..

 

.

.

.

 

 

그래서 AWS에 EC2를 띄워서 mongoDB를 사용했다.

방법은 아래에 포스팅해두었음.

 

https://be-developer.tistory.com/53

[AWS] EC2에 mongoDB 설치하고 외부 연동해서 Python에서 사용하기

 

 

그리고 처음에 뉴스를 10분 주기로 크롤링 하려고

gitActions cron을 10분 주기로 해놓았더니, 작동을 안해서

구글링해보니

딜레이 시간이 있어 최소 15분 ~ 17분 주기로 해야 정상적으로 작동을 한다고 해서

그냥 30분마다 크롤링하는 것으로 바꾸어놓았다.

 

 

 

 

---

 

05.11(수)

 

크롤링 데이터가 한페이지당 20개 * 560페이지 정도 되어서

데이터가 너무 많아서 20페이지만 가져오는 것으로 변경했다.

 

try- catch로 에러가 날 수 있는 곳들을 잡아주었고

 

break flag를 넣어서

크롤링 해온 기사의 등록일이, mongoDB에 저장된 최신 등록일보다 같거나 작으면

break flag = true로 바꿔서

while 문을 빠져나와 크롤링을 종료 한 뒤

데이터를 저장하도록 코드를 변경하였고

 

안쓰는 코드들을 제거해주었다.

 

 

 

언어를 이것저것 쓰다보면

(ex. kotlin, java, js, python)

어이없는 실수들을 한다 ㅋㅋㅋ

 

이번에

Python을 아주 오랜만에 써봤는데

얘네는 특이하게

Boolean값의 첫 글자가

대문자로 시작한다

false -> Fasle

true -> True

 

그래서 이것때문에

어이없는 오류가 나서

고쳐주었다 ㅎㅎ

 

 

요즘은 go도 배워보고 시픔...

 

---

05.12(목)

 

오늘은 mongoDB와 Spring Boot Webflux server를 연동하는 개발을 했다.

 

이전에 과제 할때 H2 DB를 썼었고, 수업을 들을때도 R2DBC 로 배웠어서

R2DBC mongoDB로 키워드를 검색했더니 

내가 원하는 자료가 잘 안나와서 한 두시간정도 삽질하다가

reactive mongoDB라는 키워드로 검색을 했더니

 

아주 간단하게 연동을 할 수 있는 방법을 찾아서

약간 허무했다 ㅋㅋ

 

다 됐나?! 했는데

생각해보니 페이지 기능을 구현해야 해서

다시 삽질 시작

 

아니 진짜 reative로 뭐 하는거 진짜 속터진다 ㅋㅋㅋㅋㅋ

디버그 모드 안잡혀,

로그 찍으면 주소값만 나와

객체 값이라도 쓰려면

꼭 체이닝 해야돼....

 

아휴

 

.

.

.

 

 spring data reative mongoDB와 pagable로 어찌저찌 구현 했다.

오늘은 로컬에서까지만 구현을 완료했고

내일은 CI/CD 구현하고 AWS에 올려서 게이트웨이와 함께 테스트를 해봐야겠다.

 

AWS 올리고

게이트웨이 담당자분한테

domain 연결해달라고 해야지

 

 

그리고 주말에는

전체적으로 코드 리팩토링좀 하고

에러 핸들링좀 해야될 것 같다.

 

 

 

 

 

---

05.13(금)

 

오늘은 Spring Boot Webflux server를 AWS의 EC2 위에 올리고, CI/CD 설정을 했다.

 

실수로 local-properties가 올라가는 바람에

DB 정보들이 같이 올라가버려서

리파지토리 날리고

새로 다시 만들었다.

 

 

 

local-properties 는 gitignore 처리를 해 주었고

prod-properties만 빈 파일로 리파지토리에 올린 후

 

DB 정보들은 git Actions의 secrets에 넣어 준 후

CI 과정에서 properties에 적용 할 수 있게 코드를 수정해주었다.

 

 

gitActions용 yml 파일에 위와 같은 코드 삽입

 

 

그 후 배포했는데 안되서 확인해보니

application.properties 의 spring.profiles.active = local 로 되어있어서

spring.profiles.active = prod 로 변경해 주어서

 

배포를 완료하였다.

 

 

 

 

 

오늘은 빗썸테크아카데미의 Q&A 세션이 있는날이고

우리는 1조라서 7시부터 첫 조로 들어가서

세션을 진행했다.

 

코드스테이츠에서 새로운 분이 오셔서

하다가 어려운점이 없냐고 물어보셔서,

 

채팅에 대한 이야기를 좀 드리고

어느정도까지는 구현을 했는데,내가 원하는 세부적인 구현이 조금 어렵다 말씀드리니

 

생각보다 간단하게 구현할수 있겠다고 하시더니

구글링을 해보시다가 자료가 정말 없네요... 하고

내가 구현해놓은걸 달라고 하셨다 ㅋㅋㅋㅋ

 

그래서 두가지 버전으로 드렸고

한번 확인해 본 후 답변을 주겠다고 하셨는데

 

사실 답변이 언제올지도 모르겠고,

백엔드에서 주는 데이터에 따라

프론트엔드 개발도 달라지기 때문에

 

백엔드가 바뀌면

프론트도 또 같이 바꿔야한다.

 

우리는 프론트분이

이번주 주말에 채팅이랑 캔버스랑 유저정보를 다 합칠거라고 하셔서

사실 답을 다음주에 주셔도 그걸 적용할 수 있을지 모르겠다.

 

 

 

---

05.14(토)

 

오늘은 원래 에러 핸들링을 하려고 했는데

생각지 못한 업무가 생겼다!

 

바로

 

 

이것!

 

ISSUE는 처음 받아봐서 너무 신기한 주니어 개발자..

 

 

사실 회사에서 업무를 할때는

프론트, 백엔드 둘다 혼자 개발했기 때문에

프론트 하다가

어 이게 필요하네? 하면

아무생각없이 백엔드로 가서

데이터를 던져서 받아서 처리했는데

 

프론트와 백엔드의 업무 분담이 완벽하게 된

이번 프로젝트에서는

프론트에 데이터를 어떻게 줘야할지에 대해

훨씬 많은 고민을 하게 된다

 

 

우선 프론트에 총 데이터 갯수와 페이지 수를 던져주기 위해

Mono<Page<News>> 이런식으로 데이터를 빼서

가공을 해줘야했다.

 

 

 

처음에는 Page 통째로 넘기니까

 

 

이런식으로 너무 많은 데이터가 넘어갔는데

이렇게 주는게 과연 맞는건가..? 싶어서

다른 백엔드 개발자분들에게 연락을 돌려서 물어봤다

 

 

 

보통 pageable을 통으로 넘겨주진 않고

프론트에서 원하는 값만 빼서 넘겨주는 편이고

page 객체를 따로 만들지 아니면 그냥 단일 컬럼들로 넘겨줄지는

프론트와 상의를 해서 진행하는게 가장 좋다고 하시길래

프론트분에게 물어봤다

 

 

 

협의후 최종적으로 완성된 response 객체!

 

현재 page 번호나, size같은 것들이 필요하진 않은지 여쭤봤는데

일단은 저거 두개만 있으면 된다고 하셨고, 추후에 필요하면 요청한다고 하셔서

오늘의 개발은 여기까지 ㅎㅎ

 

 

 

 

 

 

 

---

05.15(일)

 

 

오늘은 에러핸들링을 처리하기로 계획한 날

 

처음에는 MVC에서 사용하던 대로

 

@RestControllerAdvice 로 에러 핸들링을 하다가

Exception도 Mono로 빼는건가? 싶어서 구글링을 했다.

 

Webflux는 Exception 처리 방법이 조금 다르길래

방법을 바꿔서 다시 개발을 진행했다.

 

 

우리조는 첫주에 API 규약을 정할때

{
   status : "error"
   message : "에러 메세지 출력"
}

이렇게 설계하기로 했었는데

개발을 하다보니까 세가지 의문점이 생겼다.

 

 

 

1번

실제 HttpStatus도 같이 줘야 하는데

이때는 그냥 200OK를 주고

메세지만 error로 던져줘서

프론트에서 메세지 값을 보고 처리를 할지?

아니면 실제 HttpStatus도 에러에 맞는 에러 코드로 던져줄지?

 

 

 

2번

200OK로 던져주면

응답 메세지에 error code가 없는데

뭘 기준으로 처리를 할지??

 

 

 

3번

조회 데이터가 없을 시

No Data Error로 처리할지, 

Success와 빈 배열로 던져줄지?

 

 

 

 

세가지 의문이 생겨서 8시 회의때 이것에 대한 논의좀 하자고 미리 요청해두었다.

 

 

8시가 되어 회의를 진행했는데 HttpStatus는 그냥 200OK로 날리고,

프론트에서 응답 메세지에 status : "error"가 담겨오면

message를 출력하는 방향으로 진행하자고 하셨다.

 

그리고 조회 데이터가 없을 경우

그냥 빈 배열로 달라고 하셨다.

 

이부분은 프론트님이 처리할 부분이라

프론트님의 의견을 전적으로 따랐다

 

 

 

 

 

---

 

이렇게 한주가 또 끝났다

 

협업은 정말 회의의 연속이구나 라는것을 느낀 한 주 :)

 

업무를 혼자 할때는

그냥 혼자 생각하고 혼자 판단해서

일이 쭉쭉쭉 진행되었는데,

 

분업이 되니

개발을 하다가도

협의할 부분이 생기면 그 개발의 진척도가 뚝 멈춘다 ㅋㅋㅋ

 

피가되고 살이되는 빗썸테크아카데미 팀프로젝트

일주일만 더 힘내면

조금은 쉴 수 있다!!