Azure Service Fabric의 마이크로서비스 아키텍처

이 참조 아키텍처는 Azure Service Fabric에 배포된 마이크로 서비스 아키텍처를 보여 줍니다. 대부분의 배포에서 시작점으로 사용할 수 있는 기본 클러스터 구성을 보여 줍니다.

이 아키텍처의 참조 구현은 GitHub에서 사용할 수 있습니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

이 아키텍처는 다음 구성 요소로 구성됩니다. 다른 용어는 Service Fabric 용어 개요를 참조하세요.

• Service Fabric 클러스터. 클러스터는 마이크로 서비스를 배포하고 관리하는, 네트워크로 연결된 VM(가상 머신) 세트입니다.

• 가상 머신 확장 집합. 가상 머신 확장 집합을 사용하면 동일한 부하 분산 및 자동 크기 조정 VM 그룹을 만들고 관리할 수 있습니다. 이러한 컴퓨팅 리소스는 장애 및 업그레이드 도메인도 제공합니다.

• 노드. 노드는 Service Fabric 클러스터에 속하는 VM입니다.

• 노드 형식. 노드 형식은 노드 컬렉션을 배포하는 가상 머신 확장 집합을 나타냅니다. Service Fabric 클러스터에는 하나 이상의 노드 형식이 있습니다.

  여러 노드 형식이 있는 클러스터에서는 하나를 주 노드 형식으로 선언해야 합니다. 클러스터의 주 노드 형식은 Service Fabric 시스템 서비스를 실행합니다. 이러한 서비스는 Service Fabric의 플랫폼 기능을 제공합니다. 기본 노드 형식은 기본 클러스터의 가용성을 유지하는 노드인 시드 노드의 역할도 작동합니다.

  서비스를 실행하도록 추가 노드 형식을 구성합니다.

• 서비스. 서비스는 다른 서비스와 독립적으로 시작하고 실행할 수 있는 독립 실행형 기능을 수행합니다. 서비스 인스턴스는 클러스터의 노드에 배포됩니다. Service Fabric에는 다음과 같은 두 가지 종류의 서비스가 있습니다.

  • 상태 비저장 서비스. 상태 비저장 서비스는 서비스 내에서 상태를 유지하지 않습니다. 상태 지속성이 필요한 경우 상태가 Azure Cosmos DB와 같은 외부 저장소에 기록되고 검색됩니다.
  • 상태 저장 서비스. 서비스 상태는 서비스 자체 내에서 유지됩니다. 대부분의 상태 저장 서비스는 Service Fabric의 신뢰할 수 있는 컬렉션을 통해 이를 구현합니다.

• Service Fabric Explorer. Service Fabric Explorer는 Service Fabric 클러스터를 검사하고 관리하기 위한 오픈 소스 도구입니다.

• Azure Pipelines. Azure Pipelines는 Azure DevOps Services의 일부이며 자동화된 빌드, 테스트 및 배포를 실행합니다. Jenkins와 같은 타사 CI/CD(연속 통합 및 지속적인 업데이트) 솔루션을 사용할 수도 있습니다.

• Azure Monitor Azure Monitor는 솔루션 및 애플리케이션 원격 분석의 Azure 서비스에 대한 플랫폼 메트릭을 포함하여 메트릭 및 로그를 수집 및 저장합니다. 이 데이터를 사용하여 애플리케이션을 모니터링하고, 경고 및 대시보드를 설정하고, 오류의 근본 원인을 분석할 수 있습니다. Azure Monitor는 Service Fabric과 통합되어 컨테이너 및 노드 로그와 함께 컨트롤러, 노드, 컨테이너에서 메트릭을 수집합니다.

• Azure Key Vault Key Vault를 사용하여 마이크로 서비스에서 사용하는 애플리케이션 비밀(예: 연결 문자열)을 저장합니다.

• Azure API Management. 이 아키텍처에서 API Management는 클라이언트의 요청을 수락하고 서비스로 라우팅하는 API 게이트웨이 역할을 합니다.

고려 사항

이러한 고려 사항은 워크로드 품질을 향상하는 지침 원칙 세트인 Azure Well-Architected Framework의 핵심 요소를 구현합니다.

디자인 고려 사항

이 참조 아키텍처는 마이크로 서비스 아키텍처에 중점을 줍니다. 마이크로 서비스는 독립적으로 버전이 지정된 작은 코드 단위입니다. 서비스 검색 메커니즘을 통해 검색할 수 있으며 API를 통해 다른 서비스와 통신할 수 있습니다. 각 서비스는 자체 포함되며 단일 비즈니스 기능을 구현해야 합니다. 애플리케이션 도메인을 마이크로 서비스로 분해하는 방법에 대한 자세한 내용은 도메인 분석을 사용하여 마이크로 서비스 모델링을 참조하세요.

Service Fabric은 마이크로 서비스를 효율적으로 빌드, 배포, 업그레이드하는 인프라를 제공합니다. 또한 오류 발생 시 자동 크기 조정, 상태 관리, 상태 모니터링, 서비스 다시 시작 옵션을 제공합니다.

Service Fabric은 애플리케이션이 마이크로 서비스의 컬렉션인 애플리케이션 모델을 따릅니다. 애플리케이션은 애플리케이션 매니페스트 파일에 설명되어 있습니다. 이 파일은 독립 서비스 패키지를 가리키는 포인터와 함께 애플리케이션에 포함된 서비스 유형을 정의합니다.

애플리케이션 패키지에는 일반적으로 서비스에서 사용하는 특정 설정에 대한 재정의 역할을 하는 매개 변수도 포함됩니다. 각 서비스 패키지에는 이진, 구성 파일, 읽기 전용 데이터를 포함하여 해당 서비스를 실행하는 데 필요한 실제 파일 및 폴더를 설명하는 매니페스트 파일이 있습니다. 서비스 및 애플리케이션은 독립적으로 버전이 지정되고 업그레이드할 수 있습니다.

