티스토리 뷰

 

사이트 규모가 증가함에 따라서 과부하를 처리 하는 방식 중 하나를 로드 밸런싱이라 합니다. 그리고 로드 밸런싱은 N개의 다른포트에 똑같은 서비스 (  ex : 주문 서비스 ) 를 기동시켜 교차하며 서비스를 제공하도록 합니다. 이 방법은 굉장히 효율적으로 과부하에 대비 할 수 있지만 한가지 문제점이 존재합니다.

바로 데이터 동기화의 문제 인데, 만약 H2 DB처럼 각 Port별로 어플리케이션 실행 시 생성되는 DB인 경우에는 어떨까요? 


#Load Balancer의 동작원리


많이 생략되어 있지만, LoadBalancer에서 어떤 Port로 접속 할지 접속 정보를 가지고 있습니다. 그리고 처음으로 요청이 들어오면, 보시는 것처럼 9091 Port로 요청값을 보냅니다. 그럼 9091Port 에서 H2-DB에는 유저의 주문정보1 이 저장이 됩니다.

이번에는 반대로 두번째 요청 시에는 9092 Port H2-DB에 두번째 주문 정보가 저장됩니다.

Load Balancer를 활용하면 해당 과정이 계속 반복해서 일어납니다.  계속해서 교차적으로 주문정보를 각 Port의 DB안에 저장하게 될거에요.  그렇다면 이런 상황에서의 가장 큰 문제점은 무엇일까요? 바로 데이터 동기화 문제입니다. 


#데이터 동기화 문제...?

아마 제가 이번에 예시를 들면 바로 와닿으실 거에요.

저희가 주문정보를 확인하기 위해서 주문정보 조회 쿼리 문을 보내면 어떻게 될까요? 위에서 설명한 그림을 토대로 9091 Port를 참조중인 DB는 A라고 지정하고 9092Port를 참조하는 DB는 B라고 지정하겠습니다. 그리고 최초 주문을 통해서  UmJunSik이라는 사람이 주문을 했다면 아마 A라는 DB에 해당 주문 정보가 들어가게 됩니다. B는 아마 아무값도 없을거에요.

 마찬가지로 조회시에도 로드밸런싱을 활용하면 교차적으로 접속하기 때문에, 최초 접속 시 A라는 DB에 접속하게 됩니다. A에는 Umjunsik이라는 값이 있으니 SELECT 문을 날리면 당연히 해당하는 주문정보를 리턴할 수 있습니다. 하지만 다음 요청 시 B라는 DB에 접속하게 됩니다. 그럼 당연하게도 B라는 DB에는 Umjunsik이라는 값이 없으니 아무 값도 받지 못하게 됩니다. 

이렇듯 요청을 보낼때마다 동기화되지 않은 데이터 때문에 계속 다른 결과값이 나오기 때문에, 프로그램이 뒤죽박죽 섞여 버립니다. 


#해결방안

이렇듯 저희는 문제점을 발견했습니다. 사실 이런 동기화 문제는 전에도 다룬적이 있지만, 다시한번 정리한 이유는 다음 포스팅에서 Kafka Connect를 활용해서 단일 DB를 사용할 예정입니다. 단일 DB를 사용하게 되면 참조하는 DB자체는 1개이기 때문에, 어디서 요청을 보내든 해당 DB에 차곡차곡 데이터가 쌓이게 됩니다. 너무 어렵게 생각할 필요는 없이 단일DB를 사용해서 데이터를 쌓겠다! 정도로 생각하면 될 것 같습니다.

 

Umm이라는 언어도 있네요..

 

감사합니다.

 

참고강의

 

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

Spring framework의 Spring Cloud 제품군을 이용하여 마이크로서비스 애플리케이션을 개발해 보는 과정입니다. Cloud Native Application으로써의 Spring Cloud를 어떻게 사용하는지, 구성을 어떻게 하는지에 대해

www.inflearn.com

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/09   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
글 보관함