저렴한 서버리스 Azure 서비스를 사용하여 실시간으로 위치 공유

이 시나리오는 실시간 서비스를 사용하여 페이지를 새로 고칠 필요 없이 웹 보기 내에서 기본 데이터의 변화를 처리하는 솔루션을 설계하는 방법에 대해 설명합니다. 이 시나리오를 사용하는 예제에는 제품과 상품 실시간 추적 및 소셜 미디어 솔루션이 있습니다.

아키텍처

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

구성 요소

• Azure Service Bus는 애플리케이션과 서비스(이 중 하나 이상이 오프라인 상태인 경우에도) 간에 안정성이 뛰어난 클라우드 메시징 서비스입니다.
• Azure SignalR Service를 사용하면 웹 애플리케이션에 실시간 통신을 쉽게 추가할 수 있습니다.
• Azure Functions는 복잡한 오케스트레이션 문제도 해결할 수 있는 이벤트 기반 서버리스 컴퓨팅 플랫폼입니다.

대안

이 시나리오를 해결하기 위한 대안이 존재하며 Pusher는 그 중 하나입니다. 스케일링 가능한 실시간 통신 기능을 빌드하는 앱 개발자를 위한 강력한 API의 범주 리더입니다.

PubNub도 있습니다. PubNub를 사용하면 인프라에 대한 걱정 없이 실시간 기능을 앱에 쉽게 추가할 수 있습니다. 사용자가 모바일, 브라우저, 데스크톱 및 서버에서 실시간으로 활용할 수 있는 앱을 구축하세요.

Ably는 또 다른 대안입니다. 서버리스 게시/구독(pub/sub) 메시징을 제공하여 필요에 따라 안정적으로 스케일링합니다. 메시지는 WebSocket을 사용하여 에지에서 배달됩니다. Ably 플랫폼은 API 호출 시 탄력적으로 스케일링 가능하고, 전역적으로 분산된 고가용성 실시간 인프라를 제공합니다.

Pusher, PubNub 및 Ably는 실시간 메시징을 위해 가장 널리 채택된 플랫폼이지만 이 시나리오에서는 Azure에서 모든 작업을 수행합니다. SignalR은 서버와 클라이언트 간 양방향 통신을 허용하므로 이동 플랫폼으로 사용하는 것이 좋습니다. GitHub 별모양이 7,900여개이고 GitHub 포크가 2,200여개에 달하는 오픈 소스 도구이기도 합니다.

자세한 내용은 GitHub의 SignalR 오픈 소스 리포지토리를 참조하세요.

시나리오 정보

이 시나리오에서는 음식 배달 서비스 트랜잭션의 실시간 위치를 공유하는 실시간 메시징 서비스를 설정하는 방법을 살펴봅니다. 이 예제는 웹 또는 모바일 애플리케이션을 위한 실시간 위치 공유 플랫폼을 빌드하려는 사용자에게도 유용할 수 있습니다.

서버리스 모드로 구성된 SignalR Service를 사용하여 Service Bus에 의해 트리거되는 Azure Functions 앱과 통합합니다. 모두 .NET Core를 사용합니다.

잠재적인 사용 사례

다음과 같은 다른 사용 사례의 디자인 패턴도 비슷합니다.

• 클라이언트 디바이스와 실시간 위치 공유
• 사용자에게 알림 푸시
• 타임라인 업데이트
• 채팅방 만들기

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

ServiceBusTrigger의 Azure Service Bus 연결 문자열에서 매개 변수를 구성하는 방법을 포함하여 이 시나리오를 개발할 때 유의해야 할 몇 가지 사항은 다음과 같습니다.

• 허브: 허브는 비디오 스트리밍 서비스에 비교할 수 있습니다. 허브를 구독하여 메시지를 주고받을 수 있습니다.
• 대상: 대상은 라디오 채널과 같습니다. 대상은 대상 채널을 수신하는 모든 사용자를 포함하며 새 메시지가 표시되면 알림을 받습니다.

SignalR 플랫폼의 이전 두 가지 기능을 기억할 수 있으면, 쉽고 빠르게 시작하고 실행할 수 있습니다.

가용성, 확장성 및 보안