필요에 따라 애플리케이션 매니페스트는 애플리케이션 인스턴스를 만들 때 자동으로 프로비저닝되는 서비스를 설명할 수 있습니다. 이를 기본 서비스라고 합니다. 이 경우 애플리케이션 매니페스트는 이러한 서비스를 만드는 방법도 설명합니다. 이 정보에는 서비스 이름, 인스턴스 수, 보안 또는 격리 정책 및 배치 제약 조건이 포함됩니다.

자세한 내용은 Service Fabric이 궁금하신가요?를 참조하세요.

애플리케이션-서비스 패키징 모델

마이크로 서비스의 신조는 각 서비스를 독립적으로 배포할 수 있다는 것입니다. Service Fabric에서 모든 서비스를 단일 애플리케이션 패키지로 그룹화하고 하나의 서비스를 업그레이드하지 못하면 전체 애플리케이션 업그레이드가 롤백됩니다. 이 롤백으로 인해 다른 서비스가 업그레이드되지 않습니다.

따라서 마이크로 서비스 아키텍처에서는 여러 애플리케이션 패키지를 사용하는 것이 좋습니다. 하나 이상의 밀접하게 관련된 서비스 유형을 단일 애플리케이션 유형에 배치합니다. 예를 들어 팀이 다음 특성 중 하나가 있는 서비스 세트를 담당하는 경우 서비스 유형을 동일한 애플리케이션 유형에 배치합니다.

• 서비스가 같은 기간 동안 실행되며 동시에 업데이트해야 합니다.
• 서비스의 수명 주기가 동일합니다.
• 서비스가 종속성 또는 구성과 같은 리소스를 공유합니다.

Service Fabric 프로그래밍 모델

Service Fabric 애플리케이션에 마이크로 서비스를 추가할 때 가용성이 높고 안정적이어야 하는 상태 또는 데이터가 있는지 여부를 결정합니다. 그렇다면 데이터를 외부에 저장할 수 있나요, 아니면 데이터가 서비스의 일부로 포함될 수 있나요? 데이터를 저장할 필요가 없거나 외부 스토리지에 데이터를 저장하려는 경우 상태 비저장 서비스를 선택합니다. 다음 설명 중 하나에 해당하면 상태 저장 서비스를 선택하는 것이 좋습니다.

• 상태 또는 데이터를 서비스의 일부로 유지하려고 합니다. 예를 들어 데이터가 코드와 가까운 메모리에 상주해야 합니다.
• 외부 저장소에 대한 종속성을 허용할 수 없습니다.

Service Fabric에서 실행하려는 기존 코드가 있는 경우 서비스로 실행되는 임의의 실행 파일인 게스트 실행 파일로 실행하면 됩니다. 또는 배포에 필요한 모든 종속성이 있는 컨테이너에 실행 파일을 패키징하면 됩니다.

Service Fabric은 컨테이너와 게스트 실행 파일을 모두 상태 비저장 서비스로 모델화합니다. 모델 선택에 대한 지침은 Service Fabric 프로그래밍 모델 개요를 참조하세요.

게스트 실행 파일이 실행되는 환경을 유지 관리할 책임이 있습니다. 예를 들어 게스트 실행 파일에 Python이 필요하다고 가정합니다. 실행 파일이 자체 포함되지 않은 경우 필요한 Python 버전이 환경에 미리 설치되어 있는지 확인해야 합니다. Service Fabric이 환경을 관리하지 않습니다. Azure는 사용자 지정 가상 머신 이미지 및 확장을 포함하여 환경을 설정하는 여러 메커니즘을 제공합니다.

역방향 프록시를 통해 게스트 실행 파일에 액세스하려면 게스트 실행 파일의 서비스 매니페스트에서 Endpoint 요소에 UriScheme 특성을 추가해야 합니다.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

서비스에 추가 경로가 있는 경우 PathSuffix 값에 경로를 지정합니다. 이 값의 접두사 또는 접미사로 슬래시(/)를 사용해서는 안 됩니다. 또 다른 방법은 서비스 이름에 경로를 추가하는 것입니다.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

자세한 내용은 다음을 참조하세요.

• 애플리케이션 패키지 작성
• 기존 실행 파일을 Service Fabric으로 패키징 및 배포

API 게이트웨이

API 게이트웨이(수신)는 외부 클라이언트와 마이크로 서비스 사이에 위치하는 게이트웨이입니다. 역방향 프록시로 작동하면서 클라이언트에서 마이크로 서비스로 요청을 라우팅합니다. 또한 인증, SSL 종료 및 속도 제한과 같은 교차 작업을 수행할 수도 있습니다.

대부분의 시나리오에는 Azure API Management를 사용하는 것이 좋으며, 인기 있는 오픈 소스 대안으로 Traefik이 있습니다. 두 기술 옵션은 모두 Service Fabric과 통합됩니다.

• API Management. 공용 IP 주소를 노출하고 트래픽을 서비스로 라우팅합니다. Service Fabric 클러스터와 동일한 가상 네트워크의 전용 서브넷에서 실행됩니다.

  API Management는 개인 IP 주소가 있는 부하 분산 장치를 통해 노출되는 노드 형식의 서비스에 액세스할 수 있습니다. 이 옵션은 API Management의 프리미엄 및 개발자 계층에서만 사용할 수 있습니다. 프로덕션 워크로드의 경우 프리미엄 계층을 사용합니다. 가격 책정 정보는 API Management 가격 책정에 설명되어 있습니다.

  자세한 내용은 Service Fabric 및 Azure API Management 개요를 참조하세요.

