게이트웨이 집계 패턴

게이트웨이를 사용하여 여러 개별 요청을 단일 요청으로 집계합니다. 이 패턴은 클라이언트가 작업을 수행하기 위해 다른 백 엔드 시스템을 여러 차례 호출해야 하는 경우에 유용합니다.

컨텍스트 및 문제점

단일 작업을 수행하려면 클라이언트가 다양한 백 엔드 서비스를 여러 차례 호출해야 할 수 있습니다. 여러 서비스를 사용하여 작업을 수행하는 애플리케이션은 각 요청마다 리소스를 확장해야 합니다. 애플리케이션에 새 기능 또는 서비스가 추가되면 추가 요청이 필요하므로 리소스 요구 사항 및 네트워크 호출이 더욱 증가합니다. 클라이언트와 백 엔드 간의 이러한 대화는 애플리케이션의 성능과 규모에 부정적인 영향을 줄 수 있습니다. 마이크로 서비스 아키텍처는 많은 소규모 서비스를 중심으로 빌드된 애플리케이션의 서비스 간 호출 수가 더 많기 때문에 이 문제를 더 흔하게 만들었습니다.

다음 다이어그램에서 클라이언트는 각 서비스(번호 1, 2 및 3)에 요청을 보냅니다. 각 서비스는 요청을 처리하고 애플리케이션에 대한 응답을 반환합니다(번호가 4, 5 및 6). 대기 시간이 긴 셀룰러 네트워크를 통해 이러한 방식으로 개별 요청을 보내는 것은 비효율적이며 연결 손실 또는 불완전한 응답을 유발할 수 있습니다. 각 요청은 병렬로 실행될 수 있습니다. 그러나 애플리케이션은 별도의 연결에서 각 요청에 대한 데이터를 보내고, 대기하고, 처리해야 하므로 실패 가능성이 높아질 수 있습니다.

해결 방법

게이트웨이를 사용하여 클라이언트와 서비스 간의 대화 시간을 줄입니다. 게이트웨이는 클라이언트 요청을 수신하고, 다양한 백 엔드 시스템에 요청을 디스패치하고, 결과를 클라이언트로 다시 보내기 전에 집계합니다.

이 패턴은 애플리케이션이 백 엔드 서비스에 대해 만드는 요청 수를 줄이고 대기 시간이 긴 네트워크를 통해 애플리케이션 성능을 향상시킬 수 있습니다.

다음 다이어그램에서는 애플리케이션이 게이트웨이에 요청을 보냅니다(1). 요청에는 추가 요청 패키지가 포함되어 있습니다. 게이트웨이는 이러한 요청을 분해하고 각 요청을 관련 서비스(2)로 전송하여 처리합니다. 각 서비스는 게이트웨이에 응답을 반환합니다(3). 게이트웨이는 각 서비스의 응답을 결합하고 애플리케이션에 응답을 보냅니다(4). 애플리케이션은 단일 요청을 수행하고 게이트웨이에서 단일 응답만 수신합니다.

문제 및 고려 사항

이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.

• 게이트웨이는 백 엔드 서비스 간에 서비스 결합을 도입해서는 안 됩니다.

• 게이트웨이는 가능한 한 대기 시간을 줄이기 위해 백 엔드 서비스 근처에 있어야 합니다.

• 게이트웨이 서비스에서 SPoF(단일 실패 지점)를 도입할 수 있습니다. 게이트웨이가 애플리케이션의 가용성 요구 사항을 충족하도록 올바르게 설계되었는지 확인합니다.

• 게이트웨이에서 병목 현상이 발생할 수 있습니다. 게이트웨이에 현재 부하를 처리할 수 있는 적절한 성능이 있고 예상된 증가에 맞게 크기를 조정할 수 있는지 확인합니다.

• 게이트웨이에 대한 부하 테스트를 수행하여 서비스에 연속 오류가 발생하지 않도록 합니다.

• 격벽, 회로 차단, 재시도, 시간 제한과 같은 기술을 사용하여 복원력 있는 설계를 구현하세요.

• 하나 이상의 서비스 호출이 너무 오래 걸리는 경우 시간 초과를 허용하고 일부 데이터 집합을 반환할 수 있습니다. 애플리케이션에서 이 시나리오를 처리하는 방법을 고려합니다.

• 비동기 입력 및 출력(I/O)을 사용하여 백 엔드에서 지연이 애플리케이션의 성능 문제를 일으키지 않도록 합니다.

• 상관 관계 ID를 사용하여 각 개별 호출을 추적하여 분산 추적을 구현합니다.

• 요청 메트릭 및 응답 크기를 모니터링합니다.

• 캐시된 데이터를 장애 조치(failover) 전략으로 반환하여 오류를 처리하는 것이 좋습니다.

• 게이트웨이에 집계를 빌드하는 대신 게이트웨이 뒤에 집계 서비스를 배치하는 것이 좋습니다. 요청 집계는 게이트웨이의 다른 서비스와 리소스 요구 사항이 다를 수 있으며 게이트웨이의 라우팅 및 오프로드 기능에 영향을 줄 수 있습니다.

이 패턴을 사용하는 경우

다음 경우에 이 패턴을 사용합니다.

• 클라이언트는 작업을 수행하기 위해 여러 백 엔드 서비스와 통신해야 합니다.

• 클라이언트는 셀룰러 네트워크와 같이 대기 시간이 긴 네트워크를 사용할 수 있습니다.

