AWS 기반의 실시간 통신 1/2

16 min readMar 15, 2020

AWS에서 고가용성 및 확장 가능한 실시간 통신 (RTC) 워크로드 설계를 위한 모범 사례

[ 고지 사항 (Disclaimer) ]

본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.

본 문서는 Real-Time Communication on AWS (2020년, 영문) 내용에 기반하여 작성 되었습니다.

이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.

본 문서는 총 2부로 구성되어 있으며 이 글은 1부입니다.

2부 링크 : AWS 기반의 실시간 통신 2/2

요약

오늘날 많은 조직에서 실시간 음성, 메시징 및 멀티미디어 워크로드에 대한 비용을 절감하고 확장성을 확보하고자 합니다. 이 백서는 AWS에서 실시간 통신 워크로드를 관리하기 위한 모범 사례를 간략하게 설명하고 이러한 요구 사항을 충족하는 참조 아키텍처를 포함합니다. 이 백서는 이러한 워크로드에 대한 고가용성 및 확장성을 달성하는 방법에 대한 실시간 통신에 익숙한 개인을 위한 안내서입니다.

소개

음성, 비디오 및 메시징을 채널로 사용하는 통신 응용 프로그램은 많은 조직과 최종 사용자에게 중요한 요구 사항입니다. 이러한 실시간 통신 (RTC) 워크로드에는 관련 설계 모범 사례를 준수하여 충족 할 수 있는 특정 대기 시간 및 가용성 요구 사항이 있습니다. 과거에는 RTC 워크로드가 전용 리소스가 있는 기존 온 프레미스 데이터 센터에 배포되었습니다.

그러나 성숙하고 급증하는 기능 세트로 인해 엄격한 서비스 수준 요구 사항에도 불구하고 Amazon Web Services (AWS)에 RTC 워크로드를 배포 할 수 있으며 확장 성, 탄력성 및 고가용성의 이점도 얻을 수 있습니다. 현재 여러 고객이 AWS, 파트너 및 오픈 소스 솔루션을 사용하여 비용을 줄이고 민첩성을 높이고 몇 분 안에 전 세계로 진출 할 수 있는 기능과 AWS 서비스의 풍부한 기능으로 RTC 워크로드를 실행하고 있습니다.

고객은 ENA (Elastic Network Adapter) 및 최신 Amazon Elastic Compute Cloud (EC2) 인스턴스를 통한 향상된 네트워킹과 같은 AWS 기능을 활용하여 DPDK (Data Plan Development Kit), SR-IOV (Single Root I / O Virtualization)의 이점을 누릴 수 있습니다. ), NVMe (NVM Express), NUMA (Non-Uniform Memory Access) 지원 및 RTC 워크로드 요구 사항을 충족하는 베어 메탈 인스턴스. 이 인스턴스는 최대 100Gbps의 네트워크 대역폭과 초당 패킷을 제공하여 네트워크 집약적인 애플리케이션의 성능을 향상 시킵니다. 확장을 위해 Elastic Load Balancing은 초당 수백만 건의 요청을 처리 할 수 있는 WebSocket 지원 및 Network Load Balancer를 제공하는 Application Load Balancer를 제공합니다. 네트워크 가속화를 위해 AWS Global Accelerator는 AWS의 애플리케이션 엔드 포인트에 고정 진입점 역할을 하는 고정 IP 주소를 제공합니다. 로드 밸런서에 대한 고정 IP 주소를 지원합니다. 지연 시간 단축, 비용 및 대역폭 처리량 향상을 위해 AWS Direct Connect는 온 프레미스에서 AWS로 전용 네트워크 연결을 설정합니다. 고가용성 관리형 SIP 트렁크는 Amazon Chime Voice Connector에서 제공합니다. WebRTC가 포함 된 Amazon Kinesis 비디오 스트림은 고가용성으로 실시간 양방향 미디어를 쉽게 스트리밍합니다.

