Windows 서비스 스케일 아웃

Question

현재 회사에서 실행중인 Windows 서비스를 수평 확장하는 방법에 대한 정보를 찾고 있습니다. 우리는 (그리고 미래의 어떤 시점에서 4.5로 업그레이드 할 수 있습니다) .NET 4.0을 사용하고
서비스의 작업에 새로운 행을 조회 할 수있는 서비스에 대해 윈도우 서버 2012

에 실행 로깅 테이블 (Oracle 데이터베이스로 작업 중), 정보 처리, 5 개의 다른 테이블에있는 행 집합 작성 및/또는 업데이트 (추적 테이블이라고 부름), 로깅 테이블 업데이트 및 반복

로깅 테이블에는 다른 5 개의 추적 테이블에서 선택하여 저장해야하는 대량의 XML (행 당 최대 20MB까지 올라갈 수 있음)이 있습니다. 새로운 행은 항상 시간당 최대 500,000 개의 행에 추가됩니다.
트래킹 테이블의 트래픽은 가장 큰 테이블의 90,000 개의 새 행에서 가장 큰 테이블의 잠재적으로 수백만 개의 행까지 훨씬 더 높습니다. 물론 그 테이블에 대해서도 Update 연산이있다. 데이터에 대한

은
내가이 비트는 이러한 개체 그룹화 및 처리 방법에 따라 솔루션을 찾는 것이 중요하다고 생각 처리된다. 데이터 구조는 다음과 같습니다

public class Report 
{ 
    public long Id { get; set; } 
    public DateTime CreateTime { get; set; } 
    public Guid MessageId { get; set; } 
    public string XmlData { get; set; } 
} 

public class Message 
{ 
    public Guid Id { get; set; } 
} 

• 보고서는 평균 5 개 보고서에가있는 모든 메시지에 대한 로깅 내가 선택해야 데이터 및 프로세스
• 입니다. 어떤 경우에는 1에서 수백까지 다양합니다.
• 메시지에는 다른 컬렉션 및 기타 관계가 많이 포함되어 있지만 질문과 관련이 없습니다.

---

오늘은 겨우 16 코어 서버의 부하를 관리하는 우리가 가지고있는 Windows 서비스는 (I 전체 사양을 기억하지 않습니다,하지만이 기계는 짐승이라고하는 것이 안전). 나는이 모든 데이터를 처리하고 다른 인스턴스를 간섭하지 않는 더 많은 머신을 추가하고 확장하는 방법을 찾는 임무를 맡았습니다.

현재 각 메시지는 자체 스레드를 가지며 관련 보고서를 처리합니다. Google은 데이터를 처리 할 때 DB 쿼리 수를 최소로 줄이기 위해 MessageId별로 그룹화 된 보고서를 일괄 적으로 처리합니다. 내가 알아서 어떤 아키텍처를 사용하여 처음부터 다시 쓰기이 서비스에 허용하고이 단계에서

제한

• 합니다.
• 인스턴스가 충돌하면 다른 인스턴스는 충돌 한 인스턴스가있는 곳을 선택할 수 있어야합니다. 데이터가 손실 될 수 없습니다.
• 이 처리는 보고서가 데이터베이스에 삽입 될 때 가능한 한 실시간에 가까워 야합니다.

---

나는 그런 프로젝트를 빌드하는 방법에 대한 입력 또는 조언을 찾고 있어요. 서비스가 stateless 일 필요가 있다고 가정하거나, 모든 인스턴스에 대해 캐시를 어떻게 든 동기화하는 방법이 있습니까? 모든 인스턴스간에 어떻게 조정해야하며 동일한 데이터를 처리하지 않는지 확인해야합니다.부하를 어떻게 균등하게 분배 할 수 있습니까? 물론 인스턴스 충돌을 처리하고 작업을 완료하지 않는 방법은 무엇입니까?

작업 항목의
제거 관련이없는 정보

Answer 1

나는 내 자신이 모든 확장 성 및 중복 물건을 코딩하여이를 해결했다. 나는 누군가가 이것을 필요로한다면, 내가 한 일과 어떻게했는지 설명 할 것이다.

