📚 배운 것
배포 자동화와 아키텍처
Airbnb 프로젝트 15일 중 7일 차 진행 중이다. 어제, 오늘은 Github Actions을 활용한 배포 자동화를 하였다.
아키텍처는 아래와 같다.
AWS를 활용하였다. VPC을 사용하여 public, private subnet을 구분하여 Web Server와 DB를 구분하였다. 특별한 점으론 DB ec2 네트워크를 private subnet으로 설정하여 외부 User에서 곧바로 접속할 수 없도록 하였다. VPC NAT Gateway를 활용하여 아웃바운드만 허용하였는데 VPC NAT Gateway 비용 문제로 ec2를 활용해 NAT을 직접 구현하거나 잠깐 외부 접속이 필요할 때 Elastic IP를 인터넷 게이트웨이에 잠깐 붙여 통신하는 방법을 사용하였다.
자동화 배포 구조는 위와 같다. Github 저장소에 push 한 뒤 merge 과정을 거쳐 배포 브랜치가 최신화되면 Github Actions이 작동한다.(작성한 워크플로우) 크게 빌드와 배포로 구분하였다.
빌드 과정에서 위에처럼 Docker Hub에 최신 코드가 빌드된 jar를 Docker image를 push 한다.
배포 과정에서 Github Actions이 ec2에 접속하여 해당 Docker image를 pull 받아 빌드하고 있다.
문제점 : 빌드, 배포 완료했지만 Spring 서버가 런타임에 문제가 발생한 경우
gradle에서 build가 문제없이 되었고 Docker image가 Docker Hub에 정상적으로 push 되었다.
ec2에서 docker hub image를 pull 받아 배포하였다. Github Actions에서 작성한 워크플로우는 여기까지 작성되어있다.
하지만 문제는 docker에 뜬 spring 서버가 죽는 문제가 발생했다. 문제는 spring 서버 런타임 시에 DB 연결 문제가 발생했고 실행된 컨테이너는 꺼져버렸다.
이유 : gradle build 할 때 테스트를 어떻게 통과했을까?
테스트, 빌드엔 통과했지만 실제 런타임엔 작동하지 못했다. 왜냐하면 test 환경의 application.yml과 운영의 application.yml이 달랐기 때문이다. 테스트 환경의 db와. sql 파일들이 달랐기 때문이다. Github Actions 워크플로우가 컨테이너 작동 확인까지 하지 못했다.
고민, 해결 방법
- 배포 직전 운영 서버를 실제로 작동해본다.?
- Github Actions에서 배포 과정을 확인하는(docker에 뜬 web server 확인) 워크 플로우를 추가한다.
데이터베이스 테스트
드디어 책 단위테스트를 다 읽었다. 오늘 읽은 내용 중 감명 깊게 본 한 줄은 아래와 같다.
ch10 데이터베이스 테스트 중
테스트 코드를 잘 작성하려면 제품 코드가 좋아야 한다. 반대로 제품 코드가 좋아야 좋은 테스트를 작성할 수 있다. 서로 영향을 미친다.
데이터베이스를 테스트 코드도 마찬가지이다. 좋은 데이터베이스 테스트 코드를 작성하다 보면 역으로 데이터베이스의 상태도 좋아진다.
모르는 사람 주도 개발
현재 팀원과 함께 모든 과정을 페어 프로그래밍으로 하고 있다. 종종 특정 기술에 대해 익숙하지 못한 사람이 주도하여 개발하는 방법을 해보고 있다. 예를 들어 VPC private subnet 설정에 대해 나는 잘 모르고 팀원은 잘 알고 있다. 이때 private subnet 설정은 잘하는 팀원이 아닌 못하는 내가 구현하고 모르는 것에 대해 잘하는 사람에게 묻는 방법이다. 반대로 nginx 설정에 대해 내가 잘 알고 팀원이 잘 모른다면 팀원이 해보는 것이다. 개발 효율적으론 떨어질 수 있지만 학습과 팀워크에선 좋은 방법이었습니다. 현재 프로젝트는 시간에 쫓기지 않기 때문에 좋은 방법으로 생각된다. 회고로 되돌아보니 아, 이게 페어 프로그래밍이지 참.. 하는 생각도 든다.
댓글