편집

다음을 통해 공유

Gridwich 클라우드 미디어 시스템

Azure Blob Storage
Azure Event Grid
Azure 기능
Azure Logic Apps

Gridwich 파이프라인은 Azure Event Grid 샌드위치와 Terraform 샌드위치의 두 가지 새로운 방법을 사용하여 미디어 자산을 수집, 처리, 저장 및 제공합니다.

아키텍처

Gridwich 아키텍처는 비동기 이벤트 처리 및 코드 제공 인프라의 요구 사항을 처리하는 두 개의 샌드위치를 제공합니다.

  • Event Grid 샌드위치는 외부 Saga 워크플로 시스템에서의 미디어 인코딩과 같은 원격 및 장기 실행 프로세스를 두 Event Grid 처리기 사이에 끼워넣어 추상화합니다. 이 샌드위치를 사용하면 외부 시스템이 요청 이벤트를 보내고, 예약된 이벤트를 모니터링하고, 몇 분 또는 몇 시간 후에 도착할 수 있는 최종 성공 또는 실패 응답을 기다릴 수 있습니다.

    Event Grid 처리기 샌드위치를 보여 주는 다이어그램

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

  • Terraform 샌드위치는 코드 제공 인프라를 지원하도록 업데이트된 다단계 Terraform 패턴입니다. 인프라 및 소프트웨어 릴리스를 분리하면 Terraform이 Event Grid 구독을 배포하기 전에 Azure Functions 앱을 릴리스하고 실행해야 합니다. 이 요구 사항을 해결하기 위해 CI/CD 파이프라인에는 다음 두 Terraform 작업이 있습니다.

    Terraform 샌드위치 작업을 보여 주는 다이어그램

    • Terraform 1은 Azure Event Grid 구독을 제외한 모든 리소스를 만듭니다.
    • Terraform 2는 소프트웨어가 실행되고 난 후 Event Grid 구독을 만듭니다.

    이러한 방식으로 Terraform은 소프트웨어 아티팩트가 배포되기 전에 모든 Azure 리소스를 만들 수 없는 경우에도 솔루션 인프라를 완전히 관리하고 배포할 수 있습니다.

워크플로

Gridwich 요청 및 응답 프로세스는 다음 요청이 포함됩니다.

  • 만들기
  • 전송
  • Reception
  • Gridwich 구성 요소에 디스패치
  • 승인 및 작업
  • 응답

다음 단계에서는 외부 시스템과 Gridwich 간의 요청 및 응답 프로세스를 설명합니다. Gridwich에서 외부 시스템은 MAM 및 Saga 워크플로 오케스트레이션 시스템입니다. Gridwich 작업 메시지 이벤트의 정확한 형식은 Gridwich 메시지 형식을 참조하세요.

Gridwich 요청-응답 프로세스를 보여 주는 다이어그램

  1. 외부 시스템은 요청을 만들어 요청 브로커에 보냅니다.

  2. 요청 브로커는 기존 게시-구독 모델에서 Gridwich 요청 수신기에 요청을 디스패치해야 합니다. 이 솔루션에서는 Azure Event Grid가 요청 브로커입니다. 모든 요청은 Event Grid 이벤트 스키마를 사용하여 캡슐화됩니다.

  3. Gridwich Azure Functions 앱에서는 Event Grid의 이벤트를 사용합니다. 처리량 개선을 위해 Gridwich는 HTTP 엔드포인트를 Azure Functions에서 제공하는 Event Grid 바인딩 폴링 모델이 아니라 Event Grid가 시작하는 푸시 모델로 정의합니다.

  4. Azure Functions 앱은 이벤트 속성을 읽고 해당 이벤트 유형 및 버전을 처리하는 Gridwich 코드의 일부로 이벤트를 디스패치합니다.

  5. 현재 요청에서 작동하는 모든 처리기는 일반적인 EventGridHandlerBase 클래스를 사용하여 요청을 받을 때 승인 메시지를 즉시 보냅니다. 그런 다음, 처리기는 파생 클래스에 작업을 디스패치합니다.

    Gridwich 요청 워크플로는 본질적으로 동기적이거나 비동기적일 수 있습니다. 쉽게 수행하고 빠르게 완료할 수 있는 요청의 경우 동기 처리기가 작업을 수행하고 승인이 전송된 직후 성공 또는 실패 이벤트를 반환합니다.

    장기 실행 요청의 경우 비동기 처리기가 요청을 평가하고, 인수의 유효성을 검사하고, 장기 실행 작업을 시작합니다. 그런 다음, 처리기는 예약됨 응답을 반환하여 해당 작업 활동을 요청했는지 확인합니다. 작업 활동을 완료할 때 요청 처리기는 작업에 대한 성공 또는 실패 완료 이벤트를 제공해야 합니다.

    이벤트 게시 서비스는 승인, 실패, 예약됨 또는 성공 메시지를 Event Grid 요청 브로커에 전달합니다.

  6. Azure Function의 이벤트 게시자는 신뢰할 수 있는 메시지 브로커 역할을 하는 Event Grid 토픽에 응답 이벤트를 보냅니다. 외부 시스템은 토픽을 구독하고 메시지를 사용합니다. Event Grid 플랫폼은 외부 시스템에 게시하기 위한 일반적인 재시도 논리를 제공합니다.

