중요 업무용 워크로드에 대한 애플리케이션 설계 고려 사항

기본 중요 업무용 참조 아키텍처는 간단한 온라인 카탈로그 애플리케이션을 사용하여 매우 안정적인 워크로드를 보여 줍니다. 사용자는 항목 카탈로그를 탐색하고, 항목 세부 정보를 검토하고, 항목에 대한 등급 및 의견을 게시할 수 있습니다. 이 문서에서는 비동기 요청 처리와 같은 중요 업무용 애플리케이션의 안정성 및 복원력 측면과 솔루션 내에서 높은 처리량을 달성하는 방법에 중점을 둡니다.

애플리케이션 조합

중요 업무용 대규모 애플리케이션의 경우 엔드 투 엔드 확장성 및 복원력을 위해 아키텍처를 최적화해야 합니다. 구성 요소를 독립적으로 작동할 수 있는 기능 단위로 구분할 수 있습니다. 시스템의 각 부분이 독립적으로 확장되고 수요 변화를 충족할 수 있도록 애플리케이션 스택의 모든 수준에서 이 분리를 적용합니다. 구현은 이 방법을 보여 줍니다.

애플리케이션은 메시징 브로커를 통해 장기 실행 쓰기 요청을 비동기적으로 분리하는 상태 비스테이션 API 엔드포인트를 사용합니다. 워크로드의 컴퍼지션을 사용하면 언제든지 스탬프의 전체 AKS(Azure Kubernetes Service) 클러스터 및 기타 종속성을 삭제하고 다시 만들 수 있습니다. 애플리케이션의 주요 구성 요소는 다음과 같습니다.

• UI(사용자 인터페이스) : 사용자가 액세스할 수 있는 단일 페이지 웹 애플리케이션입니다. UI는 Azure Storage 계정의 정적 웹 사이트 호스팅에서 호스트됩니다.

• API(CatalogService): UI 애플리케이션에서 호출되지만 다른 잠재적 클라이언트 애플리케이션에 계속 사용할 수 있는 REST API입니다.

• 작업자(BackgroundProcessor): 메시지 버스에서 새 이벤트를 수신 대기하고 데이터베이스에 대한 쓰기 요청을 처리하는 백그라운드 작업자입니다. 이 구성 요소는 API를 노출하지 않습니다.

• 상태 서비스 API(HealthService): 데이터베이스 또는 메시징 버스와 같은 중요한 구성 요소가 작동하는지 확인하여 애플리케이션의 상태를 보고하는 API입니다.

  

워크로드는 API, 작업자 및 상태 검사 애플리케이션으로 구성됩니다. 호출 workload 된 전용 AKS 네임스페이스는 워크로드를 컨테이너로 호스트합니다. Pod 간에 직접 통신이 발생하지 않습니다. Pod는 상태 비 상태이며 독립적으로 확장할 수 있습니다.

클러스터에서 실행되는 다른 지원 구성 요소는 다음과 같습니다.

• NGINX 수신 컨트롤러: 들어오는 요청을 워크로드로 라우팅하고 Pod 간에 부하를 분산합니다. NGINX 수신 컨트롤러는 공용 IP 주소가 있는 Azure Load Balancer를 통해 노출되지만 Azure Front Door를 통해서만 액세스할 수 있습니다.

• 인증서 관리자: 수신 규칙에 Let's Encrypt를 사용하여 Jetstack의 cert-manager TLS(전송 계층 보안) 인증서를 자동으로 프로비전합니다.

• 비밀 저장소 CSI 드라이버: 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자는 Key Vault의 연결 문자열 같은 비밀을 안전하게 읽습니다.

• 모니터링 에이전트: 기본 OMSAgentForLinux 구성은 Azure Monitor 로그 작업 영역으로 전송되는 모니터링 데이터의 양을 줄이기 위해 조정됩니다.

데이터베이스 연결

