[26.10.07] 사내 버셀의 배포와 권한 조회 개선하기

사내 버셀 배포를 자동화하고 배포 상태 확인하기

상황

사내 버셀을 개발하면서 변경 사항을 사내 서버에 반복해서 배포했습니다. 개발할 때마다 수동 배포를 반복하는 것이 번거로웠습니다.

문제

• 수동 배포: 코드를 수정한 뒤 매번 직접 배포해야 했습니다.
• 배포 상태 확인: 이미지 발행과 배포 요청 생성이 끝나도 서버 배포가 성공했는지 확인하기 어려웠습니다.

해결

CI를 통과한 main 커밋을 자동으로 배포하도록 CD를 추가했습니다. 서비스 교체 중에도 받은 배포 요청이 유지되도록 배포 요청 수신과 배포 실행을 분리했습니다.

사내 버셀을 배포할 때는 진행 중인 프로젝트 배포와 기존 프리뷰도 보호해야 했습니다. 기존 Worker가 진행 중인 작업을 마친 뒤 서비스를 순서대로 교체하고 검증하도록 했습니다. 기존 프리뷰와 데이터는 유지했습니다.

CD 실행기가 GitHub App으로 배포 상태를 GitHub Deployments에 보고하도록 했습니다. 서버 배포의 진행 중, 성공, 실패 상태를 커밋별로 기록합니다.

현재는 이 배포 이력으로 실제 서버의 배포 상태를 확인하고 있습니다.

GitHub 권한 조회를 DB 권한 조회로 바꾸기

상황과 문제

GitHub를 SSOT(진실 원천)로 삼아 멤버십과 저장소 권한을 관리했습니다. 하지만 Portal 요청마다 GitHub에서 권한을 순차로 조회하니 프로젝트가 늘수록 응답이 느려졌습니다. 응답이 최대 15초까지 지연되는 문제가 발생해, 직접 개발하면서 사용해도 답답했습니다. API 호출 한도도 Portal 사용에 영향을 줬습니다.

해결

GitHub는 SSOT로 유지하고, Portal은 DB에 저장된 권한을 조회하도록 바꿨습니다. GitHub와의 동기화는 주기적으로 실행합니다.

단점 보완

GitHub와 DB의 권한 상태가 다를 수 있어, 기본 10분마다 동기화합니다. 다음 동기화까지 권한 반영이 늦어지는 것은 허용하고, 다음 처리를 추가했습니다.

• 동기화 실패: 모든 조회가 성공했을 때만 한 번에 DB를 갱신합니다. 동기화 실패 시 과거 데이터가 유지됩니다.
• 사용성 개선: 프로젝트 생성과 가입 요청 직후, GitHub에서 처리한 결과를 DB에도 바로 저장했습니다. 다음 동기화를 기다리지 않고 프로젝트에 접근하거나 가입 상태를 확인할 수 있습니다.

결과

권한 조회를 DB로 바꾼 뒤 응답 시간 p95가 줄었습니다.