이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.

• 여러 작업에서 클라이언트와 단일 서비스 간의 호출 수를 줄이려고 합니다. 이 시나리오에서는 서비스에 일괄 처리 작업을 추가하는 것이 더 적합할 수 있습니다.

• 클라이언트 또는 애플리케이션은 백 엔드 서비스 근처에 있으며 대기 시간은 중요한 요소가 아닙니다.

워크로드 디자인

워크로드 디자인에서 게이트웨이 집계 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.

Example

고객에게 주문 요약 환경을 제공하는 마이크로 서비스 기반 애플리케이션을 고려합니다. 사용자가 주문 페이지를 열면 애플리케이션은 주문 서비스, 배송 서비스 및 고객 프로필 서비스와 같은 여러 백 엔드 서비스에서 데이터를 검색해야 합니다.

마이크로 서비스 아키텍처에서 이러한 서비스는 독립적으로 구현 및 배포됩니다. 집계가 없으면 클라이언트는 각 서비스를 직접 호출해야 하므로 대기 시간과 복잡성이 증가합니다.

이 문제를 해결하기 위해 애플리케이션은 게이트웨이 집계 계층으로 Azure API Management 사용합니다. 클라이언트는 주문 정보의 수집기 역할을 하는 API Management 작업에 단일 요청을 보냅니다. 그런 다음 API Management는 지원되는 백 엔드 API를 호출하고 클라이언트에 대한 통합 응답을 반환합니다.

API Management 송신 요청 정책을 사용하여 여러 서비스에서 데이터를 검색하고 결합된 응답을 생성하여 이 간단한 컴퍼지션을 구현할 수 있습니다. 이 예제에서 백 엔드 서비스는 Azure Container Apps 환경에서 실행되며, 각 백 엔드 서비스를 직접 클라이언트 액세스에서 숨겨진 상태로 유지되는 컨테이너 앱으로 배포합니다.

이 아키텍처의 Visio 파일을 다운로드하십시오.

요청 흐름은 다음 단계를 수행합니다.

1. 클라이언트는 API Management를 통해 노출되는 주문 요약 엔드포인트에 요청을 보냅니다.

2. API Management는 백 엔드 서비스에서 주문, 배송 및 고객 프로필 데이터를 수집하는 정책을 적용합니다.

3. API Management는 백 엔드 응답을 단일 주문 요약 페이로드로 구성합니다.

4. API Management는 집계된 응답을 클라이언트에 반환합니다.

이 집계 계층을 도입하여 솔루션은 클라이언트-서비스 왕복을 줄이고 클라이언트 상호 작용을 간소화합니다. 이 계층은 응답하지 않는 백 엔드 서비스를 정상적으로 처리하고 집계된 응답에서 오류가 연속되지 않도록 방지합니다. 요청당 시간 제한, 조건부 오류 처리 및 회로 차단기를 사용하여 API Management 정책을 강화합니다.

백 엔드 중 하나가 시간 초과를 호출하거나 오류를 반환하는 경우 API Management는 작업에 가장 적합한 동작을 적용할 수 있습니다. 예를 들어 누락된 데이터가 허용되는 경우 부분 응답을 반환하거나 완전하고 일관된 주문 데이터가 필요할 때 전체 요청이 실패할 수 있습니다. 클라이언트가 예측 가능한 동작을 경험할 수 있도록 정책 디자인에서 이 결정을 명시적으로 지정합니다.

이 방법은 게이트웨이가 경량 컴퍼지션, 셰이핑 및 응답 어셈블리를 수행할 때 잘 작동합니다. 집계에 사용자 지정 도메인 논리, 복잡한 변환 또는 장기 실행 오케스트레이션이 필요한 경우 해당 기능을 게이트웨이 뒤에 있는 전용 사용자 지정 서비스에 배치합니다.

모니터링의 경우 API Management 동작과 백 엔드 대기 시간의 상관 관계를 지정할 수 있도록 전체 요청 경로에서 원격 분석을 수집합니다. 단일 클라이언트 작업은 여러 백 엔드 호출에 종속되며, 한 종속성의 실패 또는 느린 응답은 최종 집계 결과에 영향을 줄 수 있으므로 이 가시성은 게이트웨이 집계 패턴에서 중요합니다. Azure Monitor를 중앙 관찰 플랫폼으로 사용합니다. 게이트웨이 및 정책 실행 경로에 대한 API Management 로그 및 메트릭을 수집하고 , Container Apps에 대한 모니터링을 사용하여 백 엔드 컨테이너 앱에서 애플리케이션 로그 및 메트릭을 캡처할 수 있습니다. API Management 및 백엔드 원격 분석 데이터를 통합 쿼리, 경고 및 문제 해결을 위해 Log Analytics 작업 영역으로 전송합니다. 이 원격 분석을 사용하면 시간 제한 패턴을 감지하고, 부분 또는 실패한 응답을 발생시킨 백 엔드 종속성을 식별하고, 높은 대기 시간 또는 오류 비율에 대한 경고를 만들 수 있습니다.

다음 단계

• API Management 서비스에서 외부 서비스 사용
• 송신 요청 정책
• Container Apps 설명서

관련 리소스

• 프런트 엔드에 대한 백 엔드 패턴
• 게이트웨이 오프로딩 패턴
• 게이트웨이 라우팅 패턴