배포 검증 및 롤백 프로세스 정립 - 100-hours-a-week/KTB4-16th-Cloud GitHub Wiki

배포 전 체크리스트

API Key, 환경 변수

• API 키가 코드에 직접 들어있거나 노출하고 있지는 않은가?

  • API 키가 노출되면 다른 사람이 우리 서비스의 권한으로 API를 호출할 수 있다.
  • 그로인해 예상하지 못한 요금이 발생할 수 있다.

• .env 파일이 GitHub에 올라가지는 않았는가?

  • env 파일에는 DB 비밀번호, API 키, 인증 토큰 등 민감한 값이 들어갈 수 있습니다.
  • GitHub에 커밋하면 저장소 접근자가 이를 확인할 수 있고, 파일을 삭제해도 과거 커밋 기록에 남을 수 있다.
  • 따라서 현재 파일뿐 아니라 커밋 이력에도 포함되지 않았는지 확인해야 합니다.

• CD도구 배포 로그에 토큰, 비밀번호가 노출되지는 않았는가?

  • 토큰과 비밀번호가 노출되면 계정 도용으로 이어질 수 있다.

Database

• 데이터베이스 보안 규칙이 의도한 대로 설정되어 있는가?
  • 필요한 서버와 계정만 필요한 작업을 수행하기 위해
  • 범위를 너무 넓게 잡으면 불필요한 외부 접근이 가능할 수 있다.
• 배포 전 데이터베이스 백업이 완료되었는가?
  • 배포 과정에서 문제가 생기면 롤백해야하는데 애플리케이션을 이전 버전으로 롤백해도 이미 변경되거나 삭제된 데이터까지 복구되지는 않는다.
  • 따라서 문제가 발생했을 때 데이터를 복원할 수 있도록 배포 전 백업이 정상적으로 완료되었는지 확인해야 한다.

Infra

• 로그에 토큰이나 개인정보가 출력되지 않는가?

  • 로그는 파일, CI/CD 시스템 등 여러 곳에 저장되고 다양한 사람이 열람할 수 있는데, 요청이나 본문을 그대로 출력하면 인증 토큰, 비밀번호등 개인정보가 함께 남을 수 있다.

• HTTP -> HTTPS 리다이렉트가 적용되어있는가?

  • HTTP 통신은 암호화되지 않아 전송 중인 정보가 노출되거나 변조될 수 있기 때문에, 사용자가 HTTP 주소로 접속하더라도 HTTPS로 이동하도록 설정해 암호화된 연결을 사용하게 해야 합니다.

• 장애 발생 시 사용할 이전 배포 이미지가 보관되어 있는가?

  • 새 버전에 문제가 생겼을 때 이전에 정상 동작하던 버전을 빠르게 실행하기 위해

• 롤백 준비가 되어있는가?

  • 문제가 생기면 빠르게 복구해야하는데 롤백 준비를 해두지 않으면 실행 명령, 환경 변수 설정 등 복구 시간이 지연된다.

• Secret이 GitHub Secrets에 전부 등록되어 있는가?

  • GitHub Actions의 배포 과정에서 필요한 Secret이 빠지거나 이름이 잘못되면 인증 실패, 배포 중단, 애플리케이션 실행 오류가 발생할 수 있습니다

https://leevigong.tistory.com/29

https://secufi.kr/checklist

https://wikidocs.net/410366

배포 성공 및 실패 판정 기준 정의

배포 성공 기준

• CD 배포 파이프라인이 정상적으로 동작했는가?

  • 사전에 정의한 필수 작업이 빠짐없이 완료되었는지 확인해야한다.

• 실행 중인 이미지의 태그가 대상 커밋으로 빌드한 이미지와 일치하는가?

  • 의도한 코드가 실제 서비스에 반영되었는지 확인해야한다.

• 실제 서비스 도메인을 통해 HTTPS 접속이 가능한가?

  • 사용자가 실제로 접근하는 경로에서 서비스가 동작하는지 확인해야 한다.

• 핵심 기능 API Smoke Test가 성공했는가?

  • 배포 직후 로그인, 자물쇠 데이터 조회, 저장 등 필수 기능이 동작하는지 확인하기 위해서

• 정해진 API별 응답 시간을 충족하는가?

  • 오히려 배포 후 쿼리 성능이나 외부 서비스 호출 속도가 나빠지지 않았는지 확인해야 한다.