• Traefik. 라우팅, 추적, 로그, 메트릭과 같은 기능을 지원합니다. Traefik은 Service Fabric 클러스터에서 상태 비저장 서비스로 실행됩니다. 라우팅을 통해 서비스 버전 관리가 지원될 수 있습니다.

  서비스 수신 및 클러스터 내 역방향 프록시로 Traefik을 설정하는 방법에 대한 자세한 내용은 Traefik 웹 사이트의 Azure Service Fabric 공급자를 참조하세요. Service Fabric에서 Traefik를 사용하는 방법에 대한 자세한 내용은 Traefik을 사용한 Service Fabric의 지능형 라우팅 블로그 게시물을 참조하세요.

Traefik은 Azure API Management와 달리 요청이 라우팅되는 상태 저장 서비스(둘 이상의 파티션 포함)의 파티션을 확인하는 기능이 없습니다. 자세한 내용은 분할 서비스에 대한 검사기 추가를 참조하세요.

다른 API 관리 옵션으로는 Azure Application Gateway 및 Azure Front Door가 있습니다. 이러한 서비스를 API Management와 함께 사용하여 라우팅, SSL 종료, 방화벽과 같은 작업을 수행할 수 있습니다.

서비스 간 통신

서비스 간 통신을 용이하게 하려면 다음 권장 사항을 따르는 것이 좋습니다.

• 통신 프로토콜. 마이크로 서비스 아키텍처에서 서비스는 런타임에 최소 결합으로 서로 통신해야 합니다. 언어 중립적 통신을 사용하기 위한 HTTP는 다양한 언어로 제공되는 다양한 도구와 HTTP 서버를 갖춘 업계 표준입니다. Service Fabric은 모든 도구와 서버를 지원합니다.

  대부분의 워크로드에는 Service Fabric에 기본 제공되는 서비스 원격 대신 HTTP를 사용하는 것이 좋습니다.

• 서비스 검색. 클러스터 내의 다른 서비스와 통신하려면 클라이언트 서비스가 대상 서비스의 현재 위치를 확인해야 합니다. Service Fabric에서는 서비스가 노드 간에 이동할 수 있으며 서비스 엔드포인트가 동적으로 변경됩니다.

  부실 엔드포인트에 연결되지 않도록 하려면 Service Fabric의 Naming Service를 사용하여 업데이트된 엔드포인트 정보를 검색하면 됩니다. 그러나 Service Fabric은 명명 서비스를 추상화하는 기본 제공 역방향 프록시 서비스도 제공합니다. 이 서비스 검색 옵션은 사용하기 쉽고 코드가 간단하기 때문에 대부분의 시나리오에서 기준으로 사용하는 것이 좋습니다.

그 외에도 다음과 같은 서비스 간 통신 옵션이 있습니다.

• 고급 라우팅을 위한 Traefik입니다.
• 서비스에서 DNS를 사용해야 하는 호환성 시나리오에 대한 DNS입니다.
• 서비스 엔드포인트를 캐시하는 ServicePartitionClient<TCommunicationClient> 클래스입니다. 호출이 중개자 또는 사용자 지정 프로토콜 없이 서비스 간에 직접 이동하므로 보다 나은 성능을 제공할 수 있습니다.

확장성

Service Fabric은 다음 클러스터 엔터티의 스케일링을 지원합니다.

• 각 노드 유형의 노드 수 스케일링
• 서비스 스케일링

이 섹션은 자동 스케일링에 중점을 줍니다. 상황에 따라 수동으로 스케일링하도록 선택할 수 있습니다. 예를 들어 인스턴스 수를 설정하려면 수동 개입이 필요할 때가 있습니다.

스케일링 성능을 위한 초기 클러스터 구성

Service Fabric 클러스터를 만들 때 보안 및 스케일링 성능 요구 사항에 따라 노드 유형을 프로비저닝합니다. 각 노드 유형은 가상 머신 확장 집합에 매핑되며 독립적으로 스케일링할 수 있습니다.

• 스케일링 성능 또는 리소스 요구 사항이 다른 각 서비스 그룹에 대한 노드 유형을 만듭니다. 먼저 Service Fabric 시스템 서비스에 대한 노드 형식(기본 노드 형식이 됨)을 프로비저닝합니다. 공용 또는 프런트 엔드 서비스를 실행할 별도의 노드 유형을 만듭니다. 백 엔드 및 프라이빗 또는 격리된 서비스에 필요한 다른 노드 형식을 만듭니다. 서비스가 의도한 노드 형식에만 배포되도록 배치 제약 조건을 지정합니다.
• 각 노드 형식의 내구성 계층을 지정합니다. 내구성 계층은 Service Fabric이 가상 머신 확장 집합의 업데이트 및 유지 관리 작업에 영향을 주는 기능을 나타냅니다. 프로덕션 워크로드의 경우 Silver 이상의 내구성 계층을 선택합니다. 각 계층에 대한 자세한 내용은 클러스터의 내구성 특성을 참조하세요.
• Bronze 내구성 계층을 사용하는 경우 특정 작업에는 수동 단계가 필요합니다. Bronze 내구성 계층을 사용하는 노드 형식은 스케일 인하는 동안 추가 단계가 필요합니다. 스케일링 작업에 대한 자세한 내용은 이 가이드를 참조하세요.

노드 스케일링

Service Fabric은 스케일 인 및 스케일 아웃의 자동 크기 조정을 지원합니다. 각 노드 형식이 독립적으로 자동 크기 조정되도록 구성할 수 있습니다.

