티스토리 뷰
2주 전까지만 해도 이 포스트를 작성할 생각이 별로 없었습니다.
하지만, 지난 2주간 두 명의 다른 스타트업 대표님들을 만났고 이 포스트를 작성하게 되었습니다.
한 분은 서버를 백만원쯤 주고 구매하셨다고 하셨고,
한 분은 서비스가 지금 돌아가지도 않는데 매월 약 10만원의 금액을 지출하고 계신다고 하셔서,
안타까운 마음에 이 포스트를 작성하게 되었습니다.
서비스를 운영해 본 경험이 있으신 분들은 모두 다 아시는 내용이리라 생각됩니다만,
처음에 서버를 사야할지, 클라우드를 도입해야 할지 고민하시는 분들을 위해
이 포스트를 작성하게 되었습니다.
서버를 사야하는가? 클라우드를 도입해야 하는가?
이런 질문의 답은 항상 "상황에 따라 다르다"인 것 같습니다.
그렇기 때문에, 왜 밥대생 팀이 AWS를 선택하게 되었는지를 말씀드리고자 합니다.
아시는 분들은 모두 아시겠지만,
밥대생은 본래 KAIST 모바일 컴퓨터 동아리 인클루드 내 동아리 프로젝트 였습니다.
[KAIST 밥]이란 이름으로 시작했던 서비스였죠.
[밥대생]이란 이름으로 대학을 확장해 나가기 전까지
동아리 서버를 이용해 꽤 오랜 기간 서비스를 진행했습니다.
처음에 동아리 서버를 이용했던 이유는 간단했습니다.
무료로 이용할 수 있기 때문이었습니다.
그리고, 동아리 프로젝트 였기 때문에
굳이 다른 옵션을 알아보는 것도 귀찮았습니다.
그래서 처음에 동아리 서버를 이용해 진행했습니다.
하지만, 확장을 결정하면서 서버를 이전할 필요가 생겼습니다.
KAIST는 매년 2번이상 정전이 됩니다.
따라서, 정전 시간 중에는 서버를 제대로 운영할 수 없습니다.
KAIST만 서비스 하는 경우에는 이 문제가 큰 문제가 되지 않을 수 있지만,
다른 학교로 확장하는 경우에는 큰 문제가 될 수 있습니다.
그리고, 매번 장비를 직접관리하는 불편함을 느끼고 있었기에
클라우드 서버로 옮겨갈 필요성을 느꼈습니다.
밥대생팀이 고민했던 옵션은 다음과 같습니다.
1. 코노하
2. 아마존 AWS
3. 구글 앱엔진
이 때 heroku도 알았더라면, heroku도 고민해 볼법했는데,
저희 역량 부족으로 heroku의 존재에 대해서 제대로 알지 못했고,
heroku는 고려하지 못했습니다.
몇 년이 지난 지금 그 당시의 결정에 대한 이유를 회상하면,
1. 코노하는 가장 저렴한 솔루션이었습니다.
하지만, 실제 사용하시는 분들에게 이야기를 들어보면, 가끔 알 수 없는 문제가 발생한다고 하셨습니다.
서버를 운영하는 초기에 저희의 문제인지 아니면, 서버의 문제인지 알 수 없다는 것은
서비스 운영에 치명적일 수 있기 때문에, 채택하지 않았습니다.
차라리 돈을 좀 더 내자 하는 생각이었습니다.
3. 구글 앱엔진은 안정적인 솔루션이었습니다.
하지만, 한국 내 지원에 있어 가끔 문제가 있다는 이야기를 들은적이 있었고,
특히 구글 앱엔진을 사용하기 위해서는
특화된 몇몇 서비스(FTP)들을 사용해야 됐기 때문에
이전 비용이 클 것이라 판단했습니다.
2. 의 경우 자사 입장에서는 가장 합리적인 솔루션이었습니다.
동아리 서버와 같은 방식으로 운영할 수 있고,
이전을 고민할 당시 AWS Seoul Region이 열린 상황이라
latency에 대한 걱정도 매우 적어졌습니다.
그래서 자사는 AWS로의 이전을 결정했습니다.
일단, 동아리 서버에서 운영했던 것과 동일하게
file server, db server, api server 모두 한 서버안에 설치해서 운영했습니다.
물론 이렇게 운영하다가 여유가 생길 때마다, 필요한 작업들을 수행했습니다.
아마존 s3로 file server를 이전했고,
rds로 db server를 이전했습니다.
단계적으로 이전을 해나갔기 때문에 그 과정에서 생기는 시행착오를 줄일 수 있었습니다.
이제 다른 포스트에서는 잘 말해주지 않는 내용들에 대해서 말씀드리고자 합니다.
제가 만났던 스타트업 대표님들께서 가장 궁금해하셨던 내용은 이것입니다.
그래서 밥대생은 얼마나 나오는데요?
아무래도 저희가 이 내용에 대해서 정확한 정보를 공유해드리는 것이 디자인 초이스에 도움이 되실 것 같습니다.
저희는 거의 내지 않습니다.
요즘 한달에 천 원 쯤 청구되는 것 같은데, 이 마저도 저희 크롤링 팀의 실수로 인한 비용이고 문제가 해결되면,
아예 내지 않을 수 있을 것 같습니다. 다시 확인해보니 현재 한 달에 약 $10쯤 청구되고 있네요! (프리티어 사용금액 입니다)
현재 저희 서비스의 DAU는 약 2만 정도입니다. 세션이 아니라, DAU가 2만입니다.
그렇다고 저희 프론트엔드에서 캐싱을 열심히하냐고 물어보시면, 그것도 아닙니다.
캐싱은 이미지를 제외하고는 거의 안한다고 보시면 됩니다.
이 것도 저희가 하려고 한게 아니라, 이미지 캐싱 라이브러리르 쓰다보니 자연히 되는 것이고요.
어떻게 가능할까?
사실 밥대생도 1년 전에 지금보다 트래픽이 반도 안되던 시절에 한달에 만원씩 냈었습니다.
그리고 이제는 프리티어로 안되는 트래픽이라는 사실에 흐뭇해 했었죠.
하지만, 서버팀에서 이 돈을 내지 않을 수도 있다는 생각을 했습니다.
최적화를 진행하는 방식으로 말이죠.
저희는 두 가지 방식으로 최적화를 진행했습니다.
1. 기존에는 유저의 요청이 올 때마다 db에서 데이터를 읽어서 보여주었습니다.
이 부분을 redis라는 메모리 캐시를 이용해 반복되는 작업을 캐싱하기 시작했습니다.
2. 기존에 api 서버와 크롤러 서버를 분리했습니다.
크롤링 서버는 아예 다른 계정에서 돌아가고 있습니다.
크롤링이 생각보다 트래픽을 많이 잡아먹는 작업인데,
이 서버를 분리하게 되면서 두 서버를 모두 무료로 돌릴 수 있게 되었습니다.
web server나 apron server 역시 언제든지 이사갈 수 있도록
같은 물리서버에서 돌아가고는 있지만,
다른 가상 서버 상에서 돌아가게 셋팅해두었습니다.
이렇게 기능별로 서버를 분리하면,
과금이 되는 threshold를 넘지 않을 수 있기 때문에 과금되지 않을 수 있습니다.
지금은 heroku라는 서비스도 알게 되었고,
최근에는 Firebase Realtime database도 출시되었습니다.
만약 제가 지금 서버를 구축해야 한다면,
heroku나 firebase를 사용할 것 같습니다.
둘 중 하나를 고르라면 firebase를 선택할 것 같습니다.
firebase를 사용하면 서버개발자 없이도 서버가 필요한 기능들을 개발할 수 있습니다.
안드로이드, iOS, JS를 지원하기 때문에 거의 모든 플랫폼을 지원한다고 볼 수 있을 것 같습니다.
실제로 밥대생 내 이벤트 페이지는 FIREBASE를 이용해서 개발되고 있고,
출시 예정인 밥대생팀과의 채팅기능 역시 Firebase를 통해 구현될 예정입니다.
(특히 채팅 서비스의 경우 Firebase를 기술적으로 채택하는 것이 훨씬 더 유리할 것 같습니다.)
그렇다고 Firebase가 저렴한 것은 아닙니다.
실제 계산해보면 Firebase가 그리 저렴하지는 않습니다.
하지만, 실제로는 저렴합니다.
필요한 개발량이 매우 줄기 때문에, 개발팀의 인건비를 절약할 수 있습니다.
서버비보다 개발자의 시간이 더 소중하니까요!
그리고 Firebase도 트래픽이 엄청 많지 않는 이상 많은 금액이 청구되는 것은 아닌 것으로 알고 있습니다.
지금까지 클라우드 서버를 중심으로 특히 Serverless에 대한 장점만 말씀드렸는데,
저희 서비스와 유사한 상황에서는 클라우드나 Serverless platform이 유리한 것이 사실입니다.
하지만, 머신러닝을 위한 서버를 구축하거나 특수 목적용으로 서버 구축이 필요한 경우에는
클라우드보다 직접 서버를 구축하는 것이 저렴하실 수 있습니다.
상황을 정확히 파악하고, 본인 서비스에 맞는 선택을 하시면 될 것 같습니다.
지금까지 저희가 왜 AWS를 선택하게 되었는지 말씀드렸습니다.
이 글을 통해 조금은 서버 선택에 도움이 되셨으면 합니다.