소개

쿠버네티스 환경에서 다양한 서비스 개발/운영 경험을 바탕으로 생성형 AI Use Case 발굴을 위한 Pilot 프로젝트를 진행하고자 합니다.

이를 위해 Cloud Native 기반 기술을 활용하여 생성형 AI 기술과 연동하기 위한 WebRTC 기반의 인스턴스 메신저 서비스 (ex: Discord)를 개발하고,

이를 지탱하기 위한 플랫폼으로써 쿠버네티스 환경에서의 DevOps 기술에 대해 소개합니다.

향후 이러한 메신저 서비스를 에이전트로 활용하여 생성형 AI 서비스와 연계하기 위한 인터페이스로 확장해 나갈 계획입니다.

향후 소개할 목차는 다음과 같으며 첫 걸음으로 WebRTC 소개를 시작합니다.

이어질 목차는 꾸준히 개발/운영하면서 관련 기술문서 올릴 예정입니다.

향후 목차

• WebRTC 소개

• Cloud Native 기반 WebRTC 아키텍처 설계

• Kubernetes 클러스터 구축

• Istio (Service Mesh) 를 이용한 Web RTC Traffic Management 활용 방안

• WebRTC 서비스 개발 (MERN Stack MongoDB, Express, React, NodeJS)

• GitOps Pattern 을 이용한 CI/CD (ArgoCD)

• 서비스 통합 모니터링 (Grafana & Prometheus)

WebRTC 소개

WebRTC는 웹 기반의 실시간 음성, 영상 및 데이터 통신을 제공하는 오픈 소스 프로젝트 입니다.

WebRTC를 사용하면 브라우저에서 플러그인이나 어플리케이션 설치 없이, 다른 사용자와 실시간 연결하여 채팅, 화상 회의, 파일 공유 등의 서비스를 제공할 수 있습니다.

WebRTC는 Google, Mozilla, Opera 등의 브라우저 업체와 IETF, W3C 등의 표준화 기구에서 지원하고 있으며, 이를 이용한 다양한 서비스가 개발되고 있습니다.

WebRTC는 주로 JavaScript와 HTML5를 이용하여 개발되며, 사용하기 쉽고 빠른 응답 시간을 보장합니다.

또한, P2P(Peer-to-Peer) 기술을 이용하기 때문에 중간 서버를 거치지 않아 높은 보안성과 저렴한 비용을 제공합니다.

WebRTC는 현재 다양한 분야에서 활용되고 있으며, 브라우저 기반의 음성, 영상 통화 서비스 뿐만 아니라, IoT, AR/VR 등의 새로운 분야에서도 활용 가능합니다.

WebRTC 주요기능

1. 실시간 음성/영상 통신

WebRTC는 브라우저 상에서 플러그인이나 어플리케이션의 설치 없이 두 사용자 간 실시간 화상 회의나 음성 통화를 제공할 수 있습니다.

이를 통해 음성, 영상과 같은 멀티미디어 데이터는 P2P 통신을 통해 Low Latency 제공하여 지연 없이 빠르게 상대방과 커뮤니케이션이 가능합니다.

2. 데이터 채널

WebRTC는 데이터 채널을 통해 브라우저 간에 데이터를 전송할 수 있습니다. 이는 파일 전송, 채팅 등 다양한 용도로 활용될 수 있습니다.

3. NAT Traversal

WebRTC는 NAT(Network Address Translation) Traversal 기술을 이용하여 중간 서버 없이 P2P 연결을 구성할 수 있습니다. 이를 통해 높은 보안성과 저렴한 비용을 제공합니다.

4. 확장성

WebRTC는 다양한 플랫폼과 브라우저를 지원하며, 다양한 기능을 확장할 수 있습니다. 이를 통해 다양한 분야에서 활용이 가능합니다.

WebRTC 아키텍처

WebRTC 아키텍처는 크게 3가지로 구성됩니다.

1. Application

