Published 2021. 10. 2. 23:10

배포 방법 및 이슈 관리

이동욱님의 책 이 책을 보고 1년 전에 처음으로 자동화 배포를 알게 되었다.
그 때는 실습 개념이었기 때문에 모두 따라해 보았는데 정말 신세계였다.
이 책에서 나오는 배포 구조는 CI/CD를 이용 했는데 이 때 이 개념도 처음 알게 되었다.
구조는 CI는 TravisCI 배포는 AWS CodeDeploy 소스 저장소는 S3를 사용했다.
그리고 무중단 배포를 위해 ec2 앞에 nginx를 붙였다. 이 때 shell도 작성을 했는데 처음 작성 해보았다.
정말 큰 도움이 되었던 책이었고, 가볍게 볼 수 있지만, 넓게 알 수 있는 가장 좋은 책이었다. 초심자 누구에게나 추천하고,
중급자여도, 전반적인 흐름을 모른다면 추천할만한 책이다.
하지만 이번 토이 프로젝트에는 무중단과 자동화를 적용하지 않았다. 어떻게 사용하는지만 배우려고 했던거라, 엄청 겉핥기여서
굳이 이번에는 적용을 하지 않았다.
그래서 이번 배포 구조는 간단하다. 구조라고 할 것도 없다.

하지만 이번에 새로 시도해 본 것 중 좋은 것이 있었다. 바로 Issue 별로 branch를 생성하여, Issue를 해결하는 것이었다.
기억은 안나지만, devlogmoa 진행 중 온라인 상에서 어떤 분께 피드백을 받았다.
진행한 결과 너무 만족했다. 이 전 토이 프로젝트는 그냥 막 했었다. 브랜치를 따로 따긴 했지만, 명확하게 하나의 기능만을 가지고 브랜치를 생성하지는 않았다. 그러다 보니, 브랜치가 지저분했는데, 확실히 Issue 베이스로 관리하니까 하나의 Issue에만 집중할 수 있었고, 이를 실제로 사용한다면, 나중에 추적도 좋을 것 같았다. 왜냐하, Issue를 해결하고, 커밋 메시지에 Issue 번호를 작성 했기 때문인데 github에서 링크가 잡혀서 굉장히 좋을 것 같다고 생각했다. 물론 실무에서 매번 Issue 하나만으로 브랜치를 따서 하는게 가능할지는 의문이 들긴한다. 하지만 이렇게 하면 정말 관리가 좋을 것 같다.
뒤엉키는 일이 줄 것 같다.

Application Server

AWS의 EC2 서버를 사용하였다.
Amazon Linux 2 AMI (HVM), SSD Volume Type을 사용했다.
AMI(Amazon Machine Image)sms EC2 인스턴스를 필요한 정보를 이미지로 만들어 둔 것이라고 한다.

DB Server

이동욱님의 책을 보기 전 까지는 토이 프로젝트를 할 때 스프링으로 했었는데 굉장히 힘겹게 ec2에 tomcat을 설치하고, DB도 설치했던 기억이 있다.
하지만, DB와 Application이 같은 서버에 있으면, 둘 중 하나가 터지면 전 부다 터지기 때문에 좋지 않고, 성능상 좋지도 않다고 알고 있다.
그래서 서버는 AWS의 RDS가 편리한 기능을 제공한다고 하고, 따로 만들 필요없이 EC2 처럼 바로 사용하면 되기 때문에 RDS를 사용했다.

Maria DB
DB는 MySQL이 아닌 MariaDB를 사용했다. 선택한 이유는 아래와 같다.

가격이 저렴하다.
Amazon Aurora 교체의 용이성 : 월 10만원이 기본 요금이란다.
- RDS보다 성능이 훨씬 좋음
- AWS에서 직접 관리하기 때문에 여러가지 기능이 있고, 계속 update 되는 중.
- MySQL, MariaDB, PostgreSQL을 지원하기 때문에 굳이 MSSQL, 오라클을 선택하지 않는다.
  책에서 이렇게 설명을 하였고, 이렇다는 이유로만 알고있다. 그래도 이런 이유정도는 알고 있어야 나중에 진짜 필요할 때 배경지식이 된다.
  근데 나는 회사에서는 주로 ORACLE만 써봤는데, 솔직히 어떤 DB를 선택해야 하는지, 각 DB의 장점이 뭔지 전혀 모른다.
  앞으로 알아가야겠다. 그래서 이번 주 부터 회사에서 ORACLE 쿼리 공부가 아닌, INDEX구조를 공부하기 위해 준비 중이다.
  쿼리는 업무하면서 어떻게든 대충이라고 알게 되지만, DB의 구조는 알 수가 없을 것 같아 따로 공부해야 할 것 같다.
  사실 Application쪽만 공부하기 바빠서 DB는 나중에 하려고 했는데 회사에서는 쿼리 업무가 우선 순위가 더 높기 때문에 회사에서 시간날 때 공부하기로
  마음 먹었다. 선임 분들이 계시니 더 배우기도 좋다.