• 핵심 API가 각 상황에 맞는 HTTP Status를 반환하는가?

  • 클라이언트가 각 기능의 요청의 성공, 실패를 올바르게 판단하고 처리할 수 있는지 확인하기 위해서다.

• 배포 후 Docker Health Check가 5분 간 정상 상태를 유지하는가?

  • 애플리케이션이 시작된 직후뿐 아니라 일정 시간 동안 정상 상태를 유지하는지 확인하기 위해서다.

• 애플리케이션 로그에 치명적인 오류가 없는가?

  • 사용자 요청이 겉으로 성공해도 내부 작업 처리가 실패할 수 있다.

• 브라우저 콘솔 및 서버 로그에 민감한 정보가 노출되지 않는가?

  • 디버깅 출력에 포함된 토큰, 비밀번호, 개인정보가 로그 열람자에게 노출될 수 있다.

• 데이터베이스에 데이터가 정상적으로 저장되는가?

  • API가 성공 응답을 반환해도 트랜잭션 롤백이나 저장 오류로 데이터가 남지 않을 수 있다.

• 배포 후 30분 동안 오류율과 응답 시간이 허용 범위에 있는가?

  • 짧은 테스트에서는 실제 트래픽에서 발생하는 자원 부족, 특정 요청의 오류를 놓칠 수 있다.

• Storage에 파일이 변조되지 않고 업로드 되었는가?

  • 이미지 업로드가 실패하면 사용자가 등록한 이미지를 조회하거나 사용할 수 없다.

배포 실패 기준

• CD 파이프라인의 필수 단계가 실패하거나 제한 시간 내 완료되지 않는다.

  • 필수 작업이 완료되지 않았다면 의도한 배포 상태를 보장할 수 없다.

• 실행 중인 이미지가 배포 대상 이미지와 다르다.

  • 검증한 코드와 실제 실행 코드가 달라 수정 사항이 반영되지 않았거나 예상하지 못한 동작이 발생할 수 있다.

• 실제 서비스 도메인으로 HTTPS 접속이 불가능하다.

  • 내부 서버가 정상이어도 사용자가 서비스에 접근하지 못하면 서비스 제공에 실패한 상태다.

• 배포 후 Docker Health Check가 정해진 횟수 이상 실패한다.

  • 정상적인 초기화 시간을 지나서도 반복적으로 실패하면 애플리케이션이 요청을 처리할 준비가 되지 않았거나 장애 상태일 수 있다.

• 핵심 API Smoke Test에서 예상하지 않은 HTTP Status나 잘못된 응답 내용을 반환한다.

  • 사용자가 반드시 이용해야 하는 기능이 배포 환경에서 정상 동작하지 않는다는 의미다.

• 오류율 또는 API별 응답 시간이 정해진 시간 이상 초과한다.

  • 일부 요청의 성공만으로는 전체 서비스의 정상 상태를 판단할 수 없다.

• 데이터베이스 연결에 실패한다.

  • DB에 의존하는 로그인, 조회, 저장 등의 기능을 정상적으로 처리할 수 없다.

• 데이터베이스에 핵심 및 부가 데이터가 저장되지 않는다.

  • 성공한 작업이 실제로 반영되지 않거나 잘못된 정보가 남으면 사용자 신뢰가 훼손된다.

• 브라우저 콘솔 및 서버 로그에 민감한 정보가 노출된다.

  • 기능이 정상이어도 인증 정보나 개인정보가 노출되면 보안 측면에서 배포를 성공으로 볼 수 없다.

Docker Health Check

• Docker의 health check는 live, read를 구분하지 않는다
• Docker에서 헬스체크는 하나의 개념이라고 본다.
• 하지만 k8s에선
  • livenessProbe : 컨테이너, 애플리케이션이 살아있는가?
  • readinessProbe : 트래픽을 받을 수 있는 상태인가?
  • 를 정의할 수 있다.
• 그렇다면 docker에서 굳이 하나를 따진다면 어떤 헬스체크를 하는가?
  • DB, 외부 API, 네트워크 상태는 보지 않음
  • 실패하면 컨테이너를 재시작해도 문제 없음
• 따라서 docker에서 헬스체크는
  • 컨테이너가 살아있다라는 것을 확인하는 liveness 성격이다.
  • 도커는 컨테이너 생존만을 관리하지 트레픽 제어는 관여하지 않는다.
  • 그래서 docker 환경에서 트래픽 제어를 하기 위해선
    • Reverse Proxy를 추가하여 역할을 대신하게 해야한다.

