2022-07-12-TIL
Today I Learned
배포 전략
새 버전을 배포할 때 이전 버전을 언제, 어떻게 내릴지에 따라 배포 전략이 나뉜다. 다운타임, 필요한 서버 자원, 롤백 속도가 서로 맞바뀐다.
- Recreate: 기존 인스턴스를 모두 내린 뒤 새 버전을 올린다. 쿠버네티스 Deployment 문서는
.spec.strategy.type이Recreate이면 새 Pod를 만들기 전에 기존 Pod를 모두 종료한다고 설명한다. 단순하지만 그 사이에 다운타임이 생긴다. - Rolling Update: 인스턴스를 조금씩 새 버전으로 교체한다. 쿠버네티스 Deployment의 기본 전략이고,
maxUnavailable(동시에 내려가도 되는 수)과maxSurge(추가로 더 띄워도 되는 수)로 속도를 조절한다. 기본값은 각각 25%다. 교체 중에는 두 버전이 동시에 요청을 받으므로, API와 DB 스키마가 두 버전 모두와 호환되어야 한다. - Blue-Green: 마틴 파울러의 BlueGreenDeployment는 가능한 한 똑같은 운영 환경 두 개를 두고, 하나(blue)가 서비스하는 동안 다른 하나(green)에 새 버전을 배포해 검증한 뒤 라우터를 green으로 전환하는 방식으로 설명한다. 문제가 생기면 라우터를 다시 blue로 돌리면 되므로 롤백이 빠르다. 대신 운영 환경을 두 벌 유지해야 한다.
- Canary: CanaryRelease는 새 버전을 일부 사용자에게만 먼저 내보내고, 문제가 없으면 전체로 넓히는 방식이다. 실제 트래픽으로 검증하면서 문제의 영향 범위를 작게 유지할 수 있지만, 트래픽을 비율대로 나누는 라우팅과 두 버전을 비교할 모니터링이 필요하다.
| 전략 | 다운타임 | 추가 자원 | 롤백 |
|---|---|---|---|
| Recreate | 있음 | 없음 | 다시 배포 |
| Rolling Update | 없음 | 조금(maxSurge만큼) | 다시 롤링 |
| Blue-Green | 없음 | 환경 한 벌 | 라우터 전환 |
| Canary | 없음 | 일부 | 트래픽 회수 |
- https://velog.io/@jm1225/Deployment
- https://blog.naver.com/classmethodkr/222540331678
페이지네이션
API가 큰 목록을 한 번에 돌려줄 수 없으니 나눠서 돌려주는 것이 페이지네이션이다. 대표적인 방식은 offset 방식과 cursor 방식이다.
Slack의 Evolving API Pagination at Slack이 두 방식의 차이를 잘 정리한다.
- Offset 방식은 클라이언트가 페이지 크기와 페이지 번호를 보내고, 서버는
LIMIT <count> OFFSET <offset>으로 조회한다. 원하는 페이지로 바로 이동할 수 있다는 장점이 있다. 하지만 offset이 커질수록 DB는 offset + count개의 행을 읽은 뒤 앞부분을 버려야 해서 느려진다. 또 조회 중에 데이터가 자주 추가되면 페이지 경계가 밀려서 같은 항목이 두 번 나오거나 건너뛰게 된다. - Cursor 방식은 서버가 마지막 항목을 가리키는 커서를 응답에 담고, 클라이언트는 다음 요청에 그 커서를 보내 그 뒤의 결과를 받는다. 앞의 문제를 해결하지만, 커서는 고유하고 순차적인 컬럼에 기반해야 하고 특정 페이지로 바로 이동할 수는 없다.
1
2
3
4
5
-- offset: 뒤 페이지로 갈수록 느려진다
SELECT * FROM message ORDER BY id DESC LIMIT 20 OFFSET 10000;
-- cursor: 마지막으로 받은 id를 기준으로 이어서 조회한다
SELECT * FROM message WHERE id < :lastId ORDER BY id DESC LIMIT 20;
GitHub REST API는 응답의 link 헤더에 이전, 다음, 처음, 마지막 페이지 URL을 담아 준다.
무한 스크롤이나 피드처럼 계속 다음만 보는 화면은 cursor, 게시판처럼 페이지 번호로 이동하는 화면은 offset이 자연스럽다.
- https://ignaciochiazzo.medium.com/paginating-requests-in-apis-d4883d4c1c4c
MSA
MSA(Microservice Architecture)는 하나의 애플리케이션을 작은 서비스 여러 개로 나눠 만드는 방식이다. 마틴 파울러와 제임스 루이스의 Microservices는 마이크로서비스를 각자 자기 프로세스에서 실행되고, HTTP API 같은 가벼운 방식으로 통신하며, 비즈니스 역량(business capability)을 중심으로 만들어지고, 완전히 자동화된 배포로 독립적으로 배포할 수 있는 작은 서비스들의 모음으로 정의한다.
장점은 서비스별로 독립 배포와 확장이 가능하고, 팀이 자기 서비스를 맡아 따로 발전시킬 수 있다는 점이다. 대가는 분산 시스템의 복잡도다. 서비스 간 호출이 네트워크를 타므로 장애와 지연을 다뤄야 하고, 여러 서비스에 걸친 데이터 일관성, 모니터링, 배포 파이프라인이 모두 어려워진다.
- https://dataportal.kr/81
댓글
아직 댓글이 없습니다