편집

다음을 통해 공유


클레임 확인 패턴

Azure Event Grid
Azure Blob Storage

클레임 확인 패턴을 사용하면 워크로드가 메시징 시스템에 페이로드를 저장하지 않고 페이로드를 전송할 수 있습니다. 패턴은 페이로드를 외부 데이터 저장소에 저장하고 "클레임 검사"를 사용하여 페이로드를 검색합니다. 클레임 검사는 고유하고 모호한 토큰 또는 키입니다. 페이로드를 검색하려면 애플리케이션이 외부 데이터 저장소에 클레임 확인 토큰을 제공해야 합니다.

컨텍스트 및 문제점

기존의 메시징 시스템은 대량의 작은 메시지를 관리하도록 최적화되어 있으며 처리할 수 있는 메시지 크기에 제한이 있는 경우가 많습니다. 큰 메시지는 이러한 제한을 초과할 위험이 있을 뿐만 아니라 메시징 시스템에서 저장할 때 전체 시스템의 성능을 저하시킬 수도 있습니다.

솔루션

Claim-Check 패턴을 사용하고 메시지 시스템에 큰 메시지를 보내지 마세요. 대신, 페이로드를 외부 데이터 저장소로 보내고 해당 페이로드에 대한 클레임 확인 토큰을 생성합니다. 메시징 시스템은 클레임 확인 토큰이 포함된 메시지를 수신 애플리케이션에 보내므로 이러한 애플리케이션은 데이터 저장소에서 페이로드를 검색할 수 있습니다. 메시징 시스템은 페이로드를 보거나 저장하지 않습니다.

클레임 확인 패턴의 다이어그램

  1. 페이로드
  2. 데이터 저장소에 페이로드를 저장합니다.
  3. 클레임 확인 토큰을 생성하고 클레임 확인 토큰을 사용하여 메시지를 보냅니다.
  4. 메시지를 받고 클레임 확인 토큰을 읽습니다.
  5. 페이로드를 검색합니다.
  6. 페이로드를 처리합니다.

클레임 확인 패턴의 문제 및 고려 사항

Claim-Check 패턴을 구현할 때 다음 권장 사항을 고려합니다.

  • 사용된 메시지를 삭제합니다. 메시지를 보관할 필요가 없는 경우 수신 애플리케이션에서 메시지를 사용한 후 메시지 및 페이로드를 삭제합니다. 동기 또는 비동기 삭제 전략을 사용합니다.

    • 동기 삭제: 소비하는 애플리케이션은 소비 직후 메시지와 페이로드를 삭제합니다. 삭제를 메시지 처리 워크플로와 연결하고 메시징 워크플로 컴퓨팅 용량을 사용합니다.

    • 비동기 삭제: 메시지 처리 워크플로 외부의 프로세스는 메시지와 페이로드를 삭제합니다. 메시지 처리 워크플로에서 삭제 프로세스를 분리하고 메시징 워크플로 컴퓨팅의 사용을 최소화합니다.

  • 패턴을 조건부로 구현합니다. 메시지 크기가 메시징 시스템의 제한을 초과하는 경우 Claim-Check 패턴을 적용하는 보내는 애플리케이션에 논리를 통합합니다. 작은 메시지의 경우 패턴을 무시하고 메시지 시스템에 더 작은 메시지를 보냅니다. 이 조건부 접근 방식은 대기 시간을 줄이고 리소스 사용률을 최적화하며 처리량을 향상시킵니다.

클레임 확인 패턴을 사용하는 경우

다음 시나리오는 클레임 확인 패턴의 기본 사용 사례입니다.

  • 메시징 시스템 제한 사항: 메시지 크기가 메시징 시스템의 제한을 초과하는 경우 클레임 확인 패턴을 사용합니다. 페이로드를 외부 스토리지로 오프로드합니다. 클레임 확인 토큰이 있는 메시지만 메시징 시스템에 보냅니다.

  • 메시징 시스템 성능: 대용량 메시지가 메시징 시스템에 부담을 주고 시스템 성능이 저하되는 경우 Claim-Check 패턴을 사용합니다.

다음 시나리오는 클레임 확인 패턴에 대한 보조 사용 사례입니다.

  • 중요한 데이터 보호: 페이로드에 메시징 시스템에 표시되지 않으려는 중요한 데이터가 포함된 경우 클레임 확인 패턴을 사용합니다. 페이로드의 중요한 정보의 전부 또는 일부에 패턴을 적용합니다. 메시징 시스템을 통해 직접 전송하지 않고 중요한 데이터를 보호합니다.

  • 복잡한 라우팅 시나리오: 여러 구성 요소를 트래버스하는 메시지는 직렬화, 역직렬화, 암호화 및 암호 해독 작업으로 인해 성능 병목 현상이 발생할 수 있습니다. 클레임 확인 패턴을 사용하여 중간 구성 요소의 직접 메시지 처리를 방지합니다.