배포 스탬프는 일시적인 특성이 있으므로 가능한 한 스탬프 내에서 상태를 유지하지 마세요. 외부화된 데이터 저장소에 상태를 유지해야 합니다. 안정성 SLO(서비스 수준 목표)를 지원하려면 복원력 있는 데이터 저장소를 만듭니다. 시간 제한, 연결 끊김 및 기타 오류 상태를 자동으로 처리하는 네이티브 SDK 라이브러리와 함께 관리형 또는 PaaS(Platform as a Service) 솔루션을 사용하는 것이 좋습니다.

참조 구현에서 Azure Cosmos DB는 애플리케이션의 기본 데이터 저장소 역할을 합니다. Azure Cosmos DB 는 다중 지역 쓰기를 제공합니다. 각 스탬프는 동일한 지역의 Azure Cosmos DB 복제본에 쓸 수 있으며, Azure Cosmos DB는 내부적으로 지역 간 데이터 복제 및 동기화를 처리합니다. NoSQL용 Azure Cosmos DB는 데이터베이스 엔진의 모든 기능을 지원합니다.

자세한 내용은 중요 업무용 워크로드를 위한 데이터 플랫폼을 참조하세요.

성능보다 가용성을 우선시하는 중요 업무용 애플리케이션의 경우 강력한 일관성 수준으로 단일 지역 쓰기 및 다중 지역 읽기를 권장합니다 .

이 아키텍처는 Storage를 사용하여 Azure Event Hubs 검사점에 대한 스탬프에 상태를 일시적으로 저장합니다.

모든 워크로드 구성 요소는 Azure Cosmos DB .NET Core SDK를 사용하여 데이터베이스와 통신합니다. SDK에는 데이터베이스 연결을 유지하고 실패를 처리하는 강력한 논리가 포함되어 있습니다. 주요 구성 설정은 다음과 같습니다.

• 직접 연결 모드: 이 설정은 더 나은 성능을 제공하므로 .NET SDK v3의 기본값입니다. 직접 연결 모드는 HTTP를 사용하는 게이트웨이 모드에 비해 네트워크 홉 수가 적습니다.

• 쓰기 시 콘텐츠 응답 반환: 이 방법은 Azure Cosmos DB 클라이언트가 만들기, upsert 및 패치 및 바꾸기 작업에서 문서를 반환할 수 없도록 비활성화되어 네트워크 트래픽을 줄입니다. 클라이언트에서 추가 처리를 수행해도 이 설정이 필요하지 않습니다.

• 사용자 지정 serialization: 이 프로세스는 .NET 속성을 표준 JSON 속성으로 변환하도록 JsonNamingPolicy.CamelCase JSON 속성 명명 정책을 설정합니다. 또한 JSON 속성을 .NET 속성으로 변환할 수도 있습니다. 기본 무시 조건은 serialization 중에 null 값이 있는 속성(예: JsonIgnoreCondition.WhenWritingNull/>)을 무시합니다.

• ApplicationRegion: 이 속성은 SDK가 가장 가까운 연결 엔드포인트를 찾을 수 있도록 스탬프의 영역으로 설정됩니다. 엔드포인트는 동일한 지역에 있어야 합니다.

참조 구현에 표시되는 코드 블록은 다음과 같습니다.

//
// /src/app/AlwaysOn.Shared/Services/CosmosDbService.cs
//
CosmosClientBuilder clientBuilder = new CosmosClientBuilder(sysConfig.CosmosEndpointUri, sysConfig.CosmosApiKey)
    .WithConnectionModeDirect()
    .WithContentResponseOnWrite(false)
    .WithRequestTimeout(TimeSpan.FromSeconds(sysConfig.ComsosRequestTimeoutSeconds))
    .WithThrottlingRetryOptions(TimeSpan.FromSeconds(sysConfig.ComsosRetryWaitSeconds), sysConfig.ComsosMaxRetryCount)
    .WithCustomSerializer(new CosmosNetSerializer(Globals.JsonSerializerOptions));

if (sysConfig.AzureRegion != "unknown")
{
    clientBuilder = clientBuilder.WithApplicationRegion(sysConfig.AzureRegion);
}

_dbClient = clientBuilder.Build();

비동기 메시징

