2016.11.24

벤더 기고 | AWS에서 웹RTC 구동··· '10가지 체크포인트'

Gerald Baldino | Network World
* 본 기고문은 벤더가 작성한 것으로 네트워크월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다.

웹RTC를 이용하면 기업 웹사이트 모바일 애플리케이션에서 실시간 커뮤니케이션 기능을 구현할 수 있도록 한 기술이다. 최근에는 이 솔루션을 클라우드에서 호스팅할 수도 있다. 여기 관련해 감안해야 할 핵심 정보들을 정리했다.

웹사이트 또는 모바일 애플리케이션에 실시간 통신 기능을 포함하려고 알아 보다가 WebRTC를 알게 됐는가? 좋은 시작점이다.

당신은 이후 탄탄한 솔루션을 구축하기 위해서는 백엔드 서비스가 중요하다는 사실을 파악했다. 이제는 AWS를 기반으로 구축된 IaaS 환경에서 클라우드를 이용해 솔루션을 호스팅 하는 것을 검토하고 있다. 좋은 선택이다. 클라우드 서비스 부문을 선도하고 있는 AWS이기에 우선적으로 고려할 만한 이유가 충분하다.

하지만 AWS EC2(Elastic Compute) 인스턴스, S3 버킷(Bucket) 등을 덜컥 구입하기에 앞서 관련된 것들을 정확히 파악하는 것이 중요하다. AWS에 WebRTC를 배치하기 전에 알아야 할 10가지 사항에 관해 알아보도록 하자.

절대적인 완벽을 기대하지 말라. AWS는 프리미엄 인프라 서비스를 제공한다. 기대치를 상회하는 경우가 많지만 완벽을 기대하기엔 무리다. 주기적인 EC2 고장 및 다양한 서비스 지연을 예상해야 한다. 발생할 수 있는 상황을 상정하고 우회할 계획을 수립하면 방심하다가 당하는 일이 없을 것이다.

가용성은 필수다. 이상적인 세계에서는 하나의 서버로 아무런 문제 없이 모두에게 도달할 수 있을 만큼 용량과 속도가 충분하다. 안타깝게도 이는 순수한 환상일 뿐이다. 서비스를 항상 이용 가능하도록 하려면 고장을 염두에 두고 설계하고 중복적인 가용성 구역을 설정해야 한다. 수평 및 수직적으로 원활한 시스템 대체 작동을 계획한다. 이렇게 확보한 중복(redundancy) 영역은 고장 시나리오가 진행되거나 예상치 못한 일이 발생했을 때 다운타임(Downtime)을 방지한다. 언제 해저 광섬유 라인이 손상되거나 정전이 발생할지 알 수 없다.

기억하자. 단일 서비스는 통째로 고장 난다. 그러나 중복적 마이크로 서비스는 고립돼 고장 난다. 적절히 설계한 경우 서비스 중단을 최소화하고 신속하게 복구할 수 있다. 서비스 지연과 예상치 못한 정전을 방지하기 위해 롤링(Rolling) 배치를 고려하자. 그리고 하드웨어를 꼼꼼하게 계획하자! 각 구성품이 멈추는 경우의 영향을 고려하고 대기 행렬 또는 선로 변경을 계획하자.

보안과 가용성은 반대의 개념이다. 아마존이 아키텍처를 안전하게 보호할 것이라고 믿지 말자. 아마존은 하드웨어를 제공하지만 무단 액세스, 데이터 노출, 항상 존재하는 DDoS 공격의 위협으로부터 인프라를 보호하는 것은 자신의 몫이다. AWS는 해커들에게 최고의 표적이기 때문에 고급 위협 캠페인 스캔만큼이나 인스턴스를 보호하는 것도 중요하다는 사실을 기억해야 한다.

기본적인 보안 장치는 충분한 보호를 제공하지 않는다. 가용성이 높은 안전한 서비스를 개발하기 위해서는 서비스 수준이 아니라 개별 연결 수준에서의 신중한 계획이 필요하며, 보안은 가용성의 반대 개념이다.

네트워크 모니터링은 자신의 책임이다. AWS가 제공하는 것과 기타 기성 솔루션을 포함해 전통적인 모니터링 툴은 WebRTC를 효과적으로 모니터링하지 못 한다. 사용자 정의 지표를 제공하는 실시간 네트워크 분석 및 용량 모니터링 시스템을 구성하여 문제 발생 시 신속하게 해결할 수 있도록 할 필요가 있다.

