Juntiger

기록으로 남기는 배포

업로드 수정 조회수 —

검사 결과와 배포 대상을 기록으로 남겨 같은 릴리스를 반복할 수 있게 만든 과정

한강자리 배포에는 App Store 앱이 호출하는 API와 worker, DB migration, Redis cache, 예측과 push가 함께 움직인다. 이 구성 요소의 적용 순서와 결과를 CI/CD 기록으로 남겼다.

한강자리 백엔드는 CI, container registry, deploy repository, ArgoCD와 K3s를 거쳐 배포한다. 각 단계는 변경이 통과한 검사, image와 desired state를 기록한다.

반복 가능한 배포 경로

검사, image 생성과 desired state 업데이트를 한 파이프라인으로 고정했다.

sequenceDiagram
  autonumber
  participant Dev as 개발자
  participant Git as Git 서버
  participant CI as CI
  participant Registry as 컨테이너 레지스트리
  participant Deploy as 배포 저장소
  participant Sync as ArgoCD
  participant Runtime as K3s
  participant Smoke as 스모크 검사

  Dev->>Git: 변경 브랜치 올리기
  Git->>CI: 검증 절차 실행 알림
  CI->>CI: 기본 검사와 테스트, API 약속 확인
  CI->>CI: 배포 manifest 생성과 검증
  CI->>Registry: 버전 붙은 이미지 만들고 게시
  CI->>Deploy: 운영 원하는 상태 갱신
  Sync->>Deploy: 운영 원하는 상태 읽기
  Sync->>Runtime: 적용 순서와 훅 실행
  Sync->>Runtime: 서버와 작업 프로세스 배포
  Smoke->>Runtime: 상태와 핵심 기능 확인

feature branch에서는 확인만 한다. production desired state 갱신은 보호된 기본 브랜치에서만 일어난다. 브랜치별 권한이 실험 브랜치의 운영 배포를 막는다.

실험 브랜치의 실패는 검증 결과로 끝나고 production image나 deploy repository를 바꾸지 않는다.

배포 전 자동 검사

현재 CI는 빌드와 함께 다음 항목을 확인한다.

단계목적
lintbackend 코드의 기본 오류 확인
testPostgres, Redis를 포함한 API 로직 테스트
localization validate앱 문자열 catalog와 문서화된 key 검증
API 형식 보존API contract와 만들어진 산출물 보존
manifest validationKustomize/Kubernetes manifest가 빌드되는지 확인
image buildbackend image 만들기
security artifactsSBOM, image scan, signing 같은 공급망 검증
deploy repo updateproduction desired state의 image tag 갱신

이 검사는 함께 배포되는 API, worker, DB migration, cache, push와 forecast의 변경 범위를 다룬다.

사람은 자동 검사의 결과와 변경 영향을 확인해 배포 시점을 결정한다.

별도 저장소에 남긴 서버 설정값

애플리케이션 코드 저장소와 production desired state를 분리했다. CI는 이미지를 만들고 deploy repository의 image tag를 갱신한다. ArgoCD는 deploy repository를 보고 K3s 쪽 실행 상태를 맞춘다.

flowchart LR
  Build["애플리케이션 저장소<br/>CI 파이프라인"] --> Image["버전 이미지"]
  Build --> Desired["배포 저장소<br/>원하는 상태"]
  Image --> Release["배포 입력"]
  Desired --> Release
  Release --> Runtime["ArgoCD 동기화<br/>K3s cluster"]

저장소를 나누면 다음 기록을 따로 추적할 수 있다.

  • 코드 commit과 배포 image의 연결을 추적한다.
  • production manifest 변경과 앱 코드 변경을 분리할 수 있다.
  • rollback은 이전 desired state로 되돌리는 방식이 된다.
  • ArgoCD가 실제 cluster 상태와 desired state의 차이를 보여준다.

장애 발생 시점을 조사할 때 코드 commit, image, desired state와 K3s rollout 기록을 한 경로로 추적할 수 있다.

migration과 worker의 배포 순서

백엔드 배포는 API deployment만 바꾸는 일이 아니다. DB schema, bootstrap job, API, worker가 순서대로 맞아야 한다.

ArgoCD의 sync phase와 wave로 migration/bootstrap과 rollout 순서를 지정한다.

flowchart TB
  Wave1["사전 동기화<br/>마이그레이션 또는 부트스트랩"] --> Wave2["핵심 서비스<br/>Postgres Redis API"]
  Wave2 --> Wave3["워커<br/>주차 나들이 예측 푸시"]
  Wave3 --> Wave4["스모크 검사<br/>상태 · 기능 최신성"]

CI는 image 생성과 desired state 업데이트를 반복해서 수행한다. DB migration, worker rollout과 원천 데이터 수집이 함께 움직이는 배포는 sync 전에 변경 범위를 확인하고 적용 뒤 smoke 결과를 확인한다.

iOS 릴리즈와 서버 릴리즈의 시간차

iOS 앱과 백엔드는 배포 주기가 다르다. 서버는 몇 분 안에 바뀔 수 있지만 앱은 App Store review와 사용자 업데이트 주기를 거친다.

그래서 API contract는 보수적으로 다룬다.

  • 이미 배포된 DTO를 깨지 않는다.
  • optional field 추가와 required field 변경을 구분한다.
  • 앱 버전이 섞여 있는 기간을 고려한다.
  • 서버 변경은 앱 rollout보다 빨리 켜질 수 있다.
  • 위젯은 앱보다 더 오래된 snapshot을 볼 수 있다.

이 점 때문에 generated_at, observed_at, freshness, status 같은 메타데이터를 DTO에 명시했다. 여기서 freshness는 값이 얼마나 최신인지 알려주는 필드다. 클라이언트가 알 수 없는 값을 성공 상태로 해석하지 않도록 했다.

배포 기록으로 확인하는 변경 경로

CI job은 API 형식, manifest, image와 supply-chain 산출물을 확인하고 deploy repository에 K3s desired state를 남긴다. migration과 worker rollout의 적용 순서, smoke 결과도 이 경로에서 확인한다. iOS 앱의 App Store review와 사용자 업데이트 기간을 고려해 서버 DTO의 기존 의미를 유지했다.

Comments

댓글

    이미지 확대