분산 애플리케이션의 빌딩 블록. 두 번째 근사

발표

동료 여러분, 저는 한여름에 대기열 시스템 설계에 관한 또 다른 기사 시리즈인 "VTrade 실험"을 발표할 계획입니다. 이는 거래 시스템을 위한 프레임워크를 작성하려는 시도입니다. 이 시리즈에서는 거래소, 경매 및 상점 구축에 대한 이론과 실제를 검토합니다. 기사 끝부분에서 가장 관심 있는 주제에 투표해 주시기 바랍니다.

이것은 Erlang/Elixir의 분산 반응형 애플리케이션에 관한 시리즈의 마지막 기사입니다. 안에 첫 번째 기사 반응형 아키텍처의 이론적 기초를 찾을 수 있습니다. 두 번째 기사 이러한 시스템을 구축하기 위한 기본 패턴과 메커니즘을 보여줍니다.

오늘 우리는 코드 베이스와 프로젝트 전반의 개발 문제를 제기할 것입니다.

서비스 조직

실제 생활에서 서비스를 개발할 때 하나의 컨트롤러에 여러 상호 작용 패턴을 결합해야 하는 경우가 많습니다. 예를 들어 프로젝트 사용자 프로필 관리 문제를 해결하는 사용자 서비스는 req-resp 요청에 응답하고 pub-sub를 통해 프로필 업데이트를 보고해야 합니다. 이 경우는 매우 간단합니다. 메시징 뒤에는 서비스 논리를 구현하고 업데이트를 게시하는 하나의 컨트롤러가 있습니다.

내결함성 분산 서비스를 구현해야 할 때 상황은 더욱 복잡해집니다. 사용자 요구 사항이 변경되었다고 가정해 보겠습니다.

1. 이제 서비스는 5개의 클러스터 노드에서 요청을 처리해야 합니다.
2. 백그라운드 처리 작업을 수행할 수 있습니다.
3. 또한 프로필 업데이트에 대한 구독 목록을 동적으로 관리할 수도 있습니다.

참고 : 우리는 일관된 저장 및 데이터 복제 문제를 고려하지 않습니다. 이러한 문제가 이전에 해결되었고 시스템에 이미 안정적이고 확장 가능한 스토리지 계층이 있고 핸들러에 이와 상호 작용하는 메커니즘이 있다고 가정해 보겠습니다.

사용자 서비스에 대한 공식적인 설명이 더욱 복잡해졌습니다. 프로그래머의 관점에서 보면 메시징 사용으로 인해 변경 사항이 최소화됩니다. 첫 번째 요구 사항을 충족하려면 req-resp 교환 지점에서 균형 조정을 구성해야 합니다.

백그라운드 작업을 처리해야 하는 요구 사항이 자주 발생합니다. 사용자의 경우 이는 사용자 문서 확인, 다운로드한 멀티미디어 처리, 소셜 미디어와 데이터 동기화 등이 될 수 있습니다. 네트워크. 이러한 작업은 클러스터 내에서 어떻게든 분산되어야 하며 실행 진행 상황을 모니터링해야 합니다. 따라서 두 가지 솔루션 옵션이 있습니다. 이전 기사의 작업 분배 템플릿을 사용하거나, 적합하지 않은 경우 필요한 방식으로 프로세서 풀을 관리할 사용자 정의 작업 스케줄러를 작성하는 것입니다.

포인트 3에는 pub-sub 템플릿 확장이 필요합니다. 그리고 구현을 위해서는 pub-sub 교환 포인트를 생성한 후 서비스 내에서 이 포인트의 컨트롤러를 추가로 실행해야 합니다. 따라서 이는 구독 및 구독 취소 처리 논리를 메시징 계층에서 사용자 구현으로 옮기는 것과 같습니다.

결과적으로 문제를 분해한 결과, 요구 사항을 충족하려면 서로 다른 노드에서 5개의 서비스 인스턴스를 시작하고 구독을 담당하는 게시-구독 컨트롤러라는 추가 엔터티를 생성해야 한다는 사실이 나타났습니다.
5개의 핸들러를 실행하기 위해 서비스 코드를 변경할 필요는 없습니다. 유일한 추가 작업은 교환 지점에서 균형 조정 규칙을 설정하는 것인데, 이에 대해서는 잠시 후에 설명하겠습니다.
또한 추가적인 복잡성도 있습니다. pub-sub 컨트롤러와 사용자 지정 작업 스케줄러는 단일 복사본에서 작동해야 합니다. 다시 말하지만, 메시징 서비스는 기본적으로 리더를 선택하기 위한 메커니즘을 제공해야 합니다.

리더 선정

분산 시스템에서 리더 선택은 일부 로드의 분산 처리 일정을 담당하는 단일 프로세스를 지정하는 절차입니다.

중앙 집중화 경향이 없는 시스템에서는 paxos 또는 raft와 같은 보편적이고 합의 기반 알고리즘이 사용됩니다.
메시징은 브로커이자 핵심 요소이므로 모든 서비스 컨트롤러, 즉 후보 리더에 대해 알고 있습니다. 메시징을 사용하면 투표 없이 리더를 임명할 수 있습니다.