이 백서에는 AWS에서 RTC 워크로드를 설정하는 방법과 클라우드에 최적화하면서 최종 사용자 요구 사항을 충족하도록 솔루션을 최적화하는 모범 사례를 보여주는 참조 아키텍처가 포함되어 있습니다. 진화 된 패킷 코어 (EPC)는 이 백서에서 다루지 않지만 자세한 모범 사례는 VNF (가상 네트워크 기능)에 적용될 수 있습니다.

RTC 아키텍처의 기본 구성 요소

통신 산업에서 실시간 통신 (RTC)은 일반적으로 최소 대기 시간으로 두 엔드 포인트 간의 라이브 미디어 세션을 말합니다. 이 세션은 다음과 관련이 있을 수 있습니다.

· 두 당사자 간의 음성 세션 (예 : 전화 시스템, 모바일, VoIP)

· 인스턴트 메시징 (예 : 채팅, IRC)

· 라이브 비디오 세션 (예 : 화상 회의, 텔레프레즌스)

전술한 각각의 솔루션은 공통의 일부 컴포넌트 (예를 들어, 인증, 인증 및 액세스 제어를 제공하는 컴포넌트, 트랜스 코딩, 버퍼링 및 중계 등) 및 전송 된 매체의 유형 (예를 들어, 방송 서비스, 메시징)에 서버 및 대기열 등 고유한 일부 컴포넌트를 갖습니다. 이 섹션에서는 음성 및 비디오 기반 RTC 시스템과 그림 1에 설명 된 모든 관련 구성 요소를 정의하는 데 중점을 둡니다.

소프트 스위치 / PBX

소프트 스위치 또는 PBX는 음성 전화 시스템의 두뇌이며 다른 구성 요소를 사용하여 기업 내부 또는 외부에서 음성 통화를 설정, 유지 관리 및 라우팅하기 위한 인텔리전스를 제공합니다. 기업의 모든 가입자는 소프트 스위치에 등록하여 전화를 받거나 받아야 합니다. 소프트 스위치의 중요한 기능은 음성 네트워크 내의 다른 구성 요소를 사용하여 각 가입자와 가입자에게 도달하는 방법을 추적하는 것입니다.

Session Border Controller (SBC)

SBC (Session Border Controller)는 음성 네트워크의 가장자리에 있으며 모든 수신 및 발신 트래픽 (제어 및 데이터 평면)을 추적합니다. SBC의 주요 책임 중 하나는 악의적인 사용으로부터 음성 시스템을 보호하는 것입니다. SBC는 외부 연결을 위해 SIP (Session Initiation Protocol) 트렁크와 상호 연결하는 데 사용할 수 있습니다. 일부 SBC는 CODECS를 한 형식에서 다른 형식으로 변환하기 위한 코드 변환 기능도 제공합니다. 마지막으로, 대부분의 SBC는 방화벽이 있는 네트워크에서도 통화가 이루어질 수 있도록 NAT 통과 기능을 제공합니다.

PSTN 연결

VoIP (Voice over IP) 솔루션은 PSTN 게이트웨이 및 SIP 트렁크를 사용하여 기존 PSTN 네트워크에 연결합니다.

PSTN 게이트웨이

PSTN (Public Switched Telephone Network) 게이트웨이는 시그널링 (SIP와 SS7 간)과 미디어 (CODEC 트랜스 코딩을 사용하여 RTP와 TDM (Time Division Multiplexing) 간)를 변환 합니다. PSTN 게이트웨이는 항상 PSTN 네트워크와 가까운 가장자리에 있습니다.

SIP 트렁크

SIP 트렁크에서 기업은 TDM (SS7 기반) 네트워크에 대한 통화를 종료하지 않지만 기업과 통신 업체 간의 흐름은 IP를 통해 유지됩니다. 대부분의 SIP 트렁크는 SBC를 사용하여 설정됩니다. 기업은 특정 범위의 IP 주소, 포트 등을 허용하는 등 Telco의 사전 정의 된 보안 규칙에 동의해야 합니다.

미디어 게이트웨이 (트랜스 코더)

