AWS에서 고가용성 및 확장 가능한 실시간 통신 (RTC) 워크로드 설계를 위한 모범 사례
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Real-Time Communication on AWS (2020년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 2부로 구성되어 있으며 이 글은 2부입니다.
1부 링크 : AWS 기반의 실시간 통신 1/2
Network Load Balancer 또는 AWS Marketplace 제품을 사용한 SIP 구현
SIP 기반 통신의 경우 TCP 또는 UDP를 통해 연결되며 대부분의 RTC 응용 프로그램은 UDP를 사용합니다. SIP / TCP가 선택한 신호 프로토콜 인 경우 완벽하게 관리되고가용성이 높으며 확장 가능하며 성능이 뛰어난 로드 밸런싱을 위해 Network Load Balancer를 사용하는 것이 가능합니다.
Network Load Balancer는 연결 수준 (계층 4)에서 작동하여 IP 프로토콜 데이터를 기반으로 Amazon EC2 인스턴스, 컨테이너 및 IP 주소와 같은 대상으로 연결을 라우팅합니다. TCP 또는 UDP 트래픽 로드 밸런싱에 이상적인 네트워크로드 밸런싱은 초 당 대기 시간을 유지하면서 초당 수백만 건의 요청을 처리 할 수 있습니다. AWS Auto Scaling, Amazon ECS (Amazon Elastic Container Service), Amazon EKS (Amazon Elastic Kubernetes Service) 및 AWS CloudFormation과 같은 널리 사용되는 다른 AWS 서비스와 통합됩니다.
SIP 연결이 시작되면 다른 옵션은 AWS Marketplace 상용 상용 소프트웨어 (COTS)를 사용하는 것입니다. AWS Marketplace는 UDP 및 기타 유형의 레이어 4 연결 로드 밸런싱을 처리 할 수 있는 많은 제품을 제공합니다. 이러한 COTS에는 일반적으로 고가용성에 대한 지원이 포함되며 일반적으로 기능과 통합됩니다.
가용성 및 확장 성을 더욱 향상시키기 위해 AWS Auto Scaling과 같은 그림 6
대상 토폴로지를 보여줍니다.
교차 리전 DNS 기반 로드 균형 조정 및 페일 오버
Amazon Route 53은 RTC 클라이언트가 미디어 애플리케이션을 등록하고 연결할 수 있는 퍼블릭 또는 프라이빗 엔드 포인트로 사용할 수 있는 글로벌 DNS 서비스를 제공합니다. Amazon Route 53을 사용하면 트래픽을 정상 엔드 포인트로 라우팅하거나 애플리케이션의 상태를 독립적으로 모니터링하도록 DNS 상태 확인을 구성 할 수 있습니다. Amazon Route 53 트래픽 흐름 기능을 사용하면 지연 시간 기반 라우팅, 지리 DNS, 지리 근접성 및 가중 라운드 로빈을 포함한 다양한 라우팅 유형을 통해 전 세계적으로 트래픽을 쉽게 관리 할 수 있습니다. 대기 시간이 짧고 내결함성이 있는 다양한 아키텍처. Amazon Route 53 트래픽 흐름 단순 비주얼 편집기를 사용하면 단일 AWS 리전 또는 전 세계에 분포 된 최종 사용자가 애플리케이션의 엔드 포인트로 라우팅 되는 방식을 관리 할 수 있습니다.
글로벌 배포의 경우 Route 53의 대기 시간 기반 라우팅 정책은 미디어 서버가 실시간 미디어 교환과 관련된 서비스 품질을 향상시키기 위해 고객을 가장 가까운 지점으로 안내하는 데 특히 유용합니다.
새 DNS 주소로 장애 조치를 시행하려면 클라이언트 캐시를 플러시 해야합니다. 또한 DNS 변경 내용이 전역 DNS 서버에 전파 될 때 지연 될 수 있습니다. TTL (Time to Live) 속성을 사용하여 DNS 조회의 새로 고침 간격을 관리 할 수 있습니다.
이 속성은 DNS 정책을 설정할 때 구성 할 수 있습니다.
전 세계 사용자에게 빠르게 연락하거나 단일 퍼블릭 IP 사용 요구 사항을 충족하기 위해 AWS Global Accelerator를 리전 간 장애 조치에 사용할 수도 있습니다. AWS Global Accelerator는 로컬 및 글로벌 범위를 가진 애플리케이션의 가용성과 성능을 향상시키는 네트워킹 서비스입니다. AWS Global Accelerator는 단일 또는 여러 AWS 리전의 Application Load Balancer, Network Load Balancer 또는 Amazon EC2 인스턴스와 같은 애플리케이션 엔드 포인트에 대한 고정 진입점 역할을 하는 고정 IP 주소를 제공합니다. AWS 글로벌 네트워크를 사용하여 사용자에서 애플리케이션까지의 경로를 최적화하여 TCP 및 UDP 트래픽의 대기 시간과 같은 성능을 향상시킵니다. AWS Global Accelerator는 애플리케이션 엔드 포인트의 상태를 지속적으로 모니터링하고 현재 엔드 포인트가 비정상으로 바뀌는 경우 트래픽을 가장 가까운 정상 엔드 포인트로 자동 리디렉션합니다. 추가적인 보안 요구 사항을 위해 Accelerated Site-to-Site VPN은 AWS Global Accelerator를 사용하여 AWS 글로벌 네트워크 및 AWS 엣지 로케이션을 통해 트래픽을 지능적으로 라우팅하여 VPN 연결 성능을 향상시킵니다.
영구 스토리지를 통한 데이터 내구성 및 HA
대부분의 RTC 응용 프로그램은 영구 저장소를 사용하여 인증, 권한 부여, 계정 (세션 데이터, 통화 정보 레코드 등), 운영 모니터링 및 로깅을 위해 데이터를 저장하고 액세스합니다. 기존의 데이터 센터에서 영구 스토리지 구성 요소 (데이터베이스, 파일 시스템 등)의 고가용성 및 내구성을 보장하려면 일반적으로 SAN, RAID 설계 및 백업, 복원 및 장애 조치 처리를 위한 프로세스를 설정하여 많은 양의 작업이 필요합니다. . AWS 클라우드는 데이터 내구성 및 가용성과 관련된 기존 데이터 센터 관행을 크게 단순화하고 향상시킵니다.
객체 스토리지 및 파일 스토리지의 경우 Amazon Simple Storage Service (Amazon S3) 및 Amazon Elastic File System (Amazon EFS)과 같은 AWS 서비스는 관리되는 고가용성 및 확장성을 제공 합니다. Amazon S3의 데이터 내구성은 99.999999999%입니다.
트랜잭션 데이터 스토리지의 경우 고객은 고가용성 배포 환경에서 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle 및 Microsoft SQL Server를 지원하는 완전 관리 형 Amazon Relational Database Service (Amazon RDS)를 활용할 수 있습니다. 등록자 기능, 가입자 프로파일 또는 계정 레코드 저장 (예 : CDR)의 경우 Amazon RDS는 내결함성, 고가용성 및 확장 가능한 옵션을 제공합니다.
AWS Lambda, Amazon Route 53 및 AWS Auto Scaling을 사용한 동적 확장
AWS는 기능을 체인화 하고 맞춤형 서버리스 기능을 인프라 이벤트를 기반으로 하는 서비스로 통합 할 수 있습니다. RTC 애플리케이션에서 다양한 용도로 사용되는 이러한 디자인 패턴 중 하나는 자동 스케일링 수명주기 후크와 Amazon CloudWatch Events, Amazon Route 53 및 AWS Lambda 기능의 조합입니다. AWS Lambda 함수는 모든 작업 또는 논리를 포함 할 수 있습니다. 그림 8은 이러한 기능들이 서로 연결되어 자동화로 시스템 안정성과 확장 성을 향상시키는 방법을 보여줍니다.
Kinesis 비디오 스트림을 갖춘 고가용성 WebRTC
Amazon Kinesis Video Streams는 WebRTC를 통해 실시간 미디어 스트리밍을 제공하여 사용자가 미디어 스트림을 캡처, 처리 및 저장하여 재생, 분석 및 기계 학습을 수행 할 수 있습니다. 이 스트림은 가용성이 높고 확장 가능하며 WebRTC 표준을 준수합니다. Amazon Kinesis 비디오 스트림에는 빠른 피어 검색 및 안전한 연결 설정을 위한 WebRTC 신호 엔드 포인트가 포함되어 있습니다. 여기에는 STUN (Managed Session Traversal Utilities) 및 피어 간의 미디어 교환을 위한 NAT (TURN) 주변 릴레이 사용 (TURN) 엔드 포인트를 통한 통과를 포함합니다. 또한 카메라 펌웨어와 직접 통합되는 무료 오픈 소스 SDK가 포함되어 Kinesis Video Streams 엔드 포인트와 안전하게 통신 할 수 있어 피어 검색 및 미디어 스트리밍이 가능합니다. 마지막으로, WebRTC 호환 모바일 및 웹 플레이어가 미디어 스트리밍 및 양방향 통신을 위해 카메라 장치를 안전하게 검색하고 연결할 수 있도록 하는 Android, iOS 및 JavaScript 용 클라이언트 라이브러리를 제공합니다.
Amazon Chime Voice Connector를 통한 고가용성 SIP 트렁킹
Amazon Chime Voice Connector는 회사가 전화 시스템으로 안전하고 저렴한 전화를 걸거나 받을 수 있도록 하는 종량제 SIP 트렁크 서비스를 제공합니다. Amazon Chime Voice Connector는 서비스 제공 업체 SIP 트렁크 또는 ISDN (Integrated Services Digital Network) PRI (primary Rate Interface)의 저렴한 대안입니다. 고객은 인바운드 통화, 아웃 바운드 통화 또는 둘 다 활성화 할 수 있습니다. 이 서비스는 AWS 네트워크를 활용하여 여러 AWS 리전에서 고가용성 통화 경험을 제공합니다. SIP 직통 전화 또는 SIPREC (Forward SIP-based Media Recording) 피드에서 Amazon Kinesis 비디오 스트림으로 오디오를 스트리밍하여 실시간으로 비즈니스 콜로부터 통찰력을 얻을 수 있습니다. Amazon Transcribe 및 기타 일반적인 기계 학습 라이브러리와의 통합을 통해 오디오 분석을 위한 애플리케이션을 신속하게 구축 할 수 있습니다.
현장에서 모범 사례
이 섹션은 대규모 실시간 SIP (Session Initiation Protocol) 워크로드를 실행하는 최대 규모의 가장 성공적인 AWS 고객이 구현한 모범 사례를 요약합니다. 퍼블릭 클라우드에서 자체 SIP 인프라를 실행하려는 AWS 고객은 여러 가지 유형의 장애 발생시 시스템의 안정성과 복원력을 향상시키는 데 도움이 되므로 이러한 모범 사례가 중요하다는 것을 알게 될 것입니다. 이러한 모범 사례 중 일부는 SIP별로 다르지만 대부분은 AWS에서 실행되는 모든 실시간 통신 애플리케이션에 적용 할 수 있습니다.
SIP 오버레이 생성
AWS는 서로 다른 리전간에 연결을 제공하는 강력하고 확장 가능하며 중복되는 네트워크 백본을 보유하고 있습니다. 파이버 컷과 같은 네트워크 이벤트가 AWS 백본 링크의 성능을 저하 시키면 BGP와 같은 네트워크 수준 라우팅 프로토콜을 사용하여 중복 경로로 트래픽이 빠르게 페일 오버됩니다. 이 네트워크 수준 트래픽 엔지니어링은 AWS 고객에게 블랙 박스이며 대부분의 경우 이러한 장애 조치 이벤트를 인식하지 못합니다. 그러나 음성, 고품질 비디오 및 짧은 대기 시간 메시징과 같은 실시간 작업을 실행하는 고객은 때때로 이러한 이벤트를 인지합니다. 그렇다면 AWS 고객은 어떻게 네트워크 수준에서 AWS가 제공하는 것 위에 자체 트래픽 엔지니어링을 구현할 수 있습니까? 이 솔루션은 여러 다른 AWS 리전에 SIP 인프라를 구축하고 있습니다. 통화 제어 기능의 일부로 SIP는 특정 SIP 프록시를 통해 통화를 라우팅하는 기능도 제공합니다.
그림 9에서 SIP 인프라 (녹색 점으로 표시)는 미국 네 지역 모두에서 실행 중입니다. 파란색 선은 AWS 백본의 가상의 묘사를 나타냅니다. SIP 라우팅이 구현되지 않은 경우 미국 서해안에서 시작하여 미국 동부 해안으로 향하는 통화는 오레곤과 버지니아 지역을 직접 연결하는 백본 링크를 통과합니다. 다이어그램은 고객이 네트워크 수준 라우팅을 재정의하고 SIP 라우팅을 사용하여 캘리포니아를 통해 라우팅되는 오레곤과 버지니아간에 동일한 통화 하는 방법을 보여줍니다. 이 유형의 SIP 트래픽 엔지니어링은 SIP 재전송 및 고객 별 비즈니스 선호도와 같은 네트워크 메트릭을 기반으로 SIP 프록시 및 미디어 게이트웨이를 사용하여 구현할 수 있습니다.
상세 모니터링 수행
실시간 음성 및 비디오 응용 프로그램의 최종 사용자는 기존 전화 통신 서비스와 동일한 수준의 성능을 기대합니다. 따라서 응용 프로그램에 문제가 발생하면 공급자의 평판이 떨어집니다. 사후 대응보다는 사전 대응을 위해서는 최종 사용자에게 서비스를 제공하는 시스템의 모든 부분에 세부 모니터링을 배치해야합니다.
SIP / RTP 트래픽을 모니터링하는 데 사용할 수 있는 iPerf 또는 SIPp 및 VOIPMonitor와 같은 많은 오픈 소스 도구를 사용할 수 있습니다. 앞의 예에서 클라이언트 및 서버 모드에서 SIPp를 실행하는 노드는 4 개의 미국 AWS 리전 간 성공적인 호출 및 SIP 재전송과 같은 SIP 지표를 측정하고 있습니다. 그런 다음 사용자 지정 스크립트를 사용하여 이러한 지표를 Amazon CloudWatch로 내보낼 수 있습니다. CloudWatch를 사용하여 고객은 특정 임계 값을 기반으로 이러한 사용자 지정 지표에 대한 경보를 생성 할 수 있습니다. 그런 다음 이러한 CloudWatch 경보의 상태에 따라 자동 또는 수동 수정 작업을 수행 할 수 있습니다.
맞춤형 모니터링 시스템을 개발하고 유지 관리하는 데 필요한 엔지니어링 리소스를 할당하지 않으려는 고객을 위해 ThousandEyes와 같은 다양한 VoIP 모니터링 솔루션이 시장에 나와 있습니다. 교정 조치의 예는 증가 된 SIP 재전송에 따라 SIP 라우팅을 변경하는 것입니다.
장애 조치를 위한 부하 분산 및 유동 IP에 DNS 사용
DNS SRV 기능을 지원하는 IP 텔레포니 클라이언트는 여러 SBC / PBX에 클라이언트를 로드 밸런싱하여 인프라에 내장 된 중복성을 효율적으로 사용할 수 있습니다.
그림 11은 고객이 SRV 레코드를 사용하여 SIP 트래픽의 부하를 분산시키는 방법을 보여줍니다. SRV 표준을 지원하는 모든 IP 텔레포니 클라이언트는 SRV 유형 DNS 레코드에서 sip ._ <transport protocol> 접두사를 찾습니다. 이 예에서 DNS의 답변 섹션에는 다른 AWS 가용 영역에서 실행중인 두 PBX가 모두 포함되어 있습니다. 그러나 SRV 레코드에는 끝점 URI 외에도 세 가지 추가 정보가 포함됩니다.
· 첫 번째 숫자는 우선 순위입니다 (위 예에서 1). 우선 순위가 낮을수록 선호됩니다.
· 두 번째 숫자는 무게입니다 (위 예에서 10).
· 세 번째 숫자는 사용할 포트입니다 (5060).
우선 순위는 두 PBX 서버 모두에 대해 동일하므로 (1), 클라이언트는 가중치를 사용하여 두 PBX 사이의 로드 밸런스를 수행합니다. 이 경우 가중치가 동일하므로 SIP 트래픽은 두 PBX간에 동일하게 로드 밸런싱되어야 합니다.
DNS는 클라이언트로드 밸런싱에 좋은 솔루션이 될 수 있지만 DNS ‘A’레코드를 변경 / 업데이트하여 페일 오버를 구현하는 것은 어떻습니까? 이 방법은 클라이언트와 중간 노드 내에서 DNS 캐싱 동작에 불일치가 있기 때문에 권장하지 않습니다. SIP 노드 클러스터 간의 AZ 내부 장애 조치에 대한 더 나은 접근 방법은 EC2 API를 사용하여 손상된 호스트의 IP 주소가 정상 호스트에 즉시 재 할당되는 EC2 IP 재 할당을 사용하는 것입니다. 상세 모니터링 및 상태 확인 솔루션과 함께 장애가 발생한 노드의 IP 재 할당은 최종 사용자 중단을 최소화하는 적시에 트래픽이 정상적인 호스트로 이동되도록 합니다.
여러 가용 영역 사용
각 AWS 리전은 별도의 가용 영역으로 세분됩니다. 각 가용 영역에는 자체 전원, 냉각 및 네트워크 연결이 있으므로 격리 된 장애 도메인을 형성합니다. AWS 구성 내에서는 항상 고객이 둘 이상의 가용 영역에서 워크로드를 실행하는 것이 좋습니다. 이를 통해 고객 응용 프로그램이 전체 가용 영역 장애를 견뎌 낼 수 있습니다. 이 권장 사항은 실시간 SIP 인프라에도 적용됩니다.
카테고리 5 허리케인과 같은 치명적인 이벤트로 인해 us-east-1 지역에서 가용 영역이 완전히 중단되었다고 가정 해 봅시다. 다이어그램에 표시된 대로 인프라가 실행되면 장애가 발생한 가용 영역의 노드에 원래 등록 된 모든 SIP 클라이언트가 가용 영역 # 2에서 실행중인 SIP 노드에 다시 등록해야 합니다. SIP 클라이언트 / 전화로 이 동작을 테스트하여 지원되는지 확인하십시오. 가용 영역 중단 시 활성 SIP 통화는 손실되지만 새 통화는 가용 영역 # 2를 통해 라우팅 됩니다.
요약하면 DNS SRV 레코드는 클라이언트가 각 가용 영역에 하나씩 여러 개의 ‘A’레코드를 가리켜 야합니다. 이러한 각 ‘A’레코드는 가용 영역 내 및 AZ 간 복원력을 모두 제공하는 가용 영역에 있는 SBC / PBX의 여러 IP 주소를 가리켜 야합니다. IP가 공용 인 경우 IP 재 할당을 사용하여 인프라 및 AZ 간 페일 오버를 모두 구현할 수 있습니다. 그러나 가용 영역에서 개인 IP를 재 할당 할 수 없습니다. 고객이 개인 IP 주소 지정을 사용하는 경우 AZ 간 장애 조치를 위해 백업 SBC / PBX에 다시 등록하는 SIP 클라이언트에 의존해야 합니다.
하나의 가용 영역 내에 트래픽을 유지하고 EC2 배치 그룹 사용
가용 영역 선호도라고도하는이 모범 사례는 전체 가용 영역 오류가 발생하는 드문 경우에도 적용됩니다. 한 가용 영역에 들어가는 SIP 또는 RTP 트래픽이 리전을 종료 할 때까지 해당 가용 영역에 남아 있도록 AZ 간 트래픽을 제거하는 것이 좋습니다.
그림 13은 가용 영역 선호도를 사용하는 단순화 된 아키텍처를 보여줍니다. 전체 가용 영역 중단의 영향을 설명하는 경우이 방법의 비교 이점이 분명해집니다. 다이어그램에 표시된 것처럼 가용 영역 # 2가 손실되면 활성 통화의 50 %가 최대 영향을 받습니다 (가용 영역간에 동일한 로드 밸런싱 가정). 가용 영역 선호도가 구현되지 않은 경우 일부 통화는 한 지역의 가용 영역간에 흐르고 실패는 활성 통화의 50 % 이상에 영향을 줄 수 있습니다.
또한 트래픽 대기 시간을 최소화하기 위해 각 가용 영역 내에서 EC2 배치 그룹을 사용하는 것이 좋습니다. 동일한 EC2 배치 그룹 내에서 시작된 인스턴스는 EC2가 서로에 대해 이러한 인스턴스의 네트워크 근접성을 보장하므로 대역폭이 높고 대기 시간이 줄어 듭니다.
향상된 네트워킹 EC2 인스턴스 유형 사용
Amazon EC2에서 올바른 인스턴스 유형을 선택하면 시스템 안정성과 효율적인 인프라 사용이 보장됩니다. EC2는 다양한 사용 사례에 맞게 최적화 된 다양한 인스턴스 유형을 제공합니다. 인스턴스 유형은 CPU, 메모리, 스토리지 및 네트워킹 용량의 다양한 조합으로 구성되며 애플리케이션에 적합한 리소스 조합을 선택할 수 있는 유연성을 제공합니다. 이러한 향상된 네트워킹 인스턴스 유형은 실행중인 SIP 워크로드가 일관된 대역폭에 액세스하고 상대적으로 낮은 총 대기 시간을 갖도록 합니다. 최근 Amazon EC2에 추가 된 것은 최대 100Gbps의 대역폭을 제공하는 Elastic Network Adapter (ENA)의 가용성입니다. EC2 인스턴스 유형 및 관련 기능의 최신 카탈로그는 EC2 인스턴스 유형 페이지에서 찾을 수 있습니다.
대부분의 고객에게 최신 컴퓨팅 최적화 인스턴스는 비용 대비 최고의 가치를 제공해야합니다. 예를 들어 C5N은 초당 수백만 개의 패킷 (PPS)으로 최대 100Gbps의 대역폭으로 새로운 Elastic Network Adapter를 지원합니다. 대부분의 실시간 응용 프로그램은 네트워크 패킷 처리를 크게 향상시킬 수 있는 인텔 DPDK (Data Plane Developer Kit)를 사용하면 도움이 됩니다.
그러나 요구 사항에 따라 다양한 EC2 인스턴스 유형을 벤치마킹하여 가장 적합한 인스턴스 유형을 확인하는 것이 좋습니다.
벤치마킹을 통해 특정 인스턴스 유형이 한 번에 처리 할 수 있는 최대 호출 수와 같은 다른 구성 매개 변수를 찾을 수도 있습니다.
보안 고려 사항
RTC 애플리케이션 구성 요소는 일반적으로 Amazon EC2 인스턴스가있는 인터넷에서 직접 실행됩니다. TCP 외에도 흐름은 UDP 및 SIP와 같은 프로토콜을 사용합니다. 이 경우 AWS Shield Standard는 UDP 리플렉션 공격, DNS 리플렉션, NTP 리플렉션, SSDP 리플렉션 등과 같은 일반적인 인프라 계층 (Layer 3 및 4) DDoS 공격으로부터 Amazon EC2 인스턴스를 보호합니다. AWS Shield Standard는 우선 순위 기반 트래픽 형성과 같은 다양한 기술을 사용하여 잘 정의 된 DDoS 공격 서명이 탐지 될 때 자동으로 참여합니다.
또한 AWS는 탄력적 IP 주소에서 AWS Shield Advanced를 활성화하여 이러한 애플리케이션에 대한 대규모의 정교한 DDoS 공격에 대한 고급 보호 기능을 제공합니다. AWS Shield Advanced는 강화 된 DDoS 탐지 기능을 제공하여 AWS 리소스 유형과 EC2 인스턴스 크기를 자동으로 감지하고 SYN 또는 UDP 서비스 장애로부터 보호하여 사전 정의 된 적절한 완화 조치를 적용합니다. 고객은 AWS Shield Advanced를 사용하여 24x7 AWS DDoS 대응 팀 (DRT)에 참여하여 자체 맞춤형 완화 프로파일을 생성 할 수도 있습니다. 또한 AWS Shield Advanced는 DDoS 공격 중에 모든 Amazon VPC 네트워크 액세스 제어 목록 (ACL)이 AWS 네트워크의 경계에 자동으로 적용되어 대량의 DDoS 공격을 완화하기 위한 추가 대역폭 및 스크러빙 용량에 대한 액세스를 제공합니다.
결론
AWS (Amazon Web Services)에 RTC (실시간 통신) 워크로드를 배포하여 주요 요구 사항을 충족하면서 확장성, 탄력성 및 고가용성을 달성 할 수 있습니다. 현재 여러 고객이 AWS, 파트너 및 오픈 소스 솔루션을 사용하여 비용을 줄이고 민첩성을 높이고 글로벌 풋 프린트를 줄인 RTC 워크로드를 실행하고 있습니다.
이 백서에서 제공하는 참조 아키텍처 및 모범 사례를 통해 고객은 AWS에서 RTC 워크로드를 성공적으로 설정하고 최종 사용자 요구 사항을 충족하도록 클라우드를 최적화하면서 솔루션을 최적화 할 수 있습니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