각 노드 형식에는 최대 100개의 노드가 있을 수 있습니다. 작은 노드 세트로 시작하고, 이후 부하에 따라 더 많은 노드를 추가합니다. 노드 형식에 100개가 넘는 노드가 필요한 경우 더 많은 노드 형식을 추가해야 합니다. 자세한 내용은 Service Fabric 클러스터 용량 계획 고려 사항을 참조하세요. 가상 머신 확장 집합은 즉시 스케일링되지 않으므로 자동 스케일링 규칙을 설정할 때 해당 요소를 고려합니다.

자동 스케일 인을 지원하려면 실버 또는 골드 내구성 계층을 갖도록 노드 형식을 구성합니다. 이 구성은 Service Fabric이 서비스 재배치를 완료할 때까지 스케일 인을 지연합니다. 또한 가상 머신 확장 집합은 Service Fabric에 VM이 일시적으로 다운된 것이 아니라 제거되었다고 알립니다.

노드 또는 클러스터 수준의 스케일링에 대한 자세한 내용은 Azure Service Fabric 클러스터 스케일링을 참조하세요.

서비스 스케일링

상태 비저장 및 상태 저장 서비스는 스케일링에 다양한 접근 방식을 적용합니다.

상태 비저장 서비스(자동 크기 조정):

• 평균 파티션 로드 트리거를 사용합니다. 이 트리거는 스케일링 정책에 지정된 부하 임계값에 따라 서비스가 스케일 인 또는 스케일 아웃되는 시기를 결정합니다. 트리거가 검사되는 빈도를 설정할 수도 있습니다. 인스턴스 기반 스케일링을 사용하는 평균 파티션 로드 트리거를 참조하세요. 이 접근 방식을 사용하면 사용 가능한 최대 노드 수까지 스케일링할 수 있습니다.
• 서비스 매니페스트에서 InstanceCount를 -1로 설정하면 Service Fabric이 모든 노드에서 서비스 인스턴스를 실행하도록 지시합니다. 이 방법을 사용하면 클러스터가 스케일링됨에 따라 서비스가 동적으로 스케일링할 수 있습니다. 클러스터의 노드 수가 변경되면 Service Fabric은 일치시킬 서비스 인스턴스를 자동으로 만들고 삭제합니다.

상태 저장 서비스의 경우 스케일링은 파티션 수, 각 파티션의 크기, 머신에서 실행되는 파티션/복제본 수에 의해 제어됩니다.

• 분할된 서비스를 만드는 경우 리소스 경합을 일으키지 않고 각 노드가 워크로드를 고르게 배포할 수 있는 적절한 복제본을 가져오는지 확인합니다. 노드를 더 추가하면 Service Fabric은 기본적으로 워크로드를 새 머신에 배포합니다. 예를 들어 5개의 노드와 10개의 파티션이 있는 경우 기본적으로 Service Fabric은 각 노드에 두 개의 주 복제본을 배치합니다. 노드를 스케일 아웃하면 작업이 더 많은 리소스에 균등하게 분산되므로 더 큰 성능을 얻을 수 있습니다.

  이 전략을 활용하는 시나리오에 대한 자세한 내용은 Service Fabric의 스케일링을 참조하세요.

• 파티션 추가 또는 제거는 잘 지원되지 않습니다. 스케일링에 일반적으로 사용되는 또 다른 옵션은 서비스 또는 전체 애플리케이션 인스턴스를 동적으로 만들거나 삭제하는 것입니다. 해당 패턴의 예는 명명된 새 서비스를 만들거나 제거하여 스케일링에 설명되어 있습니다.

자세한 내용은 다음을 참조하세요.

• 자동 크기 조정 규칙을 사용하여 또는 수동으로 Service Fabric 클러스터 스케일 인 또는 아웃
• 프로그래밍 방식으로 Service Fabric 클러스터의 크기 조정
• 가상 머신 확장 집합을 추가하여 Service Fabric 클러스터 스케일 아웃

메트릭을 사용하여 부하 분산

파티션을 디자인하는 방법에 따라 다른 복제본보다 더 많은 트래픽을 가져오는 복제본이 있는 노드가 있을 수 있습니다. 이 상황을 방지하려면 모든 파티션에 분산되도록 서비스 상태를 분할합니다. 좋은 해시 알고리즘을 사용하여 범위 파티션 구성표를 사용합니다. 분할 시작을 참조하세요.

Service Fabric은 메트릭을 사용하여 클러스터 내에서 서비스를 배치하고 균형을 맞추는 방법을 알고 있습니다. 해당 서비스를 만들 때 서비스와 연결된 각 메트릭에 대한 기본 부하를 지정할 수 있습니다. 그러면 Service Fabric은 서비스를 배치할 때 또는 클러스터의 노드 균형을 맞추기 위해 서비스를 이동해야 할 때마다(예: 업그레이드 중) 해당 로드를 고려합니다.

서비스에 대해 처음 지정된 기본 로드는 서비스의 수명 동안 변경되지 않습니다. 서비스에 대한 변경 메트릭을 캡처하려면 서비스를 모니터링한 다음, 부하를 동적으로 보고하는 것이 좋습니다. 이 접근 방식을 사용하면 Service Fabric은 지정된 시간에 보고된 부하에 따라 할당을 조정할 수 있습니다. IServicePartition.ReportLoad 메서드를 사용하여 사용자 지정 메트릭을 보고합니다. 자세한 내용은 동적 로드를 참조하세요.

가용성

서비스를 기본 노드 형식이 아닌 노드 형식에 배치합니다. Service Fabric 시스템 서비스는 항상 기본 노드 형식에 배포됩니다. 서비스가 기본 노드 형식에 배포되는 경우 리소스를 두고 시스템 서비스와 경합(하여 시스템 서비스를 방해)할 수 있습니다. 노드 형식이 상태 저장 서비스를 호스트해야 하는 경우 노드 인스턴스가 5개 이상 있는지 확인하고 Silver 또는 Gold 내구성 계층을 선택합니다.