다음 두 섹션에 설명된 내용에 따라 이 솔루션으로 고가용성을 달성할 수 있습니다.

지역을 쌍으로 연결

Azure 지역은 동일한 지역 내에서 다른 지역과 쌍을 이룹니다. 일반적으로 같은 지역 쌍에서 지역을 선택합니다. 예를 들어 미국 동부 2와 미국 중부입니다. 이에 따른 장점은 다음과 같습니다.

• 광범위한 가동 중단이 발생한 경우 모든 쌍 중에서 하나 이상의 지역에 대한 복구에 우선 순위가 지정됩니다.
• 계획된 Azure 시스템 업데이트는 순차적으로 쌍을 이루는 지역으로 출시되어 가동 중지 시간을 최소화할 수 있습니다.
• 대부분의 경우 지역 쌍은 데이터 상주 요구 사항을 충족하기 위해 동일한 지리 내에 상주합니다.
• 그러나 두 지역 모두 애플리케이션에 필요한 모든 Azure 서비스를 지원하는지 확인합니다. 지역별 서비스를 참조하세요. 지역 쌍에 대한 자세한 내용은 BCDR(무중단 업무 방식 및 재해 복구): Azure 쌍을 이루는 지역을 참조하세요.

Azure Front Door

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

Azure Front Door는 글로벌 애플리케이션을 빠르게 제공할 수 있는 확장 가능하고 안전한 진입점입니다. 우선 순위 라우팅을 사용하면 주 지역을 사용할 수 없는 경우 자동으로 장애 조치(failover)됩니다. 다중 지역 아키텍처는 단일 지역에 배포하는 것보다 더 높은 가용성을 제공할 수 있습니다. 지역 중단이 주 지역에 영향을 미치는 경우 Front Door를 사용하여 보조 지역으로 장애 조치(failover)할 수 있습니다.

이 아키텍처는 솔루션의 개별 하위 시스템에 장애가 발생한 경우에도 유용합니다. 웹 애플리케이션 방화벽 및 DDoS Protection을 사용하여 에지에서 네트워크 및 애플리케이션 계층 공격을 막습니다. Microsoft 관리형 규칙 집합을 사용하여 서비스를 강화하고 앱의 사용자 지정 보호를 위한 자체 규칙을 작성합니다.

Front Door는 시스템에서 오류가 발생할 수 있는 지점입니다. 서비스가 실패하면 클라이언트가 가동 중지 시간 동안 애플리케이션에 액세스할 수 없습니다. Front Door SLA(서비스 수준 계약)를 검토하고 Front Door만 사용하여 고가용성을 위한 비즈니스 요구 사항을 충족하는지 여부를 확인합니다. 그렇지 않은 경우 다른 트래픽 관리 솔루션을 장애 복구(Failback)로 추가합니다. Front Door 서비스가 실패하면 다른 트래픽 관리 서비스를 가리키도록 DNS의 CNAME(정식 이름) 레코드를 변경합니다. 이 단계는 수동으로 수행해야 하며 DNS 변경 내용이 전파될 때까지 애플리케이션을 사용할 수 없습니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

비즈니스에 하루 1,000개 주문이 있고 위치 데이터를 모두와 동시에 공유해야 한다고 가정해 보겠습니다. 이 시나리오를 배포하기 위한 예상 Azure 사용량은 게시 날짜의 가격 책정에 따라 매월 USD192에 가깝습니다.

시나리오 배포

Azure Functions 개발

Azure Functions 및 Azure SignalR Service로 빌드된 서버리스 실시간 애플리케이션에는 일반적으로 다음과 같은 두 가지 Azure Functions가 필요합니다.

• 클라이언트가 유효한 SignalR Service 액세스 토큰 및 서비스 엔드포인트 URL을 얻기 위해 호출하는 negotiate 함수.
• 메시지를 보내거나 그룹 멤버 자격을 관리하는 하나 이상의 함수.

SignalRFunctionApp

SignalRFunctionApp은 SignalR과 함께 Service Bus 트리거를 사용하여 Azure Functions 인스턴스를 만드는 함수 앱입니다.

Negotiate.cs

