관리 메뉴

공부한것들을 정리하는 블로그 입니다.

무중단 DB/서버 Scale Up 진행시, 라운드로빈 설정이라면 유의 할 것(L4제어 무중단 DB Scale Up 중 실거래 발생) 본문

경력 실무경험/실무 주제

무중단 DB/서버 Scale Up 진행시, 라운드로빈 설정이라면 유의 할 것(L4제어 무중단 DB Scale Up 중 실거래 발생)

호 두 2023. 4. 25. 02:01
반응형

* 해당 글은 계속 수정 예정입니다.
최초 작성일 2022.03
마지막 수정일 2023.04

 

 

 


#상황 설명

이중화 되어있는 서버(A,B)의 엔드포인트에서 추가적으로 분산처리를 위하여 라운드로빈 방식을 사용중인 상황이라 가정

=> 동일한 지불수단의 거래여도 1번,2번 컨테이너로 순차적으로 서비스를 호출


#상황 흐름

1. L4제어
L4를 통해 A서버의 거래를 제어하여, A서버의 A1컨테이너로 거래가 들어오지 않도록 제어
  거래비 A:B = 50:50
  A1 컨테이너 : 25
  A2 컨테이너 : 25
  B1 컨테이너 : 25
  B2 컨테이너 : 25
  => (L4 제어)
  거래비 A:B = 50:50
  A1 컨테이너 : 0
  A2 컨테이너 : 50
  B1 컨테이너 : 25
  B2 컨테이너 : 25


2. DB변경
A서버의 A1 컨테이너에 연결된 DB를 a에서 a'로 스케일 업(scale up)

2-1. A서버의 비즈니스서버의 A1컨테이너를 설정변경 후 재구동하여 변경된 설정을 적용
2-2. A서버의 프론트서버의 A1컨테이너를 각각 재구동하여 변경된 설정을 적용
2-3. A서버의 백서버의 A1컨테이너를 각각 재구동하여 변경된 설정을 적용
  A서버 A1컨테이너 DB연결 : a
  A서버 A2컨테이너 DB연결 : a
  => (DB 변경)
  A서버 A1컨테이너 DB연결 : a' (변경)
  A서버 A2컨테이너 DB연결 : a (유지)

*A1,A2 컨테이너를 모두 변경하지 않은 이유 : 사실IP로 연결되어 있거나, 해당 서버의 IP/PORT로만 방화벽이 열려있는 경우가 있어서. 무중단 테스트를 지향하려면 각 서버의 컨테이너도 1개는 유지해야 함.


3. 테스트거래
이후 A서버의 DB(a')에 대한 검증을 위해, 개발자가 지불수단별 테스트거래를 발생시킴
  A서버 A1컨테이너 테스트거래 인입 : a'
  A서버 A2컨테이너 실거래 인입 : a (유지)


4. DB원복
이후 DB(a') 테스트 검증 완료 후, A서버 A1컨테이너 DB원복 진행

4-1. A서버 A1컨테이너 DB(a')를 DB(a)로 설정 원복
4-2. A서버의 비즈니스서버의 A1컨테이너를 설정원복 후 재구동하여 변경되었던 설정을 원복
4-3. A서버의 프론트서버의 A1컨테이너를 설정원복 후 재구동하여 변경되었던 설정을 원복
4-4. A서버의 백서버의 A1컨테이너를 설정원복 후 재구동하여 변경되었던 설정을 원복
  A서버 A1컨테이너 DB연결 : a'
  A서버 A2컨테이너 DB연결 : a 
  => (DB 변경)
  A서버 A1컨테이너 DB연결 : a
  A서버 A2컨테이너 DB연결 : a

5. L4제어
L4 제어하여 A서버의 A1컨테이너 거래비 원복
  거래비 A:B = 50:50
  A1 컨테이너 : 0
  A2 컨테이너 : 50
  B1 컨테이너 : 25
  B2 컨테이너 : 25
  => (L4 제어)
  거래비 A:B = 50:50
  A1 컨테이너 : 25
  A2 컨테이너 : 25
  B1 컨테이너 : 25
  B2 컨테이너 : 25

6. 원복완료 후 특이사항 확인
테스트 거래건 및 로그를 확인 중, 실거래가 A2컨테이너로 인입되어 DB a'으로 처리된 건이 확인됨


# 실거래가 인입된 사유?

결론부터 이야기하자면, 해당 서버가 라운드로빈(Round Robin) 방식으로 설정되어 있었기 때문이다.

* 1. 로드 밸런서에서 Round Robin 방식으로 인해 서버A,B로 균등분산 (50:50)
** 2. 이후 서버A에서 각 프론트서버(AF1,AF2)가 다시 라운드로빈 방식으로 균등분산(25:25) + 한쪽이 문제 발생시 나머지 서버로 거래비 자동설정 가능(0:50)

위의 2에서 설정된 라운드로빈 으로 인하여 실거래가 인입된 것이다.

ex) 클라이언트 -> (요청) -> A서버 -> AF2컨테이너 -> (라운드로빈) -> AZ1컨테이너 -> ...


다시 설명하자면,

A서버가 내부적으로 프론트서버(AF1,AF2) -> 비즈니서서버(AZ1,AZ2)로 나뉘어져 있다보니

위 "3. 거래인입" 단계에서 A2컨테이너로 들어온 실거래 중 특정건이,

라운드로빈 방식으로 인해 균등 분산(혹은 A2서버 문제발생)으로 인하여 A1컨테이너로 인입된 것이다.

ex) 클라이언트 -> (요청) -> A서버 -> AF1컨테이너 -> (라운드로빈) -> AZ2컨테이너 -> ...
ex) 어댑터 클러스터를 통해 컨테이너 우선순위를 정해두었고, 비즈니스 로직은 AZ2, AB2 컨테이너에서 수행되나, 응답은 다시 AF1컨테이너로 나간다(세션이 남아있으므로)


이에 대한 해결법은,

테스트거래를 받는 동안에는 라운드로빈 설정을 끄는것이 옳다고 생각한다. 
(다만, 이 경우 서버 문제발생시 다른서버로 돌지 않음)

라운드로빈 설정을 끌 수 없는 상황이라면,

컨테이너 우선순위가 설정되어 있지 않은 경우 어댑터 클러스터를 통해 설정해주고

라운드로빈이 설정된 서버를 먼저 재기동하는 것이 최선인 듯 하다.

ex) 프론트서버(AF1) 재기동 => 백서버(AB1) 재기동 => 비즈니스서버(AZ1) 재기동

 

 

p.s. (후처리) : DB a' 는 아직 실시간 동기화가 적용되어있지 않았을테니, 인입된 실거래는 따로 특정하여 운영DB에 반영해주도록 하자


# 참고

1. 본인 블로그 : (참고사례)

https://drsggg.tistory.com/544

 

(참고사례)라운드로빈 이슈

공부한것들을 정리하는 블로그 입니다. (참고사례)라운드로빈 이슈 본문

drsggg.tistory.com

 

 

 

반응형
Comments