Maria DB가 MySQL보다 좋은 점

MySQL을 만든 사람이 퇴사하고 만든게 Maria DB라고 알고 있다. 그래서 더 기능이 좋다.
커뮤니티가 더 활성화 되어있다.(정말 중요.. 회사에서 nexacro, miplatform, devonframework를 사용하는데 커뮤니티가 최악이다..특히 devon)
다양한 기능
다양한 스토리지 엔진(뭔지 모르겠다)

Build Tool

gradle을 사용했다. 단지 maven말고 새로운게 써 보고 싶었다. 근데 문제는 maven도 복붙만 할 줄 알지.. 모른다..
그래도 새로운걸 접했다는 점에서 의미를 둔다.
이것도 Maven이든 gradle이든 따로 공부가 필요하다고 한다.

Backend

Spring Boot : 2.4.5(최신 안정화 버전을 선택했다. 버전에 대한 차이는 잘 모른다.)
JPA : hibernate : 5.4.30
DB : 운영은 Maria DB, 로컬은 h2 DB
JAVA 8 : 스트림, 람다를 써 보려고 했는데 못 썼다 ㅜ.ㅜ
Lombok : 1.18.20
queryDSL : 4~~버전JPAJPA는 영한님의 강의를 들었다. 무슨 강의든 정말 쵝오!! JPA는 처음 써 본건 아니고, 이전 토이 프로젝트에서 사용 해봤다.
하지만 그 때는 기본편은 듣지 않았고, 구조에 대해 전혀 몰랐다. 물론 지금도 잘 모르지만, 영속상태에 대한 개념은 어느정도 잡혔다.
사용한 코드는 동일 하지만 그래도 조금 더 이해하고 써 보고 싶어서 다시 또 도입을 했다. 확실히 기본편을 듣고 보니,
쿼리가 여러개 날라가는 이유, 쿼리가 안나가는 이유도 알게 되니 확실히 수월했다.

내가 직접 느끼고 공감할 수 있는 장점과 단점이 있었다.
장점

단순 반복 쿼리를 만들 필요가 없다. 솔직히 토이 프로젝트에서는 못느끼지만, 실무에서 정말 지옥이다. 이거 하다가 오타라도 내면..
그리고 수정하다가 컬럼 하나라도 빼면.. 컬럼명 변경되면.. 정말 짜잘하게 무서운게 엄청 많다.
근데 JPA를 쓰면 이런 단순 반복 쿼리는 자동으로 만들어 주니 정말 편하다.
테이블이 아닌 객체를 바라보기 때문에 객체지향적인 개발이 가능하다. 솔직히 이 부분은 내가 아직 객체지향적으로 짜는 연습을 하는 중이라
피부에 와닿지가 않는다.
DB에 종속적이지 않다. 이건 정말 장점인 것 같다. 단순한 쿼리를 자동으로 생성을 해주고, 직접 쿼리를 작성 하더라도, dialect를 통하여,
어차피 쿼리는 바뀐 DB에 맞는 쿼리로 생성되기 때문에 정말 정말 큰 장점인 것 같다.
근데 나는 아직까지 2년간 SI를 하며, 중간에 DB가 바뀌는 건 본 적이 없지만, 정말 바꼈는데 모든 코드 다 바꾼다 하면.. 소름 돋을 것 같다.
하지만 분명, JPA라도 100% 완벽하게 아무 것도 안건드려도 될까?? 라는 생각도 든다.
queryDSL 같은 컴파일 단계에 문법 에러를 잡아 낼 수 있는 것. 정말 쵝오!! 이건 피부로 너무 와닿는다.
실무에서 쿼리 오타를 안내는 사람을 없을텐데.. 이게 아무리 조심해도 실수한다. 그래서 빌드 다 하고, 화면 켰는데 오타.. 은근 시간 많이 든다.

