Realtime

이번에는 실시간(Realtime) 기술만 똑 떼어내서(?) 얘기 한 번 해보겠습니다.

TIP

사용자들은 더 이상 매번 리프레시를 하기 원하지 않는다.

실시간(Realtime) 기술을 쓰는 핵심 이유는 이것입니다.

Serverless와 Realtime의 아이러니

특히나 저희 같이 협업이 핵심인 서비스들은 특히나 실시간 기술이 필수입니다. 매번 리프레시를 하지 않고 데이터를 실시간으로 갱신하는 방법은 많이 있습니다. 하지만 저희가 추구하는 Serverless를 기반으로 Realtime을 구축하는 방법은 많지 않습니다.

웹 서비스에서 일반적으로 실시간 처리를 위해서 제일 많이 사용하는 기술은 Web Socket입니다. Web Socket이란 ws 프로토콜을 기반으로 클라이언트와 서버 사이에 지속적인 양방향 연결 및 데이터 전송이 가능한 기술입니다.

앞서도 여러 번 얘기했지만 Serverless를 사용하는 이유는 인프라 관리를 최소화하고 생산성을 높이기 위함인데, Serverless의 최대 단점은 Web Socket과 같은 연결지향 프로토콜을 사용할 수 없다는 것입니다. Function 단위로 로직이 실행되고 대부분 5분 이내로 강제로 종료되다보니 연결지향 프로토콜을 사용해봐야 최대 유지 시간이 5분입니다.(Serverless에 집착하는 이유는 이것 말고도 많습니다.)

해결책

Serverless와 Realtime을 동시에 만족할 수 있는 서비스는 제가 찾은 것 중 대중적인 것은 Firebase의 FireStore와 AWS의 AppSync 뿐이었습니다. AWS SA(Solution Architecture)들과 미팅을 해서 얘기해보아도 방법은 이것 뿐이었습니다. 하지만 AppSync는 사용여부와 상관없이 연결만 하고 있어도 비용이 꽤 나갑니다. 사용량에 비례해서 비용이 나가면 이해가 가지만 단순히 연결만 하고 있는데 비용이 나간다고 하니, 사용자가 늘어날수록 비용이 기하급수적으로 늘어날 것이라 사용하기가 꺼려집니다. FireStore에는 연결 유지 비용이 없습니다.

애초에 Web Socket을 위해서 인스턴스를 띄우고 Auto Scale을 적용하고 세션의 종료 및 마이그레이션 처리를 하면 어려운 일도 아니긴 하지만, 그냥 Native로 Serverless와 Realtime을 바로 구축이 가능한 대중적인 서비스는 이것밖에 찾지 못했습니다. (혹시나 비용, 생산성, 대중성을 고려하고 이거보다 좋은 방법이 있으시면 연락 부탁드립니다. 바로 모실 준비 하겠습니다.)