느슨한 결합을 구현하는 경우 서비스에는 다른 서비스에 대한 종속성이 없습니다. 느슨한 측면을 사용하면 서비스가 독립적으로 작동할 수 있습니다. 결합 측면은 잘 정의된 인터페이스를 통해 서비스 간 통신을 가능하게 합니다. 중요 업무용 애플리케이션의 경우 느슨한 결합은 다운스트림 오류가 프런트 엔드 또는 다른 배포 스탬프로 연속되지 않도록 방지하여 고가용성을 제공합니다.

비동기 메시징의 주요 특징은 다음과 같습니다.

• 서비스는 동일한 컴퓨팅 플랫폼, 프로그래밍 언어 또는 운영 체제를 사용할 필요가 없습니다.

• 서비스는 독립적으로 스케일링됩니다.

• 다운스트림 실패는 클라이언트 트랜잭션에 영향을 미치지 않습니다.

• 데이터 생성 및 지속성은 별도의 서비스에서 발생하므로 트랜잭션 무결성을 유지하기가 어렵습니다. 트랜잭션 무결성은 메시징 및 지속성 서비스 전반에서 어려운 과제입니다. 자세한 내용은 Idempotent 메시지 처리를 참조 하세요.

• 엔드 투 엔드 추적에는 복잡한 오케스트레이션이 필요합니다.

큐 기반 부하 평준화 패턴 및 경쟁 소비자 패턴과 같은 잘 알려진 디자인 패턴을 사용하는 것이 좋습니다. 이러한 패턴은 생산자의 부하를 소비자에게 분산시키고 소비자가 비동기 처리를 사용하도록 설정합니다. 예를 들어 작업자는 API가 요청을 수락하고 신속하게 호출자에게 반환할 수 있도록 하고 작업자는 데이터베이스 쓰기 작업을 별도로 처리합니다.

Event Hubs는 API와 작업자 간에 메시지를 조정합니다.

쓰기 작업 구현 세부 정보

사후 등급 및 게시물 메모와 같은 쓰기 작업은 비동기적으로 처리됩니다. API는 먼저 작업 유형 및 주석 데이터와 같은 모든 관련 정보가 포함된 메시지를 메시지 큐에 보내고 만들 개체의 헤더와 함께 Location 즉시 반환 HTTP 202 (Accepted) 합니다.

BackgroundProcessor 인스턴스는 큐에서 메시지를 처리하고 쓰기 작업에 대한 실제 데이터베이스 통신을 처리합니다. BackgroundProcessor 큐 메시지 볼륨에 따라 확장되고 동적으로 확장됩니다. 프로세서 인스턴스의 스케일 아웃 제한은 Event Hubs 파티션의 최대 수(기본 계층 및 표준 계층의 경우 32개, 프리미엄 계층의 경우 100개, 전용 계층의 경우 1,024개)로 정의됩니다.

Azure Event Hubs 프로세서 라이브러리는 BackgroundProcessor Azure Blob Storage를 사용하여 파티션 소유권을 관리하고, 다른 작업자 인스턴스 간의 부하를 분산하고, 검사점을 사용하여 진행 상황을 추적합니다. 검사점은 모든 메시지에 비용이 많이 드는 지연을 추가하기 때문에 모든 이벤트 후에 Blob Storage에 기록되지 않습니다. 대신 검사점은 타이머 루프에 기록되며 기간을 구성할 수 있습니다. 기본 설정은 10초입니다.

참조 구현에 표시되는 코드 블록은 다음과 같습니다.

while (!stoppingToken.IsCancellationRequested)
{
    await Task.Delay(TimeSpan.FromSeconds(_sysConfig.BackendCheckpointLoopSeconds), stoppingToken);
    if (!stoppingToken.IsCancellationRequested && !checkpointEvents.IsEmpty)
    {
        string lastPartition = null;
        try
        {
            foreach (var partition in checkpointEvents.Keys)
            {
                lastPartition = partition;
                if (checkpointEvents.TryRemove(partition, out ProcessEventArgs lastProcessEventArgs))
                {
                    if (lastProcessEventArgs.HasEvent)
                    {
                        _logger.LogDebug("Scheduled checkpointing for partition {partition}. Offset={offset}", partition, lastProcessEventArgs.Data.Offset);
                        await lastProcessEventArgs.UpdateCheckpointAsync();
                    }
                }
            }
        }
        catch (Exception e)
        {
            _logger.LogError(e, "Exception during checkpointing loop for partition={lastPartition}", lastPartition);
        }
    }
}

