들어가기 전에 버즈덤 프로젝트에서는 [RabbitMQ] 설치 및 적용기에 작성한 것처럼 Feed 기능을 구현했다. 이때 템플릿을 지정해놓고 스케줄 정보만 지정된 위치의 문자열에 치환할 수 있도록 아래와 같이 MessageTemplate 클래스에 상수로 템플릿 메시지를 선언해서 사용했다. MessageTemplate public class MessageTemplate { // 치환해야 할 문자열이 한 개일 때 public static final String CREATE_SCHEDULE = "%s님이 {0}로 코칭 일정을 신청했습니다."; // 치환해야 할 문자열이 두 개일 때 public static final String UPDATE_SCHEDULE = "%s님이 {0}에서 {1}로 코칭 일정을 변경했습..

들어가기 전에 버즈덤 프로젝트에서는 Spring Security와 JWT를 통해 인증 및 인가 처리를 하는데 이때 Token 저장소로 Redis를 사용하기로 했다. 같이 하시는 팀원 분 파트였는데 하시는 데 어려움을 겪으셔서 내가 연결 정보만 넘겨드리기로 하면서 Redis를 조금이나마 경험할 수 있었다. 사실 설치하고 사용하는 과정까지는 크게 어렵지 않지만 혹시나 나처럼 실수를 겪는 분이 있을까봐 글을 작성하게 됐다. 공식 문서나 블로그 글이나 큰 차이가 없을 것이라고 생각해서 "Redis 설치"를 검색하고 상위에 뜨는 블로그 글들의 설치 방법을 그대로 따라했다가 계속 오류가 나서 생각보다 시간을 쏟게 되었었기 때문이다. 🥲 역시 올타임 교훈은 뭐다? 공식 문서를 참고하자! 설치하기 1. APT 인덱스에..

들어가기 전에 버즈덤 프로젝트는 F-lab의 코칭 시스템 이용하면서 일정이나 피드백 관리가 있으면 좋을 것 같다는 마음에서 시작하게 됐다. 메인 기능은 코치가 코칭 가능한 시간을 등록하는 것과 멘티가 코칭을 신청하는 것인데 기본 내용은 다음과 같다. 코치 한 명에 여러 명의 멘티가 매칭될 수 있다. 코치는 코칭 가능한 시간을 등록한다. 멘티들은 코치의 일정을 조회해 그중 하나를 선택해 코칭을 신청한다. 그중 내가 맡은 것은 멘티가 코칭을 신청하는 기능이었는데 코치 한 명에 여러 명의 멘티가 있다 보니 동시성 문제가 발생할 것이라고 보고 동시성 제어에 대한 경험을 해볼 수 있을 것이라고 생각했다. 그래서 처음에는 수강 신청처럼 오픈되는 시간을 정해두고 멘티가 동시에 선착순으로 코칭 일정을 선점하는 방식으로..

들어가기 전에 Github Actions와 shell script로 CI/CD를 구축했는데 이번에는 Docker hub에 이미지를 빌드하고 원격 서버에서 이 이미지를 pull 받아서 컨테이너로 실행하도록 했다. Github Actions: CI/CD 구축 (feat.shell script) - 준비편 Github Actions: CI/CD 구축 (feat.shell script) - 실전편 그래서 밑작업들은 모두 이전 포스팅에 설명해놨기 때문에 설정 안 한 부분이 있다면 위의 링크를 참고하면 좋겠다. 참고로 이전 작업들은 Docker를 도입하기 전에 직접 jar 파일을 배포해서 실행하는 shell script도 작성도 해보고 리눅스 명령어도 최대한 경험할 수 있는 시간을 가지기 위함이었다. Docker를..

들어가기 전에 이번 F-lab 프로젝트에서 Feed 기능을 구현하게 됐다. 각각의 이벤트가 발생했을 때 피드 메시지를 생성하고 전달해서 Feed 테이블에 저장했어야 하는데 직접 저장하는 메소드를 호출하느냐, 아니면 이벤트를 처리하기 위한 별도의 장치를 사용하느냐를 두고 생각하다가 각 서비스 간의 의존도와 결합도를 낮추기 위해서 후자를 선택하기로 했다. 그 다음으로 고민했던 것은 Spring의 @EventListener를 사용하느냐, Message broker를 사용하느냐였다. Spring의 @EventListener로도 충분히 하고자 하는 기능 구현을 해낼 수 있었지만 굳이 Message broker를 사용한 이유는 scale out에 대한 대비였다. 지금 당장은 싱글 서버이지만 증설을 목표로 두고 하고..

들어가기 전에 지난 준비편을 통해 모든 준비가 끝났다면 이번 글에서 CI/CD 구축 작업을 직접 해보도록 하자. 참고로 이 글은 Github Actions 내의 모든 기능이나 개념에 대한 설명보다는 집중에 구현한 글이다. 만약 기초 개념에 대한 공부가 필요하다면 Microsoft에서 제공하는 Github Actions로 개발 주기 자동화라는 발표 영상을 추천한다. 목차 🌊 실전 1. CI - workflow 생성 2. CD - workflow 생성 - ssh-action 활용하여 서버 접속하기 - scp-action 활용하여 빌드된 아티팩트 복사하기 시작하기 1️⃣ CI workflow 생성 /github/workflows 하위에 ci.yml 파일을 생성하고 내용을 커스텀한다. name: CI on: p..

들어가기 전에 프로젝트에서 Github Actions를 활용해서 빌드 및 테스트를 자동화하고 서버에 jar 파일과 shell script를 배포해서 script를 실행하기까지의 과정을 글로 남기기로 했다. 과정 중에 필요한 모든 내용을 담으려고 하다 보니 글이 지저분해지는 것 같아 준비편과 실전편을 나누기로 했고 이번 편은 다음 편을 진행하기 위해 필요한 과정을 작성했다. 목차 ⚓️ 준비 1. 서버 생성 2. 서버에 Java 설치 및 환경 변수 설정 3. jar 파일 생성 설정 4. workflow 생성하는 방법 준비하기 1️⃣ 서버 생성 NCP 서버 생성부터 ssh 접속까지 들어가기 전에 그동안 AWS 서버 인스턴스 생성만 해봤는데 F-lab에서 크레딧을 제공해줘서 처음으로 NCP를 사용하게 되면서 ..

들어가기 전에 그동안 AWS 서버 인스턴스 생성만 해봤는데 F-lab에서 크레딧을 제공해줘서 처음으로 NCP를 사용하게 되면서 해당 과정을 정리해봤다. ACG 설정만 조금 주의하면 아주 간단하게 이용할 수 있다. 1. NCP 서버 생성 2. 포트포워딩 설정 3. ACG 규칙 설정 4. 공인 IP 할당 5. ssh 접속 1️⃣ NCP 서버 생성 1. 로그인 후 홈페이지 우측 상단에 위치한 콘솔 버튼을 클릭한다. 2. 좌측에 있는 Server 탭을 클릭하고 서버 생성 버튼을 누른다. 3. 본인의 프로젝트와 맞는 서버 이미지를 선택한다. 부팅 디스크 크기 : 50GB 이미지타입 : OS OS 이미지타입 : Ubuntu 서버 타입 : Compact 서버 이미지 이름 : ubuntu-18.04 나는 Compac..

들어가기 전에 이번 프로젝트에서는 API 문서 자동화를 위해 Spring Restdocs를 선택했다. Swagger와 Spring REST Docs를 두고 고민했었는데 둘의 차이점은 무엇이고 왜 REST Docs를 선택했는지 기록하고자 한다. Spring REST Docs vs. Swagger Spring REST Docs Swagger 테스트 코드에 적용한다. Controller/DTO 코드에 적용한다. 테스트 기능은 제공하지 않는다. 문서를 통해 테스트할 수 있다. 문법에 따라 자유롭게 문서를 만들 수 있다. 스타일 가이드라인에 따라 문서를 만들 수 있다. Spring REST Docs 1. 테스트 코드에 적용한다. 테스트 클래스에 REST Docs를 사용할 수 있도록 설정한 후에 아래처럼 작성하면 ..