상태 저장 서비스를 사용할시기와 Azure Service Fabric의 외부 지속성에 의존하는시기 이해
현재 WebApps / CloudServices 스택을 대체하기 위해 Azure Service Fabric을 평가하는 시간을 보내고 있으며, 상태가있는 서비스 / 액터가 언제 상태 저장 행위자가되어야하고 언제 상태 비 저장 행위자가되어야 하는지를 결정하는 방법에 대해 약간 확신이 없습니다. 외부 지속 상태 (Azure SQL, Azure Storage 및 DocumentDB). 나는 이것이 (적어도 일반 대중에게는) 상당히 새로운 제품이라는 것을 알고 있으므로 아직 이것에 관한 모범 사례가 많지 않을 것입니다.하지만 확실한 정보를 찾지 못한 채 Microsoft에서 제공하는 대부분의 문서를 읽었습니다. 이것에 대한 대답.
제가 접근하고있는 현재 문제 도메인은 이벤트 스토어입니다. 애플리케이션의 일부는 이벤트 소싱 및 CQRS를 기반으로하며이 이벤트 저장소를 Service Fabric 플랫폼으로 이동하는 방법을 평가하고 있습니다. 이벤트 저장소는 많은 시계열 데이터를 포함 할 것이며, 그곳에서 유지되는 데이터에 대한 우리의 유일한 진실 소스이기 때문에 일관성 있고, 복제되고, 어떤 형태의 내구성있는 저장소에 저장되어야합니다.
제가 이것을 고려한 한 가지 방법은 상태 저장 "EventStream"액터를 사용하는 것입니다. 이벤트 소싱을 사용하는 집계의 각 인스턴스는 격리 된 스트림 내에 이벤트를 저장합니다. 이는 상태 저장 행위자가 자체 스트림에 대한 모든 이벤트를 추적 할 수 있으며 데이터 저장 방법 (트랜잭션, 복제 및 내구성)에 대한 요구 사항을 충족했음을 의미합니다. 그러나 일부 스트림은 매우 커질 수 있으며 (수백만은 아니더라도 수십만 개의 이벤트), 이것이 제가 확실하지 않은 부분입니다. 많은 양의 상태를 가진 액터가 있으면 이러한 대용량 데이터 모델을 디스크로 직렬화하거나 디스크에서 역 직렬화해야 할 때 시스템 성능에 영향을 미칠 것이라고 생각합니다.
또 다른 옵션은 이러한 행위자를 상태 비 저장으로 유지하고 Azure SQL과 같은 일부 외부 저장소에서 데이터를 읽도록하거나 행위자 대신 상태 비 저장 서비스를 사용하도록하는 것입니다.
기본적으로 액터 / 서비스에 대한 상태의 양이 "너무 많은"때는 언제 상태를 처리하는 다른 방법을 고려해야합니까?
또한 Service Fabric Actors 디자인 패턴 의이 섹션 : 일부 안티 패턴 문서는 저를 약간 의아하게 만듭니다.
Azure Service Fabric Actors를 트랜잭션 시스템으로 취급합니다. Azure Service Fabric Actors는 ACID를 제공하는 2 단계 커밋 기반 시스템이 아닙니다. 선택적 지속성을 구현하지 않고 액터가 실행중인 머신이 죽으면 현재 상태가 그대로 유지됩니다. 액터는 다른 노드에 매우 빠르게 올라 오지만 백업 지속성을 구현하지 않으면 상태가 사라질 것입니다. 그러나 재시도, 중복 필터링 및 / 또는 멱 등성 설계를 활용하면 높은 수준의 안정성과 일관성을 얻을 수 있습니다.
"선택적 지속성을 구현하지 않는 경우"는 여기에서 무엇을 의미합니까? 상태를 수정하는 트랜잭션이 성공하는 한 데이터가 내구성있는 저장소에 유지되고 복제본의 하위 집합에 복제된다는 인상을 받았습니다. 이 단락은 내 행위자 / 서비스 내의 상태가 손실되는 상황이 있는지, 그리고 이것이 내가 스스로 처리해야하는 상황인지 궁금하게 만듭니다. 문서의 다른 부분에서 상태 저장 모델에서 얻은 인상은이 진술에 반하는 것 같습니다.
한 가지 옵션은 행위자에 상태의 '일부'를 유지하고 (빠르게 사용할 수 있어야하는 핫 데이터로 간주 될 수 있다고 가정 해 보겠습니다) 나머지 모든 것을 SQL Azure와 같은 '전통적인'스토리지 인프라에 저장하는 것입니다. , DocDB, .... 너무 많은 로컬 상태에 대한 일반적인 규칙을 갖는 것은 어렵지만 핫 데이터와 콜드 데이터에 대해 생각하는 것이 도움이 될 수 있습니다. 신뢰할 수있는 액터는 또한 StateProvider를 사용자 지정하는 기능을 제공하므로 데이터 양, 대기 시간 측면에서 보유한 요구 사항을보다 효율적으로 처리해야하는 특정 정책으로 사용자 지정 StateProvider 구현 (IActorStateProvider 구현)을 고려할 수도 있습니다. , 신뢰성 등 (참고 :
안티 패턴에 대해 : 메모는 여러 행위자간에 트랜잭션을 구현하는 것에 관한 것입니다. 신뢰할 수있는 행위자는 행위자의 경계 내에서 데이터의 신뢰성을 완벽하게 보장합니다. Actor 모델의 분산되고 느슨하게 결합 된 특성으로 인해 여러 액터를 포함하는 트랜잭션을 구현하는 것은 간단한 작업이 아닙니다. '분산'트랜잭션이 강력한 요구 사항 인 경우 안정적인 서비스 프로그래밍 모델이 더 적합 할 것입니다.
나는 이것이 답을 얻었음을 알고 있지만 최근에 CQRS / ES 시스템과 동일한 곤경에 처해 있음을 발견했으며 여기에 내가 어떻게했는지는 다음과 같습니다.
- 각 Aggregate는 현재 상태 만 저장된 액터였습니다.
- 명령에서 집계는 상태 변경에 영향을 미치고 이벤트를 발생시킵니다.
- 이벤트 자체는 DocDb에 저장되었습니다.
- 활성화시 AggregateActor 인스턴스는 상태를 다시 생성 할 수있는 경우 DocDb에서 이벤트를 읽습니다. 이것은 액터 활성화 당 한 번만 수행됩니다. 이것은 액터 인스턴스가 한 노드에서 다른 노드로 마이그레이션되는 경우를 처리했습니다.
@Trond의 sedcondary 질문에 대답하려면 " '선택적 지속성을 구현하지 않으면'는 무엇을 의미합니까?"
액터는 항상 상태 저장 서비스이며 액터 클래스의 속성을 사용하여 해당 상태를 구성하여 다음 세 가지 모드 중 하나로 작동 할 수 있습니다.
- 지속되었습니다. 상태는 모든 복제본 인스턴스에 복제되고 디스크에도 기록됩니다. 이 상태는 모든 복제본이 종료 된 경우에도 유지됩니다.
- 휘발성 물질. 상태는 메모리에서만 모든 복제본 인스턴스에 복제됩니다. 즉, 하나의 복제본 인스턴스가 활성 상태 인 한 상태가 유지됩니다. 그러나 모든 복제본이 종료되면 상태가 손실되고 다시 시작한 후에는 복구 할 수 없습니다.
- 끈기가 없습니다. 상태는 다른 복제본 인스턴스 나 디스크에 복제되지 않습니다. 이것은 최소한의 상태 보호를 제공합니다.
주제에 대한 전체 토론은 Microsoft 문서에서 찾을 수 있습니다.
'programing' 카테고리의 다른 글
| std :: multiset에는 요소가 발견되면 하나의 샘플 (단일화 또는 복제) 만 지우는 함수 또는 알고리즘이 있습니다. (0) | 2020.12.13 |
|---|---|
| Picasa // Google + 동기화 폴더의 갤러리에서 이미지를 가져올 수 없습니다. (0) | 2020.12.13 |
| Android 페이지 말림 애니메이션 (0) | 2020.12.13 |
| Xcode 8 iOS 10 논스톱 기기 로그 (0) | 2020.12.13 |
| nonce가있는 이메일의 활성화 / 등록 / 암호 재설정 링크에 대한 모범 사례는 무엇입니까? (0) | 2020.12.13 |