프로세서 애플리케이션에서 오류가 발생하거나 메시지를 처리하기 전에 중지된 경우:

• 다른 인스턴스는 스토리지에서 검사점이 제대로 지정되지 않았기 때문에 다시 처리할 메시지를 선택합니다.

• 작업자가 실패하기 전에 이전 작업자가 데이터베이스에 문서를 유지하면 충돌이 발생합니다. 이 오류는 동일한 ID 및 파티션 키가 사용되기 때문에 발생합니다. 문서가 이미 유지되어 있으므로 프로세서는 메시지를 안전하게 무시할 수 있습니다.

• 새 인스턴스는 단계를 반복하고 데이터베이스에 기록하기 전에 이전 작업자가 종료된 경우 지속성을 종료합니다.

작업 구현 세부 정보 읽기

API는 읽기 작업을 직접 처리하고 즉시 사용자에게 데이터를 반환합니다.

작업이 성공적으로 완료되면 클라이언트와 통신하도록 백 채널 메서드가 설정되지 않습니다. 클라이언트 애플리케이션은 HTTP 헤더에 지정된 Location 항목에 대한 업데이트를 위해 API를 사전에 폴링해야 합니다.

확장성

각 구성 요소의 부하 패턴이 다르므로 개별 워크로드 구성 요소는 독립적으로 확장해야 합니다. 스케일링 요구 사항은 서비스의 기능에 따라 달라집니다. 특정 서비스는 사용자에게 직접적인 영향을 미치며 빠른 응답과 긍정적인 사용자 환경을 보장하기 위해 적극적으로 확장해야 합니다.

구현은 서비스를 컨테이너 이미지로 패키지하고 Helm 차트를 사용하여 각 스탬프에 서비스를 배포합니다. 서비스는 예상된 Kubernetes 요청 및 제한 및 미리 구성된 자동 크기 조정 규칙을 사용하도록 구성됩니다. CatalogService BackgroundProcessor 두 서비스가 모두 상태 비 상태이므로 워크로드 구성 요소와 워크로드 구성 요소는 개별적으로 스케일 인 및 스케일 아웃할 수 있습니다.

사용자가 직접 CatalogService상호 작용하므로 워크로드의 이 부분은 부하에 따라 응답해야 합니다. 각 클러스터에 대한 최소 3개의 인스턴스가 Azure 지역의 세 가용성 영역에 분산됩니다. AKS의 HPA(Horizontal Pod Autoscaler)는 필요에 따라 더 많은 Pod를 자동으로 추가합니다. Azure Cosmos DB 자동 크기 조정 기능은 컬렉션에 사용할 수 있는 RU(요청 단위)를 동적으로 늘리고 줄일 수 있습니다. 및 Azure Cosmos DB는 CatalogService 스탬프 내에서 배율 단위를 형성하기 위해 결합됩니다.

HPA는 구성 가능한 최대 수 및 최소 복제본 수가 있는 Helm 차트와 함께 배포됩니다. 부하 테스트는 각 인스턴스가 표준 사용 패턴으로 초당 약 250개의 요청을 처리할 수 있음을 확인했습니다.

BackgroundProcessor 서비스에는 요구 사항이 다르며 사용자 환경에 제한된 영향을 주는 백그라운드 작업자로 간주됩니다. 따라서 BackgroundProcessor 자동 크기 조정 구성과는 CatalogService다른 크기 조정 구성이 있으며 2~32개의 인스턴스 간에 크기를 조정할 수 있습니다. 이벤트 허브에서 사용하는 파티션 수에 따라 이 제한을 결정합니다. 파티션보다 더 많은 작업자가 필요하지 않습니다.