일반적인 음성 솔루션은 다양한 유형의 코덱을 허용합니다. 일반적인 코덱 중 일부는 북미의 경우 G.711 µ-law, 북미 이외의 경우 G.711 A-law, G.729 및 G.722입니다. 서로 다른 두 코덱을 사용하는 두 장치가 서로 통신 할 때 미디어 서버는 장치 간 코덱 흐름을 변환합니다. 즉, 미디어 게이트웨이는 미디어를 처리하고 최종 장치가 서로 통신 할 수 있도록 합니다.

WebRTC 및 WebRTC 게이트웨이

WebRTC (Web real-time communication)를 사용하면 웹 브라우저에서 호출을 설정하거나 API를 사용하여 백엔드 서버에서 자원을 요청할 수 있습니다. 이 기술은 클라우드 기술을 염두에 두고 설계 되었으므로 호출을 설정하는데 사용할 수 있는 다양한 API를 제공합니다. SIP를 포함한 모든 음성 솔루션이 이러한 API를 지원하는 것은 아니기 때문에 WebRTC 게이트웨이는 API 호출을 SIP 메시지로 변환하거나 그 반대로 변환해야 합니다.

그림 2는 고가용성 WebRTC 아키텍처의 디자인 패턴을 보여줍니다. WebRTC 클라이언트에서 들어오는 트래픽은 Auto Scaling Group의 일부인 EC2 인스턴스에서 WebRTC를 실행하는 Amazon 애플리케이션로드 밸런서에 의해 균형이 조정됩니다.

SIP 및 RTP 트래픽의 또 다른 디자인 패턴은 가용 영역 전체의 활성 수동 모드에서 Amazon EC2의 SBC 쌍을 사용하는 것입니다 (그림 3). 여기서 DNS를 사용할 수 없는 장애가 발생하면 인스턴스간에 탄력적 IP 주소를 동적으로 이동할 수 있습니다.

*그림 3 : VPC에서 Amazon EC2를 사용하는 RTC 아키텍처*

AWS의 고가용성 및 확장성

대부분의 실시간 통신 제공 업체는 99.9 % ~ 99.999 %의 가용성을 제공하는 서비스 수준에 따라 조정됩니다. 원하는 고가용성 (HA) 정도에 따라 응용 프로그램의 전체 수명주기에 따라 점점 더 정교한 조치를 취해야 합니다. 강력한 고가용성을 달성하려면 다음 지침을 따르는 것이 좋습니다.

· 단일 장애 지점이 없도록 시스템을 설계하십시오. 상태 비 저장 및 상태 저장 구성 요소 모두에 대해 자동 모니터링, 오류 감지 및 장애 조치 메커니즘 사용

o SPOF (Single Point of Failure)는 일반적으로 N + 1 또는 2N 이중화 구성으로 제거되며, 여기서 활성 + 활성 노드 간의 로드 밸런싱을 통해 N + 1이 달성되고 활성-대기 구성의 한 쌍의 노드가 2N을 달성합니다.

o AWS에는 확장 가능한 로드 밸런싱 클러스터 또는 액티브-스탠바이 쌍 가정과 같은 두 가지 접근 방식을 통해 HA를 달성하는 몇 가지 방법이 있습니다.

· 시스템 가용성을 올바르게 계측하고 테스트하십시오.

· 장애에 대응하고 완화하고 복구하기 위한 수동 메커니즘에 대한 운영 절차를 준비하십시오.

이 섹션에서는 AWS에서 사용할 수 있는 기능을 사용하여 단일 실패 지점을 달성하지 않는 방법에 중점을 둡니다. 특히 이 섹션에서는 플랫폼에서 고가용성 실시간 통신 애플리케이션을 구축 할 수 있는 핵심 AWS 기능 및 디자인 패턴의 하위 세트에 대해 설명합니다.

액티브-스탠바이 상태 저장 서버 간의 HA에 대한 유동 IP 패턴