서비스의 리소스를 제한하는 것이 좋습니다. 리소스 거버넌스 메커니즘을 참조하세요.

일반적인 고려 사항은 다음과 같습니다.

• 리소스 관리 서비스와 동일한 노드 형식의 리소스 비 관리 서비스를 혼합하지 마세요. 비 관리 서비스는 리소스를 너무 많이 사용하여 관리 서비스에 영향을 줄 수 있습니다. 배치 제약 조건을 지정하여 이러한 유형의 서비스가 동일한 노드 집합에서 실행되지 않도록 합니다. (이는 격벽 패턴의 예입니다.)
• 서비스 인스턴스에 대해 예약할 CPU 코어 및 메모리를 지정합니다. 리소스 거버넌스 정책의 사용 및 제한 사항에 대한 자세한 내용은 리소스 거버넌스를 참조하세요.

SPOF(단일 실패 지점)를 방지하려면 모든 서비스의 대상 인스턴스 또는 복제본 수가 1보다 커야 합니다. 서비스 인스턴스 또는 복제본 수로 사용할 수 있는 가장 큰 수는 서비스를 제한하는 노드 수와 같습니다.

모든 상태 저장 서비스에 2개 이상의 활성 보조 복제본이 있어야 합니다. 프로덕션 워크로드에는 5개의 복제본이 권장됩니다.

자세한 내용은 Service Fabric 서비스의 가용성을 참조하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

Service Fabric에서 애플리케이션을 보호하기 위한 몇 가지 핵심 사항은 다음과 같습니다.

가상 네트워크

통신 흐름을 제어하기 위해 각 가상 머신 확장 집합에 대한 서브넷 경계를 정의하는 것이 좋습니다. 각 노드 형식에는 Service Fabric 클러스터의 가상 네트워크 내 서브넷에 자체 가상 머신 확장 집합이 있습니다. NSG(네트워크 보안 그룹)를 서브넷에 추가하여 네트워크 트래픽을 허용하거나 거부할 수 있습니다. 예를 들어 프런트 엔드 및 백 엔드 노드 형식을 사용하면 백 엔드 서브넷에 NSG를 추가하여 프런트 엔드 서브넷의 인바운드 트래픽만 허용할 수 있습니다.

클러스터에서 외부 Azure 서비스를 호출할 때, Azure 서비스가 가상 네트워크 서비스 엔드포인트를 지원하는 경우 가상 네트워크 서비스 엔드포인트를 사용합니다. 서비스 엔드포인트를 사용하면 클러스터의 가상 네트워크 서비스만 보호됩니다.

예를 들어 Azure Cosmos DB를 사용하여 데이터를 저장하는 경우 특정 서브넷에서만 액세스할 수 있도록 서비스 엔드포인트를 사용하여 Azure Cosmos DB 계정을 구성합니다. 가상 네트워크에서 Azure Cosmos DB 리소스에 액세스를 참조하세요.

엔드포인트 및 서비스 간 통신

보호되지 않는 Service Fabric 클러스터를 만들지 마세요. 클러스터가 퍼블릭 인터넷에 관리 엔드포인트를 노출하는 경우 익명 사용자가 클러스터에 연결할 수 있게 됩니다. 보호되지 않은 클러스터는 프로덕션 워크로드에 지원되지 않습니다. Service Fabric 클러스터 보안 시나리오를 참조하세요.

서비스 간 통신을 보호하려면 다음을 수행합니다.

• ASP.NET Core 또는 Java 웹 서비스에서 HTTPS 엔드포인트를 사용하도록 설정하는 것이 좋습니다.
• 역방향 프록시와 서비스 간의 안전한 연결을 설정합니다. 자세한 내용은 보안 서비스에 연결을 참조하세요.

API 게이트웨이를 사용하는 경우 인증을 게이트웨이로 오프로드하면 됩니다. 메시지를 인증하는 추가 보안 과정이 없으면 개별 서비스에 직접(API 게이트웨이 없이) 연결할 수 없도록 합니다.

Service Fabric 역방향 프록시를 공개적으로 노출하지 않습니다. 노출하면 HTTP 엔드포인트를 노출하는 모든 서비스를 클러스터 외부에서 액세스할 수 있습니다. 그러면 보안 취약성이 발생하며 클러스터 외부에 불필요하게 추가 정보가 노출될 수 있습니다. 서비스에 공개적으로 액세스하려면 API 게이트웨이를 사용합니다. 이 문서의 뒷부분에 있는 API 게이트웨이 섹션에 몇 가지 옵션이 설명되어 있습니다.

원격 데스크톱은 진단 및 문제 해결에 유용하지만 반드시 닫아야 합니다. 열어 두면 보안 허점이 발생합니다.

암호 및 인증서

연결 문자열과 같은 비밀을 키 자격 증명 모음의 데이터 저장소에 저장합니다. 키 자격 증명 모음은 가상 머신 확장 집합과 동일한 지역에 있어야 합니다. 키 자격 증명 모음을 사용하려면 다음을 수행합니다.

1. 서비스의 키 자격 증명 모음 액세스를 인증합니다.

   서비스를 호스트하는 가상 머신 확장 집합에서 관리형 ID를 사용하도록 설정합니다.

2. 비밀을 키 자격 증명 모음에 저장합니다.

   키-값 쌍으로 변환할 수 있는 형식으로 비밀을 추가합니다. 예를 들면 CosmosDB--AuthKey를 사용합니다. 구성이 빌드되면 이중 하이픈(--)이 콜론(:)으로 변환됩니다.

