정적 파일, 웹 서버, DB 스키마까지 무중단 배포 시도하기(1) - 무중단 배포 과정 계획하기

하루스터디 서비스에서 다음 핵심 기능인 '스터디 실시간 함께 진행하기'를 테스트 서버에서 시험 중이다.

기존의 기능에선 같이 하기 과정에서 진행도를 공유할 수 없어 여럿이 함께 한다는 느낌을 받기 어렵다는 평이 많았다.

 

통계를 보았을 때 현재는 개인 사용자 수가 그룹 사용자에 비해 압도적으로 높은 상황이다.

새로운 기능을 통해 개인 사용자 외에 그룹 사용자 또한 스터디를 함께 진행하기를 기대한다.

 

실시간으로 참여자를 확인하며 진행도를 공유 가능하다.

 

이번 기능으로 인해 기존의 로직이 변경되는 부분이 굉장히 많았다.

프론트의 정적 파일과 웹 서버의 로직은 당연하며 기존의 DB 스키마까지 변경되는 부분이 있었다.

실사용자들이 주요 쓰는 혼자 하기 기능까지 변경의 영향을 받아 중단 배포를 해야 할까 고민하였으나

복잡하지만 무중단 배포가 가능하여 고려한 부분들을 정리해보고자 한다.

 

---

0. 진행 계획

 

WAS 혹은 배포되는 정적 파일만 바뀌는 경우 남는 EC2가 있어 간단히 Blue Green 방식으로 배포를 진행하면 되나 이번 업데이트에서는 변경되는 포인트가 너무 많아 Rolling 배포를 진행하기로 했다. 고려해야 할 상황은 다음과 같다

 

• 동기화 기능이 추가된 정적 페이지를 받은 사람과 구버전 페이지에 머무르는 사람은 스터디를 같이 진행할 수 없음
• 구버전 페이지 사용자를 점차 신버전 페이지를 사용하도록 넘겨줘야 함
• 무중단으로 유지해야 하는 '혼자 공부하기' 기능 또한 새로운 기능으로 인한 변화에 영향을 받는다

 

중간 단계의 정적 페이지(V1.5)를 준비해야 했고 아래와 같이 계획을 짰다.

 

 

 

'혼자 공부하기' 기능만 사용 가능하게 한 뒤 DB 스키마 변경하기 (1, 2단계)

모두 혼자만 이용하는 기능만 존재한다면 업데이트가 간편했겠지만

이전 페이지와 신규 페이지에서 타인과 함께 스터디를 진행하는 건 아예 호환이 되지 않아 일시적으로 해당 기능을 막아두어야 했다.

 

 

대규모로 변경하려고 하는 개설 및 참여 기능은 불행인지 다행인지 최초 방문자들이 몇 번 이용한 뒤 이용자가 거의 없어...

호환성을 고려해 중단하되 '혼자 공부하기' 기능만 중단이 없도록 한다

 

같은 시점에 DB 스키마 변경점을 해결한다. 다음의 두 가지를 해소해야 한다.

• 일부 테이블 이름 변경
• 일부 컬럼에 해당하는 데이터가 이름이 바뀐 다른 테이블로 이전

 

정적 페이지의 1.5 버전은 1 버전의 웹 서버와 1 버전의 DB를 사용해야 한다.

테이블의 이름을 단순히 바꾸면 1 버전의 웹 서버와 2 버전의 웹 서버가 사용되는 데이터 정합성이 깨지므로 기존 데이터를 카피한 DB를 2 버전의 웹 서버가 사용하도록 한다.

 

카피 이후 기존 버전의 테이블에 저장되는 데이터는 실시간으로 신규 테이블들에 바뀐 컬럼에 맞게 반영되어야 한다(Master - Slave 구조에서 Log를 읽어 알아서 업데이트하듯). 만약 기존 버전에만 데이터가 저장된다면 업데이트 이후 스터디를 진행한 사용자가 스터디 기록을 조회했을 때 기존 버전에서의 기록을 바로 볼 수 없는 문제가 발생한다.

 

업데이트 도중 간단하게 짧은 간격의 DB 스케줄을 통해서 기존 테이블에 적힌 신규 데이터를 새로운 테이블에도 기록해 주면 PK가 다르다는 것 외에는 같은 데이터를 온전히 옮겨올 수 있다.

 

 

2 버전의 페이지와 웹 서버 배포하기 (3, 4, 5단계)

 

DB 정합성 문제는 해결했으니 2 버전의 웹 서버를 띄우고 NGINX를 통해 신규 접속자는 2 버전의 페이지만 받아가도록 수정한다.

 

프론트는 React를 사용하여 랜딩 페이지에서 1회 index.html을 받아가고 페이지를 넘길 때마다 해당 페이지에 대한 JS를 받아가도록 되어 있었는데 이 부분에서 문제가 생기지 않는지 꼼꼼한 검토가 필요했다.

 

아직 1 버전을 사용 중이던 사용자는 1 버전에 해당되던 JS를 받아가야 하는데 2 버전을 배포한 시점부터 2 버전의 JS가 응답으로 나가게 되면 JS가 호환되지 않아 기능이 동작하지 않기 때문이었다.

 

다행히도 프론트는 이전 배포부터 버저닝을 통해 배포된 버전에 맞는 JS를 알아서 찾아가는 것으로 변경되어 있었고,

간단히 한 폴더에 1 버전의 JS와 2 버전의 JS를 몰아넣으면 두 버전의 사용자가 공존해도 알아서 자기 버전에 맞는 JS를 가져간다.

 

 

사용자 추이를 보고 1 버전 지원 중단하기 (6단계)

 

마지막으로 구버전의 웹 서버와 DB 테이블을 정리할 차례다.

이 시점은 기존에 Grafana를 통한 모니터링을 구축해 놓았기 때문에 판단이 용이하다.

 

적절히 1 버전의 웹 서버 사용자 추이를 확인한 뒤 서버를 내리고 낡은 DB 테이블과 걸어놓은 스케줄을 걷어내면 된다.

웹이라는 서비스 특성상 맥시멈 하루면 충분하리라 예상된다.

 

 

---

기존의 실 사용자가 가장 많았던 '혼자 공부하기' 기능이 신 기능으로 인한 변화에 함께 영향을 받는 것이 불편했다.

내부적으로는 개발 편의를 위해 '같이하기'를 혼자 하는 것처럼 하여 일부 API를 공유하도록 설계된 것이 문제였다.

추후 '혼자 공부하기' 기능을 별도의 서브 도메인으로 고려하고 다른 API와 구분된 도메인 객체를 사용하도록 분리해 낸다면

이후의 일부 기능에 변화가 있을 때 부분적인 기능 업데이트 선에서 마무리될 수 있을 것 같다.

 

웹 서버만 변경되는 경우 업데이트가 수월한데 DB 및 프론트 페이지까지 동시에 변경되는 작업이어서 지금 가진 자원으로 쉽게 해낼 수 있을지 고민하는 것이 오래 걸렸다. 쉽게 구체적인 해결법이 떠오르지 않아 짧은 중단 배포를 하는 쪽으로 팀의 의견이 모아졌었는데 그래도 조금 더 고민해 보자고 얘기하고 할 만한 해결책을 제안할 수 있어서 뿌듯했다.