Meetup Note
AWSKRUG
플랫폼엔지니어링소모임 (2024.04)

AWSKRUG 플랫폼엔지니어링 모임 (2024.04)

Overview

  • Preview Deployment로 베타 환경에 날개달기 - 김요욱 (우아한형제들 프론트엔드 개발자) : 제약없이 자유롭게 배포하면 그대로 새 베타 환경이 되는 Preview Deployment를 소개합니다.
  • 클라우드 권한을 개발팀에 맡겨도 안전한 당근 리소스 플랫폼 - 김승호(당근 SRE) : 클라우드 권한을 개발팀에 열어두는 당근의 문화를 유지하면서, 규칙 기반 리소스 생성과 리소스 가시성을 어떻게 확보할 수 있었을까요? 당근의 리소스 플랫폼을 만들면서 겪은 우여곡절과 앞으로의 고민 등을 나눕니다.

Preview Deployment로 베타 환경에 날개달기 (김요욱, 우아한형제들 프론트엔드 개발자)

TL;DR

  1. 과제는 많고, 베타 배포는 한 번에 하나만?
  2. 베타 환경에 Lambda@Edge로 Preview라는 날개 달기
  3. 모두가 행복한 무한 베타 세상

발표 시작

과제가 이렇게 많은데 베타 환경은 하나라구요??

당시의 상황 : 파트원 11명, 개발 중인 서비스 5개, 협업 팀 무수히 많음

커머스 서비스들이 고도화되고 점점 더 많은 서비스들이 추가되는 중. 그러다보니 점점 협업하는 팀들도 많아지고, 일정도 정말 다양하게 내려오고... 어휴!

그래서 당시의 상황을 생각해보면 물밀듯이 떠밀려 오는 과제의 쓰나미 속에 의연히 서있는 모습...

실제로 어떤 느낌이었는지?

당시에 매주 1개 정도의 배포와 나중에는 격주로 대규모 오픈이 2번에 걸쳐 이루어졌다.

특히 대규모 오픈이다보니까 2주정도 QA 기간이 잡혀있고, 베타 환경에 배포해야하는 상황이 많아진다.

그런데 베타 배포 환경이 하나라서, "베타 배포하고 싶은 사람?"하면 모두가 손을 드는 진풍경이... ^^;

Git Branch 전략

  • feature 1
  • feature 2 -> release A -> beta env
  • ...... -> release B -> (!)

release A 브랜치가 베타 환경을 점유하고 있는 경우, release B 브랜치는 베타 환경에 배포할 수 없다.

그러다보니 각각 서로의 작업이 Blocking 요인이 된다. QA기간도 길어지고 ㅠㅠ 매번 상황을 공유하기도 힘들고 ㅠㅠ 어떡하지?

야 그럴거면 그냥 필요한만큼 늘리면 되는거 아님?

  • 필요한 만큼 : 얼마나? 언제까지?
  • 늘리자 : 배포 인프라 추가, 태그도 달아야하고, CI/CD 파이프라인 생성/연결... 이걸 매번??? ㅠㅠ

그래서 해결하는 방법? : 필요할 때만 쉽게 늘리자!!

  • 필요할 때만 : QA 테스트 시, 새로운 MR 생성 시 등 필요한 시점에 사용이 끝나면 바로 정리
  • 쉽게 늘리자 : 새로 생성하는 인프라 리소스 없이 프로젝트 단위로 간단한 파이프라인 설정만으로

그래서 등장하게 된게...

Preview Deployment

Preview Deployment는 무엇인가? : Preview Deployment는 모든 코드 체인지 혹은 피쳐 브랜치에 대해 생성되는 임시 환경으로, 팀에서 변경점이 메인 코드베이스에 반영되기 전에 리뷰, 테스트, 협업할 수 있도록 한다.

그럼 어떻게 구성하냐? : S3, CloudFront, Lambda@Edge (+ GitLab CI)

그래서 3줄 요약

  1. 많은 인원, 많은 과제, but 베타는 하나
  2. 일정 지연, 관리 포인트 증가, 소통 비용
  3. 필요할 때만 쉽게 베타 테스트 환경 증설하는 Preview Deployment 제작!

실제로 만들어보자!

