끄적끄적 코딩일지

저번글에 이어서 이번 글에서는 Spring 자동배포 방법을 포스팅 하겠다. ※ 먼저 이 글은 Spring 서버와 Jenkins서버가 분리되어 있으며 각 서버는 EC2 free tier Ubuntu 18.04 버전으로 되어있다. 자동배포는 Jenkins에서 SSH 연결을 통해 배포파일 업로드 및 Shell Script 실행하는 방식으로 진행되며 현제 Ubuntu 20번대 버전에서는 Jenkins에서 SSH 연결을 하지 못하는 버그가 있으므로 참고하면 된다. 자동배포를 SSH를 통해서 하는경우 데시보 -> Jenkins 관리 -> 플러그인 관리 -> 설치 가능에서 Publish Over SSH를 설치한다. 이어서 Jenkins 관리 -> 시스템 설정에서 제일 아래에 있는 Publish over SSH에서 S..

기본적인 MVP 개발은 모두 마쳤다. 문제 발생시 분석을 위한 Actuator, Promethus를 적용했고 Jenkins를 구현할때 민감한 정보가 담긴 설정파일이 올라가야 한다는 것에서 Submodule을 이용하여 설정파일을 분리시켰다. 그외 오류들을 수정했으며 약간의 사용자 피드백또한 받을 수 있었다. 카카오톡 로그인에서 크리티컬한 문제가 발생해서 (다른 사용자로 로그인이 되는 문제) 기술 매니져님과 예기를 했지만 원인을 찾지 못했다. 딱 한번 일어나서 원인을 찾기 힘들고 RestTemplate에서 무엇인가 꼬인게 아닐까라는 의심만 하고 있다. 기존에 메소드에서 new로 생성하던것을 bean으로 등록한후 지금까지 다시 문제가 발생하지 않았지만 원인을 정확히 찾아서 해결한것이 아니다 보니 조금 찜찜하기..

MVP 기능 구현이 거의 끝났다. 연속적인 서비스를 제공하기 위해 Jenkins, Nignx를 사용한 CI/CD, 무중단 배포를 구현했고 Jmeter를 사용한 부하테스트,Junit을 사용한 Test Code 작성을 하면서 배포할 준비를 했다. Spring boot를 사용한 제대로된 서비스를 만드는것은 처음이라서 Spring DDD구조를 잘 지키지 못했고 너무 많은 Builder Pattern을 남발하긴 했지만 앞으로 서비스를 운영하면서 하나씩 수정을 해가면 될 일이다.

3주간 실전 프로젝트를 진행하면서 CRUD : QueryDSL,AOP, Redis 모니터링 : Actuator, Spring Admin, Prometheus, Grafana CI/CD : Jenkins, Nginx 등을 알게되었다. 앞으로 공부할것은 많은데 프로젝트를 진행하느라 블로그에 정리할 시간이 부족하다. 끝나고 2~3주일동안 블로그에 정리해야할것같다.

※항해 99를 진행하면서 배포할 서버로 나의 EC2를 사용하게 되었다. 그중에 Spring을 개발하는 사람은 나포함 3명이다. 그런데 내가 쓴 코드를 반영해서 배포할때는 괜찮은데 다른 사람이 쓴 코드를 배포할때는 1. Github에서 해당 코드를 받음 (충돌이 일어나면 해결해야됨) 2. Intellij에서 bootJar으로 jar 파일 생성 3. EC2에 SSH 접속 및 FileZila(파일 업로드 프로그램)으로 접속 4. 기존 서버 종료 5. jar파일 업로드 6. 다시 Spring 서버 시작 ...... 그러다가 코드에 오류가 있으면 해당 부분을 맏은 팀원에게 전달하고 팀원이 해당 오류를 해결하면 다시 반복... 프리티어라도 나의 EC2서버니 다른사람에게 맏기기도 좀 그렇고 좋은 방법이 없나 고민하던..

기본적인 CRUD를 마치고 내부기능을 강화하기 시작했다. Refresh Token을 적용하고 Spring Actuator를 써서 지표를 가져왔고 Prometheus, Grafana를 써서 데이터를 시각화 하였다. 하지만 Prometheus Query를 사용하기 어렵다는 단점이 있어서 해결 방안을 찾다가 Spring Admin을 발견하여 적용하였다.

본격적으로 실전프로젝트를 시작하고 1주차가 지났다. 생각보다 서버 개발은 빠르게 끝나서 내부 기능 강화에 집중을 하고 있다. AOP와 Redis를 써서 날씨, 시세등의 API 호출횟수를 최소화 하고 Front 에서 사용할 통계데이터를 만들기 위해 Join을 사용하거나 Sum,Year,Month,Group By를 써서 월별로 데이터를 정렬하기도 했다. 또한 QueryDSL을 써서 데이터를 조회하기도 하였다. 그리고 멘토링을 하면서 Setter를 지양해야하는 이유, 유지 보수가 편한 프로젝트 관리등의 이유를 알수 있었다

프로젝트를 진행하면서 Lombok 쓰면 편하게 코드를 작성할 수 있다. 생성자, Getter, Setter, Builder 등을 Annotation하나로 쉽게 만들수가 있어 코드의 가독성을 높혀준다. 하지만 이중에서 Setter는 가능한 사용을 지양해야하는데 그 이유를 알아보자 1. 값을 변경한 의도를 알기가 어렵다. Setter 자체에 오류가 있다기보다는 유지/보수 측면에서 잘 사용하지 않는다. 일단 setter를 사용하면 해당 값을 왜 변경했는지 알기 어렵다. 어떤 변수를 변경하는지는 쉽게 알 수 있지만 왜 해당 변수를 변경하는지는 쉽게 알 수가 없다. 이는 실무에서 코드를 유지보수할 때 꽤 불리하게 적용된다. 2. 객체의 일관성을 유지할 수 없다. @setter를 사용하면 모든 변수에 대하여 pub..

AirBnb를 클론코딩하면서 여러가지로 배운것이 많았다. 특히 프로젝트를 진행하면서 시간을 지키지 못할경우 빠르게 일정을 제조정을 해야한다는 것과 팀원들간의 소통의 중요성등을 몸으로 체감한 주차라고 할 수 있다. 팀장이 아니라는 이유로, 피곤하다는 이유로, 낮설다는 이유로, 같은 팀원을 존중한다는 이유로 나의 할일을 끝내놓고는 프론트쪽의 진행사항을 많이 체크하지 않았고 ,일정을 제대로 세우지도 않았고 개발이 늦어저도 프론트 쪽을 제촉하거나 대책을 세우지 않은결과 백엔드 쪽에서 개발한 사항을 제대로 써 먹지도 못하고 마무리를 하게 되었다. 클론코딩을 마무리할때는 프론트쪽에서 개발이 늦어져 제대로 테스트를 못했고, 다른 벡엔드팀원들도 개발을 끝내자 테스트도 할 생각없이 나에게 다 맞겼다는것에 화가나기도 했다..

처음으로 React와 협엽을 하여 개발을 시작했다. 서버를 2개사용해서 개발을하는것은 처음이라서 여러가지 시행착오를 겪었다. 특히 로컬에서 테스트할때는 문제가 없었지만 배포하였을때 예상하지 못한 오류가 많이 발생하였다. 이 경험을 발판삼아 이번 클론코딩주차에는 더 완성도 높은 서버를 개발할 것이다.