확장성 패턴 3 - 스캐터 게더 패턴(Scatter Gather Pattern)

스캐터 게더 패턴 정의

스캐터 게더 패턴은 로드 밸런싱 패턴과 유사하다.

시스템 요청을 보내는 요청자 또는 클라이언트가 존재하고, 이 요청에 응답하는 Worker 그룹이 있다.

그리고 요청자가 보낸 요청을 워커에 전달하는 중간 매개체(Dispatcher)가 존재한다.

 

구조 자체는 비슷하지만, 로드 밸런싱 패턴과 다른 부분은 요청을 받은 Dispatcher가 모든 Worker에 전달한다는 점이다.

이후에 모든 Worker들의 응답을 모아 하나로 종합하여 요청자에게 보내는 과정을 거치게 된다.

스캐터 게더 패턴 구조

 

또 다른 점은 로드 밸런싱 패턴의 Worker는 가용성을 위해 모두 같은 Worker를 사용하지만, 스캐터 게더 패턴에서는 Worker가 다를 수도 있다.

동일한 애플리케이션이지만, 각 Worker는 서로 다른 데이터 액세스한다. 이때 데이터는 다른 기능을 제공하는 서비스일 수도 있고, 파트너사가 소유한 외부 서비스일 수도 있는 점이 굉장히 특이하다.

 

 

각 Worker가 서로 다른 데이터에 액세스한다는 것은 워커에 전달되는 각 요청이 다른 Worker에 영향을 받지 않아 독립적으로 작동한다는 점이 매우 큰 장점이다. → 덕분에 많은 양의 요청을 병렬 처리하여 일정 시간 동안 많은 정보를 제공할 수 있게 된다.

 

쇼핑몰 애플리케이션으로 예를 들면, Worker 1이 받은 요청은 고객 데이터베이스에 접근하고, Worker 2는 구매 정보 데이터베이스에 접근하는 식으로 독립적으로 요청을 받아 응답하는 형식이다.

또는 사용 사례 중 하나인 검색 서비스를 예로 들면, 사용자의 검색 쿼리를 전달받은 검색 Worker들은 자신이 보유한 데이터 서브넷 내에서 검색하고, 결과를 도출하게 된다.

검색 서비스에서의 스캐터 게더 패턴

 

스캐터 게더 패턴 사용 사례

• 클라이언트에게 제공하는 검색 서비스
• Worker가 3rd-Party로 구성된 경우 (예: 호텔 예약 사이트 등)

위에서 살짝 설명했지만 다시 풀어서 설명해보자면,

예시를 활용한 스캐터 게더 패턴을 이용한 통신 순서는 다음과 같다.

1. 사용자는 브라우저나 모바일 앱에서 검색 쿼리를 실행한다.
2. 검색 쿼리 요청은 백엔드 서버에 수신되어 내부 검색 워커 인스턴스로 이루어진 그룹에 전달된다.
3. 각 인스턴스에서는 해당 검색 쿼리의 중요 키워드를 회사가 제공하는 검색 서비스의 서브넷 내에서 검색한다.
4. 각 워커는 검색을 마친 후 백엔드로 응답을 돌려보낸다.
5. 백엔드 서버에서는 모든 워커의 검색 결과를 종합한다. 
6. 백엔드 서버에 존재하는 집합체 컴포넌트(Aggregation component)는 종합한 결과를 최종적으로 전달하기 전에 데이터를 결합하고 품질을 평가하는 등 데이터에 필요한 모든 처리를 수행한다.
7. 검증된 결과를 사용자에게 전송한다.

 

만약에 클라이언트가 특정 도시와 특정 날짜에 숙박할 호텔을 검색하는 요청을 보냈을 때도 마찬가지로 작동한다.

1. 클라이언트의 호텔 검색 쿼리를 실행한다.
2. 여러 호텔 정보에 대해 외부 시스템에 요청한다.
3. 예약 가능한 호텔 목록을 가격, 별점, 후기 등의 기준으로 정렬하여 사용자에게 결과를 전달한다.

 

스캐터 게더 패턴 특징

1. 통신하는 Worker의 수가 정확히 몇 갠지 전혀 알지 못한다. → 모든 통신이 병렬적으로 이루어지기 때문이다.
2. 워커가 내부 서비스(Storage 등)인지 외부 서비스(3rd-party)인지 알 수 없다. 

사실 이러한 것을 알지 못해도 어차피 병렬로 통신이 되고 있기 때문에 사용자 경험은 대체로 비슷할 것이다!

 

 

스캐터 게더 패턴 고려 사항

첫 번째로는 서드 파티 워커의 경우, 클라우드 환경에서 각 워커가 네트워크/인프라 문제로 인해 연결이 불가능할 수도 있다. (예: 외부 회사가 새 릴리즈를 롤아웃하는 중일 경우, 정전으로 인해 서버가 다운된 경우 등)

이러한 상황을 대비하기 위해서 디스패처는 워커가 응답하기까지의 시간을 정해두게 되는데, 대기 시간 이후에도 워커에서 응답이 오지 않으면, 그냥 무시하고 다른 워커의 응답만 종합하여 집합체(Aggregation)로 넘어간다.

디스패처의 대기 시간을 초과한 워커에 대한 응답은 종합하지 않는다.

 

 

 

두 번째는 디스패처와 워커를 분리하는 것이다.

검색 사이트 사례의 경우에는 디스패처와 워커가 굉장히 밀접하게 연관되어 있었다. → 디스패처가 지속적으로 워커의 존재와 사용 가능한 수를 계속 파악해야 함

 

이러한 연관성을 제거하고 싶다면, 디스패처와 워커 사이에 메시지 브로커를 넣어줄 수도 있다.

디스패처 → 메시지 브로커에게 메시지를 발행하면 해당 주제를 구독하고 있는 워커는 알림을 받고 검색을 수행하게 된다. → 이를 통해 비동기식 통신이 가능해진다.

 

 

마지막으로 스캐터 개더 패턴을 적용했을 때 요청 결과 시간을 고려해야 한다.

바로 나오는지, 오랜 시간이 걸리는지 파악하는 것은 아주 중요하다.

결과가 즉각적으로 나온다면 정상적으로 작동한다는 뜻인데,

만일 수 분, 수 시간이 걸리는 복잡한 분석 보고서 또는 빅데이터 보고서라면 디스패처와 집합체를 분리하고, 고유 식별자를 사용하는 것이 더 효율적일 수 있다.