[Infra] 무중단배포 전략

이열음·2022년 9월 29일

터놓고 인프라 구축기

목록 보기

3/8

로드밸런싱을 활용하여 요청을 분산시켜 운영 중인 서비스를 중단하지 않고 신규 소프트웨어를 배포하는 기술이다. 서비스 장애와 배포의 부담을 최소화시키고 서버나 프론트엔드를 업데이트해도 사용자 입장에서는 끊기는 시간이 없게 느껴진다.

- 서버 1을 라우팅에서 빼고
- 서버 1 배포
- 서버 1 라우팅 추가
- 서버 2 라우팅 빼고
- 서버 2 배포
- 서버 2 라우팅 추가

- 서버 1만 연결 서버 2는 라우팅에서 빠져있음
- 서버 2 배포
- 서버 1 라우팅 끊고 서버 2로 라우팅 추가

아힝구

EC2 단위의 부하분산 경험을 포기하고 경제적인 판단력을 어필하는게 지금 서비스 사이즈에선 좀 더 설득력이 있을 것 같음

학습을 위해서는 인스턴스를 여러개로 늘려서 로드밸런싱을 IP 단위로 하게하는게 맞긴함

근데 면접때 뭔가 근거를 물어보면 학습을 위해서라는 대답보다는 좀더 현실적인 이유를 대고싶음

프로젝트가 끝나는 시점을 기준으로 한다면 우리 서버에 들어올 예상 트래픽은 많아봤자 150명
진짜 서비스라고 가정했을때 로드밸런싱으로 부하분산해야할 크기일까? 나누기엔 쏘스몰
가뜩이나 우리는 이번 4기 활동내에서 주요 타겟층이 우테코로 한정되어있음
확장할 계획은 있으나 계획 자체가 불투명하기때문에 지금 유저가 늘어날 상황을 가정해서 ec2 리소스를 추가적으로 쓰는건 다른 사람이 들었을때 경제적인 판단이 아니라는 생각이 들 것 같음.

서버 버전이 바뀌는 시점이 똑같고, 신버전에 한해서 요청을 받게되기 때문에 사용자입장에서는 언제나 일관된 경험을 할 수 있음

우리 서비스가 현재 메인기능 개발을 마치고 유지보수에 집중하는 단계라면 부하분산덕에 효율적이겠지만 우리는 릴리즈와 개발을 동시에 진행하고 있기때문에 아무래도 더 안전한 방향을 택하는게 좋겠다고 생각함

롤링은 PROD 배포시 에러를 발견해도 교체를 끊기가 애매함 + 롤백이 어려움

이 설계는 서버 어플리케이션이 올라가자마자 새 버전에 포워딩을 통해 사용자를 받게 됨 + 하나 완료되면 다른 EC2에 떠있던 애들도 차례차례 자동으로 새버전 교체됨
만약 어플리케이션이 정상적으로 동작하지만 dev단계에서 발견하지 못한 에러가 있다면?
- 교체 도중에 발견했을 시, 다른 EC2를 새 버전으로 교체되는걸 막기 애매함
  - 중간에 멈추면 어떤 유저는 구버전, 어떤 유저는 신버전을 보고있게되니까
- 교체 이후에 발견했을 시, 이미 다 업데이트 된 버전(에러터진 버전) 일거라 롤백하기가 어려움
- 1개 업데이트 중 1개 구버전일때 구버전 EC2로 부하가 쏠림(천만명..)

먼가.. 카나리가 사실 이상적이고 좋은데, 네트워크 관리비용이 클 것 같음.
구현이 어려울 것 같아서 제한시간내에 하려면 블루그린 거의 확정으로 갈듯...?
프론트는 그대론데 백엔드만 API스펙을 변경해서 배포하게 되면 프론트에선 터지지않을까? 두개를 동기화하는 방식 연구해보기.
순차적으로 업데이트되는 전략(카나리나 롤링)을 사용하게 되면 프론트가 받게되는 요청이 일관적이지 않음. -> 버저닝이라는게 있다는데 한번 알아볼 것!