Service Fabric으로 상태 저장 마이크로서비스 운영하기

Microsoft Service Fabric은 클라우드 규모의 계층 1(Tier-1) 애플리케이션을 컨테이너와 마이크로서비스 단위로 빌드·배포·운영하기 위한 분산 시스템 플랫폼이다. 패키징과 자동 롤링 업그레이드, 상태 저장(Stateful) 서비스 지원, 헬스 모델과 자가 치유 메커니즘을 갖추고 있고 Windows·Linux, 퍼블릭 클라우드·온프레미스 전반에서 쓸 수 있다.

클러스터가 애플리케이션을 담는 방식

클러스터는 노드(Node) 집합으로 구성되고, 용도와 격리 수준을 정의하는 노드 타입(Node Type) 아래 애플리케이션 타입/버전과 서비스, 파티션, 레플리카가 애플리케이션 모델을 이룬다. 패키지는 이미지 스토어(Image Store)에 저장되고 여기서부터 배포가 관리된다. 프로그래밍 모델은 컨테이너·게스트 실행 파일뿐 아니라 Reliable Services(Stateless/Stateful), Reliable Actors까지 아우르며 DNS·네이밍 서비스로 서비스 디스커버리를 제공한다.

상태를 서비스 안에 두는 방식

Reliable Collections·Actors는 애플리케이션 레벨에서 상태를 관리하며, 프라이머리-세컨더리 동기 복제와 쿼럼 합의로 강한 일관성을 보장한다. 파티셔닝과 레플리카 셋 구성을 통해 고가용성과 선형적 확장성을 동시에 달성하는 것이 이 모델의 핵심이다. 리소스·상태 관리는 파티셔닝, 프라이머리-세컨더리 레플리카 구조, 트랜잭션 로그 복제·쿼럼 커밋으로 강한 일관성을 보장하고, 리소스 매니저와 로드 밸런서가 동적 리밸런싱을 수행한다.

배포와 무중단 업그레이드

애플리케이션 타입·버전·매개변수 기반의 표준화된 패키징과 프로비저닝이 준비되면, 이미지 스토어 업로드 → 프로비저닝 → 인스턴스 생성 순으로 배포가 진행된다. 업그레이드는 헬스 기반 롤링 업그레이드와 자동 롤백 메커니즘을 갖추고 있어 버전을 병행 운영하며 점진적으로 트래픽을 전환할 수 있다.

⤢✕

운영 절차를 요약하면 입력은 컨테이너 이미지·애플리케이션 매니페스트·파티션/레플리카 설정이고, 처리는 이미지 스토어 업로드→프로비저닝→롤링 업그레이드→헬스 게이트 평가→자동 리밸런싱 순이며, 출력은 신규 버전 활성화와 헬스 상태 정상화, 트래픽 전환 완료다. 헬스 게이트를 통과하지 못하면 자동 롤백이 일어나고 실패한 노드는 격리된 뒤 백오프를 두고 재시도된다.

오케스트레이션과 배치, 그리고 관측성

컨테이너·게스트·네이티브 서비스를 혼합 배치할 수 있고, 배치 제약(Placement Constraints)과 업타임·포트·리소스 기반 스케줄링을 지원한다. 장애 노드는 자동으로 회피되고 자동 리밸런싱과 자가 치유(Replica Reconfiguration)가 뒤따른다. 헬스 모델과 ETW/로그 수집, 이벤트 구독으로 이상을 감지하고 근본 원인을 추적하며, 수리 관리자(Repair Manager)와 연동해 자동 복구 절차를 구성한다. 백업·복구, 데이터 손실 보호, 업그레이드 도중의 헬스 게이트 기반 안전성 확보도 이 관측성 체계의 일부다.

보안은 X.509 인증서 기반 상호 인증과 암호화로 구성되고, 관리 엔드포인트 접근 제어와 인증서 회전 절차를 지원한다. 노드 타입을 분리·격리하면 멀티테넌트·다계층 아키텍처도 구현할 수 있다.

Service Fabric vs Kubernetes

지표	Service Fabric	Kubernetes
성능	상태 저장 서비스의 로컬 상태 접근과 동기 복제 기반 낮은 지연 제공	광범위한 최적화와 CNI/CSI 선택지로 균형적 성능 제공
확장성	파티셔닝+레플리카 기반 선형 확장, 노드 타입별 스케일 아웃 지원	수평 확장에 최적화, 대규모 클러스터 운영 성숙
일관성	프라이머리-세컨더리 쿼럼 커밋의 강한 일관성 기본 제공	스토리지/오퍼레이터 조합에 따른 선택적 일관성 모델
안정성	헬스 모델·자가 치유·무중단 업그레이드 내장	헬스 프로브·롤링 업데이트·오토리페어 체계 제공
운영 편의	애플리케이션 타입/버전·헬스 기반 롤백 표준화	에코시스템 광범위, 표준 API와 도구 체계 풍부