그렇지 않으면 작은 문제를 알아차리지 못해 장기적인 서비스 중단으로 이어질 수 있다. 고객보다 먼저 성능 예상값으로부터의 일탈 추세를 파악하는 것이 요령이다. 웹RTC는 완전히 동작을 멈추기 전에 신호를 보내는 특성이 있다.

AWS가 도움을 줄 수는 있지만 손을 잡아 주지는 않는다. AWS는 기본적으로 고객이 직접 환경을 관리할 것으로 생각한다. 물론 이 기업의 지원 팀은 전반적인 성능, 확장성, 효율성을 높이기 위해 상당한 도움을 제공한다. 필요할 때 망설이지 말고 도움을 청하자. 많은 비용이 발생하는 오류를 방지할 수 있다. 만약을 대비해 BSS(Business Support Subscription)에 투자하는 것도 괜찮다.

그럼에도 불구하고 다량의 트랜잭션(Transaction) 서비스에 제공하는 것과 같은 수준의 안내를 제공할 수는 없을 것이라는 사실을 이해해야 한다.

사용량 경보를 설정하자. 서비스 비용 및 사용량 추적을 위해 ACW(Amazon CloudWatch)를 이용해 청구 경보를 설정하는 것을 고려하자. 그렇지 않으면 갑자기 많은 비용이 청구될 수도 있다. 주의하지 않으면 대역폭 활용과 EC2 인스턴스 운영 비용이 빠르게 증가할 수 있다.

고장 난 기기는 즉시 조치해야 한다. 모든 인스턴스의 클래스가 동등하게 생성되지 않는다. 하드웨어 고장으로 인해 네트워크 문제가 예상치 못하게 발생할 수 있으므로 사양에서 벗어나는 것들을 참고하고 대체하자. 문제가 해결되었다 하더라도 영향을 받은 노드(Node)를 제거하고 새 것을 실행시키자. 그렇지 않으면 기기가 예상치 못하게 다시 고장 날 수 있다. 최고의 인스턴스만 추적하여 선택해야 한다.

사용하는 인스턴스의 적절한 크기를 선택하자. 아마존은 다양한 종류의 컴퓨팅 인스턴스를 제공하며, 이들 각각은 서로 다른 자원 요건 유형에 최적화되어 있다. 프로세서, 네트워크 역량, 메모리 등의 구성이 다양하다.

백엔드 WebRTC 서비스를 위한 만능 옵션은 없다. 다시 한 번 말하지만 자신의 필요에 따라 다르다. 최고의 규형을 찾기 위해 참고하고 시험하며 수정하고 반복할 필요성을 인정해야 한다. 또 일부 인스턴스는 한계가 있다는 사실을 알아야 한다. 예를 들어, 일부 보급형 인스턴스의 경우 CPU 크레디트(Credit) 스키마에 주의할 필요가 있다.

적절한 기술과 적절한 툴. WebRTC가 자신의 필요에 적합한 솔루션인지 확인하는 것도 빼놓을 수 없다. WebRTC는 많은 애플리케이션에 이상적이지만 모든 애플리케이션에 이상적인 것은 아니다.

이를 테면 실시간이 아니라 니어 타임(Near Time)이 요구되는 활용 시나리오에는 WebRTC에 그리 적합하지 않다. 한편 아마존은 유튜브(YouTube) 또는 넷플릭스(Netflix)와 유사한 훌륭한 스트리밍용 솔루션을 제공하고 있다.

PaaS 이용이 더 적합할 수도 있다. 제품 소유자 또는 개발자로써 주된 목적은 사용자를 만족시키고 (많은 경우에) 수익 발생 시간을 단축시키는 훌륭한 제품을 개발하는 것이다. 그러나 AWS에서 플랫폼을 호스팅하면 WebRTC 벤엔드 서비스를 위한 탄탄한 근간을 제공할 수 있지만 DIY확장에 비용과 시간이 많이 소요될 수 있다.

TTM(Time To Market)을 단축하고 제품에 대한 초점을 유지하려면 제 3 PaaS 제공자 활용을 고려할 이유가 충분하다. PaaS 제공자는 실시간 통신 성부 구축 및 유지라는 벅찬 문제를 없애 준다. 위험이 덜하고 TTM이 단축될 것이다.

* Gerald Baldino는 테크놀로지 전문 저술가이자 기고가다. 본 기고문을 후원한 Temasys는 임베디드 실시간 커뮤니케이션 PaaS 기업이다. ciokr@idg.co.kr 