3. 서비스에서 해당 비밀에 액세스합니다.

   appSettings.json 파일에서 키 자격 증명 모음 URI를 추가합니다. 서비스에서, 키 자격 증명 모음에서 데이터를 읽고 구성을 빌드하고 빌드된 구성의 비밀에 액세스하는 구성 공급자를 추가합니다.

다음은 Workflow 서비스가 비밀을 키 자격 증명 모음에 CosmosDB--Database 형식으로 저장하는 예제입니다.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

비밀에 액세스하려면 기본 구성에서 비밀 이름을 지정합니다.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

클라이언트 인증서를 사용하여 Service Fabric Explorer에 액세스하지 마세요. 대신 Microsoft Entra ID를 사용합니다. Microsoft Entra 인증을 지원하는 Azure 서비스를 참조하세요.

자체 서명된 인증서를 프로덕션에 사용하지 마세요.

미사용 데이터 보호

Service Fabric 클러스터의 가상 머신 확장 집합에 데이터 디스크를 연결했으며 서비스가 이 디스크에 데이터를 저장하는 경우 디스크를 암호화해야 합니다. 자세한 내용은 Azure PowerShell을 사용하여 가상 머신 확장 집합에서 OS 및 연결된 데이터 디스크 암호화(미리 보기)를 참조하세요.

Service Fabric 보안에 대한 자세한 내용은 다음을 참조하세요.

• Azure Service Fabric 보안 개요
• Azure Service Fabric 보안 모범 사례
• Azure Service Fabric 보안 검사 목록

복원력

실패에서 복구하고 완벽하게 작동하는 상태를 유지하려면 애플리케이션이 특정 복원력 패턴을 구현해야 합니다. 다음은 몇 가지 일반적인 패턴입니다.

• 다시 시도: 일시적으로 사용할 수 없는 리소스와 같이 일시적일 것으로 예상되는 오류를 처리합니다.
• 회로 차단기: 수정하는 데 오래 걸릴 수 있는 오류를 해결합니다.
• 격벽: 각 서비스에 대한 리소스를 격리합니다.

이 참조 구현에서는 오픈 소스 옵션인 Polly를 사용하여 이러한 모든 패턴을 구현합니다.

모니터링

모니터링 옵션을 살펴보기 전에 Service Fabric을 사용하여 일반적인 시나리오 진단에 대한 이 문서를 읽어보는 것이 좋습니다. 다음 집합의 모니터링 데이터를 생각할 수 있습니다.

• 애플리케이션 메트릭 및 로그
• Service Fabric 상태 및 이벤트 데이터
• 인프라 메트릭 및 로그
• 종속 서비스에 대한 메트릭 및 로그

다음은 해당 데이터를 분석하기 위한 두 가지 주요 옵션입니다.

• Application Insights
• Log Analytics

Azure Monitor를 사용하여 모니터링을 위한 대시보드를 설정하고 운영자에게 경고를 보낼 수 있습니다. Dynatrace처럼 Service Fabric과 통합된 타사 모니터링 도구도 있습니다. 자세한 내용은 Azure Service Fabric 모니터링 파트너를 참조하세요.

애플리케이션 메트릭 및 로그

애플리케이션 원격 분석은 서비스의 상태를 모니터링하고 문제를 파악하는 데 도움이 되는 데이터를 제공합니다. 서비스에서 추적 및 이벤트를 추가하려면 다음을 수행합니다.

• ASP.NET Core를 사용하여 서비스를 개발하는 경우 Microsoft.Extensions.Logging을 사용합니다. 다른 프레임워크를 사용하는 경우 Serilog와 같이 원하는 로깅 라이브러리를 사용합니다.
• SDK의 TelemetryClient 클래스를 사용하여 고유의 계측을 추가하고, Application Insights에서 데이터를 살펴봅니다. 애플리케이션에 사용자 지정 계측 추가를 참조하세요.
• EventSource를 사용하여 ETW(Windows용 이벤트 추적) 이벤트를 기록합니다. 이 옵션은 Visual Studio Service Fabric 솔루션에서 기본적으로 사용할 수 있습니다.

Application Insights는 요청, 추적, 이벤트, 예외, 메트릭, 종속성 등 다양한 기본 제공 원격 분석을 제공합니다. 서비스에서 HTTP 엔드포인트를 노출하는 경우 Microsoft.AspNetCore.Hosting.IWebHostBuilder에 대한 UseApplicationInsights 확장 메서드를 호출하여 Application Insights를 사용하도록 설정합니다. Application Insights에 대한 서비스 계측에 대한 자세한 내용은 다음 문서를 참조하세요.

• 자습서: Application Insights를 사용하여 Service Fabric에서 ASP.NET Core 애플리케이션 모니터링 및 진단
• ASP.NET Core용 Application Insights
• Application Insights .NET SDK
• Service Fabric용 Application Insights SDK

추적 및 이벤트 로그를 보려면 Application Insights를 구조적 로깅을 위한 싱크 중 하나로 사용합니다. AddApplicationInsights 확장 메서드를 호출하여 계측 키로 Application Insights를 구성합니다. 이 예제에서 계측 키는 키 자격 증명 모음에 비밀로 저장됩니다.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

서비스에서 HTTP 엔드포인트를 노출하지 않는 경우 Application Insights에 추적을 보내는 사용자 지정 확장을 작성해야 합니다. 예제는 참조 구현의 워크플로 서비스를 참조하세요.

ASP.NET Core 서비스는 애플리케이션 로깅에 ILogger 인터페이스를 사용합니다. 이러한 애플리케이션 로그를 Azure Monitor에서 사용할 수 있도록 하려면 Application Insights에 ILogger 이벤트를 보냅니다. Application Insights는 분산 추적을 시각화하는 데 유용한 상관 관계 속성을 ILogger 이벤트에 추가할 수 있습니다.

