기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 의 고가용성 및 확장성 AWS
대부분의 실시간 통신 공급자는 99.9%에서 99.999%까지의 가용성을 제공하는 서비스 수준에 부합합니다. 원하는 고가용성(HA)의 정도에 따라 애플리케이션의 전체 수명 주기 동안 점점 더 정교한 조치를 취해야 합니다. AWS는 강력한 고가용성 수준을 달성하기 위해 다음 지침을 따를 것을 권장합니다.
+ 단일 장애 지점이 없도록 시스템을 설계합니다. 상태 비저장 및 상태 저장 구성 요소 모두에 자동 모니터링, 장애 감지 및 장애 조치 메커니즘 사용
+ 단일 장애 지점(SPOF)은 일반적으로 N\$11 또는 2N 중복 구성으로 제거됩니다. 여기서 N\$11은 *활성-활성* 노드 간의 로드 밸런싱을 통해 달성되고 2N은 *활성-대기* 구성의 노드 쌍에 의해 달성됩니다.
+ AWS에는 확장 가능하고 로드 밸런싱된 클러스터를 통하거나 *활성-대기* 페어를 수임하는 등 두 가지 접근 방식을 통해 HA를 달성하는 여러 가지 방법이 있습니다.
+ 시스템 가용성을 올바르게 구성하고 테스트합니다.
+ 수동 메커니즘이 장애에 대응, 완화 및 복구할 수 있도록 운영 절차를 준비합니다.
이 섹션에서는에서 사용할 수 있는 기능을 사용하여 단일 장애 지점을 달성하지 못하는 방법을 중점적으로 다룹니다 AWS. 특히이 섹션에서는 고가용성 실시간 통신 애플리케이션을 구축할 수 있는 핵심 AWS 기능 및 설계 패턴의 하위 집합을 설명합니다.
# 활성-대기 상태 저장 서버 간의 HA에 대한 부동 IP 패턴
부동 IP 설계 패턴은 활성 및 대기 하드웨어 노드 쌍(미디어 서버) 간에 자동 장애 조치를 수행하는 잘 알려진 메커니즘입니다. 정적 보조 가상 IP 주소가 활성 노드에 할당됩니다. 활성 노드와 대기 노드 간의 지속적인 모니터링은 장애를 감지합니다. 활성 노드가 실패하면 모니터링 스크립트가 가상 IP를 대기 노드에 할당하고 대기 노드가 기본 활성 함수를 인계합니다. 이렇게 하면 가상 IP가 활성 노드와 대기 노드 간에 부동됩니다.
## RTC 솔루션의 적용 가능성
N 노드의 활성-활성 클러스터와 같이 동일한 구성 요소의 여러 활성 인스턴스를 서비스에 항상 보유할 수 있는 것은 아닙니다. 활성 대기 구성은 HA에 가장 적합한 메커니즘을 제공합니다. 예를 들어 미디어 서버나 회의 서버 또는 SBC나 데이터베이스 서버와 같은 RTC 솔루션의 상태 저장 구성 요소는 활성 대기 설정에 적합합니다. SBC 또는 미디어 서버에는 특정 시간에 여러 개의 장기 실행 세션 또는 채널이 활성화되어 있으며, SBC 활성 인스턴스가 실패하는 경우 엔드포인트는 부동 IP로 인해 클라이언트 측 구성 없이 대기 노드에 다시 연결할 수 있습니다.
### 의 구현 AWS
Amazon Elastic Compute Cloud(Amazon EC2), Amazon EC2 API, 탄력적 IP 주소의 핵심 기능과 보조 프라이빗 IP 주소에 대한 Amazon EC2 지원을 사용하여 AWS에서이 패턴을 구현할 수 있습니다.
에서 부동 IP 패턴을 구현하려면 AWS:
1. 두 개의 EC2 인스턴스를 시작하여 기본 노드와 보조 노드의 역할을 수임합니다. 여기서 기본 노드는 기본적으로 *활성* 상태로 간주됩니다.
1. 기본 EC2 인스턴스에 추가 보조 프라이빗 IP 주소를 할당합니다.
1. 가상 IP(VIP)와 유사한 탄력적 IP 주소는 보조 프라이빗 주소와 연결됩니다. 이 보조 프라이빗 주소는 외부 엔드포인트에서 애플리케이션에 액세스하는 데 사용하는 주소입니다.
1. 일부 운영 체제(OS) 구성은 보조 IP 주소를 기본 네트워크 인터페이스에 별칭으로 추가하는 데 필요합니다.
1. 애플리케이션은이 탄력적 IP 주소에 바인딩해야 합니다. 별표 소프트웨어의 경우 고급 별표 SIP 설정을 통해 바인딩을 구성할 수 있습니다.
1. 각 노드에서 사용자 지정, Linux 기반 KeepAlive, Corosync 등의 모니터링 스크립트를 실행하여 피어 노드의 상태를 모니터링합니다. 현재 활성 노드가 실패하는 경우 피어는이 실패를 감지하고 Amazon EC2 API를 호출하여 보조 프라이빗 IP 주소를 자신에게 재할당합니다.
따라서 보조 프라이빗 IP 주소와 연결된 VIP에서 수신 대기 중인 애플리케이션은 대기 노드를 통해 엔드포인트에서 사용할 수 있게 됩니다.
![\[탄력적 IP 주소를 사용하여 상태 저장 EC2 인스턴스 간의 장애 조치를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/real-time-communication-on-aws/images/failover-stateful.jpg)
#### 이점
이 접근 방식은 EC2 인스턴스, 인프라 또는 애플리케이션 수준에서 장애가 발생하지 않도록 보호하는 안정적인 저예산 솔루션입니다.
##### 제한 사항 및 확장성
이 설계 패턴은 일반적으로 단일 가용 영역 내에서만 제한됩니다. 두 가용 영역에서 구현할 수 있지만 변형이 있습니다. 이 경우 부동 탄력적 IP 주소는 사용 가능한 탄력적 IP 주소 재연결 API를 통해 서로 다른 가용 영역의 활성 노드와 대기 노드 간에 다시 연결됩니다. 위 그림에 표시된 장애 조치 구현에서는 진행 중인 호출이 삭제되고 엔드포인트가 다시 연결되어야 합니다. 기본 세션 데이터를 복제하여이 구현을 확장하여 세션 또는 미디어 연속성의 원활한 장애 조치를 제공할 수도 있습니다.
#### WebRTC 및 SIP를 통한 확장성 및 HA를 위한 로드 밸런싱
라운드 로빈, 선호도 또는 지연 시간 등과 같은 사전 정의된 규칙을 기반으로 활성 인스턴스의 클러스터를 로드 밸런싱하는 것은 HTTP 요청의 상태 비저장 특성에 의해 널리 사용되는 설계 패턴입니다. 실제로 로드 밸런싱은 RTC 애플리케이션 구성 요소가 많은 경우 실행 가능한 옵션입니다.
로드 밸런서는 여러 활성 노드에서 동시에 실행되도록 구성된 원하는 애플리케이션에 대한 요청의 역방향 프록시 또는 진입점 역할을 합니다. 지정된 시점에서 로드 밸런서는 사용자 요청을 정의된 클러스터의 활성 노드 중 하나로 보냅니다. 로드 밸런서는 대상 클러스터의 노드에 대해 상태 확인을 수행하고 상태 확인에 실패한 노드에 수신 요청을 보내지 않습니다. 따라서 로드 밸런싱을 통해 기본적인 고가용성 수준을 달성할 수 있습니다. 또한 로드 밸런서가 1초 미만의 간격으로 모든 클러스터 노드에 대해 액티브 및 패시브 상태 확인을 수행하기 때문에 장애 조치 시간이 거의 순간적입니다.
지시할 노드에 대한 결정은 다음을 포함하여 로드 밸런서에 정의된 시스템 규칙을 기반으로 합니다.
+ 라운드 로빈
+ 세션 또는 IP 선호도 - 세션 내 또는 동일한 IP의 여러 요청이 클러스터의 동일한 노드로 전송되도록 합니다.
+ 지연 시간 기반
+ 로드 기반
## RTC 아키텍처의 적용 가능성
WebRTC 프로토콜을 사용하면 [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)(ELB), [Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/)(ALB) 또는 Network Load Balancer(NLB)와 같은 HTTP 기반 로드 밸런서를 통해 WebRTC 게이트웨이를 쉽게 로드 밸런싱할 수 있습니다. [ Load Balancer](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/) 대부분의 SIP 구현은 TCP(전송 제어 프로토콜) 및 UDP(사용자 데이터그램 프로토콜)를 통한 전송에 의존하므로 TCP 및 UDP 기반 트래픽 모두에 대한 지원을 통해 네트워크 또는 연결 수준 로드 밸런싱이 필요합니다.
## Application Load Balancer 및 Auto Scaling을 사용한 WebRTC AWS 용 로드 밸런싱 Application Load Balancer
WebRTC 기반 통신의 경우, Elastic Load Balancing은 요청의 진입점 역할을 하는 완전 관리형 고가용성 및 확장 가능한 로드 밸런서를 제공하며, 이는 Elastic Load Balancing과 연결된 EC2 인스턴스의 대상 클러스터로 전달됩니다. WebRTC 요청은 상태 비저장이므로 Amazon EC2 Auto Scaling을 사용하여 완전 자동화되고 제어 가능한 확장성, 탄력성 및 고가용성을 제공할 수 있습니다.
Application Load Balancer는 여러 가용 영역을 사용하여 가용성이 높고 확장 가능한 완전 관리형 로드 밸런싱 서비스를 제공합니다. 이는 WebRTC 애플리케이션에 대한 신호와 장기 실행 TCP 연결을 사용하여 클라이언트와 서버 간의 양방향 통신을 처리하는 WebSocket WebSocket 요청의 로드 밸런싱을 지원합니다. 또한 Application Load Balancer는 콘텐츠 기반 라우팅 및 [고정 세션을](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html) 지원하여 로드 밸런서에서 생성한 쿠키를 사용하여 동일한 클라이언트의 요청을 동일한 대상으로 라우팅합니다. 고정 세션을 활성화하면 동일한 대상이 요청을 수신하고 쿠키를 사용하여 세션 컨텍스트를 복구할 수 있습니다.
다음 그림은 대상 토폴로지를 보여줍니다.
![\[WebRTC 확장성 및 고가용성 아키텍처를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/real-time-communication-on-aws/images/webrtc-scalability.png)
## 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 트래픽 로드 밸런싱에 이상적인 네트워크 로드 밸런싱은 초당 수백만 개의 요청을 처리하면서 지연 시간을 매우 낮게 유지할 수 있습니다. Amazon EC2 Auto Scaling, Amazon [Elastic Container Service](https://aws.amazon.com/ecs/)(Amazon ECS), [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/)(Amazon EKS) 및와 같은 다른 인기 있는 AWS 서비스와 통합됩니다[AWS CloudFormation](https://aws.amazon.com/cloudformation/).
SIP 연결이 시작되면 또 다른 옵션은 [AWS Marketplace](https://aws.amazon.com/marketplace) 상용 off-the-shelf 소프트웨어(COTS)를 사용하는 것입니다. 는 UDP 및 기타 유형의 계층 4 연결 로드 밸런싱을 처리할 수 있는 많은 제품을 AWS Marketplace 제공합니다. COTS에는 일반적으로 고가용성에 대한 지원이 포함되며 일반적으로 Amazon EC2 Auto Scaling과 같은 기능과 통합되어 가용성과 확장성을 더욱 강화합니다. 다음 그림은 대상 토폴로지를 보여줍니다.
![\[AWS Marketplace 제품의 SIP 기반 RTC 확장성을 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/real-time-communication-on-aws/images/sip-based-rtc-scalability.jpg)
# 리전 간 DNS 기반 로드 밸런싱 및 장애 조치
[Amazon Route 53](https://aws.amazon.com/route53/)는 RTC 클라이언트가 미디어 애플리케이션을 등록하고 연결할 수 있도록 퍼블릭 또는 프라이빗 엔드포인트로 사용할 수 있는 글로벌 DNS 서비스를 제공합니다. Amazon Route 53를 사용하면 트래픽을 정상 엔드포인트로 라우팅하거나 애플리케이션의 상태를 독립적으로 모니터링하도록 DNS 상태 확인을 구성할 수 있습니다.
Amazon Route 53 트래픽 흐름 기능을 사용하면 지연 시간 기반 라우팅, 지리적 DNS, 지리 근접성, 가중치가 적용된 라운드 로빈을 비롯한 다양한 라우팅 유형을 통해 트래픽을 전 세계적으로 쉽게 관리할 수 있습니다.이 모든 것을 DNS 장애 조치와 결합하여 지연 시간이 짧고 내결함성이 뛰어난 다양한 아키텍처를 구현할 수 있습니다. Amazon Route 53 트래픽 흐름 단순 시각적 편집기를 사용하면 최종 사용자가 단일 AWS 리전에 있든 전 세계에 분산되어 있든 관계없이 애플리케이션의 엔드포인트로 라우팅되는 방식을 관리할 수 있습니다.
글로벌 배포의 경우 Route 53의 지연 시간 기반 라우팅 정책은 실시간 미디어 교환과 관련된 서비스 품질을 개선하기 위해 미디어 서버의 가장 가까운 존재 지점으로 고객을 안내하는 데 특히 유용합니다.
새 DNS 주소에 장애 조치를 적용하려면 클라이언트 캐시를 플러시해야 합니다. 또한 DNS 변경 사항은 글로벌 DNS 서버로 전파되므로 지연이 발생할 수 있습니다. Time to Live 속성을 사용하여 DNS 조회의 새로 고침 간격을 관리할 수 있습니다. 이 속성은 DNS 정책을 설정할 때 구성할 수 있습니다.
글로벌 사용자에게 빠르게 도달하거나 단일 퍼블릭 IP 사용 요구 사항을 충족하기 위해는 리전 간 장애 조치에도 사용할 AWS Global Accelerator 수 있습니다. [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/?blogs-global-accelerator.sort-by=item.additionalFields.createdDate&blogs-global-accelerator.sort-order=desc&aws-global-accelerator-wn.sort-by=item.additionalFields.postDateTime&aws-global-accelerator-wn.sort-order=desc)는 로컬 및 글로벌 도달 범위를 모두 가진 애플리케이션의 가용성과 성능을 개선하는 네트워킹 서비스입니다.는 단일 또는 여러 AWS 리전의 Application Load Balancer, Network Load Balancer 또는 Amazon EC2 인스턴스와 같이 애플리케이션 엔드포인트에 대한 고정 진입점 역할을 하는 정적 IP 주소를 AWS Global Accelerator 제공합니다. AWS 글로벌 네트워크를 사용하여 사용자의 애플리케이션 경로를 최적화하여 TCP 및 UDP 트래픽의 지연 시간과 같은 성능을 개선합니다.
AWS Global Accelerator 는 애플리케이션 엔드포인트의 상태를 지속적으로 모니터링하고 현재 엔드포인트가 비정상으로 바뀌는 경우 가장 가까운 정상 엔드포인트로 트래픽을 자동으로 리디렉션합니다. 추가 보안 요구 사항을 위해 Accelerated Site-to-Site VPN은를 사용하여 AWS Global Accelerator AWS 글로벌 네트워크 및 AWS 엣지 로케이션을 통해 트래픽을 지능적으로 라우팅하여 VPN 연결의 성능을 개선합니다.
![\[AWS Global Accelerator 또는 Amazon Route 53을 사용한 리전 간 고가용성 설계를 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/real-time-communication-on-aws/images/inter-region-ha-design.png)
# 영구 스토리지를 통한 데이터 내구성 및 HA
대부분의 RTC 애플리케이션은 영구 스토리지를 사용하여 인증, 권한 부여, 회계(세션 데이터, 통화 세부 정보 레코드 등), 운영 모니터링 및 로깅을 위해 데이터를 저장하고 액세스합니다. 기존 데이터 센터에서는 영구 스토리지 구성 요소(데이터베이스, 파일 시스템 등)의 고가용성과 내구성을 보장하려면 일반적으로 스토리지 영역 네트워크(SAN), 독립 디스크 중복 배열(RAID) 설계 및 백업, 복원 및 장애 조치 처리를 위한 프로세스를 설정하여 많은 작업을 수행해야 합니다. 는 데이터 내구성 및 가용성에 대한 기존 데이터 센터 관행을 AWS 클라우드 크게 간소화하고 개선합니다.
객체 스토리지 및 파일 스토리지의 경우 [Amazon Simple Storage Service](https://aws.amazon.com/s3/)(Amazon S3) 및 [Amazon Elastic File System](https://aws.amazon.com/efs/)(Amazon EFS)과 같은 AWS 서비스는 관리형 고가용성 및 확장성을 제공합니다. Amazon S3의 데이터 내구성은 99.999999999%(119)입니다.
트랜잭션 데이터 스토리지의 경우 고객은 고가용성 배포를 통해 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle 및 Microsoft SQL Server를 지원하는 완전관리형 Amazon Relational Database Service(Amazon RDS)를 활용할 수 있습니다. 등록 기관 함수, 구독자 프로필 또는 회계 레코드 스토리지(예: CDRs)의 경우 Amazon RDS는 내결함성, 가용성 및 확장성이 뛰어난 옵션을 제공합니다.
# AWS Lambda, Amazon Route 53 및 Amazon EC2 Auto Scaling을 사용한 동적 조정
AWS 를 사용하면 기능의 체인과 인프라 이벤트를 기반으로 사용자 지정 서버리스 함수를 서비스로 통합할 수 있습니다. RTC 애플리케이션에서 다양한 용도로 사용되는 이러한 설계 패턴 중 하나는 Amazon [Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)Route 53 및 [AWS Lambda](https://aws.amazon.com/lambda/) 함수와 자동 조정 수명 주기 후크의 조합입니다. AWS Lambda 함수는 모든 작업 또는 로직을 포함할 수 있습니다. 다음 그림은 이러한 기능이 함께 연결되어 자동화를 통해 시스템 안정성과 확장성을 개선하는 방법을 보여줍니다.
![\[Amazon Route 53에 대한 동적 업데이트가 포함된 자동 조정을 보여주는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/real-time-communication-on-aws/images/auto-scaling-dynamic-updates.jpg)
# Amazon Kinesis Video Streams를 통한 고가용성 WebRTC
[Amazon Kinesis Video Streams](https://aws.amazon.com/kinesis/video-streams/?nc=sn&loc=0&amazon-kinesis-video-streams-resources-blog.sort-by=item.additionalFields.createdDate&amazon-kinesis-video-streams-resources-blog.sort-order=desc)는 WebRTC를 통한 실시간 미디어 스트리밍을 제공하므로 사용자는 재생, 분석 및 기계 학습을 위해 미디어 스트림을 캡처, 처리 및 저장할 수 있습니다. 이러한 스트림은 가용성과 확장성이 뛰어나며 WebRTC 표준을 준수합니다. Amazon Kinesis Video Streams에는 빠른 피어 검색 및 보안 연결 설정을 위한 WebRTC 신호 엔드포인트가 포함되어 있습니다. 여기에는 NAT용 관리형 세션 순회 유틸리티(STUN)와 피어 간 미디어의 실시간 교환을 위해 NAT(TURN) 엔드포인트 주변의 릴레이를 사용한 순회가 포함됩니다. 또한 카메라 펌웨어와 직접 통합되어 Amazon Kinesis Video Streams 엔드포인트와의 보안 통신을 가능하게 하는 무료 오픈 소스 SDK가 포함되어 있어 피어 검색 및 미디어 스트리밍이 가능합니다. 마지막으로, WebRTC 호환 모바일 및 웹 플레이어가 미디어 스트리밍 및 양방향 통신을 위해 카메라 디바이스를 안전하게 검색하고 연결할 수 있도록 Android, iOS 및 JavaScript용 클라이언트 라이브러리를 제공합니다.
# Amazon Chime Voice Connector를 사용한 고가용성 SIP 트렁킹
[ Amazon Chime Voice Connector](https://docs.aws.amazon.com/chime-sdk/latest/ag/voice-connectors.html)는 기업이 전화 시스템으로 안전하고 저렴한 전화를 걸거나 받을 수 있는 pay-as-you-go SIP 트렁킹 서비스를 제공합니다. Amazon Chime Voice Connector는 서비스 공급자 SIP 트렁크 또는 통합 서비스 디지털 네트워크(ISDN) 기본 속도 인터페이스(PRIs)에 대한 저렴한 대안입니다. 고객은 인바운드 통화, 아웃바운드 통화 또는 둘 다를 활성화할 수 있습니다.
이 서비스는 AWS 네트워크를 사용하여 여러에서 고가용성 통화 환경을 제공합니다 AWS 리전. SIP 트렁킹 전화 통화에서 오디오를 스트리밍하거나 SIP 기반 미디어 레코딩(SIPREC) 피드를 Amazon Kinesis Video Streams로 전달하여 비즈니스 통화에서 실시간으로 인사이트를 얻을 수 있습니다. [Amazon Transcribe](https://aws.amazon.com/transcribe/) 및 기타 일반적인 기계 학습 라이브러리와의 통합을 통해 오디오 분석용 애플리케이션을 빠르게 구축할 수 있습니다.