Application은 WebRTC를 이용하여 개발된 응용 프로그램입니다.

브라우저에서 실행 되며, JavaScript API를 이용하여 미디어 스트림을 제어하고, 데이터 채널을 생성하고, P2P 연결을 설정합니다.

2. Signaling

Signaling은 WebRTC를 이용한 응용 프로그램에서 P2P 연결을 설정하기 위한 메타 데이터를 교환하는 과정입니다.

Signaling은 미디어 스트림, ICE(Interactive Connectivity Establishment) 정보, 코덱 정보 등의 메타 데이터를 교환하며, 이를 통해 브라우저 간에 P2P 연결을 설정합니다.

3. STUN/TURN Server

STUN/TURN Server는 WebRTC에서 P2P 연결을 설정하기 위해 사용되는 중간 서버입니다.

NAT Traversal을 위한 STUN(Session Traversal Utilities for NAT) 서버와, 브라우저 간에 P2P 연결이 불가능할 경우 릴레이 서버 역할을 수행하는 TURN(Traversal Using Relays around NAT) 서버로 구성됩니다.

Signalig 기술

WebRTC 기술은 P2P 통신에 최적화가 되어 있습니다.

WebRTC에 사용되는 기술은 여러 가지가 있지만 크게 3가지의 클래스에 의해서 실시간 데이터 교환이 일어납니다.

• MediaStream — 카메라와 마이크 등의 데이터 스트림 접근

• RTCPeerConnection — 암호화 및 대역폭 관리 및 오디오, 비디오의 연결 (Signaling 과정)

• RTCDataChannel — 일반적인 데이터의 P2P 통신

이 3가지의 객체를 통해서 데이터 교환이 이뤄지며 RTCPeerConnection들이 적절하게 데이터를 교환할 수 있게 처리해 주는 과정을 시그널링(Signaling)이라고 합니다.

WebRTC 주요 네트워크 기술

NAT (Network Address Translation)

WebRTC P2P 통신을 위해 각 디바이스는 자신의 고유한 이름을 통해서 통신해야 합니다. 이 고유한 이름이 Public IP 입니다.

Public IP는 정적(static) 동적(dynamic) IP 가 있기 때문에 상황에 따라서는 디바이스를 식별할 수 있는 고유한 값이 될 수도 있고, 안될 수도 있습니다.

더 나아가 회사망/내부망(LAN) 환경은 Private IP 망이기 때문에 복잡한 네트워크 환경에서 연결된 각 다비이스가 P2P 연결이 가능하기 위해서는 Public IP 가 반드시 필요하고,

디바이스와 Public IP 관계를 맵핑시키기 위한 NAT 기술이 필요합니다.

NAT(Network Address Translation)은 사설 IP 주소를 공용 IP 주소로 변환하여 인터넷에 연결하는 기술입니다. NAT는 이를 이용하여 사설 네트워크에서 인터넷을 사용할 수 있도록 합니다.

NAT를 사용하면 사설 IP 주소를 여러 대의 컴퓨터에서 공유할 수 있기 때문에, 보안성이 향상되고 IP 주소의 부족 문제를 해결할 수 있습니다.

NAT는 주로 가정에서 사용되며, 공공 장소나 기업에서는 공인 IP 주소를 사용합니다.

하지만, WebRTC 는 P2P 통신을 위해 Peer 의 Public IP를 알고 있어야 하지만,

NAT 환경에서 클라이언트가 외부 퍼블릭망으로 요청을 전송할 때마다 Private IP → Public IP NAT 변환 과정에서 Public IP 는 언제든지 변경 되어 WebRTC P2P 통신에 많은 문제를 야기시킬 수 있습니다.

결국 네트워크는 NAT, FW, Router 다양한 네트워크 장비들이 혼재되어 있고, 이러한 구조에서 WebRTC P2P 통신을 가능하게 하기 위한 근본적인 해결책으로 STUN, TURN 를 활용할 수 있습니다.