자세한 내용은 다음을 참조하세요.

• 애플리케이션 로깅
• Service Fabric 애플리케이션에 로깅 추가

Service Fabric 상태 및 이벤트 데이터

Service Fabric 원격 분석에는 Service Fabric 클러스터 및 해당 엔터티(노드, 애플리케이션, 서비스, 파티션, 복제본)의 작업 및 성능에 대한 상태 메트릭 및 이벤트가 포함됩니다. 상태 및 이벤트 데이터는 다음 위치에서 올 수 있습니다.

• EventStore. 이 상태 저장 시스템 서비스는 클러스터 및 해당 엔터티와 관련된 이벤트를 수집합니다. Service Fabric은 EventStore를 사용하여 상태 업데이트, 문제 해결, 모니터링에 사용 가능한 클러스터 정보를 제공하는 Service Fabric 이벤트를 작성합니다. EventStore 또한 지정된 시간에 여러 엔터티의 이벤트를 상호 연결하여 클러스터의 문제를 식별할 수 있습니다. 서비스는 REST API를 통해 해당 이벤트를 노출합니다.

  EventStore API를 쿼리하는 방법에 대한 자세한 내용은 클러스터 이벤트에 대한 EventStore API 쿼리를 참조하세요. WAD(Windows용 Azure Diagnostics 확장)로 클러스터를 구성하여 Log Analytics의 EventStore에서 이벤트를 볼 수 있습니다.

• HealthStore. 이 상태 저장 서비스는 클러스터의 현재 상태에 대한 스냅샷을 제공합니다. 계층의 엔터티에서 보고하는 모든 상태 데이터를 집계합니다. 데이터는 Service Fabric Explorer에서 시각화됩니다. HealthStore는 애플리케이션 업그레이드도 모니터링합니다. PowerShell, .NET 애플리케이션 또는 REST API에서 상태 쿼리를 사용할 수 있습니다. Service Fabric 상태 모니터링 소개를 참조하세요.

• 사용자 지정 상태 보고서. 실행 중인 서비스의 고장 상태와 같은 사용자 지정 상태 데이터를 주기적으로 보고할 수 있는 내부 watchdog 서비스를 구현하는 것이 좋습니다. Service Fabric Explorer에서 상태 보고서를 읽을 수 있습니다.

인프라 메트릭 및 로그

인프라 메트릭은 클러스터의 리소스 할당을 이해하는 데 도움이 됩니다. 이 정보를 수집하기 위한 주요 옵션은 다음과 같습니다.

• WAD. Windows의 노드 수준에서 로그 및 메트릭을 수집합니다. 가상 머신 확장 집합에서 진단 이벤트를 수집하는 노드 형식에 매핑되는 IaaSDiagnostics VM 확장을 구성하여 WAD를 사용할 수 있습니다. 이러한 이벤트에는 Windows 이벤트 로그, 성능 카운터, ETW/매니페스트 시스템 및 운영 이벤트, 사용자 지정 로그가 포함될 수 있습니다.
• Log Analytics 에이전트 Windows 이벤트 로그, 성능 카운터, 사용자 지정 로그를 Log Analytics로 보내도록 MicrosoftMonitoringAgent VM 확장을 구성합니다.

성능 카운터와 같이 이전 메커니즘을 통해 수집된 메트릭 종류 중 일부가 겹칩니다. 겹치는 메트릭이 있는 경우 Log Analytics 에이전트를 사용하는 것이 좋습니다. Log Analytics 에이전트는 Azure 스토리지를 사용하지 않으므로 대기 시간이 짧습니다. 또한 IaaSDiagnostics의 성능 카운터는 Log Analytics에 쉽게 공급할 수 없습니다.

VM 확장에 대한 자세한 내용은 Azure 가상 머신 확장 및 기능을 참조하세요.

데이터를 보려면 WAD를 통해 수집된 데이터를 표시하도록 Log Analytics를 구성합니다. 스토리지 계정에서 이벤트를 읽도록 Log Analytics를 구성하는 방법에 대한 자세한 내용은 클러스터에 대한 Log Analytics 설정을 참조하세요.

Service Fabric 클러스터, 워크로드, 네트워크 트래픽, 보류 중인 업데이트 등과 관련된 성능 로그 및 원격 분석 데이터를 볼 수도 있습니다. Log Analytics로 성능 모니터링을 참조하세요.

Log Analytics의 서비스 맵 솔루션은 클러스터의 토폴로지(즉, 각 노드에서 실행되는 프로세스)에 대한 정보를 제공합니다. 스토리지 계정의 데이터를 Application Insights로 보냅니다. Application Insights로 데이터를 가져오는 데 약간의 지연이 있을 수 있습니다. 데이터를 실시간으로 확인하려면 싱크 및 채널을 사용하여 Event Hubs를 구성하는 것이 좋습니다. 자세한 내용은 WAD를 사용하여 이벤트 집계 및 수집을 참조하세요.

종속 서비스 메트릭

• Application Insights의 애플리케이션 맵은 설치된 Application Insights SDK를 사용하여 서비스 간에 수행된 HTTP 종속성 호출을 사용하여 애플리케이션의 토폴로지 기능을 제공합니다.
• Log Analytics의 서비스 맵은 외부 서비스에서의 인바운드 및 아웃바운드 트래픽에 대한 정보를 제공합니다. 서비스 맵은 업데이트 또는 보안과 같은 다른 솔루션과 통합됩니다.
• 사용자 지정 watchdog은 외부 서비스에 대한 오류 조건을 보고할 수 있습니다. 예를 들어 서비스는 외부 서비스 또는 데이터 스토리지(Azure Cosmos DB)에 액세스할 수 없는 경우 오류 상태 보고서를 제공할 수 있습니다.