유동 IP 설계 패턴은 활성 및 대기 하드웨어 노드 쌍 (미디어 서버)간에 자동 장애 조치를 수행하는 잘 알려진 메커니즘입니다. 정적 보조 가상 IP 주소가 활성 노드에 할당됩니다. 활성 노드와 대기 노드 간의 지속적인 모니터링은 장애를 감지합니다. 활성 노드가 실패하면 모니터링 스크립트는 가상 IP를 준비 대기 노드에 할당하고 대기 노드는 기본 활성 기능을 대신합니다. 이러한 방식으로 가상 IP가 활성 노드와 대기 노드 사이에 플로팅 됩니다.

RTC 솔루션에 적용 가능

N 노드의 활성-활성 클러스터와 같이 서비스에 동일한 구성 요소의 여러 활성 인스턴스를 항상 가질 수 있는 것은 아닙니다. 활성 대기 구성은 HA에 가장 적합한 메커니즘을 제공합니다. 예를 들어 미디어 서버 나 회의 서버 또는 SBC 또는 데이터베이스 서버와 같은 RTC 솔루션의 상태 저장 구성 요소는 활성 대기 설정에 적합합니다. SBC 또는 미디어 서버에는 특정 시간에 여러 개의 장기 실행 세션 또는 채널이 활성화되어 있으며 SBC 활성 인스턴스가 실패하는 경우 유동 IP로 인해 클라이언트 측 구성없이 엔드 포인트가 대기 노드에 다시 연결할 수 있습니다.

AWS에서 구현

Amazon EC2 (Amazon Elastic Compute Cloud), Amazon EC2 API, 탄력적 IP 주소 및 보조 프라이빗 IP 주소에 대한 Amazon EC2 지원의 핵심 기능을 사용하여 AWS에서이 패턴을 구현할 수 있습니다.

1. 두 개의 EC2 인스턴스를 시작하여 기본 및 보조 노드의 역할을 맡습니다. 기본 노드는 기본적으로 활성 상태인 것으로 가정합니다.

2. 추가 보조 프라이빗 IP 주소를 기본 EC2 인스턴스에 할당합니다.

3. 가상 IP (VIP)와 유사한 탄력적 IP 주소는 보조 개인 주소와 연결됩니다. 이 보조 개인 주소는 외부 엔드 포인트가 애플리케이션에 액세스하기 위해 사용하는 주소입니다.

4. 보조 IP 주소를 기본 네트워크 인터페이스에 별칭으로 추가하려면 일부 OS 구성이 필요합니다.

5. 애플리케이션이 이 탄력적 IP 주소에 바인딩해야 합니다. Asterisk 소프트웨어의 경우 고급 Asterisk SIP 설정을 통해 바인딩을 구성 할 수 있습니다.

6. 각 노드에서 모니터링 스크립트 (사용자 정의, Linux의 KeepAlive, Corosync 등)를 실행하여 피어 노드의 상태를 모니터하십시오. 현재 활성 노드에 장애가 발생하면 피어는 이 장애를 감지하고 Amazon EC2 API를 호출하여 보조 프라이빗 IP 주소를 자신에게 재 할당합니다.

7. 따라서 보조 개인 IP 주소와 관련된 VIP에서 수신 대기중인 응용 프로그램은 대기 노드를 통해 끝점에서 사용할 수 있게 됩니다.

*그림 4 : 탄력적 IP 주소를 사용하는 상태 저장 EC2 인스턴스 간의 장애 조치*

혜택

이 방법은 EC2 인스턴스, 인프라 또는 애플리케이션 수준에서 장애를 방지하는 안정적인 저예산 솔루션입니다.

한계와 확장성

이 디자인 패턴은 일반적으로 단일 가용 영역 내로 제한됩니다. 두 가용 영역에서 구현할 수 있지만 변형이 가능합니다. 이 경우 유동 탄력적 IP 주소는 사용 가능한 재 연결 탄력적 IP 주소 API를 통해 서로 다른 가용 영역의 활성 노드와 대기 노드간에 다시 연결됩니다. 그림 4에 표시된 장애 조치 구현에서는 진행중인 호출이 삭제되고 엔드 포인트가 다시 연결되어야 합니다. 세션 또는 미디어 연속성에 대한 완벽한 페일 오버를 제공하기 위해 기본 세션 데이터를 복제하여 이 구현을 확장 할 수 있습니다.

