Azure Service Fabric에서 상태 저장 서비스를 사용해야 하는 시기와 외부 지속성에 의존해야 하는 시기 이해
현재 WebApp/Cloud Services 스택을 대체할 Azure Service Fabric을 평가하면서 저녁 시간을 보내고 있습니다. 상태가 있는 서비스/액터가 상태가 좋은 행위자가 되어야 하는 경우와 외부적으로 지속되는 상태가 없는 행위자가 되어야 하는 경우(Azure SQL, Azure 스토리지 및 DocumentDB)를 어떻게 결정해야 하는지에 대해 약간 확신이 없습니다.저는 이 제품이 (적어도 일반 대중에게는) 상당히 새로운 제품이라는 것을 알고 있기 때문에, 이와 관련된 모범 사례는 아직 많지 않을 것입니다. 하지만 저는 이에 대한 확실한 해답을 찾지 못한 채 Microsoft에서 제공하는 문서의 대부분을 다 읽었습니다.
현재 제가 접근하고 있는 문제 영역은 이벤트 저장소입니다. 애플리케이션의 일부는 이벤트 소싱 및 CQRS를 기반으로 하며, 이 이벤트 저장소를 서비스 패브릭 플랫폼으로 이동하는 방법을 검토 중입니다.이벤트 저장소에는 많은 시계열 데이터가 포함될 것이며, 지속되는 데이터에 대한 유일한 정보원이기 때문에 일정한 형태의 내구성 있는 스토리지에 일관성 있게 복제 및 저장되어야 합니다.
한 가지 방법은 상태 저장 "EventStream" 액터를 사용하는 것입니다. 이벤트 소스를 사용하는 Aggregate의 각 인스턴스는 해당 이벤트를 격리된 스트림 내에 저장합니다.즉, 스테이트풀한 행위자가 자신의 스트림에 대해 모든 이벤트를 추적할 수 있으며, 데이터 저장 방법(트랜잭션, 복제 및 내구성)에 대한 요구 사항을 충족할 수 있습니다.그러나 일부 스트림은 매우 커질 수 있으며(수백만 개는 아니더라도 수십만 개의 이벤트), 이것이 바로 제가 확신하지 못하는 부분입니다.이러한 대규모 데이터 모델을 디스크에 직렬화하거나 디스크에서 직렬화해야 할 때 상태가 큰 행위자가 있으면 시스템 성능에 영향을 미칠 것으로 생각됩니다.
또 다른 옵션은 이러한 행위자를 상태 비저장 상태로 유지하고 Azure SQL과 같은 외부 스토리지에서 데이터를 읽게 하거나 행위자 대신 상태 비저장 서비스를 사용하도록 하는 것입니다.
기본적으로 배우/서비스에 대한 상태의 양은 언제 "너무 많다"며 상태를 다루는 다른 방법을 고려하기 시작해야 합니까?
또한 서비스 패브릭 액터 설계 패턴의 이 섹션에서는 패턴 방지 설명서에 대해 설명합니다.
Azure Service Fabric Actors를 트랜잭션 시스템으로 처리합니다.Azure Service Fabric Actors는 ACID를 제공하는 2단계 커밋 기반 시스템이 아닙니다.만약 우리가 선택적 지속성을 구현하지 않고 행위자가 실행 중인 기계가 죽으면, 그 현재 상태는 그것과 함께 진행될 것입니다.배우가 다른 노드에서 매우 빠르게 등장할 것이지만, 우리가 지원 지속성을 구현하지 않는 한, 상태는 사라질 것입니다.그러나 재시도, 중복 필터링 및/또는 동일한 설계를 활용하면 높은 수준의 안정성과 일관성을 달성할 수 있습니다.
여기서 "선택적 저항을 구현하지 않을 경우"는 무엇을 의미합니까?상태를 수정하는 트랜잭션이 성공적으로 수행되는 한 데이터는 내구성 있는 스토리지로 유지되고 복제본의 하위 집합으로 복제됩니다.이 단락은 배우/서비스 내에서 상태가 상실되는 상황이 있는지, 그리고 이것이 내가 스스로 해결해야 할 문제인지 궁금하게 만듭니다.문서의 다른 부분에서 스테이트풀 모델로부터 받은 인상은 이 진술을 반박하는 것 같습니다.
한 가지 방법은 상태의 '일부'를 액터에 유지하고(즉, 신속하게 사용할 수 있어야 하는 핫 데이터로 간주할 수 있음) 나머지 모든 것을 SQL Azure, DocDB 등과 같은 '기존' 스토리지 인프라에 저장하는 것입니다.너무 많은 로컬 상태에 대한 일반적인 규칙을 갖는 것은 어렵지만, 핫 데이터 대 콜드 데이터에 대해 생각하는 것이 도움이 될 수 있습니다.또한 신뢰할 수 있는 Actor는 StateProvider를 사용자 지정할 수 있는 기능을 제공하므로 데이터 양, 대기 시간, 대기 시간 등의 측면에서 보다 효율적으로 사용해야 하는 특정 정책을 사용하여 맞춤형 StateProvider를 구현하는 것도 고려할 수 있습니다.신뢰성 등(참고: StateProvider 인터페이스에서는 설명서가 여전히 매우 미미하지만, 이를 추구하고자 하는 경우 몇 가지 샘플 코드를 게시할 수 있습니다.)
안티패턴 정보: 노트는 여러 행위자 간의 트랜잭션 구현에 관한 것입니다.신뢰할 수 있는 행위자는 행위자의 경계 내에서 데이터의 신뢰성에 대한 완전한 보증을 제공합니다.Actor 모델의 분산되고 느슨하게 결합된 특성 때문에 여러 행위자를 포함하는 트랜잭션을 구현하는 것은 사소한 작업이 아닙니다.분산 트랜잭션이 강력한 요구사항이라면 신뢰할 수 있는 서비스 프로그래밍 모델이 더 적합할 것입니다.
이에 대한 답변이 있었지만, 최근 CQRS/ES 시스템과 동일한 상황에 처해 있다는 것을 알게 되었고, 이에 대한 대처 방법은 다음과 같습니다.
- 각 Aggregate는 현재 상태만 저장된 행위자였습니다.
- 명령에서 집계는 상태 변경에 영향을 미치고 이벤트를 발생시킵니다.
- 이벤트 자체가 DocDb에 저장되었습니다.
- 활성화 시 AggregateActor 인스턴스는 상태를 재생성할 수 있는 경우 DocDb에서 이벤트를 읽습니다.이것은 분명히 배우 활성화당 한 번만 수행됩니다.이것은 한 노드에서 다른 노드로 배우 인스턴스가 마이그레이션되는 경우를 처리했습니다.
@Trond의 두 번째 질문인 "'선택적 지속성을 구현하지 않으면'은 여기서 무엇을 의미합니까?"에 대답합니다.
액터는 항상 상태 저장 서비스이며 액터 클래스의 속성을 사용하여 다음 세 가지 모드 중 하나로 작동하도록 상태를 구성할 수 있습니다.
- 끈질기게.상태는 모든 복제본 인스턴스에 복제되며 디스크에도 기록됩니다.이 상태는 모든 복제본이 종료된 경우에도 유지됩니다.
- 휘발성의.상태는 메모리에서만 모든 복제본 인스턴스에 복제됩니다.즉, 하나의 복제본 인스턴스가 활성 상태인 한 상태가 유지됩니다.그러나 모든 복제본이 종료되면 상태가 손실되고 재시작된 후 복구할 수 없습니다.
- 집요함이 없습니다.상태는 다른 복제본 인스턴스나 디스크에 복제되지 않습니다.이것은 최소한의 상태 보호를 제공합니다.
이 항목에 대한 자세한 내용은 Microsoft 설명서에서 확인할 수 있습니다.
언급URL : https://stackoverflow.com/questions/30051408/understanding-when-to-use-stateful-services-and-when-to-rely-on-external-persist
'programing' 카테고리의 다른 글
| 콘솔에 Swift 사전을 예쁘게 인쇄할 수 있는 방법이 있습니까? (0) | 2023.05.18 |
|---|---|
| Angular 2+에서 spec.ts 파일 없이 구성 요소를 생성하는 중 (0) | 2023.05.18 |
| 경로 및 파일 이름에서 잘못된 문자를 제거하는 방법은 무엇입니까? (0) | 2023.05.18 |
| 코드사인이 키 체인의 키 "액세스"에 액세스하고 싶어합니다. 로그인 암호를 입력했지만 계속 묻습니다. (0) | 2023.05.18 |
| Windows 명령줄에서 Git Bash를 시작하는 방법 (0) | 2023.05.18 |