교환 지점을 시작하고 연결한 후 모든 서비스는 시스템 메시지를 받습니다. #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. 만약에 LeaderPid 일치하다 pid 현재 프로세스에서는 리더로 지정되며 목록은 Servers 모든 노드와 해당 매개변수를 포함합니다.
새로운 클러스터 노드가 나타나고 작동 중인 클러스터 노드의 연결이 끊어지는 순간 모든 서비스 컨트롤러는 #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} 각각.

이렇게 하면 모든 구성 요소가 모든 변경 사항을 인식하고 클러스터는 언제든지 하나의 리더를 갖게 됩니다.

중재자

복잡한 분산 처리 프로세스를 구현하고 기존 아키텍처를 최적화하는 문제에서는 중개자를 사용하는 것이 편리합니다.
서비스 코드를 변경하지 않고 추가 처리, 메시지 라우팅 또는 로깅 문제 등을 해결하려면 서비스 전에 프록시 처리기를 활성화하여 모든 추가 작업을 수행할 수 있습니다.

게시-구독 최적화의 전형적인 예는 시장의 가격 변동과 같은 업데이트 이벤트를 생성하는 비즈니스 코어와 액세스 계층(웹 클라이언트에 웹소켓 API를 제공하는 N 서버)을 갖춘 분산 애플리케이션입니다.
정면으로 결정하면 고객 서비스는 다음과 같습니다.

• 클라이언트는 플랫폼과의 연결을 설정합니다. 트래픽을 종료하는 서버 측에서는 이 연결을 서비스하기 위한 프로세스가 시작됩니다.
• 서비스 프로세스의 맥락에서 업데이트 승인 및 구독이 발생합니다. 프로세스는 주제에 대한 구독 메소드를 호출합니다.
• 커널에서 이벤트가 생성되면 연결을 서비스하는 프로세스로 전달됩니다.

"뉴스" 주제에 대한 구독자가 50000명이라고 가정해 보겠습니다. 구독자는 5개의 서버에 균등하게 분산됩니다. 결과적으로 교환 지점에 도달하는 각 업데이트는 구독자 수에 따라 각 서버에서 50000번, 즉 10000번 복제됩니다. 그다지 효과적인 계획은 아니죠?
상황을 개선하기 위해 교환 지점과 이름이 같은 프록시를 도입해 보겠습니다. 전역 이름 등록자는 가장 가까운 프로세스를 이름으로 반환할 수 있어야 하며 이것이 중요합니다.

액세스 계층 서버에서 이 프록시를 시작하면 websocket API를 제공하는 모든 프로세스가 커널의 원래 게시-구독 교환 지점이 아닌 이를 구독하게 됩니다. 프록시는 고유한 구독의 경우에만 코어를 구독하고 들어오는 메시지를 모든 구독자에게 복제합니다.
결과적으로 커널과 액세스 서버 간에 5개가 아닌 50000개의 메시지가 전송됩니다.

라우팅 및 밸런싱

요청-응답

현재 메시징 구현에는 7가지 요청 배포 전략이 있습니다.

• default. 요청은 모든 컨트롤러로 전송됩니다.
• round-robin. 요청은 열거되고 컨트롤러 간에 주기적으로 배포됩니다.
• consensus. 서비스를 제공하는 컨트롤러는 리더와 슬레이브로 구분됩니다. 요청은 리더에게만 전송됩니다.
• consensus & round-robin. 그룹에는 리더가 있지만 요청은 모든 구성원에게 분산됩니다.
• sticky. 해시 함수가 계산되어 특정 핸들러에 할당됩니다. 이 서명이 있는 후속 요청은 동일한 처리기로 이동됩니다.
• sticky-fun. 교환포인트 초기화 시에 대한 해시 계산 기능 sticky 균형을 잡는 것.
• fun. Sticky-Fun과 마찬가지로 사용자만이 추가로 리디렉션, 거부 또는 사전 처리할 수 있습니다.

분배 전략은 교환 지점이 초기화될 때 설정됩니다.

밸런싱 외에도 메시징을 사용하면 엔터티에 태그를 지정할 수 있습니다. 시스템의 태그 유형을 살펴보겠습니다.

• 연결 태그. 이벤트가 어떤 연결을 통해 발생했는지 이해할 수 있습니다. 컨트롤러 프로세스가 동일한 교환 지점에 연결되지만 라우팅 키가 다른 경우에 사용됩니다.
• 서비스 태그. 핸들러를 하나의 서비스 그룹으로 결합하고 라우팅 및 밸런싱 기능을 확장할 수 있습니다. req-resp 패턴의 경우 라우팅은 선형입니다. 우리는 교환 지점에 요청을 보낸 다음 이를 서비스에 전달합니다. 그러나 핸들러를 논리적 그룹으로 분할해야 하는 경우 분할은 태그를 사용하여 수행됩니다. 태그를 지정하면 요청이 특정 컨트롤러 그룹으로 전송됩니다.
• 태그를 요청합니다. 답변을 구별할 수 있습니다. 우리 시스템은 비동기식이므로 서비스 응답을 처리하려면 요청을 보낼 때 RequestTag를 지정할 수 있어야 합니다. 이를 통해 우리는 어떤 요청에 대한 답변을 이해할 수 있을 것입니다.