같은 ingress-nginx 종속성을 포함하는 워크로드의 각 구성 요소에는 클러스터가 변경될 때 최소 인스턴스 수를 사용할 수 있도록 구성된 PDB(Pod 중단 예산) 설정이 있습니다.

참조 구현에 표시되는 코드 블록은 다음과 같습니다.

#
# /src/app/charts/healthservice/templates/pdb.yaml
# Example pod distribution budget configuration.
#
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: {{ .Chart.Name }}-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: {{ .Chart.Name }}

계측

계측을 사용하여 워크로드 구성 요소가 시스템에 도입할 수 있는 성능 병 목 및 상태 문제를 평가합니다. 의사 결정을 정량화하는 데 도움이 되도록 각 구성 요소는 메트릭 및 추적 로그를 통해 충분한 정보를 내보내야 합니다. 애플리케이션을 계측할 때 다음 주요 고려 사항을 고려합니다.

• 로그, 메트릭 및 기타 원격 분석을 스탬프의 로그 시스템에 보냅니다.
• 정보를 쿼리할 수 있도록 일반 텍스트 대신 구조적 로깅을 사용합니다.
• 이벤트 상관 관계를 구현하여 엔드 투 엔드 트랜잭션 뷰를 가져옵니다. 참조 구현에서 모든 API 응답에는 추적 가능성을 위한 HTTP 헤더로 작업 ID가 포함됩니다.
• stdout 로깅 또는 콘솔 로깅에만 의존하지 마세요. 그러나 이러한 로그를 사용하여 실패한 Pod 문제를 즉시 해결할 수 있습니다.

이 아키텍처는 애플리케이션 모니터링 데이터를 위한 Application Insights 및 Azure Monitor 로그 작업 영역을 사용하여 분산 추적을 구현합니다. 워크로드 및 인프라 구성 요소의 로그 및 메트릭에 Azure Monitor 로그를 사용합니다. 이 아키텍처는 API에서 온 요청의 전체 엔드 투 엔드 추적을 구현하고 Event Hubs를 통과한 다음 Azure Cosmos DB로 이동합니다.

애플리케이션 모니터링 구현 세부 정보

BackgroundProcessor 구성 요소는 Microsoft.ApplicationInsights.WorkerService NuGet 패키지를 사용하여 애플리케이션에서 즉시 사용 가능한 계측을 가져옵니다. Serilog는 애플리케이션 내의 모든 로깅에도 사용됩니다. Application Insights는 콘솔 싱크 외에도 싱크로 구성됩니다. TelemetryClient Application Insights의 인스턴스는 다른 메트릭을 추적해야 하는 경우에만 직접 사용됩니다.

참조 구현에 표시되는 코드 블록은 다음과 같습니다.

