Firebase와 Kubernetes Engine로 빠르게 성장하는 영상 채팅 스타트업
Bermuda에 대하여
버뮤다는 '영상 채팅으로 새로운 친구를 만난다'는 목표로 시작된 서비스입니다. 화면을 넘기는 것으로 전 세계의 사람들과 접속되고, 새로운 언어와 문화를 나눌 수 있다는 점 때문에 서비스 2년만에 1천만 명 넘는 가입자가 이용하는 소셜 미디어 플랫폼으로 자리 잡았습니다.
어떤 어려움을 겪고 계신지 알려주세요. Google Cloud가 도와드리겠습니다.
문의하기버뮤다는 스마트폰에서 전 세계 이용자들과 영상으로 대화하는 채팅 플랫폼입니다. 창업 초기, 버뮤다는 Firebase로 빠르게 서비스를 개발해 2년만에 1천만 명이 넘는 이용자들이 쓰는 서비스로 성장했습니다. 늘어나는 트래픽을 효과적으로 처리하기 위해 컨테이너와 Kubernetes를 도입했고, 비용을 줄이면서 서비스 개발에 집중할 수 있게 됐습니다.
구글 클라우드 사용 효과
- PaaS 수준의 손쉬운 컨테이너 운영
- 오토 스케일링으로 효과적인 리소스 관리
- 빠른 서비스 개발
- 인프라 운영 비용 절감
클라우드 이용 비용 80% 절감
버뮤다는 세계를 무대로 하는 영상 통화 서비스입니다. 전화번호나 식별 번호를 두고 영상으로 전화를 연결하는 대신 관심사나 특정 조건에 맞는 사람들끼리 무작위로 연결해줍니다. 새로운 친구를 만난다는 재미 뿐 아니라 여러 나라의 사람들을 만나 새로운 문화와 언어를 접할 수 있다는 점이 버뮤다의 인기 비결이기도 합니다.
버뮤다는 이제 2년을 조금 넘긴 서비스입니다. 전체 직원이 9명밖에 되지 않지만 서비스의 성장은 상당히 빠릅니다. 2019년 3월 현재 구글 플레이에서 1천만 명이 넘는 이용자가 앱을 내려받아 쓰고 있습니다. 동시 접속자도 수 천명에 달합니다. 작지 않은 서비스 규모지만 버뮤다는 자체 서버를 한 대도 갖고 있지 않습니다. 대신 버뮤다의 모든 서비스는 현재 GCP으로 운영되고 있습니다.
구글 클라우드와 함께 성장한 스타트업
버뮤다가 흥미로운 것은 GCP과 함께 성장해 온 스타트업이라는 점입니다. 적은 인력으로 서비스를 시작했고, 빠르게 성장하면서 필요한 서비스 요소들을 클라우드로 대신하면서 발전의 속도를 늦추지 않고 있습니다. 현재도 9명 구성원 중 개발자는 6명이지만 시스템과 인프라 관리 걱정 없이 서비스 그 자체에만 집중할 수 있다고 합니다.
버뮤다의 출발은 GCP의 'Firebase'에서 시작됐습니다. 버뮤다의 창업 멤버는 3명이었습니다. 스타트업의 특성상 인력이 많지 않기 때문에 인프라와 프레임워크 등을 모두 새로 개발하는 것은 부담스러운 일이었습니다. 인프라를 다루는 백엔드 엔지니어를 두고 서비스를 만드는 것은 벅찼기 때문에 가장 중요한 데이터베이스를 클라우드로 꾸리는 것은 당연한 선택이었습니다.
"Firebase는 이용자 정보, 채팅, 결제 내역 등 서비스 운영에 필요한 거의 모든 데이터베이스를 해결해주었습니다. 특히 아이디어를 빠르게 프로토타입 결과물로 만들 수 있었고, 제품 출시를 앞당기는 데에 효과적이었습니다. 원하는 것들을 쉽고 빠르게 만들 수 있다는 것 때문에 Firebase는 지금까지도 적극적으로 활용하고 있습니다."
버뮤다의 기술 담당 박대봉 이사는 Firebase의 강점을 쉽고 강력한 기능으로 꼽았습니다. 서버를 관리할 필요가 없을 뿐 아니라 원하는 데이터베이스를 쉽게 만들고 운영할 수 있었습니다. Firebase는 크고 작은 기업들이 많이 쓰고 있지만 특히 인력과 시간이 아쉬운 스타트업이 직접적인 가능성을 확인하는 데 중요한 역할을 하는 도구이기도 합니다.
하지만 버뮤다의 성장은 빨랐고, Firebase만으로는 늘어나는 이용자를 그대로 감당하기에 부담스러웠습니다. 이용자가 늘어나는 것에 스케일아웃으로 대응하기 버거워지는 시점이 찾아왔습니다. 결국 1년 정도 지나 서비스에 동시에 접속하는 이들이 1천500명을 넘기 시작할 때쯤 버뮤다는 새로운 결정을 합니다. 각 서비스 요소에 맞는 클라우드 서비스를 구분해서 운영하기로 한 것입니다.
버뮤다의 영상 통화는 이용자들을 직접 연결하는 P2P 방식으로 이뤄집니다. 연결 프로토콜은 메시징 서비스의 표준처럼 쓰이는 웹 RTC에 기반하고 있습니다. 버뮤다의 이용자들은 기기끼리 직접 연결되지만 서로를 처음 이어주는 데에는 '시그널링(Signaling)'이 필요합니다. 서로가 대화를 나눌 수 있는지 확인하고 접속해주는 교환기 같은 역할인 셈이지요. 버뮤다는 이 역할을 Firebase에서 다른 서비스로 옮기기로 했습니다. 시그널링이 원활해질 뿐 아니라 Firebase에 그만큼의 컴퓨팅 자원이 확보되는 것을 염두에 둔 결정이었습니다.
"Firebase는 버뮤다가 창업할 때 아이디어를 빠르게 결과물로 만들 수 있게 해주었습니다. 하지만 서비스 규모가 1천만 명을 내다보면서 인프라 확장에 Kubernetes Engine를 이용했습니다. Kubernetes Engine는 컨테이너를 효율적으로 관리할 수 있게 해주었고, 결과적으로 업무 부담이 줄어들면서도 운영 비용을 크게 낮출 수 있었습니다."
—박대봉 버뮤다 이사빠른 성장, 그리고 인프라 고민
하지만 Firebase를 벗어나는 일은 그리 간단하지만은 않았습니다. 먼저 시그널링을 처리하기 위한 웹소켓 서버를 만드는 과정에서 HTTPS 기반의 보안을 동시에 처리하는 것이 쉽지 않았습니다. 이를 직접 만들 수도 있었지만 박대봉 이사는 기존처럼 코드만 바로 올려서 쓸 수 있는 클라우드 서비스를 이용하는 것이 옳다고 판단했습니다. 개발 인력을 온전히 서비스 개발에만 집중하기 위해서였지요. 이를 위해 버뮤다는 Heroku를 타 클라우드 제공업체의 PaaS에서 이용하기로 했습니다.
버뮤다는 Heroku로 서비스 일부를 옮겼지만 Firebase의 부하는 또 다시 찾아왔습니다. 버뮤다는 응용프로그램을 구동하는 데 쓰는 Meteor 프레임워크도 외부로 옮기기로 결정했고, 컨테이너를 관리해주는 'Meteor Galaxy'라는 PaaS 서비스를 도입했습니다. 한동안 클라우드 자원에 여유가 생겼고 PaaS의 편리한 관리에도 만족했습니다. 하지만 버뮤다의 이용자가 빠르게 늘어나면서 또 다른 고민이 찾아왔습니다. 바로 운영비용이었습니다.
"PaaS 서비스는 편리함 대신에 급격히 늘어나는 비용을 감당해야 했습니다. 이용자가 늘어나는 성장세 이상으로 비용이 걷잡을 수 없게 늘어나기 시작했습니다. 당장의 부담 뿐 아니라 앞으로의 이용자 증가폭을 생각하면 당시의 서비스를 그대로 운영하는 것은 비용면에서 감당하기 버겁다고 판단했습니다."
두 PaaS 서비스는 비용 문제 뿐 아니라 새로 옮긴 서비스들의 인스턴스 관리도 쉽지 않다는 점이 아쉬웠습니다. 주어진 모니터링 도구의 권한이 생각보다 적어서 직접 크롤링 도구를 이용해서 시스템 사용량을 체크하고 인스턴스를 조정해야 했습니다. 그즈음 버뮤다는 GCP의 Kubernetes Engine을 접했습니다. Kubernetes Engine은 컨테이너 관리 권한이 강력했고 서비스를 개발하면서 선택할 수 있는 클라우드 환경의 선택폭이 넓었습니다.
"개인적으로 Kubernetes Engine와 컨테이너에 관심을 가지던 시기였습니다. 내부 개발 환경의 일부를 도커 기반으로 개발해서 쓰고 있었고, 로컬 서비스에도 도커를 일부 활용하고 있었기 때문에 컨테이너의 편리함을 잘 알고 있었습니다. 그 쯤에 GCP과 Kubernetes Engine 을 함께 검토하기 시작했습니다."
버뮤다의 강지훈 소프트웨어 엔지니어는 이미 컨테이너에 대해 대비하고 있었기 때문에 Kubernetes Engine은 자연스러운 선택이었습니다. 버뮤다는 결국 Heroku와 Meteor를 GCP의 Kubernetes Engine로 옮기기로 결정했습니다.
버뮤다는 Kubernetes Engine를 도커 오케스트레이션 도구로 활용하고 있습니다. 각 서비스 요소들을 도커로 개발하고 이를 효과적으로 묶어서 서비스를 구성해주는 것이 Kubernetes Engine의 주요 역할입니다. 필요에 따라 시스템 자원을 유연하게 조정할 수 있기 때문에 컨테이너와 클라우드의 강점을 모두 활용할 수 있는 방법이기도 합니다.
세밀한 자원 관리, 운영 비용 절감으로 연결
타 클라우드에서 운영하던 Heroku와 Meteor를 Kubernetes Engine으로 이전한 뒤 버뮤다는 시스템을 더 여유롭게 쓰면서도 비용은 80% 가량 줄일 수 있었습니다. GCP 도입으로 버뮤다가 노렸던 비용 효율성이 크게 개선된 것입니다. 강지훈 엔지니어는 오토 스케일링과 세밀한 자원 할당, 그리고 GCP의 현실적인 요금 체계들이 더해지면서 나타난 결과라고 설명합니다.
"Kubernetes Engine으로 옮기는 과정에서 설정해야 하는 서버가 30대가 넘었는데, 모든 서버가 원하는 만큼의 자원을 세밀하게 할당할 수 있었습니다. 특히 클라우드 위의 컨테이너에 가상 CPU 자원을 0.1 단위로 설정할 수 있어서 관리를 더 효율적으로 할 수 있었습니다."
2019년 3월 현재 Kubernetes Engine을 이용해서 운영하는 버뮤다의 컨테이너는 16개에서 33개까지 유연하게 움직입니다. Kubernetes Engine노드 하나에 가상 CPU가 4개씩 할당되고 평소에는 노드 4개가 작동하지만 접속자가 늘어나면 9개까지 늘어나면서 33개 컨테이너가 작동하도록 설계됐습니다.
Kubernetes Engine은 시스템 모니터링이 쉽기 때문에 언제 어떻게 클라우드 할당량을 조정해야 할지 파악하기도 쉬웠습니다. 기존에 쓰던 PaaS 기반의 솔루션들이 인스턴스 관리 도구에 제한적으로 권한을 주는 경우가 많았는데 Kubernetes Engine으로 이전한 이후에는 모든 시스템 자원을 버뮤다 내부 개발자들이 실시간으로 모니터링하고 짜여진 시나리오대로 확장되었습니다. Kubernetes Engine은 애초 목표로 했던 것처럼 각 서비스들을 PaaS에서 이용하는 것과 거의 동일한 환경으로 만들어주었습니다.
"Kubernetes Engine 도입 이후에 클라우드 관리에 대한 걱정이 사라졌습니다. 원래 해야 하는 일에 더 집중할 수 있게 된 것 뿐 아니라 새로운 일을 할 수 있게 됐습니다. 무엇보다 새벽까지 시스템 이용 상황에 신경을 곤두서지 않아도 서비스를 원활하게 운영할 수 있다는 점도 좋습니다."
Firebase는 여전히 버뮤다의 가장 중요한 뼈대가 되고 있습니다. 하지만 버뮤다는 앞으로 추가되는 기능들은 모두 Kubernetes Engine으로 개발하고 기존 서비스 일부도 Kubernetes Engine으로 옮길 계획입니다. 자연스럽게 Firebase에 어울리는 요소들은 더 여유롭게 운영될 겁니다.
인프라를 꾸리고 관리하는 일에는 정답이 없습니다. 박대봉 이사는 "서비스를 100명 쓰는 것과 1천명이 쓰는 것은 단순히 서버 대수를 늘리는 문제가 아니었다"고 말합니다. 늘어나는 트래픽과 서비스 요소들에 따라 시스템의 최적화가 필요하고 적절한 서비스를 이용하는 것이 옳다는 이야기입니다. 버뮤다는 Kubernetes Engine과 Firebase를 이용해 서버 한 대 없이도 그 답을 찾아가고 있는 중입니다.
어떤 어려움을 겪고 계신지 알려주세요. Google Cloud가 도와드리겠습니다.
문의하기
Bermuda에 대하여
버뮤다는 '영상 채팅으로 새로운 친구를 만난다'는 목표로 시작된 서비스입니다. 화면을 넘기는 것으로 전 세계의 사람들과 접속되고, 새로운 언어와 문화를 나눌 수 있다는 점 때문에 서비스 2년만에 1천만 명 넘는 가입자가 이용하는 소셜 미디어 플랫폼으로 자리 잡았습니다.