티스토리 뷰
- 소개
캐치딜 서비스는 2019년 10월부터 시작된 토이프로젝트의 일환으로, 같은 대학 주니어 대학생 3명이서 똘똘뭉쳐 제작된 프로젝트입니다.
캐치딜은 여러 플랫폼(뽐뿌, 클리앙 등)에 퍼져있는 핫딜특가 데이터를 Selenium 크롤링을 통해 데이터를 수집해서 보여주는 서비스입니다.
이번 이야기는 캐치딜 서버를 운영하면서 저에게 합리적인 서버 비용에 대해 찾아 나선 이야기를 나눠볼까 합니다.
- HEROKU
첫 캐치딜의 시작은 Heroku이었습니다.
Heroku를 선택한 이유는 다음과 같습니다.
- 일단 기본 사용은 무료 (유료 서버 사용에 있어 Github Student Pack 인증 시 매 달 고정적으로 7달러, 최대 2년 지원)
- 서버 사용금액에 있어 카페24와 같이 사전에 서비스 금액을 계약하는게 아닌, 일단 쓰고 나중에 서비스를 사용한 만큼 돈이 부과
- 서버 배포의 자동화
처음엔 무난하게 헤로쿠를 잘 써왔습니다. 물론 Github Student Pack에서 지원하는 서버비도 지원받으면서 유료서버로 잘 써왔습니다.
하지만 헤로쿠를 쓰면서 한가지 아쉬웠던게 Scheduler 작업에 대한 과금 청구였습니다.
캐치딜 서비스 특성상, 캐치딜에서는 특정 시간대에 자동으로 크롤링이 이루어지게 하는 Scheduler Job 기능이 필수적으로 필요했습니다. 하지만 Heroku 서버에는 기본적으로 Cronjob이 깔려있지 않다보니, 헤로쿠에서 자체적으로 지원하는 scheduler Job(Add On)을 이용해서 Scheduler 작업을 돌려야 했습니다.
하지만 해당 Scheduler Job 작업에 대해서는 Time 제한이 따로 걸려있다 보니 내마음대로 Job 시간을 설정하기도 어려웠습니다.
부록 Scheduler Background Job
더군다나 무료로 제공하는 서버 같은 경우는 Scheduler Job 모듈 사용에 대해서는 비용이 청구가 되지 않았지만, 유료서버를 사용할 경우엔 Scheduler Job 사용에 소모되는 시간에 비례해서 서버 사용비 외에 추가적인 과금이 이루어졌습니다.
이 외에도 이런저런 복합적인 사유때문에 Heroku에서 다른 서버 플랫폼으로 옮겨야 했습니다.
이에 대한 자세한 이야기는 다음 글을 참고해주세요.
부록 캐치딜 백엔드 개발이야기 : 좌충우돌 서버 설계 및 운영 이야기
그리하여 저는 AWS로 플랫폼을 옮기기로 결심합니다.
- AWS
한 2월 쯤에 Heroku에서 AWS로 서버를 갈아타게 되었습니다.
AWS를 선택하게 됨에 있어 얻게되는 이점은 다음과 같습니다.
- 대학 웹메일 인증 시, AWS Credit 100달러 지급 (Credit은 매 달 받는 청구서에서 극 일부 서비스를 제외하고 크레딧으로 대체 가능)
- 서버 사용금액에 있어 한국의 주요 호스팅 서비스와 같이 사전에 서비스 금액을 계약하는게 아닌, 일단 쓰고 나중에 서비스를 사용한 만큼 돈이 부과
- 개발에 필요한 다양한 기술의 AWS 서비스를 사용할 수 있음. (데이터 저장서버, 호스팅 서버, DB서버 등)
- 트래픽, 메모리, 용량 등 서버 스펙이 부족하다 싶으면 유동적으로 늘리거나 줄일 수 있음.
다음으로 이전하게 된 AWS는 과거에도 많이 써왔다 보니 큰 어려움 없이 쓸거라 믿어왔습니다.
그리고 훗날 이게 옳은 선택이었던게, 서버를 운영하면서 서버 퍼포먼스 효율 향상 및 비용을 위한 다양한 작업이 이루어지는데 AWS는 이를 자유롭게 시도를 할 수 있는 무대가 되었습니다.
~ 2세대 서버
AWS에서 2세대까지 운영이 되었던 서버 인프라였습니다.
여기서 저는 AWS Lambda에서 캐치딜에서 필요한 모든 Scheduler Job을 돌리곤 했었는데, 저는 이게 나중에 비용적으로 봤을 때 큰 실수를 했다는걸 깨닫게 되었습니다.
오늘 글의 핵심이자, AWS Lambda에 과도하게 부과되었던 과금 이슈에 대해 소개해볼까 합니다.
' 100만건 이하까지는 AWS Lambda가 무료로 처리된다! '
AWS Lambda에서는 위 장점 하나를 최고로 강조하며 서비스를 소개합니다.
과금 체계를 소개하기전에 앞서, EC2와 Lambda의 차이점을 먼저 풀어보고자 합니다.
* AWS Lambda, AWS EC2 설명에 사용되는 그림은 현재 캐치딜 서비스에서 응용되는 인프라를 기준으로 설명
1) AWS EC2
과금체계 | 최초 가입한 사용자라면 프리티어 혜택으로서, t2.micro(CPU 1GB, Memory 1GB) 옵션을 750시간 내 선에서 무료로 사용이 가능합니다. 프리티어 초과 혹은 프리티어가 아닌 경우 서버를 사용한 시간 만큼 돈이 부과되는 개념입니다.
AWS EC2는 CPU, Memory, OS를 직접 선택하고 서버를 직접 운용하는 형식으로서, 사용시간에 비례하여 금액을 받습니다.
일단 현재의 캐치딜에서 크롤링을 돌리는 Job 서버 같은 경우, EC2로 운용되고 있고, 위와같은 구조로 크롤링 Job을 돌리고 있습니다.
하지만 EC2를 운영하면서 겪었던 문제점이 있는데, 아무래도 자원(CPU, Memory)가 한정적이다 보니 Background Job을 잘못관리하는 순간... 위와같이 Job이 쌓이게 되고, 서버 내부에서는 수많은 Job이 동시에 돌아가다 보니 메모리 부족으로 서버가 죽어버릴 수 있는 문제점이 있습니다.
그렇다보니 한정적인 자원 내에서 Background Job을 효율적으로 관리를 해야하는 수고가 필요합니다.
후에 저는 이 문제를 Rails의 sidekiq Gem을 이용해서 Background Job 공간을 한정지어놓고(concurrency) 동시에 실행되는 Job을 제한시키는 방식으로 해결을 했습니다.
2) AWS Lambda
과금체계 | 모든 AWS 사용자에게 있어 프리티어 혜택으로 100만건 이하의 요청, 40만GB 이하의 Memory를 사용하는 선이라면 사용요금을 내지 않아도 되는 획기적인 서비스라고 볼 수 있습니다!
하지만 프리티어 혜택을 넘어가게 되면 코드를 돌리는데 할애되는 요청횟수, 시간, 메모리 사용량에 비례하여 요금을 지불하게 됩니다.
AWS Lambda는 흔히말하는 서버리스 컴퓨터로서, 기존의 EC2와같이 24시간동안 서버가 Running 되는게 아닌, 사용자가 Trigger을 건 순간(예 : 웹페이지 접속, Schdeuler) 아주잠깐 서버가 가동됨과 동시에 코드를 돌리는 개념입니다.
Lambda는 AWS EC2와는 달리 코드가 돌아가면 AWS EC2에서 제시된 그림처럼 제한된 공간에서 돌아가는게 아닌, 여러 공간으로 돌리는 방식이다보니 EC2처럼 Background Job을 돌림에 있어 한정된 자원(CPU, RAM)을 분배하는 노력에 덜 신경쓰고 작업을 돌릴 수 있다는 장점이 있습니다.
캐치딜 서비스 같은 경우는 웹페이지의 개념으로서 돌리진 않고, 위와같이 Scheduler Job에 설정된 규칙에 따라 코드를 돌리는 개념으로 Lambda 서버를 구축했었습니다.
일단 Lambda는 코드를 돌리는 퍼포먼스 만큼은 정말 좋았습니다. 일단 코드를 Running 시, Background 내부에서 돌아가는 코드(Job)를 몇개를 돌리건 Job이 밀리는 현상이라던지 그런거 없이 매우 잘 돌아갔습니다.
저는 Lambda의 위 문구에서 강조되는 장점만을 바라보며 'AWS는 100만건의 요청에 대해선 무료로 지원해주니까 Scheduler Job을 무조건 AWS Lambda에 돌려야지~' 하는 마인드로 위 인프라를 설계를 했었던건데.. 제 Scheduler Job 작업 중 일부 코드들은 AWS Lambda 앞으로는 적합한 코드가 아님을 알게됩니다.
AWS 청구서에 고지되어있는 과금기준을 보면, AWS 람다를 돌린 횟수와 AWS Computing Time 두가지로 평가가 됩니다.
예.. Computing Time.. 저게 문제였습니다. Coumputing Time은 람다 함수를 돌리면서 요청이 완료되는데 까지 사용된 Memory를 의미합니다.
캐치딜이 내의 Scheduler Job 중에는 Selenium을 활용하여 크롤링 작업이 존재합니다. 하지만 이 Selenium이 어마무시한게, 메모리를 많이 사용합니다.
캐치딜에서는 HTTP Parsing 방식으로 많이 활용되는 Nokogiri 모듈과 가상으로 크롬 브라우저를 띄어서 크롤링을 하는 Selenium을 사용하는데, 두개의 크롤링을 돌려보면 다음과 같은 결과를 살펴볼 수 있습니다.
| 크롤링 비교 | 소요시간 | 사용 메모리 |
| Nokogiri | 200ms (0.2 Second) | 182MB |
| Selenium | 4900ms (4.9 Second) | 412MB |
이와같이 Selenium은 크롤링에 있어 퍼포먼스 적으로는 크게 떨어진다는 것이 확인이 됩니다.
덕분에 Selenium을 이용해서 Memory를 많이 쓰다보니 AWS 컴퓨팅(메모리) 사용량에 대한 비용이 청구가 많이 되는바람에 이는 Heroku의 Scheduler를 쓰는 것 보다 엄청난 과금이 부가가 되었었습니다.
* '아니 그럼 HTTP Parsing 방식 크롤링을 쓰면 되는거 아니야?' 하지만.. javascript 같은 동적으로 동작하는 홈페이지에 대해서는 크롤링을 못한다는 단점이 크흡..
아주 간단한 Selenium 크롤링만으로도 400MB 소모가 되는데, 캐치딜에서 활용되는 Selenium 크롤러는 한번 코드를 작업 할 때 마다 약 962MB정도가 소모가 됩니다. (이 때, 최대 메모리 사용량을 1GB로 한정.)
하지만 이 때 당시 '962MB정도야.. 설마 40만 GB까지 쓰겠어?' 했는데.. 그 설마가 사람을 잡게 되고맙니다.
이 때 당시 Selenium 크롤러를 3분에 한번 간격으로 돌리곤 했었는데, 이게 엄청난 화를 불렀던겁니다.
한 요청 당 약 1024MB의 메모리가 소모되고, 시간은 3분 걸린다고 가정할 때의 요금을 계산해 보면 아래와 같습니다.
AWS Lambda 월 비용 예측계산
1) 순수 메모리 사용 14400(1달 요청횟수) * 180(요청 당 소모시간, s 단위) * 1024MB/1024MB = 2,592,000
* Lambda 함수를 Running 시 할애된 메모리는 1024MB 사용을 가정
2) 순수 메모리 사용 - 프리티어 메모리 사용 2,592,000 - 400,000 = 2,192,000
3) 한달간 Lambda 메모리 사용 요금 2,192,000 * 0.000016667 USD = 약 36.53 USB
- 참고 : AWS Lambda 비용 계산기
결국 Selenium 크롤링 하나만으로 한달에 약 2,100,000GB의 매모리를 사용하는 것이고, 위와같이 과금폭탄을 부과맞게 되는겁니다..(ㅎㄷㄷ)
아무리 봐도 이건 뭔가 코드를 너무 비효율적으로 돌아가는 것 같긴 한데.. 이 때 당시에는 당장에 방법이 떠오르는게 없어서 약 1달동안 크롤링 주기를 1시간 간격으로 돌리곤 했었습니다..ㅠㅠ
그런데 프론트 개발자 캐치딜 관련 글을 작성한 페북에서 댓글을 달아주신 어느 분의 좋은 의견 내용을 참고해서 좋은 방법이 떠올랐습니다.
지금 캐치딜이 운영이 현재와 같이 원할히 돌아갈 수 있는것은 이 분의 페이스북 댓글 조언이 컸던것 같습니다.
덕분에 2세대 → 3세대 서버로 이어갈 수 있었던 것 같습니다.
이 분의 댓글을 보고 생각이 딱 들었습니다.
' EC2는 시간에 대해서만 비용이 부과되지, 메모리를 얼마를 쓰건간에 처음 EC2 생성 때 정해진 메모리 내에서만 쓰면 과금이 안되니까 Hoxy.....? '
그래서 저는 다음날부터 EC2 서버를 새로 파고, 크롤러를 돌려본 결과 일단은 EC2에서도 기본적으로 본 서버와의 DB 연동이 잘 됨과 동시에, 결과적으로는 꽤 무리없이 잘 돌아갔습니다!
덕분에 AWS Lambda에서 1시간에 1번씩 돌렸던 크롤링 작업은 크롤링 작업의 시작과 종료되는 시간을 고려해서 약 10분에 한번씩 돌아가게 하고 있습니다.
그리하여 3세대 개발 인프라는 위와같은 구조로 설계가 되었었습니다.
메모리를 적게 쓰는 푸쉬알람, 지워져야 할 핫딜 게시글에 대해서는 Lambda가 역할을 맡게 되고, 메모리가 많이 쓰이는 데이터 크롤링은 EC2가 담당하고 있습니다.
그리고 위 인프라 설계를 도입 후, 과거와 다르게 비용도 꽤 아끼게 되었습니다.
크롤링 서버를 돌리는 AWS EC2 t2.small 1달 사용료가 19.37 달러가 책정이 되었습니다. 확실히 AWS Lambda에서 돌렸던 떄에 비해서는 가격이 많이 떨어졌습니다. 하지만.. 저는 이 가격도 개인적으로 좀 불만이었습니다.
크롤링을 함에 있어서 하드웨어는 CPU보다는 RAM이 중요합니다. 그렇다보니 고지서를 보고 '굳이 AWS EC2의 제온 CPU를 활용하며 매달 저렇게 비싼 과금을 낼 필요가 있을까?' 하는 의문이 생겼습니다.
또한 한달에 약 20달러의 비용이 깨지는데, 저걸 n달을 키면서 유지시킨다고 생각하면 흠...
그래서 차라리 저는 크롤링을 위한 서버인 라즈베리파이를 도입하기로 마음먹었습니다.
마침 라즈베리파이를 구매하자고 마음먹은 때에 새로운 4B 버전이 나왔고, RAM 선택에 있어 과거 세대와 달리 1GB 뿐만 아니라 2GB, 4GB 로 늘어나게 되어 선택의 폭이 넓어졌습니다.
필요했던 서버 스펙 1순위가 RAM이었다 보니 바로 구매해야겠다고 결심하게 되고, 그렇게 라즈베리파이4B는 당근마켓 거래를 통해 69000원(온라인 판매가보다 만원정도 싸게 구입!)에 구매를 했습니다.
라즈베리파이의 기본 Ubuntu 셋팅부터 시작하여 Ruby, Rails, Selenium 설치법을 약 2일정도 공부한 끝에 Ruby on Rails 기반의 크롤링서버를 구축하게 되었습니다.
공부를 하면서 라즈베리파이 기본 셋팅부터 Selenium 설치/실습에 대한 블로그 글도 작성(클릭)을 했으니 혹시 관심있으신분은 참고해주세요.
그렇게 모든 준비가 끝나고 실제 라즈베리파이를 본서비스에 활용 전, 라즈베리파이에 크롤링 Job을 돌리게 되었고 이상이 없다는것을 확인했습니다.
개략적으로 캐치딜 서비스에는 크롤링 Job에 있어서 2가지 코드가 돌아갑니다.
- 크롤링 Job : 1~2 목록 Write/Update
- 크롤링 Job : 3~5 목록 Update Only
위 두 크롤링 Job을 AWS EC2와 라즈베리파이4B에 Running해본 결과, 작업이 끝날 때 까지 걸리는 시간에 있어선 차이도 크게 느껴지는게 없어가지고 재 구실도 잘 해냈습니다.
이로서 최종적으로는 서버비 절약을 위해 일부 RAM 작업 부담이 큰 작업에 있어선 라즈베리파이를 활용해도 좋을 것 같다는 결론이 나왔습니다.
마지막으로, 좋은 조언도 해주신것도 있지만, 서버까지 지원해주려 하셨던 위 페이스북 메세지 속 익명님께 정말 감사합니다
- Database 서비스 선택 : AWS EC2 VS RDS
현재 캐치딜 서비스는 AWS EC2 내에 Database를 설치해서 운용중에 있습니다.
하지만 이는 기본적인 방법이고, AWS에서는 Database 만을 위해 존재하는 AWS RDS 라는 서비스가 존재합니다.
만약에 AWS DB에 있어 유지보수(백업, 버전관리 등)를 해야할 경우
1) AWS EC2 사람이 일일이 설정을 해줘가며 유지보수를 해줘야 합니다.
2) AWS RDS Paas 기반으로서, DB 운용에 필요한 기능에 대해 준비가 되어있다 보니 큰 설정없이 바로 운영을 할 수 있으며, 유지보수에 필요한 작업이 (자동으로) 이루어집니다.
위의 장점만 들여다보면 RDS가 월등히 뛰어나 보입니다만, 한가지 단점이 존재합니다..
AWS RDS는 이러한 편리성을 가진 만큼, 아무래도 서버의 모든 관리(백업, scale up, 관제 등)에 있어 AWS에서 자동화 지원(Paas)을 해주다보니 이러한 장점 덕분에 EC2로 서버를 돌리는 것 보다 유지비용이 비싼게 현실입니다..
현재 RDS를 돌리기엔 아직 DB 서버의 관리까지 못맡을정도로 바쁜 편도 아니고, 백업이야 제가 좀 고생은 하지만 Rails 내 Gem(모듈)을 통해 주기적으로 할 수 있고, 결정적으로 비용적으로 큰 부담 때문에 아직 RDS가 아닌 EC2를 통해 서버를 돌리고 있습니다. (AWS RDS t2.micro에서 예비DB 등 옵션 없앨거 다 없애도 최소 20달러 이상 비용 발생)
하지만 나중에 서버도 크게 확장되고, 백엔드 관리에 있어 서버의 영역을 제 스스로 관리하기에 있어 힘들 경우 AWS EC2 → AWS RDS로 갈아타는 고민은 해봐야 할 것 같습니다.
EC2 VS RDS 부록
AWS RDS vs EC2 차이점, 간단히 파악하기
AWS EC2/RDS 상용 Database(Oralce) 사용 시 정리
- 굵직한 내용 정리
1. 본인이 학생인데 서버 운영을 경험해 보고 싶다면 국내 호스팅 업체보단 Heroku 혹은 AWS를 사용해봐라.
학교 웹메일만 인증이 된다면 Github Student Pack과 연계되어 학생 혜택으로서 크레딧을 받을 수 있으니, 크레딧을 이용해서 무료로 서비스를 이용해 볼 수 있다.
2. AWS는 서버를 지원하는 다양한 서비스를 운영하고 있다보니, 서버를 응용해서 개발할 수 있는 자유도가 어마어마 하다.
3. '이거 좋아!' 라고 해서 무조건 냅따리 하지마라, 하기전에 자신의 서비스에서 이용되는 자원(CPU, 메모리, 요금 등)이 해당 조건에 부합한지 따져보는걸 추천한다.
4. AWS Lambda는 코드 running횟수와 할애된 Memory에 따라 과금이 책정이 된다, 해당 부분의 유의하자.
* 다만, 한달 내 100만 횟수 요청과 400,000GB 메모리 사용에 대해선 무료로 인정해준다.
5. 데이터베이스 운영에 있어 AWS EC2 VS AWS RDS는 비용 및 자신의 상황에 따라 선택을 하자.
이상적으로는 유저보수에 대해 많은 편리성을 지원하는 RDS가 답이긴 하나, EC2에 비해 높은 비용을 감당할 수 있어야 한다.
- 읽으면 좋은 자료
1. [로켓펀치] 300원에 200만뷰 소화하기 – 서버리스 아키텍처 AWS 람다(Lambda) 활용 사례
- 캐치딜 개발 이야기 연결고리
1. 캐치딜 백엔드 개발이야기 : 좌충우돌 서버 설계 및 운영 이야기
5. 캐치딜 백엔드 개발이야기 : Restful API 설계의 다양한 고민
6. 캐치딜 백엔드 개발이야기 : 나에게 맞는 합리적인 서버 비용을 찾아서..
'개발 포토폴리오 > 캐치딜(백엔드) 개발 이야기' 카테고리의 다른 글
| 캐치딜 백엔드 개발이야기 : Restful API 설계의 다양한 고민 (2) | 2020.02.05 |
|---|---|
| 캐치딜 백엔드 개발이야기 : 크롤링 (3) | 2020.02.04 |
| 캐치딜 백엔드 개발이야기 : 디자이너와의 협업 (2) | 2020.02.04 |
| 캐치딜 백엔드 개발이야기 : 문서화 (0) | 2020.02.03 |
| 캐치딜 백엔드 개발이야기 : 좌충우돌 서버 설계 및 운영 이야기 (6) | 2020.02.03 |