ICE (Interactive Connectivity Establishment)

WebRTC의 ICE(Interactive Connectivity Establishment) Agent는 NAT(Network Address Translation) Traversal을 위한 기술입니다.

쉽게 설명하면 ICE는 Peer 가 서로 통신할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임워크 입니다.

ICE Agent는 브라우저에서 사용 가능한 IP 주소와 포트를 수집하고, 미디어 스트림을 전송하기 위해 브라우저 간에 P2P 연결을 설정하는 과정에서 이를 사용합니다.

또한, ICE Agent는 NAT Traversal을 위해 STUN(Session Traversal Utilities for NAT) 서버와 TURN(Traversal Using Relays around NAT) 서버를 사용할 수 있습니다.

STUN 서버는 브라우저가 공용 IP 주소와 포트를 얻을 수 있도록 도와줍니다. TURN 서버는 브라우저 간에 직접적인 연결이 불가능할 경우, 릴레이 서버 역할을 수행하여 데이터 전송을 가능하게 합니다.

ICE를 사용하는 이유는 다음과 같습니다.

• 모든 단말은 각자의 네트워크 환경 (학교 내부망, 사내망, 홈네트워크 등..) 다양하기 때문에 P2P 통신을 위한 네트워크가 단순하게 연결되지 않는다.

• 방화벽이 존재하는 환경에서는 방화벽 룰 설정을 통해 트래픽이 통과해야 하고, Public IP가 없다면 NAT IP 를 할당해야 하고, 라우터가 P2P 연결을 허용하지 않을 때는 별도의 Relay 서버가 필요하다.

ICE 를 이용하면 각 Peer 환경에서 NAT 통신을 위해 필요한 모든 포트를 오픈하고, P2P 통신을 위한 엔드포인트 Public IP, Port 정보를 모두 스캐닝하여 가지게 됩니다.

결국 위 그림처럼 WebRTC P2P 통신을 위한 워크플로우는 다음과 같습니다.

1. 각 Peer 브라우저 환경에서 getUserMedia() API를 이용하여 미디어 스트림(Audio, Video) 캡쳐

2. RTCPeerConnection을 통해 P2P 연결을 설정

3. Signlaing 프로토콜을 통해 브라우저 간 세션 설정을 위한 메타 데이터를 교환

4. 미디어 스트리밍 데이터를 중간 서버를 거치지 않고, STUN or Turn 서버를 통해 P2P 전송

STUN (Session Traveral Utilities for NAT)

ICE 는 각 Peer 브라우저 환경에서 P2P 통신이 가능한 네트워크 환경을 스캐닝 하여 Public IP, Port 정보를 STUN 서버로 전송하고,

STUN 서버는 P2P 통신이 가능한 Public IP 주소를 맵핑/관리함으로써 P2P 통신 시, Remote Peer의 Public IP 를 전송하는 역할을 수행합니다.

즉, STUN은 P2P 연결을 확인하고, NAT 바인딩을 유지하기 위한 P2P 연결 유지 프로토콜로 활용합니다.

TURN (Traversal Usgin Relay around NAT)

NAT 보안 정책이 엄격한 곳이나 Router 장비에서 P2P 통신을 제한하는 경우에는 STUN 서버가 완벽한 해결책이 될 수 없습니다.

이 경우 STUN 서버의 확장하여 Relay 기능을 제공하는 TRUN 서버를 활용할 수 있습니다.

각 사설 로컬 네트워크 망에 존재하는 Peer 들은 TURN 서버를 통해 Remote Public IP 를 확인하고,

Peer 들 간에 직접 통신하는게 아니라, Relay 서버 TURN 서버를 통해 경유합니다.

TURN 서버는 복잡하고, 보안이 강화된 네트워크 환경에서도 P2P 통신이 항상 가능한 환경을 제공하는 장점도 있지만, STUN에 비해 리소스 낭비가 큽니다.