메시지 순서

승인은 성공 응답 및 예약됨 응답보다 먼저 발생하지만 Gridwich는 예약됨 응답이 항상 해당 성공 응답보다 먼저 발생한다고 보장하지는 않습니다. 유효한 응답 시퀀스는 승인됨 > 예약됨 > 성공 또는 승인됨 > 성공 > 예약됨 중 하나일 수 있습니다.

요청 실패

요청 실패는 잘못된 요청, 누락된 사전 조건, 처리 실패, 보안 예외 또는 처리되지 않은 예외로 인해 발생할 수 있습니다. 거의 모든 실패는 동일한 메시지 형식을 사용하며 원래 작업 컨텍스트 값을 포함합니다. 일반적인 EventGridHandlerBase 클래스는 보통 Azure Function 이벤트 게시자 인터페이스를 통해 Event Grid에 실패 응답을 보냅니다. 또한 Application Insights는 구조적 로깅을 통해 실패를 기록합니다.

작업 컨텍스트

외부 시스템은 매일, 시간당 또는 초당 수천 개의 요청을 생성할 수 있습니다. Gridwich에 대한 각 요청 이벤트에는 이름이 operationContext인 JSON 개체 속성이 포함되어야 합니다.

요청에 작업 컨텍스트(예: {"id"="Op1001"})가 포함된 경우 각 Gridwich 응답에는 요청이 단기 실행인지 또는 장기 실행인지에 관계없이 해당 불투명 작업 컨텍스트가 포함되어야 합니다. 이 작업 컨텍스트는 매우 오래 실행되는 요청의 수명 동안에도 유지됩니다.

응답 요구 사항은 "동일한" JSON 개체가 아닌 "해당"하는 개체에 대한 것입니다. 컨텍스트 음소거와 같은 Gridwich 기능에서는 외부 시스템이 반환된 JSON 개체를 하향식으로 처리한다는 점을 활용합니다.

특히 외부 시스템은 다음과 같습니다.

  • 속성 순서에 대한 종속성이 없으므로 Gridwich는 동일한 속성을 가진 개체를 다른 순서로 다시 보낼 수 있습니다. {"a":1,"b":2} 및 {"b":2,"a":1}을 예로 들 수 있습니다.

  • 추가 속성을 갖는 데 문제가 없으므로 Gridwich가 {"b":2,"a":1}을 수신한 경우 유효하게 {"a":1,"b":2,"~somethingExtra":"yes"}를 반환할 수 있습니다. 충돌 가능성을 최소화하기 위해 Gridwich는 추가된 속성의 이름 앞에 물결표(~)를 추가합니다(예: ~muted).

  • JSON 형식 지정 종속성이 없습니다. 예를 들어 공백 패딩이 JSON의 문자열 표현 내에 포함될 수 있는 위치에 대한 가정은 없습니다. Gridwich는 JSON 개체의 문자열 표현에서 불필요한 공백을 압축하여 형식 지정 종속성의 부족을 활용합니다. JSONHelpers.SerializeOperationContext를 참조하세요.

Saga 참가자 및 작업 컨텍스트

Gridwich Saga 오케스트레이션 시스템에서 각 Saga 참가자는 시스템에 하나 이상의 작업 활동을 제공합니다. 각 Saga 참가자는 다른 참가자와 관계없이 작업하며, 두 명 이상의 Saga 참가자가 단일 요청에서 작업할 수 있습니다.