이 함수는 HTTP 요청에 의해 트리거됩니다. 클라이언트 애플리케이션이 SignalR Service에서 토큰을 가져오는 데 사용됩니다. 이 서비스는 클라이언트가 허브를 구독하는 데 사용할 수 있습니다. 이 함수의 이름은 negotiate여야 합니다. 자세한 내용은 Azure SignalR Service를 사용하여 Azure Functions 개발 및 구성을 참조하세요.

Message.cs

이 함수는 Service Bus 트리거에 의해 트리거됩니다. SignalR Service와 바인딩되어 있습니다. 큐에서 메시지를 끌어와서 SignalR 허브로 전달합니다.

Instructions

시작하기 전에

• Azure에서 프로비저닝된 Service Bus 큐가 있는지 확인합니다.
• SignalR 서비스가 Azure에서 서버리스 모드로 프로비저닝되어 있는지 확인합니다.

1. local.settings.json 파일에 연결 문자열(Service Bus 및 SignalR)을 입력합니다.
2. CORS(원본 간 리소스 공유)에 클라이언트 애플리케이션(SignalR 클라이언트)의 URL을 입력합니다. 가장 최근 구문은 Azure SignalR Service를 사용하여 Azure Functions 개발 및 구성을 참조하세요.
3. Message.cs 파일의 Service Bus 트리거에 Service Bus 큐 이름을 입력합니다.

이제 테스트할 클라이언트 애플리케이션을 구성하겠습니다. 먼저 solution-architectures GitHub 페이지에서 예제 원본을 가져옵니다.

SignalR 클라이언트

SignalRFunctionApp에서 만든 허브를 구독하는 간단한 .NET Core 웹 애플리케이션입니다. Service Bus 큐에서 실시간으로 수신되는 메시지를 표시합니다. SignalRFunctionApp을 사용하여 모바일 클라이언트에서 작업할 수 있지만 이 리포지토리에서 이 시나리오에 대한 웹 클라이언트를 계속 살펴보겠습니다.

지침

1. SignalRFunctionApp이 실행되고 있는지 확인합니다.

2. negotiate 함수에서 생성된 URL을 복사합니다. 모양은 다음과 같습니다. http://localhost:7071/api/

3. signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build(); 내부 chat.js 파일에 URL을 붙여넣습니다.

4. 애플리케이션을 실행합니다.

   웹 클라이언트가 SignalR 허브를 성공적으로 구독하면 상태가 연결됨으로 표시됩니다.

SendToQueue.js

이 node.js 스크립트는 방금 완료한 배포를 테스트할 수 있도록 메시지를 Service Bus에 푸시합니다.

Instructions

1. 노드 Azure Service Bus 모듈(@azure/service-bus)을 설치합니다.

2. 스크립트에 연결 문자열과 큐 이름을 입력합니다.

3. 스크립트를 실행합니다.

다음 단계

이 시나리오를 프로덕션 환경으로 가져올 수 있습니다. 그러나 Azure 서비스가 스케일링하도록 설정되어 있는지 확인합니다. 예를 들어 Azure Service Bus를 표준 또는 프리미엄 계획으로 설정해야 합니다.

코드는 Visual Studio에서 Azure Functions에 바로 배포할 수 있습니다. Visual Studio에서 Azure Functions에 코드를 게시하는 방법을 알아보려면 소프트웨어를 만드는 방법 가이드를 따르세요.

Azure Functions에서 Azure Service Bus 바인딩을 사용하는 방법을 참조하세요. Azure Functions는 Service Bus 큐 및 토픽에 대한 트리거 및 출력 바인딩을 지원합니다.

Azure Functions에서 SignalR Service 바인딩을 사용하여 Azure SignalR Service에 연결된 클라이언트에 실시간 메시지를 인증하고 전송하는 방법을 참조하세요. Azure Functions는 SignalR Service에 대한 입력 및 출력 바인딩을 지원합니다.

관련 참고 자료

• 대량 일괄 처리 트랜잭션 처리
• 전송 허브 동적 pub-sub 메시징 시스템
• 서버리스 이벤트 처리
• 블록체인 워크플로 애플리케이션
• 이벤트 기반 클라우드 자동화