다른 인스턴스를 추적하고 특정 인스턴스가 처리 할 수있는 레코드를 알기 위해 각 인스턴스에 몇 가지 프로세스를 만들었습니다. 시작시 인스턴스는 Instances이라는 테이블에 데이터베이스에 등록됩니다 (아직없는 경우).

Id     Number 
MachineName  Varchar2 
LastActive   Timestamp 
IsMaster   Number(1) 

등록하고 인스턴스의 MachineName가 발견되지 않은 경우,이 테이블의 행을 생성 한 후, 인스턴스는 LastActive 열을 업데이트, 별도의 스레드에서 매초마다이 테이블을 핑 시작 :이 표는 다음과 같은 열이 있습니다. 그런 다음이 테이블의 모든 행을 선택하고 (그 이상)이 여전히 살아 있는지 확인합니다. 즉, LastActive 시간이 지난 10 초 내에 있음을 의미합니다. 마스터 인스턴스가 응답을 중지하면 마스터 인스턴스가 제어를 가정하고 마스터 인스턴스로 설정됩니다. 다음 반복에서는 마스터가 하나만 있는지 확인합니다 (다른 인스턴스가 동시에 제어를 수행하기로 결정한 경우를 대비하여). 그렇지 않은 경우 가장 낮은 인스턴스 인 Id을 생성합니다.

마스터 인스턴스 란 무엇입니까?
서비스의 역할은 로깅 테이블을 스캔하여 사람들이 쉽게 필터링하고 읽을 수 있도록 해당 데이터를 처리하는 것입니다. 내 질문에 이것을 진술하지는 않았지만 여기에는 관련성이있을 수 있습니다. 요청마다 로깅 테이블에 여러 레코드를 작성하는 ESB 서버가 많으며 서비스의 임무는 거의 실시간으로이를 추적하는 것입니다. 로그를 비동기 적으로 작성하기 때문에 로그에 started processing request A 항목보다 먼저 finished processing request A이 표시 될 수 있습니다. 그래서, 나는 그 레코드를 정렬하고 내 서비스가 올바른 순서로 데이터를 처리하도록하는 코드를 가지고 있습니다. 이 서비스를 확장해야하기 때문에 불필요한 DB 쿼리와 미친 버그를 피하기 위해 하나의 인스턴스 만이 논리를 수행 할 수 있습니다.
여기에 Master Instance이 들어 있습니다.이 테이블은 정렬 논리를 실행하고 로그 레코드 ID를 ReportAssignment이라는 다른 테이블에 임시로 저장합니다. 이 테이블의 임무는 어떤 레코드가 처리되었는지, 누구에 의해 기록되었는지 추적하는 것입니다. 처리가 완료되면 레코드가 삭제됩니다. 테이블은 다음과 같습니다.

RecordId  Number 
InstanceId  Number Nullable 