단점

진입 장벽이 높다.

Frontend

thymeleaf : 2.4.5( 영한님 강의에서 사용해서 사용 )

주요 라이브러리

Quartz : 2.4.5
- 흠.. 스케줄링을 위해 사용했는데.. 잘 몰라서 공부해볼까 했는데 결국 못했다.. 꼭 언젠간 하자.
ROME : 1.0
- rss 정보를 가져오는 라이브러리인데 정말 편하게 사용했다. 전 토이 프로젝트 할 때 Jsoup인가?로 melone을 html 파싱 했었는데.. 고생했었다..
  근데 melong에서 rss 지원을 해야하는건데 그건 몰겠당. html 파싱은 구조를 알아야 해서 불편했다. rss는 알 필요가 없어서 훨씬 수월했다.

ERD

AQUERY TOOL을 사용했다.
(비밀번호 : u4dn5b)
원래 무료였는데 2021년 10월 1일 부터 유료로 바꼈다. 지금 알았다... 테이블 개수구 5개까지만 무료인데 난 넘어서 2개월에 12000원 결제를 했다.
erd cloud라는 무료 ERD가 있긴한데.. 난 굉장히 불편했다. 그래서 그냥 2개월 결제!!

API 문서

Swagger Ui를 사용했다. 링크

커밋 규칙

앵귤러 규칙 참고했다. 코드 스타일은 하려다가 혼자하는 건 크게 의미가 없어 보여서 안했는데 이건 정말 도움이 되는 것 같다.
회사에서는 커밋 그냥 막하는 문화인데 이런 식으로 하면 추적에 좋을 것 같다.
이렇게 커밋을 하기 위해서는 커밋 단위도 쪼개질테니까

하지만 나는 영어를 못하니까 번역 본

feat : 새로운 기능에 대한 커밋
fix : 버그 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋
ci : CI관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋

주제 선정 이유

내가 지금 보다 더 IT 세계에 대한 정보가 없을 때 도대체 어디서 컨퍼런스, 스터디, 핫한 기술, 커뮤니티, 팀 프로젝트 모집 등등
이런 관련 정보들을 다들 어디서 보는거지?? 내가 아는건 페이스북 페이지 정도였다. 이것도 좀 발전하고 난 뒤 알게된 것인데.. 그래도 너무 정보가 부족했다.
물론 지금은 이 사람 저 사람 찾아 다녀보고, 온라인 상으로도 질문도 많이 해보면서 자연스레 정보들을 알게 되었다.
그런데 문득 그런 생각이 들었다. "어? 이런 정보들을 다 모아서 알림 주면 좋지 않을까? 초보자들은 더욱 좋고, 다른 개발자들도 좋을 것 같은데?"
그래서 페이스북이나 유튜브 같은 곳에 그런 정보들을 주는 채널들이 많다. 근데 나는 블로그의 정보들을 모아서 보여주고, 알림을 주고 싶었다.
본인이 원하는건 등록도 하고. 그러다가 찾아낸게 feedly인데 이건 rss 리더였다. 국내 개발 블로그를 모아 볼 수 있는 기능이 부족했고,
직접 구독해야 하는 불편함이 있었다. 그래서 또 찾았다. awesome-devblog
여기는 딱 내가 원하는 서비스였다!! 그런데 그 당시에는 알림 기능이 없던 건지 내가 몰랐던 건지 ㅋㅋ.. 알림 기능이 없어서 불편 하다고 생각했는데
지금 보니까 있다.. 근데 돌이켜 보면, 그냥 내가 만들고 싶어서 feedly도 awesome-devlog도 일부러 대충 본 것 같다. ㅋㅋㅋ
무튼 이러한 이유로 나는 구독을 하면 카카오톡 알림을 주는 블로그 모음 서비스를 만들기로 했다. 근데 카카오톡 알림은 유료였다.
그래서 gmail smtp를 사용했다. 무료이다. 그래서 적용했다.

메일 발송 구조

