프런트 엔드 클라이언트 통신
팁
이 콘텐츠는 Azure용 클라우드 네이티브 .NET 애플리케이션 설계 eBook 에서 발췌한 것으로, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.
클라우드 네이티브 시스템에서 프런트 엔드 클라이언트(모바일, 웹 및 데스크톱 애플리케이션)에는 독립적인 백 엔드 마이크로 서비스와 상호 작용하는 통신 채널이 필요합니다.
그 옵션은 무엇입니까?
간단하게 유지하기 위해 프런트 엔드 클라이언트는 그림 4-2에 표시된 백 엔드 마이크로 서비스와 직접 통신할 수 있습니다.
그림 4-2. 클라이언트-서비스 간 직접 통신
이 접근 방법을 사용하면 각 마이크로 서비스에는 프런트 엔드 클라이언트에서 액세스할 수 있는 공용 엔드포인트가 있습니다. 프로덕션 환경에서는 부하 분산 장치를 마이크로 서비스 앞에 배치하여 트래픽을 비례적으로 라우팅합니다.
구현하기 간단하지만 간단한 마이크로 서비스 애플리케이션에 대해서만 직접 클라이언트 통신이 허용됩니다. 이 패턴은 프런트 엔드 클라이언트를 핵심 백 엔드 서비스와 긴밀하게 결합하여, 다음을 비롯한 많은 문제 가능성을 제기합니다.
- 백 엔드 서비스 리팩터링에 대한 클라이언트 장애의 영향력
- 코어 백 엔드 서비스가 직접 노출됨에 따라 더 넓은 공격 표면
- 각 마이크로 서비스에서 교차 절단 문제의 중복
- 지나치게 복잡한 클라이언트 코드 - 클라이언트는 여러 엔드포인트를 추적하고 복원력 있는 방식으로 오류를 처리해야 합니다.
대신 널리 허용되는 클라우드 디자인 패턴은 프런트 엔드 애플리케이션과 백 엔드 서비스 간에 API 게이트웨이 서비스를 구현하는 것입니다. 패턴은 그림 4-3에 표시됩니다.
그림 4-3. API 게이트웨이 패턴
이전 그림에서 API 게이트웨이 서비스가 백 엔드 코어 마이크로 서비스를 추상화하는 방법을 확인합니다. 웹 API로 구현된 이것은 들어오는 트래픽을 내부 마이크로 서비스로 라우팅하는 역방향 프록시 역할을 합니다.
게이트웨이는 내부 서비스 분할 및 리팩터링으로부터 클라이언트를 격리합니다. 백 엔드 서비스를 변경하는 경우 클라이언트를 중단하지 않고 게이트웨이에 이것을 수용합니다. 이것은 ID, 캐싱, 복원력, 계량 및 제한과 같은 교차 절단 문제에 대한 첫 번째 방어선이기도 합니다. 이러한 교차 절단 문제의 대부분은 백 엔드 코어 서비스에서 게이트웨이로 오프로드되어, 백 엔드 서비스를 간소화할 수 있습니다.
API 게이트웨이를 간단하고 빠르게 유지하려면 주의해야 합니다. 일반적으로 비즈니스 논리는 게이트웨이에서 유지됩니다. 복잡한 게이트웨이는 병목 상태가 되고 결국 모놀리식 자체가 될 위험이 있습니다. 대규모 시스템에서는 클라이언트 유형(모바일, 웹, 데스크톱) 또는 백 엔드 기능별로 분할된 여러 API 게이트웨이를 노출하는 경우가 있습니다. 프런트 엔드용 백 엔드 패턴은 여러 게이트웨이를 구현하는 방향을 제공합니다. 패턴은 그림 4-4에 표시됩니다.
그림 4-4. 프런트 엔드 패턴의 백 엔드
이전 그림에서 들어오는 트래픽이 클라이언트 유형(웹, 모바일 또는 데스크톱 앱)에 따라 특정 API 게이트웨이로 전송되는 방식을 확인합니다. 이 접근 방식은 각 디바이스의 기능이 폼 팩터, 성능 및 표시 제한에 따라 크게 달라지므로 타당합니다. 일반적으로 모바일 애플리케이션의 기능은 브라우저 또는 데스크톱 애플리케이션보다 적게 노출됩니다. 각 게이트웨이는 해당 디바이스의 성능 및 기능과 일치하도록 최적화할 수 있습니다.
단순 게이트웨이
시작하기 위해 사용자 고유의 API 게이트웨이 서비스를 빌드할 수 있습니다. GitHub를 빠르게 검색하면 많은 예제가 제공됩니다.
간단한 .NET 클라우드 네이티브 애플리케이션의 경우, Ocelot 게이트웨이를 고려할 수 있습니다. .NET 마이크로 서비스에 대해 생성된 오픈 소스는 가볍고 빠르며 확장 가능합니다. API 게이트웨이와 마찬가지로, 이것의 기본 기능은 들어오는 HTTP 요청을 다운스트림 서비스에 전달하는 것입니다. 또한 .NET 미들웨어 파이프라인에서 구성할 수 있는 다양한 기능을 지원합니다.
YARP(또 다른 역방향 프록시)는 Microsoft 제품 팀 그룹이 주도하는 또 다른 오픈 소스 역방향 프록시입니다. NuGet 패키지로 다운로드할 수 있는 YARP는 ASP.NET 프레임워크에 미들웨어로 연결되며 고도로 사용자 지정할 수 있습니다. YARP는 다양한 사용 예제로 잘 문서화되었다는 것을 알 수 있습니다.
엔터프라이즈 클라우드 네이티브 애플리케이션의 경우 작업을 시작하는 데 도움이 되는 몇 가지 관리형 Azure 서비스가 있습니다.
Azure Application Gateway
간단한 게이트웨이 요구 사항의 경우 Azure Application Gateway를 고려할 수 있습니다. Azure PaaS 서비스로 사용할 수 있는 이 서비스에는 URL 라우팅, SSL 종료 및 Web Application Firewall 같은 기본 게이트웨이 기능이 포함되어 있습니다. 이 서비스는 계층 7 부하 분산 기능을 지원합니다. 계층 7을 사용하면 하위 수준 TCP 네트워크 패킷뿐만 아니라 HTTP 메시지의 실제 콘텐츠에 따라 요청을 라우팅할 수 있습니다.
이 책 전체에서 Kubernetes에서 호스팅 클라우드 네이티브 시스템을 전파합니다. 컨테이너 오케스트레이터인 Kubernetes는 컨테이너화된 워크로드의 배포, 크기 조정 및 운영 문제를 자동화합니다. Azure Application Gateway는 Azure Kubernetes Service 클러스터용 API 게이트웨이로 구성할 수 있습니다.
Application Gateway 수신 컨트롤러를 사용하면 Azure Application Gateway가 Azure Kubernetes Service와 직접 작업할 수 있습니다. 그림 4.5는 아키텍처를 보여 줍니다.
그림 4-5 Application Gateway 수신 컨트롤러
Kubernetes에는 수신이라는 HTTP(수준 7) 부하 분산을 지원하는 기본 제공 기능이 포함되어 있습니다. 수신은 AKS 내의 마이크로 서비스 인스턴스를 외부 세계에 공개하는 방법에 대한 규칙 집합을 정의합니다. 이전 이미지에서 수신 컨트롤러는 클러스터에 대해 구성된 수신 규칙을 해석하고 Azure Application Gateway를 자동으로 구성합니다. 이러한 규칙에 따라, 애플리케이션 게이트웨이는 AKS 내에서 실행되는 마이크로 서비스로 트래픽을 라우팅합니다. 수신 컨트롤러는 수신 규칙의 변경 내용을 수신 대기하고 Azure Application Gateway를 적절하게 변경합니다.
Azure API Management
보통에서 대규모 클라우드 네이티브 시스템의 경우 Azure API Management를 고려할 수 있습니다. 이것은 API 게이트웨이 요구 사항을 해결할 뿐만 아니라, 완전한 기능을 갖춘 개발자 및 관리 환경을 제공하는 클라우드 기반 서비스입니다. API Management는 그림 4-6에 나타나 있습니다.
그림 4-6. Azure API Management
시작하기 위해 API Management는 구성 가능한 규칙 및 정책에 따라 백 엔드 서비스에 대한 제어된 액세스를 허용하는 게이트웨이 서버를 노출시킵니다. 이러한 서비스는 Azure 클라우드, 온-프레미스 데이터 센터 또는 기타 퍼블릭 클라우드에 있을 수 있습니다. API 키와 JWT 토큰은 누가 무엇을 할 수 있는지 결정합니다. 모든 트래픽은 분석 목적으로 기록됩니다.
개발자의 경우 API Management는 서비스, 설명서 및 호출을 위한 샘플 코드에 대한 액세스를 제공하는 개발자 포털을 제공합니다. 개발자는 Swagger/Open API를 사용하여 서비스 엔드포인트를 검사하고 사용량을 분석할 수 있습니다. 이 서비스는 .NET, Java, Golang 등의 주요 개발 플랫폼에서 작동합니다.
게시자 포털에는 관리자가 API를 표시하고 해당 동작을 관리하는 관리 대시보드가 나타납니다. 서비스 액세스 권한을 부여하고, 서비스 상태를 모니터링하고, 서비스 원격 분석을 수집할 수 있습니다. 관리자는 각 엔드포인트에 정책을 적용하여 동작에 영향을 줍니다. 정책은 각 서비스 호출에 대해 순차적으로 실행되는 미리 빌드된 문입니다. 정책은 인바운드 호출, 아웃바운드 호출에 대해 구성되거나 오류 발생 시 호출됩니다. 정책을 결합할 때 결정적 순서를 사용하도록 다양한 서비스 범위에서 정책을 적용할 수 있습니다. 제품에는 미리 빌드된 정책이 많이 제공됩니다.
다음은 정책이 클라우드 네이티브 서비스의 동작에 영향을 줄 수 있는 방법의 예입니다.
- 서비스 액세스를 제한합니다.
- 인증을 적용합니다.
- 필요한 경우 단일 원본에서 호출을 제한합니다.
- 캐싱을 사용합니다.
- 특정 IP 주소에서 호출을 차단합니다.
- 서비스의 흐름을 제어합니다.
- 요청을 SOAP에서 REST로 변환하거나 XML에서 JSON으로처럼, 다양한 데이터 형식 간에 변환합니다.
Azure API Management는 클라우드 또는 데이터 센터에서 호스트되는 백 엔드 서비스를 표시할 수 있습니다. 클라우드 네이티브 시스템에 나타날 수 있는 레거시 서비스의 경우 REST 및 SOAP API를 모두 지원합니다. 다른 Azure 서비스도 API Management 통해 표시될 수 있습니다. Azure Service Bus 또는 Azure Logic Apps과 같은 Azure 지원 서비스 위에 관리되는 API를 배치할 수 있습니다. Azure API Management는 기본 제공 부하 분산 지원을 포함하지 않으며 부하 분산 서비스와 함께 사용해야 합니다.
Azure API Management는 네 가지 계층에서 사용할 수 있습니다.
- 개발자
- 기본
- Standard
- Premium
개발자 계층은 비프로덕션 워크로드 및 평가를 위한 것입니다. 다른 계층은 점점 더 많은 전력, 기능 및 더 높은 SLA(서비스 수준 계약)를 제공합니다. 프리미엄 계층은 Azure Virtual Network 및 다중 지역 지원을 제공합니다. 모든 계층에는 시간당 고정 가격이 있습니다.
또한 Azure는 Azure API Management에 대한 서버리스 계층을 제공합니다. 소비 가격 책정 계층이라고 하는 서비스는 서버리스컴퓨팅 모델을 중심으로 설계된 API Management의 변형입니다. 이전에 표시된 “미리 할당된” 가격 책정 계층과 달리 소비 계층은 즉각적인 프로비전과 작업당 지불 가격 책정을 제공합니다.
다음과 같은 사용 사례에 대해 API 게이트웨이 기능을 사용하도록 설정합니다.
- Azure Functions 및 Azure Logic Apps와 같은 서버리스 기술을 사용하여 구현된 마이크로 서비스.
- Service Bus 큐 및 토픽, Azure Storage 등과 같은 Azure 지원 서비스 리소스.
- 트래픽이 가끔씩 급증하지만 대부분의 경우 낮은 수준으로 유지되는 마이크로 서비스.
소비 계층은 동일한 기본 서비스 API Management 구성 요소를 사용하지만 동적으로 할당된 리소스에 따라 완전히 다른 아키텍처를 사용합니다. 이 계층은 서버리스 컴퓨팅 모델에 완벽하게 잘 맞습니다.
- 관리할 인프라가 없습니다.
- 유휴 용량 없음.
- 고가용성.
- 자동 크기 조정
- 비용은 실제 사용량을 기준으로 청구됩니다.
새 소비 계층은 서버리스 리소스를 API로 노출하는 클라우드 네이티브 시스템에 적합합니다.
실시간 통신
실시간 또는 푸시 통신은 HTTP를 통해 백 엔드 클라우드 네이티브 시스템과 통신하는 프런트 엔드 애플리케이션에 대한 또 다른 옵션입니다. 재무 주식 종목, 온라인 교육, 게임 및 작업 진행률 업데이트와 같은 애플리케이션에는 백 엔드의 즉각적인 실시간 응답이 필요합니다. 일반적인 HTTP 통신에서는 클라이언트가 새 데이터를 사용할 수 있는 시기를 알 수 있는 방법이 없습니다. 클라이언트는 지속적으로 요청을 폴링하거나 서버에 보내야 합니다. 실시간 통신을 통해 서버는 언제든지 새 데이터를 클라이언트에 푸시할 수 있습니다.
실시간 시스템은 종종 빈도가 높은 데이터 흐름과 많은 수의 동시 클라이언트 연결이 특징입니다. 실시간 연결을 수동으로 구현하는 것은 빠르게 복잡해질 수 있으며, 연결된 클라이언트에 대한 확장성과 신뢰할 수 있는 메시징을 보장하기 위해 간단하지 않은 인프라가 필요합니다. Azure Redis Cache 인스턴스와 클라이언트 선호도에 대한 고정 세션으로 구성된 일련의 부하 분산 장치를 직접 관리할 수 있습니다.
Azure SignalR Service는 클라우드 네이티브 애플리케이션에 대한 실시간 통신을 간소화하는 완전 관리형 Azure 서비스입니다. 용량 프로비전, 스케일링 및 영구 연결과 같은 기술 구현 세부 정보는 추상화됩니다. 이들은 99.9% 서비스 수준 계약으로 처리됩니다. 인프라 배관이 아닌 애플리케이션 기능에 중점을 둡니다.
사용하도록 설정되면 클라우드 기반 HTTP 서비스는 브라우저, 모바일 및 데스크톱 애플리케이션을 포함하여 연결된 클라이언트에 직접 콘텐츠 업데이트를 푸시할 수 있습니다. 클라이언트는 서버를 폴링할 필요 없이 업데이트됩니다. Azure SignalR은 WebSocket, Server-Side 이벤트 및 긴 폴링을 포함하여 실시간 연결을 만드는 전송 기술을 추상화합니다. 개발자는 연결된 클라이언트의 전체 또는 특정 하위 집합에 메시지를 보내는 데 집중합니다.
그림 4-7에서는 Azure SignalR을 사용하도록 설정된 클라우드 네이티브 애플리케이션에 연결하는 HTTP 클라이언트 집합을 보여 줍니다.
그림 4-7. Azure SignalR
Azure SignalR Service의 또 다른 이점은 서버리스 클라우드 네이티브 서비스를 구현하는 것입니다. 코드는 Azure Functions 트리거를 사용하여 요청하면 실행될 수 있습니다. 코드가 클라이언트와의 긴 연결을 유지하지 않기 때문에 이 시나리오는 까다로울 수 있습니다. Azure SignalR Service는 이미 연결을 관리하므로 이 상황을 처리할 수 있습니다.
Azure SignalR Service는 Azure SQL Database, Service Bus 또는 Redis Cache와 같은 다른 Azure 서비스와 긴밀하게 통합되어 클라우드 네이티브 애플리케이션에 대한 많은 가능성을 열어줍니다.
.NET