2016.11.24

벤더 기고 | AWS에서 웹RTC 구동··· '10가지 체크포인트'

Gerald Baldino | Network World
* 본 기고문은 벤더가 작성한 것으로 네트워크월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다.

웹RTC를 이용하면 기업 웹사이트 모바일 애플리케이션에서 실시간 커뮤니케이션 기능을 구현할 수 있도록 한 기술이다. 최근에는 이 솔루션을 클라우드에서 호스팅할 수도 있다. 여기 관련해 감안해야 할 핵심 정보들을 정리했다.

웹사이트 또는 모바일 애플리케이션에 실시간 통신 기능을 포함하려고 알아 보다가 WebRTC를 알게 됐는가? 좋은 시작점이다.

당신은 이후 탄탄한 솔루션을 구축하기 위해서는 백엔드 서비스가 중요하다는 사실을 파악했다. 이제는 AWS를 기반으로 구축된 IaaS 환경에서 클라우드를 이용해 솔루션을 호스팅 하는 것을 검토하고 있다. 좋은 선택이다. 클라우드 서비스 부문을 선도하고 있는 AWS이기에 우선적으로 고려할 만한 이유가 충분하다.

하지만 AWS EC2(Elastic Compute) 인스턴스, S3 버킷(Bucket) 등을 덜컥 구입하기에 앞서 관련된 것들을 정확히 파악하는 것이 중요하다. AWS에 WebRTC를 배치하기 전에 알아야 할 10가지 사항에 관해 알아보도록 하자.

절대적인 완벽을 기대하지 말라. AWS는 프리미엄 인프라 서비스를 제공한다. 기대치를 상회하는 경우가 많지만 완벽을 기대하기엔 무리다. 주기적인 EC2 고장 및 다양한 서비스 지연을 예상해야 한다. 발생할 수 있는 상황을 상정하고 우회할 계획을 수립하면 방심하다가 당하는 일이 없을 것이다.

가용성은 필수다. 이상적인 세계에서는 하나의 서버로 아무런 문제 없이 모두에게 도달할 수 있을 만큼 용량과 속도가 충분하다. 안타깝게도 이는 순수한 환상일 뿐이다. 서비스를 항상 이용 가능하도록 하려면 고장을 염두에 두고 설계하고 중복적인 가용성 구역을 설정해야 한다. 수평 및 수직적으로 원활한 시스템 대체 작동을 계획한다. 이렇게 확보한 중복(redundancy) 영역은 고장 시나리오가 진행되거나 예상치 못한 일이 발생했을 때 다운타임(Downtime)을 방지한다. 언제 해저 광섬유 라인이 손상되거나 정전이 발생할지 알 수 없다.

기억하자. 단일 서비스는 통째로 고장 난다. 그러나 중복적 마이크로 서비스는 고립돼 고장 난다. 적절히 설계한 경우 서비스 중단을 최소화하고 신속하게 복구할 수 있다. 서비스 지연과 예상치 못한 정전을 방지하기 위해 롤링(Rolling) 배치를 고려하자. 그리고 하드웨어를 꼼꼼하게 계획하자! 각 구성품이 멈추는 경우의 영향을 고려하고 대기 행렬 또는 선로 변경을 계획하자.

보안과 가용성은 반대의 개념이다. 아마존이 아키텍처를 안전하게 보호할 것이라고 믿지 말자. 아마존은 하드웨어를 제공하지만 무단 액세스, 데이터 노출, 항상 존재하는 DDoS 공격의 위협으로부터 인프라를 보호하는 것은 자신의 몫이다. AWS는 해커들에게 최고의 표적이기 때문에 고급 위협 캠페인 스캔만큼이나 인스턴스를 보호하는 것도 중요하다는 사실을 기억해야 한다.

기본적인 보안 장치는 충분한 보호를 제공하지 않는다. 가용성이 높은 안전한 서비스를 개발하기 위해서는 서비스 수준이 아니라 개별 연결 수준에서의 신중한 계획이 필요하며, 보안은 가용성의 반대 개념이다.

네트워크 모니터링은 자신의 책임이다. AWS가 제공하는 것과 기타 기성 솔루션을 포함해 전통적인 모니터링 툴은 WebRTC를 효과적으로 모니터링하지 못 한다. 사용자 정의 지표를 제공하는 실시간 네트워크 분석 및 용량 모니터링 시스템을 구성하여 문제 발생 시 신속하게 해결할 수 있도록 할 필요가 있다.