https://inpa.tistory.com/entry/Cypress-%F0%9F%93%9D-%EC%9B%B9-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%9E%90%EB%8F%99%ED%99%94-%EC%82%AC%EC%9A%A9%EB%B2%95-%F0%9F%91%80-%ED%95%9C%EB%88%88%EC%97%90-%EC%A0%95%EB%A6%AC

https://structuring.tistory.com/209#google_vignette

https://until.blog/@opstoqa0/%EB%B0%B0%ED%8F%AC%EB%8A%94-%EC%84%B1%EA%B3%B5--%EA%B0%9C%EC%84%A0%EC%9D%80-%EC%8B%A4%ED%8C%A8---%EA%B8%B0%EB%B3%B8%EC%9D%84-%EC%9E%83%EC%9D%80-%EA%B0%9C%ED%8E%B8%EC%9D%98-%EA%B2%B0%EB%A7%90

Cloud SQL

1. 리전 및 영역 가용성 선택

• 단일 영역
• 여러 영역(고가용성)
• 내가 선택한건 단일 영역이다.
  • v1 설계에서 현재 서비스는 고가용성이 중요하지 않다고 설명한 바 단일 영역을 선택했다.

2. 보안

• SSL 모드

  • 암호화 되지 않은 네트워크 트래픽 허용(권장되지 않음)
  • SSL 연결만 허용
  • 신뢰할 수 있는 클라이언트 인증서 필요

• 내 선택은 SSL 연결만으로 결정했다.

  • 사용자 데이터를 다루는 DB 이기 때문에 평문 통신을 허용하지 않도록 선택했다.
  • 신뢰할 수 있는 클라이언트 인증서 필요를 쓰지 않은 이유는
    • 이걸 사용하면 VM에 인증을 위한 개인 키와 인증서를 따로 만들어야한다.
    • 그렇기에 v1 기준 운영 복잡성을 더 가져갈 필요가 없어 SSL을 선택했다.

• 서버 인증 기관 모드

  • 현재 서비스는 하나의 Cloud SQL 인스턴스를 사용하므로 인스턴스 전용 CA로 서버 인증서를 검증할 수 있다.
  • 현재는 여러 DB에 공통으로 적용할 인증서 체계나 자체 CA 정책이 필요하지 않아 CAS 방식은 선택하지 않았다.
  • 그렇기에 Google 관리형 내부 인증 기관을 선택했다.

Cloud Storage

1. 버킷 이름

• 버킷 이름은 유니크 해야한다.

2. 데이터 센터 저장 위치 설정

• 종류
  • Region (단일 리전)
  • Multi-region (폭 넓은 지역에서 높은 가용성)
  • Dual-region (리전 2곳)
  • Zone(단일 영역)
• 내가 선택한건 Region(단일 리전)이다
  • v1은 서울 단일 리전으로 구성하므로 Cloud Storage도 같은 리전에 배치한다. 백엔드와 스토리지 간 통신 거리를 줄이고, 리전 간 데이터 전송 비용을 피한다. 현재는 리전 전체 장애에 대비한 이중 리전 구성을 현재는 도입하지 않는다.

3. 스토리지 클래스

• Standard : 자주 읽음
• Nearline : 30일 이상 보관, 저렴
• Colidline : 90일 이상 보관 가장 저렴
• 사용자 업로드 파일은 서비스 이용 중 반복적으로 조회될 수 있고, 사용자가 수정하거나 삭제할 수 있다. 따라서 최소 저장 기간과 별도 데이터 검색 요금이 없는 Standard를 선택한다.

4. 공개 액세스 방지

• 인터넷을 통해 공개적으로 데이터에 액세스할 수 없도록 제한한다.
• 그로 인해 이 버킷이 웹 호스팅에 사용되지 않게 한다.

5. 객체 데이터를 보호

• 소프트 삭제 정책(데이터 복구용)
• 객체 버전 관리 (버전 제어용)
• 보관 (규정 준수용)
• 실수나 배포 오류로 파일이 삭제되는 경우에 대비해 소프트 삭제를 7일 적용한다. 현재는 파일의 과거 버전 조회 기능과 보관 조건이 없으므로 객체 버전 관리와 보관 정책은 사용하지 않는다.

https://brunch.co.kr/@topasvga/785

총 정리 파일

mulo 장애 대응 문서.md