//
// /src/app/AlwaysOn.BackgroundProcessor/Program.cs
//
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
    .ConfigureServices((hostContext, services) =>
    {
        Log.Logger = new LoggerConfiguration()
                            .ReadFrom.Configuration(hostContext.Configuration)
                            .Enrich.FromLogContext()
                            .WriteTo.Console(outputTemplate: "[{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} {Level:u3}] {Message:lj} {Properties:j}{NewLine}{Exception}")
                            .WriteTo.ApplicationInsights(hostContext.Configuration[SysConfiguration.ApplicationInsightsConnStringKeyName], TelemetryConverter.Traces)
                            .CreateLogger();
    }

실제 요청 추적 가능성을 보여주기 위해 성공 및 실패한 모든 API 요청은 상관 관계 ID 헤더를 호출자에게 반환합니다. 애플리케이션 지원 팀은 이 식별자를 사용하여 Application Insights를 검색하고 이전 다이어그램에 설명된 전체 트랜잭션에 대한 자세한 보기를 가져올 수 있습니다.

참조 구현에 표시되는 코드 블록은 다음과 같습니다.

//
// /src/app/AlwaysOn.CatalogService/Startup.cs
//
app.Use(async (context, next) =>
{
    context.Response.OnStarting(o =>
    {
        if (o is HttpContext ctx)
        {
            // ... code omitted for brevity
            context.Response.Headers.Add("Server-Location", sysConfig.AzureRegion);
            context.Response.Headers.Add("Correlation-ID", Activity.Current?.RootId);
            context.Response.Headers.Add("Requested-Api-Version", ctx.GetRequestedApiVersion()?.ToString());
        }
        return Task.CompletedTask;
    }, context);
    await next();
});

Kubernetes 모니터링 구현 세부 정보

진단 설정을 사용하여 AKS 로그 및 메트릭을 Azure Monitor 로그로 보낼 수 있습니다. AKS에서 컨테이너 인사이트 기능을 사용할 수도 있습니다. 컨테이너 인사이트를 사용하여 AKS 클러스터의 각 노드에서 Kubernetes DaemonSet을 통해 OMSAgentForLinux를 배포할 수 있습니다. OMSAgentForLinux는 Kubernetes 클러스터 내에서 더 많은 로그 및 메트릭을 수집하고 해당 Azure Monitor 로그 작업 영역으로 보낼 수 있습니다. 이 작업 영역에는 Pod, 배포, 서비스 및 클러스터의 전반적인 상태에 대한 세분화된 데이터가 포함되어 있습니다.

광범위한 로깅은 비용에 부정적인 영향을 줄 수 있으며 이점을 제공하지 않습니다. 이러한 이유로 모든 추적이 중복 레코드를 생성하는 Application Insights를 통해 이미 캡처되어 있으므로 컨테이너 인사이트 구성의 워크로드 Pod에 대해 stdout 로그 수집 및 Prometheus 스크래핑이 비활성화됩니다.

참조 구현에 표시되는 코드 블록은 다음과 같습니다.

#
# /src/config/monitoring/container-azm-ms-agentconfig.yaml
# This is just a snippet showing the relevant part.
#
[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = false

        exclude_namespaces = ["kube-system"]

자세한 내용은 전체 구성 파일을 참조 하세요.

애플리케이션 상태 모니터링

애플리케이션 모니터링 및 관찰 기능을 사용하여 시스템 문제를 신속하게 식별하고 현재 애플리케이션 상태에 대해 상태 모델에 알릴 수 있습니다. 상태 엔드포인트를 통해 상태 모니터링을 표시할 수 있습니다. 상태 프로브는 상태 모니터링 데이터를 사용하여 정보를 제공합니다. 주 부하 분산 장치는 해당 정보를 사용하여 비정상 구성 요소를 즉시 순환에서 제외합니다.

이 아키텍처는 다음 수준에서 상태 모니터링을 적용합니다.

• AKS에서 실행되는 워크로드 Pod입니다. 이러한 Pod에는 상태 및 활동성 프로브가 있으므로 AKS는 수명 주기를 관리할 수 있습니다.

• 클러스터의 전용 구성 요소인 상태 관리 서비스. Azure Front Door는 각 스탬프의 상태 관리 서비스 검색하고 자동으로 부하 분산에서 비정상 스탬프를 제거하도록 구성됩니다.

구현 세부 정보 상태 관리 서비스

HealthService는 컴퓨팅 클러스터에서 같은 다른 구성 요소와 BackgroundProcessor함께 실행되는 워크로드 구성 요소 CatalogService 입니다. HealthService 는 Azure Front Door 상태 검사에서 스탬프의 가용성을 확인하기 위해 호출하는 REST API를 제공합니다. 기본 활동성 프로브와 달리 상태 관리 서비스 자체 상태 외에도 종속성의 상태를 제공하는 더 복잡한 구성 요소입니다.

AKS 클러스터가 다운되어 워크로드가 비정상 상태가 되는 경우 상태 관리 서비스 응답하지 않습니다. 서비스가 실행되면 솔루션의 중요한 구성 요소에 대해 주기적인 검사를 수행합니다. 모든 검사는 비동기적으로 병렬로 수행됩니다. 검사에 실패하면 전체 스탬프를 사용할 수 없습니다.

상태 관리 서비스 각 스탬프의 Application Insights 리소스를 사용하여 명시적으로 구성된 URL ping 테스트에도 사용됩니다.

구현에 대한 HealthService 자세한 내용은 애플리케이션 상태 관리 서비스 참조하세요.

다음 단계