게시-구독

pub-sub의 경우 모든 것이 조금 더 간단합니다. 메시지가 게시되는 교환 지점이 있습니다. 교환 지점은 필요한 라우팅 키를 구독한 구독자에게 메시지를 배포합니다(이것은 주제와 유사하다고 말할 수 있습니다).

확장성 및 내결함성

시스템 전체의 확장성은 시스템의 레이어와 구성 요소의 확장성 정도에 따라 달라집니다.

• 서비스는 이 서비스에 대한 처리기를 사용하여 클러스터에 추가 노드를 추가하여 확장됩니다. 시운전 시 최적의 밸런싱 정책을 선택할 수 있습니다.
• 별도의 클러스터 내의 메시징 서비스 자체는 일반적으로 특별히 로드된 교환 지점을 별도의 클러스터 노드로 이동하거나 클러스터의 특별히 로드된 영역에 프록시 프로세스를 추가하여 확장됩니다.
• 전체 시스템의 확장성은 아키텍처의 유연성과 개별 클러스터를 공통 논리 엔터티로 결합하는 능력에 따라 달라집니다.

프로젝트의 성공은 확장의 단순성과 속도에 달려 있는 경우가 많습니다. 현재 버전의 메시징은 애플리케이션과 함께 성장합니다. 50~60대의 머신으로 구성된 클러스터가 부족하더라도 페더레이션에 의지할 수 있습니다. 불행하게도 연합이라는 주제는 이 기사의 범위를 벗어납니다.

페이지

로드 밸런싱을 분석할 때 이미 서비스 컨트롤러의 중복성에 대해 논의했습니다. 그러나 메시징도 예약되어야 합니다. 노드 또는 시스템 충돌이 발생하는 경우 메시징은 가능한 가장 짧은 시간에 자동으로 복구되어야 합니다.

내 프로젝트에서는 추락 시 하중을 받는 추가 노드를 사용합니다. Erlang에는 OTP 애플리케이션을 위한 표준 분산 모드 구현이 있습니다. 분산 모드는 장애가 발생한 경우 이전에 실행한 다른 노드에서 장애가 발생한 애플리케이션을 실행하여 복구를 수행합니다. 프로세스는 투명합니다. 오류가 발생한 후 애플리케이션은 자동으로 장애 조치 노드로 이동합니다. 이 기능에 대해 자세히 알아볼 수 있습니다. 여기에.

Производительность

최소한 Rabbitmq의 성능과 사용자 정의 메시징을 대략적으로 비교해 보겠습니다.
나는 찾았다 공식 결과 OpenStack 팀의 RabbitMQ 테스트.

단락 6.14.1.2.1.2.2. 원본 문서는 RPC CAST의 결과를 보여줍니다.

OS 커널이나 Erlang VM에 대한 추가 설정은 미리 하지 않습니다. 테스트 조건:

• erl은 다음을 선택합니다: +A1 +sbtu.
• 단일 erlang 노드 내 테스트는 모바일 버전의 이전 i7이 설치된 랩톱에서 실행됩니다.
• 클러스터 테스트는 10G 네트워크를 사용하는 서버에서 수행됩니다.
• 코드는 도커 컨테이너에서 실행됩니다. NAT 모드의 네트워크.

테스트 코드:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

1 스크립트 : 테스트는 이전 i7 모바일 버전이 설치된 노트북에서 실행되었습니다. 테스트, 메시징 및 서비스는 하나의 Docker 컨테이너에 있는 하나의 노드에서 실행됩니다.

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

2 스크립트: NAT(Docker) 아래의 서로 다른 머신에서 실행되는 3개의 노드.

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

모든 경우에 CPU 사용률은 250%를 초과하지 않았습니다.

결과

나는 이 사이클이 마음의 덤프처럼 보이지 않기를 바라며 내 경험이 분산 시스템 연구원과 비즈니스 시스템을 위한 분산 아키텍처 구축의 시작 단계에 있고 Erlang/Elixir에 관심을 갖고 있는 실무자 모두에게 실질적인 도움이 되기를 바랍니다. , 하지만 그만한 가치가 있는지 의심 스럽습니다 ...

Фото @chuttersnap

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

VTrade 실험 시리즈의 일부로 어떤 주제를 더 자세히 다루어야 합니까?

• 이론: 시장, 주문 및 타이밍: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• 주문서. 그룹화를 통한 책 구현의 이론과 실제

• 거래 시각화: 틱, 바, 해상도. 보관방법과 접착방법

• 백오피스. 기획 및 개발. 직원 모니터링 및 사고 조사

• API. 어떤 인터페이스가 필요한지, 어떻게 구현하는지 알아봅시다.

• 정보 저장: 거래 시스템의 PostgreSQL, Timescale, Tarantool

• 거래 시스템의 반응성

• 다른. 댓글에 쓰겠습니다

6명의 사용자가 투표했습니다. 4명의 사용자가 기권했습니다.

출처 : habr.com