[Zero-base] 12-2. 서비스 중 기능 추가, 변경 시 고려해야 할 것들

사례연구 - 서비스 중 기능 추가/변경 시 고려해야 할 것들

 

 

서비스가 만들어지는 과정

 

유지보수

• 기능 개선
• 정책 변경
• 서비스 확장
• 프로모션

 

변화하는 것들

→ SEVER, DB, Message Queue

 

 

 

DB 조회 시 고려해야 하는 것

 

단순 DB 조회 : SEVER ↔ DB ↔ Table

select *
from user
where login_id = "zerobase"
;

 

Table 검색 순서 : 순서대로 조회

• 풀 스캔 : 데이터가 늘어날 수록 검색 속도가 저하됨
• 인덱스 적용

 

페이징

select *
from product_order
where created_at > '2020-01-01 00:00:00'
order created_at asc
limit 49, 10

 

select *
from product_order
where created_at > '2020-01-01 00:00:00'
order created_at asc
limit 100000, 10

• 정렬 이후 탐색될 때까지 순차적으로 탐색
• Query 속도가 저하됨 

 

select min(product_id)
from product_order
where created_at > '2020-01-01 00:00:00'
order created_at asc

• 해결방안 : PK를 기준으로 페이징 쿼리 작성
• 빠른 조회 가능

select *
from product_order
where product_id > :nextProductId
order created_at asc
limit 10

• 페이징(+10) 만큼

select *
from product_order
where product_id > :nextProductId
order created_at asc
limit 10

 

 

 

다른 서버 호출 시 고려해야 하는 것

 

timeout

• 요청결과가 성공인 경우

클라이언트 -- request --><-- 200 ok -- 우리 서비스 -- request --><-- 200 ok -- 외부 시스템

 

• 요청결과가 실패인 경우

클라이언트 -- request --><-- 1. 500 error, 2. 200 ok -- 우리 서비스 -- request --><-- 500 error -- 외부 시스템

 

• 요청결과가 지연된 경우

클라이언트(응답대기) -- request --> 우리 서비스(응답대기) -- request --> 외부 시스템(처리지연)

• 해결방안 : Circuit Breaker 사용 (ex. timeout)

 

• 요청결과가 알수없음일 때

클라이언트 -- request --><-- result? -- 우리 서비스(Timeout 발생, disconnect) -- request --> 외부 시스템

• 별도의 프로세스 추가

우리 서비스 -- 이전 요청의 처리결과 재요청 --><-- 결과전달 -- 외부 시스템

 

 

 

배포 시 고려해야 하는 것

 

배포 전략

• 롤링 배포 (Rolling Deployment)
• 블루-그린 배포 (Blue-Green Deployment)
• 카나리아 배포 (Canary Deployment)

 

배포전략 - Rolling Update

■ 이전버전, ■ 신규버전

• 1. ■■■
• 2. ■■■
• 3. ■■■
• 4. ■■■

 

※ 이전버전과 신규버전이 공존하는 경우 주의할 점

• 이전버전과 신규버전이 호환이 가능하도록 개발되어야함

 

 

배포전략 - Bule/Green

■ 이전버전, ■ 신규버전

• 배포 전 트래픽 : ■■■
• 배보 후 트래픽 : ■■■

 

 

배포전략 - Canary

■ 이전버전, ■ 신규버전

• 트래픽 : ■■■■
• 일부 트래픽 : ■

 

※ 롤링 배포와 다른 점

• 장애가 발생되었을 경우 카나리아 서버만 문제가 생기므로, 해당 서버의 트래픽만 차단하면 됨

 

 

배포 순서

😎  ↔ ■api ↔ ■other system1

■api → Message Queue → ■consumer → ■other system2

• 마지막 시스템부터 배포해야함

 

 

하위 호환성

예제 (1)

[zb v1.0.0] -> 1. [GET] /v1/challenge/java    -> Load Balancer -> 2. -> ■■■■ -> DB

[zb v1.0.0] -> 3. [POST] /v1/challenge/java -> Load Balancer -> 4. -> ■■■■ -> DB

 

배포 중인 경우

[zb v1.0.0] -> 1. [GET] /v1/challenge/java    -> Load Balancer -> 2. -> ■■■■ -> DB

[zb v1.0.0] -> 3. [POST] /v1/challenge/java -> Load Balancer -> 4. -> ■■■■ -> DB

• 배포 특성상 두가지 버전이 공존할 수 있으므로
• 항상 요청이 따로 들어올 수 있다는 것을 가정하고
• 정상적으로 동작하도록 애플리케이션 작성해야 함

 

예제 (2)

[zb v1.0.0] -> 1. [GET] /v1/challenge/java    -> Load Balancer -> 2. -> ■■ -> DB

[zb v1.0.0] -> 3. [POST] /v1/challenge/java -> Load Balancer -> 4. -> ■■ -> DB

[zb v2.0.0] -> 1. [GET] /v2/challenge/java    -> Load Balancer -> 2. -> ■■ -> DB

[zb v2.0.0] -> 3. [POST] /v2/challenge/java -> Load Balancer -> 4. -> ■■ -> DB

 

배포 중인 경우

[zb v1.0.0] -> 1. [GET] /v1/challenge/java    -> Load Balancer -> 2. -> ■■ -> DB

[zb v1.0.0] -> 3. [POST] /v1/challenge/java -> Load Balancer -> 4. -> ■■ -> DB

[zb v2.0.0] -> 1. [GET] /v2/challenge/java    -> Load Balancer -> 2. -> ■■ -> DB

[zb v2.0.0] -> 3. [POST] /v2/challenge/java -> Load Balancer -> 4. -> ■■ -> DB

 

 

 

정리

• 서비스가 만들어지는 과정 중 변화하는 것들
• 조회 쿼리 작성 시 고려해야하는 것들
• 다른 서버 호출 시 고려해야 하는 것
• 배포 전략 및 고려해야할 점

 

---