으.. 정말 리팩토링 1순위 부분이다. 메일 발송은 아직 잘 모르겠고, 메일 발송 전 rss 데이터 가공에 문제가 있다.
지금은 데이터가 blog 정보는 30건 정도, blog의 게시글 내용은 1000건이 좀 안된다.
그래서 크게 문제는 없지만 현재 20초 정도 걸린다.
이렇게 오래 걸리는 이유는

30개의 blog의 rss 정보를 루프
루프에서 rss로 가져온 blog 게시글 내용 ( 1000 건 ) 을 전부 신규인지 기존 데이터와 체크
신규면 insert, 수정이면 update, 없으면 미처리
이런 루프가 돌고 있어서 몇 건 없는데 20초나 걸리는 것이다.
그럼 단순하게만 봤을 때 블로그 게시글 내용이 블로그당 1000 / 30 하면 약 30개 씩으로 잡고(그냥 예시로 한 것이고, 실제로는 완전 랜덤이겠지)
블로그가 100개 정도가 되었을 때는 블로그 게시글 내용이 3000건 이상인데 그럼 1분 정도로 대충 예상할 수 있다.
그럼 블로그가 200개면 2분.. 300개면 3분이다. 앞으로 업그레이드 될 수록 블로그 뿐 아니라 다른 IT 정보도 수집할 거라면 300개는 더 될 것 같은데
개선 해보고 싶다.
메일 발송도 회원이 많아지면 문제가 되지 않을까?*
rss 가공 끝나고 나서, 모든 회원 조회 후 메일 수신 여부가 허용인 회원만 메일을 각각 따로 발송한다.
애초에 모든 회원 조회가 아닌 허용인 회원만 조회하는게 좋은가?
그리고 메일 발송을 한명 씩 다 하는데 이런건 모든 메일 발송이 그렇지 않나?

정리

돌이켜 보니 역시 뭐 대단한건 없는 것 같다. 하지만 확실히 발전했다. 객체지향적으로 해보려고 조금 더 노력했다.(하지만.. 역시 잘 안됐다.)
메서드를 더 쪼개려고 해보고, 하나의 기능만 하도록 하게 노력하고, 들여쓰기도 2depth까지만 해보려고 노력했다.
근데 역시.. 하나의 기능만 갖는게 정말 어렵다.. 이건 계속 리팩토링을 할 것이다. 넥스트 스텝의 클린코드를 2단계까지 완료한 상태인데(작년 12월24일
정도에 끝난 교육이다. 하지만 평생동안 진행은 할 수 있다.) 이 교육을 듣고, 테스트 코드와 클린코드에 대한 개념은 어느정도 잡았다.
그래서 이렇게 잘 몰라도 적용 해보려고 노력하는 것 자체에 아주 조금 만족한다. 마음에는 계속 클린코드, 테스트 코드를 공부 하자는 마음이 꿈틀거린다.
사실 좀 후회가 된다. 교육 들을 때 더 열심히 할걸 ㅜㅜ 근데 정말 어려웠다. 쉽게 봤는데...
근데 지금은 일단 당장 규모가 작은 서비스 회사에서 쓰일 수 있는 사람이 되기 위해 스프링, 자바, 토이 프로젝트, 배경지식을 쌓는게 중요하다고 생각했다.
클린코드, 테스트 코드는 들어가서 해도 충분하다고 생각한다. 어차피 개념은 알고 있고, 잘 모르는 것일 뿐 적용도 나름대로 해봤기 때문에 충분하다고 생각한다. 경험상 여러가지 다 하려다가 진짜 아무것도 못건진다. 그래서 정말 중요한 클린코드, 테스트 코드인거 알지만, 우선 순위에서 일단은 미룬 것이다.

이번에는 한 번도 내가 구현해본 적 없던 쿠키, 세션, 캐시를 적용 해봐서 굉장히 만족스럽다. 엄청 간단한걸 적용했지만, 개념적으로 조금 더 다가갔고,
구현 해본게 너무 좋았다. 회사에서는 이걸 내가 만질 일이 없어서 예전에는 몰라도 되는 건 줄 알았는데 그런게 아니었다는 걸 알고, 찾아봐도 이해가
잘 안됐었는데 구현을 직접 해보니 한층 더 이해한 느낌이다. 근데 실무에서 좀 써봐야 알 것 같다.

'Toy Project > devLogMoa' 카테고리의 다른 글

devlogmoa 이슈 (0)	2021.10.02

devlogmoa 프로젝트 구조 정리 및 회고