각 Saga 참가자는 작업 컨텍스트를 유지해야 하지만 다르게 구현할 수 있습니다. 다음은 그 예입니다.

  • 단기 실행 동기 작업은 작업 컨텍스트를 유지합니다.
  • Azure Storage는 대부분의 작업에 대해 ClientRequestId라는 불투명 문자열 속성을 제공합니다.
  • 일부 서비스에는 속성이 있습니다 Job.CorrelationData .
  • 다른 클라우드 API는 진행률, 완료 또는 실패 신호를 보낼 때 반환할 수 있는 불투명 작업 컨텍스트와 유사한 개념을 제공합니다.

Saga 및 Saga 참가자에 대한 자세한 내용은 Saga 오케스트레이션을 참조하세요.

동기 및 비동기 처리기

시스템의 모든 이벤트 처리기는 일반적인 EventGridHandlerBase 클래스를 사용하여 요청 승인, 실패 처리 및 응답 이벤트 게시와 같은 일반 서비스를 제공합니다. 이벤트 게시 서비스는 승인, 실패, 예약됨 또는 성공 메시지를 Event Grid 요청 브로커에 전달합니다.

현재 요청에서 작업하려는 처리기는 요청을 받을 때 승인을 제공해야 합니다. 기본 클래스는 즉시 승인 메시지를 보낸 다음, 파생 클래스에 작업을 디스패치합니다.

승인 메시지 흐름을 보여 주는 다이어그램

동기 이벤트 처리

쉽게 수행하고 빠르게 완료할 수 있는 요청의 경우 처리기가 동기적으로 작업을 수행하고 승인이 전송된 거의 직후 성공 이벤트를 작업 컨텍스트와 함께 반환합니다.

동기 요청-응답 메시지 흐름을 보여 주는 다이어그램.

예를 들어 ChangeBlobTierHandler는 간단한 동기 흐름입니다. 처리기는 요청 DTO(데이터 전송 개체)를 가져오고, 작업을 수행하는 단일 서비스를 호출하여 대기하며, 성공 또는 실패 응답을 반환합니다.

ChangeBlobTierHandler 동기 흐름 예제를 보여 주는 다이어그램

비동기 이벤트 처리

일부 요청은 장기 실행됩니다. 예를 들어 미디어 파일을 인코딩하는 데는 몇 시간이 걸릴 수 있습니다. 이러한 경우 비동기 요청 처리기가 요청을 평가하고, 인수의 유효성을 검사하고, 장기 실행 작업을 시작합니다. 그런 다음, 처리기는 예약됨 응답을 반환하여 해당 작업 활동을 요청했는지 확인합니다.

비동기 요청-응답 메시지 흐름을 보여 주는 다이어그램

작업 활동을 완료할 때 요청 처리기는 작업에 대한 성공 또는 실패 완료 이벤트를 제공해야 합니다. 상태 비저장으로 남아 있는 동안 처리기는 원래 작업 컨텍스트를 가져와서 완료됨 이벤트 메시지 페이로드에 배치해야 합니다.

예를 들어 BlobCopyHandler는 간단한 비동기 흐름을 표시합니다. 처리기는 요청 DTO를 가져오고, 단일 서비스를 호출하여 작업이 시작되기를 기다린 다음, 예약됨 또는 실패 응답을 게시합니다.

BlobCopyHandler 비동기 흐름 예제와 예약된 이벤트를 보여 주는 다이어그램

장기 실행 요청 흐름을 완료하기 위해 BlobCreatedHandler는 플랫폼 이벤트 Microsoft.Storage.BlobCreated를 사용하고, 원래 작업 컨텍스트를 추출하고, 성공 또는 실패 완료 응답을 게시합니다.

BlobCopyHandler 비동기 흐름 예제와 성공한 이벤트를 보여 주는 다이어그램

장기 실행 함수

Gridwich가 새 Functions 앱을 배포하면 현재 장기 실행 프로세스가 삭제됩니다. 이러한 프로세스가 갑자기 종료되면 상태가 없으며 호출자에게 다시 보고하지 않습니다. Gridwich는 장기 실행 함수에 대한 전환을 정상적으로 처리하고 메시지를 누락하지 않으면서 새 Functions Apps를 배포해야 합니다.

솔루션은 다음과 같아야 합니다.

  • Gridwich 앱의 실행 중인 인스턴스 상태를 유지하지 않습니다.
  • 새로 배포 중인 항목이 있거나 새 메시지가 동일한 작업을 요청 중이기 때문에 프로세스를 종료하지 않습니다.
  • Durable Functions, Functions Apps, Logic Apps, Azure Container Instances 같은 추가 Azure 워크로드를 호출하지 않습니다.