일단 목표를 좀 더 자세히 잡아보자

  1. 여러 버전을 동시에 배포하고 접속할 수 있도록 해야 한다.
  2. 배포 환경을 늘리더라도 하나의 인프라를 활용하도록 해야 한다.
  3. 새로운 배포와 리소스 정리가 손쉽게 이루어질 수 있도록 해야 한다.

가장 먼저 규칙을 정해보자

(project)_(branch).preview.betabaemin.in -> 사용자 접속 요청 주소를 이렇게 정의해보자

근데 왜 중간에 preview 가 들어가냐? -> SSL 인증서의 범위가 한정되어 있기 때문에 (RFC 2818)

  • *.foo.com 에 인증서를 발급받으면
  • bar.foo.com 은 가능한데
  • baz.bar.foo.com 은 불가능

우회하는 방법은?

  1. Subject Alternative Name (SAN) : 여러 도메인을 하나의 인증서에 포함시키는 방법
  2. 새로운 인증서를 발급받기

그래서?

  • (project)_(branch).preview.betabaemin.in 도메인을 사용하고
  • *.preview.betabaemin.in 도메인에 대한 인증서를 발급받아 사용

하나의 인프라를 활용해서 여러 배포 환경을 만들어보자

  • Viewer Request Viewer -> CloudFront (Lambda) : Host와 URI를 Header에 추가
    • subdomain과 경로 정보, Origin Request에 전달하기
  • Origin Request CloudFront -> S3 (Lambda) : Header로 전달된 subdomain과 경로 정보를 활용해서 어느 버전(디렉토리)의 어떤 데이터(파일)을 결정
    • e.g. CSR : index.html / SSG : {route}/index.html
  • Origin Response S3 -> CloudFront (Lambda) : 오류 예외 처리
    • e.g. URL 오타 입력, 존재하지 않는 리소스 요청 -> 리다이렉트해주거나 오류 메시지같은 것들을 내려보내주기

리소스의 정리는 어떻게 할지?

일단 언제 종료할지를 정해야 한다.

  • MR이 종료되었을 때 자동 삭제
  • 확인이 완료된 시점에 직접 삭제

=> 요거는 GitLab CI로 스크립트로 돌림

어떻게 달라졌을까?

기존의 가장 큰 문제점...

  • Release A -> beta env
  • Release B -> (!)

이제는...

  • Release A -> preview env
  • Release B -> preview env

이걸 가지고 개선된 수치!

  • QA 테스트 소요 기간 : 이론적으로 35WD -> 15WD (57% 감소)
    • 큰 프로젝트라고 생각하면 15WD 정도의 기간이 소요되는데, 두 개의 큰 프로젝트가 겹치면 30WD가 소요되는 것이었다. 거기에 작은 프로젝트 하나가 5WD라고 하면 35WD인데
    • Preview Deployment를 도입하고 나서는 15WD로 줄어들었다. (병렬로 진행할 수 있게 되었기 때문)
  • 베타 테스트를 위한 배포 횟수 : 9회 -> 5회 (44% 감소)
    • 적용 전에는 A -> B -> A -> B -> A 순서로 왔다갔다 하면서 배포해서 테스트를 해야했는데 (3번만 더 한다고 하면 3+2n 이라 9회 정도)
    • Preview Deployment를 도입하고 나서는 A, B 브랜치 각각을 배포하는 2회, 그리고 필요한 배포를 n회씩만 하면 되니 5회로 줄어들었다.

DX도 챙기기

  1. 효율적인 피드백 교환을 가능하도록
  2. 자유로운 기술적 도전을 위한 배포 환경 제공
  3. 브랜치 생명주기 동안 브랜치 관리 부담 감소
  4. 베타 배포를 위한 소통 비용 감소

아직 갈 길이 멀다

안정화

  1. Lambda@Edge 코드, CI 스크립트 관리
  2. 테스트 코드 추가
  3. 적용 단순화/플랫폼화 및 가이드

고도화

  1. Module Federation 적용된 프로젝트용 파이프라인 구축
  2. Feature Flag의 도입, Trunk-Based 브랜치 관리

클라우드 권한을 개발팀에 맡겨도 안전한 당근 리소스 플랫폼 (김승호, 당근 SRE)

💡
AWS Summit에서 발표 예정! (따라서 발표자료는 공유 X)
Network 소모임 (2024.04)Burnout