Weeth(무중단 배포, DevOps)

서론

Weeth

얼마전에 포스팅을 했었던 가치택시라는 가천대학교 학생들 대상으로 AI 공학관 또는 기숙사까지 택시를 공유해서 탑승할 수 있는 서비스보다 더 먼저 시작되었던, 그리고 현재까지 진행하고있는 프로젝트가 있다
2024년 1학기 Leets 3기에서 진행했었던 Weeth라는 동아리 관리 서비스이다

항상 예쁜 디자인 만들어주는 예진님께 무한한 감사...

위 사진을 보면 알 수 있듯이 Weeth의 주요기능은 동아리 일정 + 캘린더, 출석+패널티, 게시판, 회비, 멤버(조회) 등 크게 5가지로 나누어져있다. 먼저 해당 5가지 주요 기능들에 대해서 간단히 설명해보겠다

동아리 일정, 캘린더

먼저 캘린더 기능을 통해 Leets 동아리의 일정을 한 눈에 볼 수 있고, 동아리 운영진만 관리할 수 있게 구현하였다

동아리 출석하기

또한 출석은 정기모임 당일에 직접 제공되는 출석 코드를 사용해 출석을 진행한다. 정기모임 전에 랜덤으로 생성된 출석 코드를 통해 정기모임이 진행될 때만 출석 체크가 가능하도록 구현하였다
출석 코드는 관리자 페이지에서 확인할 수 있으며, 정기모임이 종료한 후 출석 마감을 통해 출석을 관리를 할 수 있도록하였다

공지사항 및 스터디 게시판

공지사항은 운영진만 관리할 수 있게 구현되었고, 스터디 게시판의 게시글, 댓글, 대댓글 작성은 동아리원 모두가 자유롭게 사용할 수 있도록 하였다. Leets에서는 매주 스터디 발표를 진행하기 때문에 발표자료의 파일 첨부까지 가능하도록 게시판을 구현했다

멤버 조회 및 상세 조회

회비 및 영수증 확인

또한 멤버 기능과 회비 기능은 위 사진과 같이 구현되었다

---

들어가며

해당 동아리 관리 서비스 프로젝트인 Weeth는 2024년 6월부터 개발을 시작하여
2024년 9월에 Leets 4기 25명 정도의 인원을 대상으로 성공적으로 운영되었다. 그리고 2025년 1월, 현재까지 5기를 대상으로 운영될 수 있도록 꾸준히 리팩토링 되고있는 만큼 UI도 정말 많고 API도 엄청나게 많다

현재까지 개발된 수많은

Weeth의 api들

 

TMI로는 해당 프로젝트가 처음이였던 나는, Weeth를 진행하며 전체적인 프로젝트의 흐름 자체를 배울 수 있었고,
프로젝트를 진행하며 기본적인 내용들부터, 다른 부분들까지도 너무 많이 배우게 되어서 같이 진행하는 백엔드, 프론트, 디자인 팀원들에게 너무나도 감사한 마음을 가지고있다

---

본론

진행하고 있는 프로젝트의 대한 설명으로 인해서 서론이 너무 길었지만, 현재 그래서 5기를 대상으로 운영하기 위해 UI라던지 도메인이라던지 세세한 부분 하나하나 리팩토링이 되어가고있다. 
해당 내용에 대한 여러 작업들을 진행하며 꾸준히 회의하던 중에, 팀장인 강혁이의 의견으로 개발서버의 무중단 아키텍처가 도입되면 좋겠다라는 의견이 있었다.

 

현재 Weeth의 개발서버는 GitHub Actions + Docker + EC2 + RDS로 운영중인데, 8080포트를 사용하며 코드의 수정사항이 생겨서 새로 도커 이미지를 pull 해오고 실행되는 과정에서 다운타임이 발생하는 구조였다

나는 얼마전에 가치택시 프로젝트를 진행하며 무중단 배포를 라즈베리 파이로 구현을 해봤었기에 내가 해당 부분을 맡아 개발을 진행하게되었다. 해당 자세한 내용은 아래의 게시글을 참고해주면 더욱 좋을거같다

가치택시(무중단 배포)

---

구현사항

이슈 내용

이전에 무중단 배포 플로우를 참고하면 구현하는데 어려울거 같지 않았기에, 이번에도 이전 플로우와 동일한 방식인 blue/green 방식으로 구현하려고 생각하였다.
이전과 달랐던 점이 있었다면, 가치택시는 로컬 개발 환경이기때문에 8080, 8081 이런식의 자체 주소를 가지고 별도의 배포된 환경이 없었지만, Weeth는 캐디를 통해 배포된 환경이 있었다는 점에서 리버스 프록시 설정 또한 고려를 해줘야하는 부분이였다

---

도커파일 

Dockerfile -dev

Leets에서 현재 4기에 해당하는 유저들이 서비스를 이용 중에 있었기에,
운영서버인 prod 에서 Dockerfile-prod, 개발 환경에서는 별도의 Dockerfile-dev라는 이름으로 분리되어 도커파일을 사용하고 있었다 

---

deploy 스크립트

그리고 무중단 배포 스크립트는 다음과 같다, 
아래 사진과 같이 8080포트를 BLUE, 8081포트를 GREEN으로 지정을 해준 뒤, 현재 실행중인 컨테이너가 어떤 포트인지 확인한다