그렇지 않으면 작은 문제를 알아차리지 못해 장기적인 서비스 중단으로 이어질 수 있다. 고객보다 먼저 성능 예상값으로부터의 일탈 추세를 파악하는 것이 요령이다. 웹RTC는 완전히 동작을 멈추기 전에 신호를 보내는 특성이 있다.

AWS가 도움을 줄 수는 있지만 손을 잡아 주지는 않는다. AWS는 기본적으로 고객이 직접 환경을 관리할 것으로 생각한다. 물론 이 기업의 지원 팀은 전반적인 성능, 확장성, 효율성을 높이기 위해 상당한 도움을 제공한다. 필요할 때 망설이지 말고 도움을 청하자. 많은 비용이 발생하는 오류를 방지할 수 있다. 만약을 대비해 BSS(Business Support Subscription)에 투자하는 것도 괜찮다.

그럼에도 불구하고 다량의 트랜잭션(Transaction) 서비스에 제공하는 것과 같은 수준의 안내를 제공할 수는 없을 것이라는 사실을 이해해야 한다.

사용량 경보를 설정하자. 서비스 비용 및 사용량 추적을 위해 ACW(Amazon CloudWatch)를 이용해 청구 경보를 설정하는 것을 고려하자. 그렇지 않으면 갑자기 많은 비용이 청구될 수도 있다. 주의하지 않으면 대역폭 활용과 EC2 인스턴스 운영 비용이 빠르게 증가할 수 있다.

고장 난 기기는 즉시 조치해야 한다. 모든 인스턴스의 클래스가 동등하게 생성되지 않는다. 하드웨어 고장으로 인해 네트워크 문제가 예상치 못하게 발생할 수 있으므로 사양에서 벗어나는 것들을 참고하고 대체하자. 문제가 해결되었다 하더라도 영향을 받은 노드(Node)를 제거하고 새 것을 실행시키자. 그렇지 않으면 기기가 예상치 못하게 다시 고장 날 수 있다. 최고의 인스턴스만 추적하여 선택해야 한다.

사용하는 인스턴스의 적절한 크기를 선택하자. 아마존은 다양한 종류의 컴퓨팅 인스턴스를 제공하며, 이들 각각은 서로 다른 자원 요건 유형에 최적화되어 있다. 프로세서, 네트워크 역량, 메모리 등의 구성이 다양하다.

백엔드 WebRTC 서비스를 위한 만능 옵션은 없다. 다시 한 번 말하지만 자신의 필요에 따라 다르다. 최고의 규형을 찾기 위해 참고하고 시험하며 수정하고 반복할 필요성을 인정해야 한다. 또 일부 인스턴스는 한계가 있다는 사실을 알아야 한다. 예를 들어, 일부 보급형 인스턴스의 경우 CPU 크레디트(Credit) 스키마에 주의할 필요가 있다.

적절한 기술과 적절한 툴. WebRTC가 자신의 필요에 적합한 솔루션인지 확인하는 것도 빼놓을 수 없다. WebRTC는 많은 애플리케이션에 이상적이지만 모든 애플리케이션에 이상적인 것은 아니다.

이를 테면 실시간이 아니라 니어 타임(Near Time)이 요구되는 활용 시나리오에는 WebRTC에 그리 적합하지 않다. 한편 아마존은 유튜브(YouTube) 또는 넷플릭스(Netflix)와 유사한 훌륭한 스트리밍용 솔루션을 제공하고 있다.

PaaS 이용이 더 적합할 수도 있다. 제품 소유자 또는 개발자로써 주된 목적은 사용자를 만족시키고 (많은 경우에) 수익 발생 시간을 단축시키는 훌륭한 제품을 개발하는 것이다. 그러나 AWS에서 플랫폼을 호스팅하면 WebRTC 벤엔드 서비스를 위한 탄탄한 근간을 제공할 수 있지만 DIY확장에 비용과 시간이 많이 소요될 수 있다.

TTM(Time To Market)을 단축하고 제품에 대한 초점을 유지하려면 제 3 PaaS 제공자 활용을 고려할 이유가 충분하다. PaaS 제공자는 실시간 통신 성부 구축 및 유지라는 벅찬 문제를 없애 준다. 위험이 덜하고 TTM이 단축될 것이다.

* Gerald Baldino는 테크놀로지 전문 저술가이자 기고가다. 본 기고문을 후원한 Temasys는 임베디드 실시간 커뮤니케이션 PaaS 기업이다. ciokr@idg.co.kr 

X