[Typescript] 소규모 서비스에서의 FaaS(Netlify Functions)와 WebRTC를 통한 Peer간 (서버측면)저비용 통신 서비스 구현 - 1. 방법론

1. 서론

본 포스트는 작은 서비스 규모에서의 각 Peer간의 서버측면 저비용 통신 서비스를 구현하는 것에 목적을 두고 있다. 물론 필자가 소개한 방법보다 더 효율적인 방법이 있을 수는 있다. 이에 대한 의견은 적극 수용하고 있으니 다른 의견이 있다면 댓글로 남겨주기 바란다.

2. 본론

2-1. 문제확인

Peer간 통신을 구현하는 방법으로는 여러방법이 있겠지만, 대표적으로 사용하는 방법으로 socket 통신이 있다. 특히 Web기반의 클라이언트에서는 앞에서 말한던 socket과 비슷한(엄밀이 말해서 둘이 다른 프로토콜이긴 함) WebSocket을 이용할 수 있다.
WebSocket 서버를 가운데 두고 각 Peer가 WebSocket 서버에 바인딩이 되면 서버를 통해서 각 Peer가 Private Channel 내에서 데이터를 송수신을 하게 된다. 이때 서버는 각 Peer의 WebSocket 바인딩을 대기하고 송수신 데이터를 지속적으로 중개해주어야 하기 때문에 상시 Idling 상태를 유지해야한다.

위 방법으로는 지속적인 서비스를 위하여 서버가 상시 돌아가고 있어야하기 때문에 만약 클라우드서비스로 서버를 이용하게 된다면 지속적으로 온디멘드 요금이 발생하게 될 것이다. 그리고 데이터 송수신 시, 서버가 지속적으로 중간에서 데이터를 전달해주어야한다. 서버의 데이터 중개 과정을 개량한다면 서버 리소스 사용량을 크게 줄일 수 있을 것이다.

2-2. WebRTC의 도입

WebRTC(Real Time Communication)은 보통 피어간 오디오, 비디오 데이터 송수신을 구현하기 위해 많이 사용하는데, 이를 위한 STUN 서버가 무료로 공개된 도메인들이 많이 있다. 그래서 이용하면 간편하게 피어간 P2P 통신을 구현할 수 있다 (중요: 내 서버리소스 없이 말이다!)

이를 이용해 2-1 에서 확인한 서버의 데이터 중개 과정을 서버 없이 피어간 P2P 통신으로 대체한다면 서버 운영으로 인한 지속적인 비용 발생을 크게 줄일 수 있다.

그래서 JS에는 이를 위해 RTCPeerConetion라는 객체로 로컬과 원격피어의 연결을 제공한다. 이를 이용하면 SDP Offer와 Answer를 발급/등록할 수 있다. SDP의 Offer/Answer를 각 Peer가 서로 교환하고 이를 LocalDescription과 RemoteDescription으로 등록하게 되면 연결이 성립되고 추가적인 서버 자원없이 각 Peer가 P2P로 통신할 수 있게 되는 것이다. 아래 이미지는 위 과정을 나타낸다 (사실 추가적인 서버자원이 아예 필요가 없는건 아니긴한데 일단 아까 WebSocket에 비해서 획기적으로 줄어든다. 아예 필요가 없지 않은 이유는 이후에 설명하도록 하겠다.)

2-3. Peer간 SDP Offer/Anwer 교환

2.2에서 설명했듯이 각 Peer가 WebRTC로 P2P 연결이 되려면 SDP의 Offer/Answer를 교환하고 이를 LocalDescription과 RemoteDescription으로 등록을 해야하는데, 문제는 이 "Offer/Answer 교환"을 어떻게 할 것이냐는 것이다. 여기서 아까 말한 약간의 별도 서버자원이 필요하게 된다.

일반적으로 이런 Peer간 교환은 socket을 기반으로 많이 구현을 하게 되는데, 서비스 규모가 작을 경우에는 socket을 이용하여 구현할 경우 WebRTC를 써가며 서버 리소스를 줄인 의미가 없게 된다. 그래서 이번에는 단순 교환 기능만 구현되면 되기 때문에 FaaS를 이용하려고 한다. 사실 서비스 규모가 어느정도 된다면 SDP Offer/Answer 교환만을 위한 socket서버 인스턴스를 돌리는 쪽이 훨씬 효율적이고 안정적이다. 하지만 지금은 소규모 상황에서의 저비용 통신 서비스를 구현하는 것이 목적이기 때문에 FaaS를 이용하려고 한다. 충분히 이후에 socket을 이용하여 대체할 수 있기 때문에 이번 포스트에선 FaaS를 통한 기능 구현에 대해 고민해보겠다.

위 이미지를 보면 Peer1과 Peer2 그리고 Serverless API가 있다. 전체적으로보자면 Peer1과 Peer2가 SDP Offer/Answer를 교환하기 위해 Serverless API를 경유하는 것을 볼 수 있다. Peer1과 Peer2는 SDP Offer/Answer를 교환하는 동안에만 Serverless API에 polling하여 현재 Offer/Answer의 상태를 검사함과 동시에 해당 데이터를 가져오고 등록하게 된다. 이를 통해 Peer1과 Peer2의 SDP Offer/Answer 교환은 완료되고, 이후에는 Serverless API에 대한 추가적인 리소스 사용은 없게 된다.

WebRTC 연결이 성립된 이후부터는 외부의 sturn 서버를 이용하여 데이터를 송수신하기 때문에 본인이 부담해야하는 서버 비용이 연결 성립 이후에는 발생하지 않게된다.

다음 포스팅에선 위 구조로 통신하는 구현체를 제작할 계획이다.