분산된 추적

마이크로 서비스 아키텍처에서는 작업을 완료하기 위해 여러 서비스가 참여하는 경우가 많습니다. 이러한 서비스의 원격 분석 데이터는 분산 추적의 컨텍스트 필드(작업 ID, 요청 ID 등)를 통해 상호 연결됩니다.

Application Insights에서 애플리케이션 맵을 사용하면 분산 논리 작업 보기를 빌드하고 애플리케이션의 전체 서비스 그래프를 시각화할 수 있습니다. Application Insights에서 트랜잭션 진단을 사용하여 서버 쪽 원격 분석의 상관 관계를 지정할 수도 있습니다. 자세한 내용은 통합 구성 요소 간 트랜잭션 진단을 참조하세요.

큐를 사용하여 비동기적으로 디스패치되는 작업의 상관 관계를 지정하는 것도 중요합니다. 큐 메시지에서 상관 관계 원격 분석을 보내는 방법에 대한 자세한 내용은 큐 계측을 참조하세요.

자세한 내용은 다음을 참조하세요.

• 여러 리소스에서 쿼리 수행
• Application Insights의 원격 분석 상관 관계

경고 및 대시보드

Application Insights 및 Log Analytics는 로그 데이터를 검색하고 분석할 수 있는 광범위한 쿼리 언어(Kusto 쿼리 언어)를 지원합니다. 쿼리를 사용하여 데이터 세트를 만들고 진단 대시보드에서 시각화합니다.

특정 리소스에서 특정 조건이 발생하는 경우 Azure Monitor 경고를 사용하여 시스템 관리자에게 알립니다. 예를 들어 이메일, Azure 함수 또는 웹후크를 통해 알릴 수 있습니다. 자세한 내용은 Azure Monitor의 경고를 참조하세요.

로그 검색 경고 규칙을 사용하면 정기적으로 Log Analytics 작업 영역에 대해 Kusto 쿼리를 정의하고 실행할 수 있습니다. 쿼리 결과가 특정 조건과 일치하면 경고가 생성됩니다.

비용 최적화

Azure 가격 계산기를 사용하여 비용을 예측합니다. 기타 고려 사항은 Microsoft Azure Well-Architected Framework의 비용 최적화 원칙에 설명되어 있습니다.

다음은 이 아키텍처에 사용되는 서비스에 대해 고려할 사항입니다.

Azure Service Fabric

Service Fabric 클러스터를 만들 때 선택한 컴퓨팅 인스턴스, 스토리지, 네트워킹 리소스, IP 주소에 대한 요금이 청구됩니다. Service Fabric에 대한 배포 요금이 있습니다.

가상 머신 크기 집합

이 아키텍처에서 마이크로 서비스는 가상 머신 확장 집합인 노드에 배포됩니다. 클러스터의 일부로 배포된 Azure VM과 스토리지 및 네트워킹과 같은 기본 인프라 리소스에 대한 요금이 청구됩니다. 가상 머신 확장 집합 자체에 대한 증분 요금은 없습니다.

Azure API Management

Azure API Management는 클라이언트의 요청을 클러스터의 서비스로 라우팅하는 게이트웨이입니다.

다양한 가격 책정 옵션이 있습니다. 사용량 옵션은 종량제 기준으로 청구되며 게이트웨이 구성 요소를 포함합니다. 워크로드에 따라 API Management 가격 책정에 설명된 옵션을 선택합니다.

애플리케이션 정보

Application Insights를 사용하여 모든 서비스에 대한 원격 분석 데이터를 수집하고, 구조화된 방식으로 추적 및 이벤트 로그를 볼 수 있습니다. Application Insights의 가격 책정 모델은 수집되는 데이터 양과 데이터 보존 옵션을 기반으로 하는 종량제 모델입니다. 자세한 내용은 Application Insights의 사용량 및 비용 관리를 참조하세요.

Azure Monitor

Azure Monitor Log Analytics의 경우 데이터 수집과 보존에 대한 요금이 청구됩니다. 자세한 내용은 Azure Monitor 가격을 참조하세요.

Azure Key Vault

Azure Key Vault를 사용하여 Application Insights의 계측 키를 비밀로 저장합니다. Azure는 Key Vault를 두 가지 서비스 계층으로 제공합니다. HSM 보호 키가 필요 없으면 표준 계층을 선택합니다. 각 계층의 기능에 대한 자세한 내용은 Key Vault 가격 책정을 참조하세요.

Azure DevOps Services

이 참조 아키텍처는 배포에 Azure Pipelines를 사용합니다. Azure Pipelines 서비스는 CI/CD의 경우 매월 1,800분의 무료 Microsoft 호스팅 작업과 매월 제한 없는 1개의 자체 호스팅 작업이 허용됩니다. 추가 작업에는 요금이 부과됩니다. 자세한 내용은 Azure DevOps Services 가격 책정을 참조하세요.

마이크로 서비스 아키텍처의 DevOps 고려 사항은 마이크로 서비스에 대한 CI/CD를 참조하세요.

CI/CD를 사용하여 컨테이너 애플리케이션을 Service Fabric 클러스터에 배포하는 방법은 이 자습서를 참조하세요.

시나리오 배포

이 아키텍처에 대한 참조 구현을 배포하려면 GitHub 리포지토리에 설명된 단계를 따르세요.

다음 단계

• 학습: Azure Service Fabric 소개
• Azure Service Fabric의 개요
• API Management 설명서
• Azure Pipelines란 무엇인가요?

관련 참고 자료

• 도메인 분석을 사용하여 마이크로 서비스 모델링
• 마이크로서비스 아키텍처 디자인