Claim-Check 패턴을 사용하여 워크로드 디자인

설계자는 클레임 검사 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:

핵심 요소 이 패턴으로 핵심 목표를 지원하는 방법
안정성 설계 결정은 워크로드가 오작동에 대한 복원력을 갖도록 하고 실패 후 완전히 복구되도록 하는 데 도움이 됩니다. 메시징 시스템은 전용 데이터 저장소에 있는 것과 동일한 안정성 및 재해 복구를 제공하지 않습니다. 메시지에서 데이터를 분리하면 페이로드에 대한 안정성이 향상될 수 있습니다. 이러한 분리는 재해 후 페이로드를 복구할 수 있는 데이터 중복성을 용이하게 합니다.

- RE:03 오류 모드 분석
- RE:09 재해 복구
보안 디자인 결정은 워크로드 데이터 및 시스템의 기밀성, 무결성가용성을 보장하는 데 도움이 됩니다. 클레임 확인 패턴은 메시지에서 중요한 데이터를 추출하여 보안 데이터 저장소에 저장할 수 있습니다. 이 설정을 사용하면 더 엄격한 액세스 제어를 구현하여 중요한 데이터를 사용하려는 서비스만 액세스할 수 있도록 할 수 있습니다. 동시에 큐 모니터링에 사용되는 것과 같은 관련 없는 서비스에서 이 데이터를 숨깁니다.

- SE:03 데이터 분류
- SE:04 구분
비용 최적화는 워크로드의 투자 수익률유지 및 개선하는 데 초점을 맞춥니다. 메시징 시스템은 메시지 크기에 제한을 적용하는 경우가 많으며 크기 제한 증가는 종종 프리미엄 기능입니다. 메시지 본문의 크기를 줄이면 더 저렴한 메시징 솔루션을 사용할 수 있습니다.

- CO:07 구성 요소 비용
- CO:09 Flow 비용
성능 효율성은 크기 조정, 데이터 전송 및 코드 실행을 최적화하여 워크로드 가 요구를 효율적으로 충족하는 데 도움이 됩니다. 클레임 확인 패턴은 큰 메시지를 보다 효과적으로 관리하여 애플리케이션 및 메시징 시스템을 보내고 받는 효율성을 향상시킵니다. 메시징 시스템으로 전송되는 메시지의 크기를 줄이고 필요한 경우에만 수신 애플리케이션이 큰 메시지에 액세스하도록 합니다.

- PE:05 크기 조정 및 분할
- PE:12 연속 성능 최적화

디자인 결정과 마찬가지로 이 패턴을 통해 도입 가능한 다른 핵심 요소의 목표에 관한 절충을 고려합니다.

클레임 확인 패턴 예제

다음 예제에서는 Azure가 클레임 확인 패턴의 구현을 용이하게 하는 방법을 보여 줍니다.

  • Azure 메시징 시스템: 이 예제에서는 Azure Queue Storage, Azure Event Hubs(표준 API), Azure Service Bus 및 Azure Event Hubs(Kafka API)의 네 가지 Azure 메시징 시스템 시나리오를 다룹니다.

  • 자동 및 수동 클레임 확인 토큰 생성: 이러한 예제에서는 클레임 확인 토큰을 생성하는 두 가지 방법도 보여 줍니다. 코드 예제 1-3에서 보내는 애플리케이션이 페이로드를 Azure Blob Storage로 전송할 때 Azure Event Grid는 토큰을 자동으로 생성합니다. 코드 예제 4에서는 실행 가능한 명령줄 클라이언트를 사용하는 수동 토큰 생성 프로세스를 보여 있습니다.

요구 사항에 맞는 예제를 선택하고 제공된 링크를 따라 GitHub에서 코드를 봅니다.

샘플 코드 메시징 시스템 시나리오 토큰 생성기 애플리케이션 수신 데이터 저장소
코드 예제 1 Azure Queue Storage Azure Event Grid 함수 Azure Blob Storage
코드 예제 2 Azure Event Hubs(표준 API) Azure Event Grid 실행 파일 명령줄 클라이언트 Azure Blob Storage
코드 예제 3 Azure Service Bus Azure Event Grid 함수 Azure Blob Storage
코드 예제 4 Azure Event Hubs(Kafka API) 실행 파일 명령줄 클라이언트 함수 Azure Blob Storage

다음 단계