따라서 ICE Candidate 과~~~~정에서 Remote IP(Local IPor Public IP)를 연결 가능한 후보군을 모두 찾아낸 이후 불가능할 경우 최후의 수단으로 TURN 을 활용해야 합니다.

WebRTC API

WebRTC 개발을 위해 JS 라이브러리에서 제공하는 주요 클래스 API 는 다음과 같습니다.

주요 클래스

• MediaStream — 카메라와 마이크 등의 데이터 스트림 접근

• RTCPeerConnection — 암호화 및 대역폭 관리 및 오디오, 비디오의 연결

• RTCDataChannel — 일반적인 데이터의 P2P 통신

Video Codec

WebRTC 에서 오디오/비디오 데이터를 압축하여 전송하기 위해 사용하는 코덱이 필요합니다.

각 브라우저(Chrome, Edge, Firefox, Safari) 밴더마다 오디오/비디오에 대해 지원하는 코덱 정보 확인이 가능합니다

Video Codec

WebRTC는 모든 호환되는 브라우저가 지원해야 하는 기본 코덱 세트(baseline를 설정합니다. 일부 브라우저는 다른 코덱도 허용하도록 선택할 수 있습니다.

아래는 WebRTC를 완전히 준수하는 브라우저에 필요한 비디오 코덱과 필요한 프로필 및 실제로 요구 사항을 충족하는 브라우저 표 입니다.

Mandatory video codecs

필수 코덱 외에도 일부 브라우저는 추가 코덱도 지원합니다. 다음 표에 나와 있습니다.

Other video codecs

Audio Codec

RFC 7874에서 모든 WebRTC 호환 브라우저가 지원해야 하는 오디오 코덱은 아래 표에 나와 있습니다.

필수 오디오 코덱 외에도 일부 브라우저는 추가 코덱도 지원합니다. 다음 표에 나와 있습니다.

WebRTC Library

WebRTC는 계속 발전하고 있고, 각 브라우저마다 지원 수준이 다릅니다.

따라서 각 브라우저 호환성을 위해서 Google에서 제공하는 adapter.js 라이브러리 사용을 추천하고 있습니다.

Adapter.js는 shim 및 polyfill을 사용하여 다양한 플랫폼에서 WebRTC 구현 간의 다양한 차이점을 없애줍니다.

또한 WebRTC 개발 프로세스를 전체적으로 쉽게 수행 할 수 있도록 접두사와 다른 이름 지정의 차이점을 처리하며보다 광범위하게 호환되는 결과를 제공합니다.

라이브러리는 NPM 패키지로도 제공됩니다. 따라서 향후 MERN Stack 을 이용하여 개발시 해당 라이브러리 적용을 검토할 예정입니다.

WebRTC VS WebSocket Vs Socket.io 비교

WebRTC, WebSocket, Scoke.io 기술 차이점과 주요 장/단점에 대해 살펴봅니다.

WebScoket

WebSocket은 HTTP와 달리 양방향 통신을 할 수 있는 기술입니다.

클라이언트가 서버와 연결을 맺고 난 후, 서버와 클라이언트는 상호간에 자발적으로 메시지를 보내고 받을 수 있습니다.

이를 통해 서버와 클라이언트 간 실시간으로 데이터를 주고 받을 수 있습니다.

WebSocket은 이전에는 불가능했던 실시간 웹 애플리케이션을 구현하는 데 매우 유용합니다.

하지만, WebSocket은 실시간으로 데이터를 처리하기 위한 기능만을 제공하므로, WebRTC와 같은 비디오 및 오디오 스트리밍 처리와 같은 다른 기능은 제공하지 않습니다.

websocket 장/단점.

• 장점 : 적은비용, 낮은 복잡도, 빠름

• 단점 : 지원하지 않는 브라우저가 다수 존재

Socket.io

Socket.IO는 WebSocket 프로토콜을 기반으로하는 실시간 양방향 통신을 위한 JavaScript 라이브러리 입니다.

웹 브라우저와 서버 간의 실시간 통신을 위해 설계 되었으며, WebSocket 이외의 다른 프로토콜에 대한 지원도 제공합니다.

Socket.IO를 사용하면 서버에서 푸시 알림, 실시간 채팅 등을 구현할 수 있습니다.

socket.io 장/단점.

• 장점: 새로운 사람이 채팅방에 들어왔음을 연결된 모든 사용자들에게 한번에 알려야하는 경우 socket.io는 연결된 모든 클라이언트에 메세지를 브로드캐스팅 할 수 있지만

  websocket은 연결된 사용자들의 리스트를 받아와서 한명씩 메시지를 보내야합니다.

  또한, 소켓 연결 실패 시 socket.io는 fallback을 통해 다른 방식으로 알아서 reconnect하지만 websocket은 reconnect를 시도하지 않습니다.

• 단점 : 많은 비용, 자원, boilerplate 코드

요약하면, 빠르게 적은 비용으로 많은 데이터를 처리하는 경우에는 websocket을 사용하고,

연결된 클라이언트들을 세밀하게 처리하고 Broadcasting 기능이 필요한경우에는 socket.io 사용합니다.

WebRTC

WebRTC와 WebSocket은 모두 웹 기술이지만 다른 목적을 가지고 있습니다.

WebRTC는 WebScoket 처럼 브라우저와 서버 통신 방식이 아닌 중간서버 경유 없이 P2P 통신에 중점을 둔 기술로, 오디오, 비디오 및 데이터를 브라우저 간에 직접적으로 전송할 수 있습니다.

반면, WebSocket은 서버와 클라이언트 간의 양방향 통신을 지원하기 위한 기술로, HTTP 연결을 유지하면서 양방향 통신을 가능하게 합니다.

WebSocket에 연결된 클라아언트를 세밀하게 처리하고, Broadcasting 이 필요한 경우 WebSocket 프로토콜을 이용한 JS 라이브러리 socket.io 를 활용하기도 합니다.

즉, WebSocket은 서버와 클라이언트 간의 실시간 양방향 통신에 적합하고, WebRTC는 P2P 통신에 적합합니다.

WebSocket 을 통해 영상을 주고 받을 수 있는데, WebRTC를 사용하는 이유는 무엇일까요?

• WebRTC 는 영상, 오디오, 임의의 데이터의 통신이 high-performance, hight-quality 이도록 설계되었기 때문입니다.

• WebRTC 는 브라우저간 직접 통신이어서 훨씬 빠릅니다.

• WebRTC 지연시간이 훨씬 짧습니다. (low-latency)

따라서 WebRTC 다음의 요구사항을 충족하는 서비스에 적합합니다.

• 브라우저 또는 모바일 단말에서 저지연 시간의 비디오, 오디오 전송

• 입력 인터페이스 (키보드, 마우스, 게임패드 등..) 입력의 이벤트 지연 시간이 짧은 스트리밍

• 브라우저 또는 이동형 단말에 대한 게임 스트리밍 서비스

반대로 WebRTC 에 적합하지 않은 서비스는 다음과 같습니다.

• 사전 녹화된 미디어 또는 렌더링된 대규모 스트리밍 서비스

• 최신 브라우저 에서 지원되지 않는 동영상 포멧에 대한 스트리밍

• 브라우저간 호환성이 문제 소지가 있는 서비스

WebRTC 에서 시그널링 과정을 통해 세션을 생성하고 미디어 데이터를 스트리밍하기 까지 모든 과정을 WebRTC 만으로 제어하기 어렵습니다.

따라서 WebSocket or Socket.io 를 이용해서 WebRTC 세션 생성을 위한 시그널링을 처리를 별도 서버를 구축하는 방법론이 일반적입니다.

Next

다음 번에는 WebRTC 서비스를 위한 Cloud Native 기반의 아키텍처 설계 안) 에 대해서 소개합니다.

• Cloud Native 기반 WebRTC 아키텍처 설계