마스터 인스턴스는 로그 항목을 정렬하고 여기에 해당 ID를 삽입합니다. 모든 서비스 인스턴스는 모든 사람이 처리하지 않거나 비활성 인스턴스에서 처리중인 새 레코드와이 (Ping 프로세스 중에 획득 한) [record's Id] % [number of isnstances] == [index of current instance in a sorted array of all the active instances]에 대해 1 초 간격으로이 테이블을 확인합니다. 쿼리는 다소 다음과 같습니다

SELECT * FROM ReportAssignment 
WHERE (InstanceId IS NULL OR InstanceId NOT IN (1, 2, 3)) // 1,2,3 are the active instances 
AND RecordId % 3 == 0 // 0 is the index of the current instance in the list of active instances 

가 왜 이렇게해야합니까?

• 다른 두 인스턴스는 RecordId % 3 == 1 및 RecordId % 3 == 2를 쿼리합니다.
• RecordId % [instanceCount] == [indexOfCurrentInstance]은 모든 인스턴스간에 레코드가 균등하게 분산되도록합니다.
• InstanceId NOT IN (1,2,3)은 인스턴스가 충돌 한 인스턴스에 의해 처리 된 레코드를 인계하고 새 인스턴스가 추가 될 때 이미 활성 인 인스턴스의 레코드를 처리하지 못하게합니다.

는 이러한 기록에 대한 인스턴스 쿼리되면, 그것은 자신에 InstanceId을 설정, 업데이트 명령을 실행하고 그 아이디의 레코드에 대한 로깅 테이블을 쿼리. 처리가 완료되면 ReportAssignment에서 레코드를 삭제합니다.

전반적으로 매우 기쁩니다. 이는 확장 성이 뛰어나고 인스턴스가 다운 될 때 데이터가 손실되지 않도록 보장하며 기존 코드를 거의 변경하지 않았습니다.

Answer 2

편집, Windows 워크 플로은 아마 당신의 서비스를 리팩토링 당신의 가장 빠른 방법이다.

당신은 WF에서 얻을 것이다 가장 유용한 것은

Windows Workflow Foundation @ MSDN

은 적절하게 설계 워크 플로우 아무것도 그것이있는 마지막 지점에서 워크 플로우에 발생해야하는 지속 지점에서 다시 시작 할 수 워크 플로우 지속성이다 저장되었습니다.

Workflow Persistence @ MSDN

이 워크 플로우에 대한 기능을 포함

의 흐름을 다른 프로세스 충돌을 처리해야하는 동안 다른 프로세스로부터 회수한다. 공유 워크 플로 저장소를 사용하는 경우 다시 시작 프로세스가 동일한 컴퓨터에있을 필요는 없습니다. 복구 가능한 모든 워크 플로에는 워크 플로 저장소를 사용해야합니다.

작업 분배의 경우 몇 가지 옵션이 있습니다.

1. 서비스는 호스트 기반의 부하가 WCF WorkflowService 클래스를 통해 엔드 포인트를 이용하여 호출 흐름을 통해 균형 결합 메시지를 생성한다. 아마도 여기서 디자인 모드 편집기를 사용하여 Receive 및 해당 SendReply 핸들러 (WCF 메소드에 매핑)를 수동으로 설정하는 대신 입력 메소드를 구성하고자 할 것입니다. 모든 메시지에 대해 서비스를 호출하고 모든 보고서에 대해 서비스를 호출 할 수도 있습니다. 여기서 CanCreateInstance 속성이 중요합니다. 연결된 모든 호출은 독립적으로 실행되는 실행중인 인스턴스를 작성합니다.
   SendReply Class (System.ServiceModel.Activities) @ MSDN

2. 사용 대기열 지원이 서비스 버스 Receive Class (System.ServiceModel.Activities) @ MSDN
   Receive.CanCreateInstance Property (System.ServiceModel.Activities) @ MSDN WorkflowService Class (System.ServiceModel.Activities) @ MSDN
   
   ~
   . 최소한의 수의 클라이언트로부터 입력을 받아 들일 수 있고, 출력이 고유하게 식별되고 정확히 한 번만 처리 될 수있는 무언가가 필요합니다. 마음에 떠오르는 몇 가지는 NServiceBus, MSMQ, RabbitMQ 및 ZeroMQ입니다. 여기서 언급 한 항목 중 NServiceBus는 독점적으로 .NET 즉시 사용 가능합니다. 클라우드 환경에서 옵션에는 Azure Service Bus 및 Amazon SQS와 같은 플랫폼 별 오퍼링도 포함됩니다.
   ~
   NServiceBus
   MSMQ @ MSDN 서비스 버스 메시지를 시작합니다 생산자 및에있을 수 있습니다 소비자 사이의 단지 접착제이라고
   RabbitMQ
   ZeroMQ
   Azure Service Bus @ MSDN
   Amazon SQS @ Amazon AWS
   ~
   주 대기열에서 읽을 기계의 수. 마찬가지로 보고서 생성을 위해이 간접 참조를 사용할 수 있습니다. 그러면 고객이 워크 플로 인스턴스를 만들어 워크 플로 지속성을 사용할 수 있습니다.

3. Windows AppFabric을 사용하여 워크 플로를 호스팅 할 수 있으므로 IIS로드 균형 조정에 적용되는 여러 기술을 사용하여 작업을 배포 할 수 있습니다. 나는 개인적으로 그것에 대한 경험이 없으므로 좋은 모니터링을 지원하는 것 외에는 말할 것도 없다. ~
   How to: Host a Workflow Service with Windows App Fabric @ MSDN