WebRTC 및 SIP를 통한 확장성 및 HA에 대한 로드 밸런싱

라운드 로빈, 선호도 또는 대기 시간 등과 같은 미리 정의 된 규칙을 기반으로 활성 인스턴스 클러스터의로드 밸런싱은 HTTP 요청의 상태 비 저장 특성에 의해 널리 보급 된 디자인 패턴입니다. 실제로, 많은 RTC 응용 프로그램 구성 요소의 경우 로드 밸런싱이 실행 가능한 옵션입니다.

로드 밸런서는 원하는 애플리케이션에 대한 요청에 대한 리버스 프록시 또는 진입 점 역할을 하며, 자체적으로 여러 활성 노드에서 동시에 실행되도록 구성됩니다. 특정 시점에 로드 밸런서는 사용자 요청을 정의 된 클러스터의 활성 노드 중 하나에 보냅니다. 로드 밸런서는 대상 클러스터의 노드에 대해 상태 확인을 수행하고 상태 확인에 실패한 노드로 들어오는 요청을 보내지 않습니다. 따라서 로드 밸런싱을 통해 기본적인 고가용성이 달성됩니다. 또한 로드 밸런서는 초 단위 간격으로 모든 클러스터 노드에 대해 능동 및 수동 상태 점검을 수행하므로 장애 조치 시간이 거의 즉각적입니다.

지시 할 노드에 대한 결정은 다음을 포함하여로드 밸런서에 정의 된 시스템 규칙을 기반으로 합니다.

· 라운드 로빈

· 세션 또는 IP 선호도 : 세션 내에서 또는 동일한 IP의 여러 요청이 클러스터의 동일한 노드로 전송되도록합니다.

· 지연 시간 기반

· 부하 기반

RTC 아키텍처의 적용 가능성

WebRTC 프로토콜을 사용하면 Elastic Load Balancing, Application Load Balancer 또는 Network Load Balancer와 같은 HTTP 기반로드 밸런서를 통해 WebRTC 게이트웨이를 쉽게로드 밸런싱 할 수 있습니다. TCP와 UDP를 통한 전송에 의존하는 대부분의 SIP 구현에서는 TCP 및 UDP 기반 트래픽을 모두 지원하는 네트워크 또는 연결 수준로드 밸런싱이 필요합니다.

Application Load Balancer 및 Auto Scaling을 사용하여 AWS for WebRTC에서로드 밸런싱

WebRTC 기반 통신의 경우 Elastic Load Balancing은 완전히 관리되고가용성이 높으며 확장 가능한 로드 밸런서를 제공하여 요청의 진입 점으로 사용 된 다음 Elastic Load Balancing과 관련된 EC2 인스턴스의 대상 클러스터로 전달됩니다. 또한 WebRTC 요청은 상태 비 저장이므로 Amazon EC2 Auto Scaling을 사용하여 완전히 자동화 되고 제어 가능한 확장성, 탄력성 및 고가용성을 제공 할 수 있습니다.

Application Load Balancer는 여러 가용 영역을 사용하여 가용성이 높고 확장 가능한 완전 관리 형로드 밸런싱 서비스를 제공합니다. 이는 장기간 실행되는 TCP 연결을 사용하여 WebRTC 애플리케이션에 대한 신호 및 클라이언트와 서버 간의 양방향 통신을 처리하는 WebSocket 요청의로드 밸런싱을 지원합니다. Application Load Balancer는 또한 컨텐츠 기반 라우팅 및 고정 세션을 지원하여 로드 밸런서 생성 쿠키를 사용하여 동일한 클라이언트에서 동일한 대상으로 요청을 라우팅합니다. 고정 세션을 사용하면 동일한 대상이 요청을 수신하고 쿠키를 사용하여 세션 컨텍스트를 복구 할 수 있습니다.

그림 5는 대상 토폴로지를 보여줍니다.