deploy 스크립트 초반 부분

다음 단계로 BLUE 포트가 실행중 이였었다면 GREEN, 반대로 GREEN 포트가 실행중이라면 BLUE 포트가 실행되도록 작성하였다

실행중인 컨테이너 확인 후 새로운 컨테이너 실행

만약 둘다 실행되지 않는 상태라면, 이전 컨테이너 비정상 종료나 초기상태로 가정하고 BLUE 컨테이너가 실행되도록 했다

초기상태시 BLUE 컨테이너 실행

도커 컨테이너는 실행 된 후에 초기화 되는데의 시간이 필요하기에  30초 대기 시간을 설정해 주었고, 그 뒤에 최대 5번의 Health-Check를 수행하여 HTTP 상태 코드 200 응답을 확인시, HEALTHY를 true로 설정해주어 서버의 정상 작동을 확인해주었다 

컨테이너 실행 후 대기시간, Health-Check

다음 단계로는 Health-Check를 통해 서버의 상태를 확인해준뒤, 서버가 정상 실행 중일때에만 리버스 프록시 설정을 업데이트를 해주고 캐디를 재시작 할 수 있도록 하였다

캐디 관련 설정

모든 과정이 종료된 후에는  기존 컨테이너를 중지 및 삭제하고 사용하지 않는 이미지를 정리할 수 있도록 했으며
만약 Health-Check를 진행하였는데 서버가 정상 실행 중이 아니라면 이전 컨테이너의 상태를 유지할 수 있도록 하였다

기존 컨테이너 관리 및 Health-Check 실패시 롤백

---

트러블 슈팅

8080포트만 고정적으로 실행되는 문제

먼저 맨처음 막혔던 부분은, CICD 워크플로우에서 환경변수로 weeth.env 파일을 사용하면서 도커 run을 진행할때 자동으로 실행하는 포트가 8080으로만 고정되어 진행되는 오류가 발생했다.
해당 원인은 weeth.env 파일 내부에서 서버포트 번호 설정이 안되어있어서 실행하는 포트가 8080으로 자동으로 덮어씌워지는 오류였었다. 해당 내용의 해결을 위해서 아래 내용과같이 application-dev.yml에 서버포트 관련 환경변수를 새로 설정해주었다

server:
  port: ${SERVER_PORT}

해당 내용으로 수정 해준 뒤에, 서버에 SSH로 접근하여 sudo nano weeth-dev.env로 SERVER_PORT 또한 설정해주어 해결하였다

---

Health-Check 실패

두번째 막혔던 내용은, 아래 사진처럼 Health-Check에 지속적으로 실패했던 내용이다

첫 응답 실패 후, 5번 모두 Health-Check 실패

해당 문제는 컨테이너가 완전히 구동되기 전에 헬스 체크가 시작되어, 서버가 요청을 처리할 준비가 되지 않은 상태라는 사실을 알게되어 헬스 체크 전에 충분한 대기 시간을 추가해주어서 해당 문제를 해결하였다

---

Caddy 리버스 프록시 설정시 들여쓰기 문제

원래는 아래 내용처럼 리버스 프록시 설정 스크립트를 작성을 했었다

# Health-Check 결과 확인
if [ "$HEALTHY" = true ]; then
  echo "** Health-Check 성공: ${AFTER_NAME} 컨테이너 정상 작동"

  # 리버스 프록시 설정 업데이트
  echo "** 리버스 프록시 설정 업데이트"
  sudo tee /etc/caddy/Caddyfile <<EOF
{
    admin 0.0.0.0:2020
}
3.38.193.157.nip.io {
    reverse_proxy localhost:${AFTER_PORT}
}
EOF

하지만 sudo tee 명령어의 동작 원리와 EOF 사용법으로 인해 지속적으로 들여쓰기와 관련한 문제가 발생하였었고, 

bash: line 108: warning: here-document at line 82 delimited by end-of-file (wanted `EOF')

캐디 설정이 우리 워크플로우 상에선 if 조건문 안에 들어갔어야해서 지속적으로 발생하는 오류였었다는 사실을 깨닫고, Here Document 블록을 조건문 바깥으로 빼주는 내용으로 수정해서 트러블 슈팅을 완료하였다

리버스 프록시 관련 설정

---

느낀점

Blue/Green 배포 방식 자체는 이전 가치택시 프로젝트에서 이미 경험해본 적이 있었기에 익숙해서 금방 할 수 있을거라고 생각했었지만, 아예 환경 자체가 달라지면서 새로운 트러블들이 발생했었다. 해당 내용들을 많이 테스트하면서, 트러블 슈팅을 진행하며 문제가 해결됐을때의 뿌듯함이 느껴져서 너무 좋았던거같다
또 실제 운영 서버 환경에서는 Caddy를 활용한 리버스 프록시 설정이나, Health-Check를 통해서 서버의 상태를 확인하는 스크립트를 작성하는 등등의 경험은 앞으로 다른 프로젝트에서도 큰 도움이 될 수 있겠다라는 생각 또한 들었다

앞서 서론에서 보여줬던 Weeth의 UI들은 리팩토링 된게 아니여서 추후에 5기를 대상으로 서비스를 진행하며 느낀점에 대한 게시글로 돌아오도록 하겠다(Weeth 프론트 디자이너 짱)