Gridwich는 Azure Functions 슬롯 배포 및 취소 토큰을 사용하여 신뢰할 수 있는 장기 실행 함수에 대한 이러한 요구 사항을 충족합니다.

다음 다이어그램은 대부분의 Gridwich 작업이 작동하는 방식을 보여 줍니다. 녹색 상자는 Gridwich가 외부 서비스에 전달하는 작업을 나타냅니다. 그런 다음, Gridwich는 이벤트 기반 방식으로 상태에 반응합니다. 빨간색 상자에는 Gridwich 자체에서 장기 실행되는 함수가 표시됩니다.

단기 실행 함수와 장기 실행 함수를 보여주는 다이어그램

Functions 런타임은 애플리케이션이 종료되면 취소 토큰을 추가합니다. Gridwich는 토큰을 감지하여 모든 요청 및 현재 실행 중인 프로세스에 대한 오류 코드를 반환합니다.

슬롯 배포에서는 새 소프트웨어 버전을 배포합니다. 프로덕션 슬롯에는 실행 중인 애플리케이션이 있으며 스테이징 슬롯에는 새 버전이 있습니다. Azure는 일련의 배포 단계를 수행한 다음, 슬롯 인스턴스를 교환합니다. 이전 인스턴스는 프로세스의 마지막 단계로 다시 시작됩니다.

Gridwich는 호스트 이름을 다시 매핑한 후 30초 동안 대기하므로 HTTP 트리거 함수의 경우 Gridwich는 이전 프로덕션 슬롯을 다시 시작하기 전에 최소 30초의 시간이 보장됩니다. 다른 트리거는 앱 설정 업데이트 시 대기하는 메커니즘이 없는 앱 설정에 의해 제어될 수 있습니다. 이러한 함수는 이전 프로덕션 슬롯이 다시 시작되기 직전에 실행이 시작되는 경우 중단될 위험이 있습니다.

자세한 내용은 Azure Functions에 대한 슬롯 교환 중에 수행되는 작업 및 Azure Functions 배포 슬롯을 참조하세요.

구성 요소

Gridwich 미디어 처리 솔루션은 Azure Event Grid, Azure Functions, Azure Blob Storage, Azure Logic Apps 및 Azure Key Vault를 사용합니다. CI/CD 및 Saga 오케스트레이션 프로세스는 Azure Repos, Azure Pipelines 및 Terraform을 사용합니다.

  • Azure Event Grid는 비동기 미디어 이벤트 처리를 허용하는 두 개의 샌드위치된 Event Grid 작업을 통해 Gridwich 이벤트의 라우팅을 관리합니다. Event Grid는 매우 신뢰성이 높은 요청 제공 엔드포인트입니다. Azure 플랫폼은 필요한 요청 제공 엔드포인트 작동 시간 및 안정성을 제공합니다.

    Gridwich는 Event Grid 브로커 및 전송 계층에 불투명한 Event Grid 스키마 Event.Data 속성 개체 내의 이벤트를 캡슐화합니다. 또한 Gridwich는 eventType 및 dataVersion 개체 필드를 사용하여 이벤트를 라우팅합니다. Event Grid 요청 브로커를 다른 게시-구독 이벤트 브로커로 대체할 수 있도록 Gridwich는 가능한 한 가장 적은 이벤트 필드를 사용하며 topic 또는 subject 필드를 사용하지 않습니다.

  • Azure Functions를 사용하면 인프라를 명시적으로 프로비저닝하거나 관리할 필요 없이 이벤트 트리거 코드를 실행할 수 있습니다. Gridwich는 다양한 함수의 실행을 호스트하는 Azure Functions 앱입니다.

  • Azure Blob Storage는 미디어 자산과 같은 비정형 데이터에 대한 확장 가능하고 비용 효율적인 클라우드 스토리지 및 액세스를 제공합니다. Gridwich는 Azure Storage 블록 Blob과 컨테이너를 모두 사용합니다.

  • Azure Key Vault는 Azure 및 타사 앱과 서비스에서 사용하는 암호화 키, 암호 및 기타 비밀을 보호합니다.

  • Azure DevOps는 Azure와 통합되는 Git 기반 코드 리포지토리와 자동화된 빌드 및 릴리스 파이프라인을 비롯한 개발자 및 운영 서비스 세트입니다. Gridwich는 Azure Repos를 사용하여 코드 프로젝트를 저장 및 업데이트하며, CI/CD 및 기타 워크플로에는 Azure Pipelines를 사용합니다.

  • Terraform은 코드 제공 인프라를 사용하여 인프라 및 서비스를 프로비전하고 관리하는 오픈 소스 도구입니다.

