홈페이지에 뭔가 자꾸 얹고 싶은 욕심이 들 때 마다 빌드를 했더니, 그 사이에 가끔 접속하는 사람이 종종 있긴 한것 같다.
그러다 보니 서치콘솔에서 점수가 점점 하락하는 현상이 발생했다.
이대로는 안될 것 같아 무중단 배포를 하는 방법을 생각해 보게 되었다.

1. 대표적인 무중단 배포 방식
1) Green-Blue 배포

가장 대표적인 배포 방식이다.
Blue는 현재 서비스중인 버전이고 Green은 새로 배포할 서버이다.
현재 내 서버에서 트래픽은 Caddy가 담당하고 있으므로, Caddyfile을 수정하면 구현할 수 있다.
두 버전을 운영하면서 문제점을 살펴보고, 이상이 없으면 Blue를 제거하고 Green으로 전환 한다.
3000번, 3001번 포트를 이용하면 구현할 수 있다.
2) 롤링 배포

여러대의 서버가 동시에 서비스 하고, 일부 서버만 새 버전으로 교체하면서 트래픽을 유지하는 방식이다.
나 같은 경우에는 서버가 1개 뿐이므로, 서버를 교체하고 싶을때도 가능할 듯 하다.
3) 카나리 배포

트래픽 중 1~10% 정도를 새 버전으로 전달한다.
위 그림에서 Load Balancer는 Caddy나 Nginx같은 프로그램을 이용하면 된다.
4) 무엇을 선택해야 하나?
이 셋 중에서 가장 현실적인 것은 블루-그린 배포이다.
개인 블로그 굴리는데 서버를 하나 더 둘 필요는 없고, 오류를 일으킬만한 큰 업데이트도 없을 것이다.
그리고 무엇보다 구현이 쉽다.
2. Blue-Green 배포 구현하기
정답은 의외로 간단한데, 터미널을 2개 켜는 것이다.
하나에서 build를 하면, 나며지 터미널에서 서버가 돌아가는 것.
문제는 하나의 프로젝트 안에서 두개의 터미널을 켜는건 충돌이 일어난다.
하나가 잘 실행되고 있다고 해도, 다른 터미널에서 build를 하는순간 .next 폴더가 새롭게 만들어지기 때문에 내부 오류가 발생하면서 결국 홈페이지가 중단되는 것.

그래서 기존에 있는 프로젝트와 똑같은 폴더 하나가 더 필요하다.
나는 이미지도 모두 로컬로 저장하고 있었기에, blogCopy라는 복사된 프로젝트는 원본 폴더를 보도록 수정해 두었다.
이제 Caddy를 손봐주면 된다.
3. Caddy 공식문서
챗지피티랑 클로드도 잘 모르는지 둘이서 자꾸 이상한 소리만 해대서 결국 공식문서로 들어갔다.
공식문서에 있는 예제는 아래와 같았다.
example.com {
reverse_proxy node1:80 node2:80 node3:80 {
health_uri /healthz
lb_try_duration 5s
}
}그런데 이건 세개의 노드에 균등하게 요청을 할당하는 것이라 다른 방식이 필요했다.
인공지능은 계속 아래와 같은 방식에 집착했는데, 집어넣으면 리버스 프록시가 멈춰버렸다.
example.com {
reverse_proxy localhost:3000 localhost:3001 {
health_uri /health
health_interval 5s
health_timeout 2s
health_status 200
}
}일단 이것의 문제는 어떤 포트가 주된 것인지 정의하지 않았다는 것.
그리고 캐디가 5초마다 포트를 점검하기 때문에, 실행 후 5초가 지나기 전에는 제대로 된 포트로 접속할 수 없다.
그래서 그냥 수동으로 잡아주기로 했다.
example.com {
reverse_proxy localhost:3000 localhost:3001 {
lb_policy first
fail_duration 20s
max_fails 2
}
}그냥 사용자의 접속에 실패를 읽고 포트를 돌려주는 방식으로 바꾸었다.
이렇게 하니 잘 작동한다.
4. 후기
이제 마음껏(?) 빌드 할 수 있게 되었다.
가끔은 빌드하다가 오류가 뜨거나 하면 너무 서버를 오래 멈추는게 아닌가 싶어서 조마조마 했다.
이제 앞으로 그럴 일은 없을 것 같다.
매일 배우고 있는데, 또 배워야 할게 계속 나온다는데 신기히다.

댓글을 불러오는 중...