전체 글

1. 배포 자동화를 구축하게 된 계기 현재 교내 서버실에 운영서버가 구축되어 있고, 교내망 정책에 따라 외부 액세스 포트는 80, 443 2개만 사용할 수 있었다. 이미 80, 443은 애플리케이션 배포를 위해 사용하고 있다. 따라서 교내망에 접속해 있을 때만 22번 포트로 ssh 접속을 통해 변경사항을 운영서버에 배포할 수 있었다. 이렇듯 교내망에 접속해야만 한다는 문제도 있었지만, 결국에는 수동으로 배포하다 보니 명령어를 잘못 입력하는 경우도 있었고 배포할 때마다 반복되는 작업을 진행하다 보니 배포 자동화가 정말 절실했다. 2. 배포 자동화 플로우 우선 Jenkins를 이용하여 배포 자동화를 구축하고자 한다. PR이 Master 브랜치로 Merge되면 Github WebHook이 Trigger 된다...

1. 클라우드 서비스로 이전하게 된 계기 현재 교내 서버실에 KIOSEK 서비스가 On-Premise 환경으로 배포되었있고, 이전에는 프론트 개발자와의 지속적인 협업을 위한 개발 서버는 필요할 때마다 내 노트북에서 틀어서 포트포워딩 해주는 방식으로 하였다. 해당 방식은 너무나도 비효율적이었지만, 가용할 물리 서버가 없었고 사실 환경을 하나 더 구축한다는게 귀찮은 점도 있었다. 하지만 한계를 느꼈고, 이번 기회에 개발 서버를 AWS 클라우드 환경에 구축해서 프론트엔드 개발자에게 IAM 계정을 할당하고 필요할 때마다 서버를 껐다 켤 수 있게 할 생각으로 구축하게 되었다. 2. 사용할 AWS 자원 정하기 1. 키오스크 백엔드 어플리케이션과 NGINX 웹서버를 운영 할 EC2 인스턴스가 먼저 필요했다. 해당 시..

1. 문제상황 Repository단에서 Command와 Query를 분리하여 책임을 분리함으로써 코드 응집도와 유지보수성을 높이고자 하였다. 이에 처음 시도했던 방법은 아래와 같다. Create, Update, Delete를 담당할 CommandableRepo Interface와 Read를 담당할 QueryableRepo Interface로 나누었다. 구현체는 CommandRepo, QueryRepo로 구현한다. 하지만, 문제가 생겼다. 어떠한 엔티티를 save해야 하는 상황을 가정할 때, 중복조회나 다른 조회 메서드를 이용해야 하는 상황이 주로 발생했다. 이럴때, Repository를 사용해야 하는 Service 계층에서 의존성이 너무나 많아지는 문제가 발생했다. 2. 문제해결 과정 1 - interf..

"테스트 코드는 선택이 아닌 필수다" 이전 다른 프로젝트에서는 테스트 코드가 없어서 포스트맨으로 API 테스트할 때는 잘 되다가 예기치 못한 오류가 나곤 했었다. 코드를 리팩터링 하거나 로직을 수정할 경우에 발생하는 휴먼 에러 또는 예기치 못한 에러를 여러 케이스로 작성해 놓은 테스트 코드 덕분에 방어할 수 있었다. 생각보다 리팩터링을 할 때 실수가 생기는 자주 생겼는데, 코드 수정 후에 테스트 코드를 실행시켜 보는 습관을 들여놓음으로써 어느 부분에서 장애가 났는지를 빠르게 확인할 수 있었다. 기존에 잘 동작하던 테스트 코드가 갑자기 실패한다는 것은 내가 방금 수정한 부분이 잘못됐다는 것이기 때문이다. 이번 프로젝트를 진행하면서 단위 테스트에 대한 모호했던 생각들이 정리되었고, 통합 테스트 코드를 통해 ..

365일 24시간 장애 모니터링을 하지 않으면 즉각적인 대응이 불가할 것이라 생각한다. 어떤 식으로 기업에서는 이를 해결하는지 찾아보다가 AWS CloudWatch에 대해서 공부해 보게 되었다. 전체적인 흐름은 아래와 같다. CloudWatch에서 알람 발생 -> SNS 푸시 서비스 호출 -> Lambda 함수 트리거 -> Slack 채널로 알람전송 1. Slack 우선 Slack에서 새 워크스페이스를 생성하고 설정에서 web hook을 추가해준다. web hook이 정상적으로 동작하는지 확인하기 위해 아래 예시 명령어를 복사하여 터미널에서 실행시킨다. OK가 뜨면 정상적으로 설정된 것이다. OK가 뜨면 그 뒤에 slack channel에 들어가면 아래와 같은 메시지가 나오는 것을 볼 수 있다. 이제 w..

✢ 프로젝트에서 헥사고날 아키텍처를 적용하기로 했고, MSA 방식으로 각자 분리된 담당 서비스를 개발한다. 아무리 분리된 서비스라고 해도 처음에는 패키지 구조나 네이밍 컨벤션을 정해놓는 게 추후에 서로 코드리뷰할 때 편하고 여러 장점이 있는 것 같아서 미리 설계하였다. 1. 헥사고날 아키텍처 구조 에 대한 것은 이전 포스팅을 확인해주세요. 2023.07.06 - [👨‍👩‍👧‍👦 Project/📩 DevTalk] - 헥사고날(Hexagonal) 아키텍처를 공부해 보자 (with Layered, Clean Architecture) 2. 내가 생각한 패키지 구조 src.groupname ㄴ global ㄴ config ㄴ util ㄴ error ㄴ exception ㄴ handler ㄴ {애그리거트 이름} ㄴ..