대안

  • Durable Functions는 장기 실행 작업을 위한 기본 제공 상태 저장소가 있으며 불투명한 작업 컨텍스트를 제공할 수도 있습니다. Durable Functions는 작업 내에서 일련의 작업을 만들고 작업 컨텍스트를 작업에 대한 입력 또는 출력으로 저장할 수 있습니다. 실제로 Gridwich는 모든 작업 활동에 Durable Functions를 사용할 수 있지만 이 접근 방식은 코드 복잡성을 증가시킵니다.

  • EventGridHandlerBase를 RequestHandlerBase로 리팩터링하고 Event Grid 개체 또는 형식에 대한 모든 연결을 제거하여 Event Grid 인프라로부터의 향상된 분리를 수행할 수 있습니다. 이렇게 리팩터링된 클래스는 기본 DTO에서만 처리되며 전송 관련 개체 형식에서는 처리되지 않습니다. 마찬가지로 IEventGridDispatcher는 특정 EventGridDispatcher 구현을 통해 IResponseDispatcher가 될 수 있습니다.

  • 또한 Gridwich.SagaParticipants.Storage.AzureStorage 라이브러리에는 다른 Saga 참가자가 사용하는 스토리지 서비스도 포함되어 있습니다. 코어 프로젝트에 인터페이스가 있으면 IoC(Inversion of Control) 문제가 방지되지만 인터페이스를 별도의 코어 스토리지 인프라 게이트웨이 라이브러리로 추출할 수 있습니다.

  • Gridwich Functions 앱은 종속성 주입을 사용하여 특정 이벤트 유형 및 데이터 버전에 대해 하나 이상의 요청 처리기를 등록합니다. 앱은 EventGridDispatcher에 Event Grid 이벤트 처리기 컬렉션을 삽입하고, 디스패처는 처리기를 쿼리하여 이벤트를 처리할 처리기를 결정합니다.

    또는 Event Grid 플랫폼에서 제공하는 이벤트 구독 및 필터링 메커니즘을 사용할 수 있습니다. 이 메커니즘은 하나의 Azure Function이 하나의 이벤트 처리기만 호스트하는 일대일 배포 모델을 사용합니다. Gridwich가 일대다 모델을 사용하지만 클린 아키텍처는 일대일에 대한 솔루션을 리팩터링하는 것이 어렵지 않음을 의미합니다.

  • 모놀리식 Gridwich 아키텍처가 아닌 대체 마이크로 서비스는 마이크로 서비스 대안을 참조하세요.

시나리오 정보

잘 알려진 대중 미디어 및 엔터테인먼트 기업이 비디오 자산을 수집, 처리 및 게시하기 위해 온-프레미스 비디오 스트리밍 서비스를 클라우드 기반 솔루션으로 대체했습니다. 이 회사의 주요 목표는 Azure 클라우드 용량, 비용 및 유연성을 활용하여 다음을 수행하는 것이었습니다.

  • 원시 비디오 파일을 수집하고, 처리 및 게시하고, 미디어 요청을 수행합니다.
  • 인코딩 및 새로운 유입과 배포 기능을 대규모로 완전히 설계된 접근 방식을 사용하여 개선합니다.
  • MAM(미디어 자산 관리) 파이프라인에 대한 CI/CD(연속 통합 및 지속적인 업데이트)를 구현합니다.

이러한 목표를 달성하기 위해 Microsoft 엔지니어링 팀은 외부 Saga 워크플로 오케스트레이션 시스템에 의해 구동되는 상태 비저장 이벤트 처리 프레임워크인 Gridwich를 개발했습니다.

잠재적인 사용 사례

엔지니어링 팀은 다음에 대한 원칙 및 업계 표준에 맞게 Gridwich를 개발했습니다.

Gridwich 시스템은 Azure에서 미디어 자산을 처리하고 전송하기 위한 모범 사례를 포함하고 있습니다. Gridwich 시스템은 미디어에 따라 다르지만 메시지 처리와 이벤트 프레임워크는 모든 상태 비저장 이벤트 처리 워크플로에 적용할 수 있습니다.

시나리오 배포