실제 선택은 조직의 기술 스택, 상태 저장 요구, 운영 인력 역량, 에코시스템 의존성에 따른 트레이드오프로 결정해야 한다.

CLI로 배포해보기

sfctl(Python 기반)이 설치돼 있고 클러스터 엔드포인트 접근 권한·인증서가 구성돼 있으며 컨테이너 이미지가 사전에 푸시돼 있다는 전제 위에서, 배포 흐름은 다음과 같다.

# 클러스터 로그인
sfctl cluster select --endpoint http://localhost:19080

# 애플리케이션 패키지 업로드
sfctl application upload --path ./MyAppPkg --show-progress

# 애플리케이션 타입 프로비저닝
sfctl application provision --application-type-build-path MyAppPkg

# 애플리케이션 인스턴스 생성
sfctl application create \
  --app-name fabric:/MyApp \
  --app-type MyAppType \
  --app-version 1.0.0

파티션 키 설계는 배포 전에 반드시 검증해야 한다(키 스큐를 방지하기 위해서다). 로드·데이터 분포를 모니터링하며 동적 재파티셔닝 계획을 세우고, 업그레이드 도중에는 헬스 폴리시를 엄격하게 설정하는 편이 좋다(서비스·애그리게이트 헬스 기준을 분리하고 자동 롤백 조건을 구체화한다). 인증서 수명·회전 절차는 SCEP·Key Vault 통합으로 자동화하는 것이 권장된다.

언제 쓰는가

세션 관리, 순서 보장 스트림 처리, 게임·실시간 매치메이킹처럼 강한 일관성과 낮은 지연이 필요한 대규모 상태 저장 트랜잭션 처리에 적합하다. 파티션 키 설계와 레플리카 수 조절로 선형 확장을 구성할 수 있다. SaaS 멀티테넌트 플랫폼에서는 테넌트별 파티션·네임스페이스를 분리하고 배치 제약으로 데이터·성능을 격리하며 버전별 점진 배포로 릴리스 리스크를 낮춘다. Windows·Linux 혼합 노드와 게스트 실행 파일이 공존해야 하는 하이브리드·온프레미스 환경에서는 레거시 워크로드를 단계적으로 컨테이너로 전환하는 전략에 쓸 수 있다. 99.99% 이상의 가용성을 목표로 하는 금융·통신 백엔드 같은 미션 크리티컬 서비스에서는 계획·비계획 장애 모두에 대한 자동 복구와 무중단 업그레이드가 필요하다. 다중 노드 타입에 35개 레플리카를 두는 구성을 가정하면 목표 가용성 99.9599.99%를 구성할 수 있다.

쿼럼 기반 복제와 자동 장애 조치는 계획·비계획 장애 상황에서도 서비스 연속성을 확보해 준다. 헬스 기반 롤링 업그레이드로 무중단 배포를 실현하고 배포가 실패하면 자동 롤백돼 평균 복구 시간(MTTR)이 분 단위로 줄어든다. 상태 저장 서비스의 로컬 접근과 파티셔닝은 P99 지연을 줄이고 처리량을 높이며, 외부 DB 의존도가 줄어드는 만큼 인프라 비용도 절감될 수 있다. 표준화된 패키징·헬스 모델은 배포 실패율을 낮추고 운영 자동화 범위를 넓히며, 내장된 관측성은 장애 탐지·분석 시간을 줄여준다.

Service Fabric의 핵심 가치는 상태 저장 마이크로서비스의 강한 일관성, 무중단 업그레이드, 자가 치유 기반 안정 운영에 있다. 컨테이너·게스트·네이티브 모델을 혼합 지원하기 때문에 단계적 현대화 전략에도 맞고, 강한 일관성과 낮은 지연, 운영 자동화가 필요한 엔터프라이즈급 워크로드에서 우선 검토할 만하다. 다만 Kubernetes 등 대안과의 트레이드오프는 도입 전에 반드시 평가하고, 파티션·레플리카·업그레이드 정책을 표준화한 뒤 프로덕션에 적용하는 편이 안전하다.