배민커넥트 얼마나 많이 할까

connector-counter.png

들어가며

배달 수요가 폭증하고 있다.

코로나 시국에, 집에서 바로 먹는게 편하기도 하고, 요즘 자주 시켜먹는 배달삼겹이 참 맛있기도 해서 그런 것일 거다.

아무튼, 수요 폭증에 맞춰 배민커넥트 홍보가 큰 폭으로 늘었고 신규 지원자도 엄청나게 늘어나고 있다.

벌써 누적 22만명이 지원했다고 한다.

활동중인 사람은 몇 명이나 될까

배민커넥트 활동을 하면서 프로모션 정보나 기타 중요한 공지는 배민커넥트 카카오톡 채널을 통해 전달받는다. 이 채널의 친구 수가 실제로 활동중인 사람 수에 근접할 것으로 가정했다. 근거는 다음과 같다.

  • 이 채널을 친구로 추가하지 않으면 중요한 정보를 모르니 일을 할 수 없다. 즉, 친구 수는 실제 활동자 수보다 항상 크거나 같을 것이다.

  • 공지가 너무 자주 날아오는 탓에 일을 그만 둔 사람들은 해당 채널을 친구 목록에서 지웠을 것이다. 즉, 활동하지 않으면서도 친구로 등록된 사람의 수는 무시할 수 있을 정도로 적을 것이다.

이 곳에 가면 해당 채널을 친구로 등록한 사람의 수를 확인할 수 있는데, 대략 2분에 한 명 꼴로 증가한다. 너무나 빠르고 규모가 큰 변화여서, 이를 기록하고 추적해보고 싶다는 생각이 들었다.

데이터 수집, 분석, 시각화

어느 한 시점에 어느 데이터를 얻을 수 있다면, 이를 적당한 시간 간격으로 모아 두면 추세를 알 수 있고 그로부터 다른 정보를 얻어낼 수도 있을 것이다.

다음 내용을 제공하는 작은 웹 페이지를 구상했다.

  • 현재 배민커넥트 카카오톡 채널 친구 수
  • 어제와의 차이
  • 기록을 시작한 시점부터 현재까지 변동 추이

구현

익숙한 Single Page App 형태를 선택헀다. 서버 쪽은 NodeJS, 프론트 쪽은 그냥 HTML과 CSS를 썼다.

캐싱 vs 실시간으로 가져오기

UI를 짜기에 앞서 먼저 데이터를 수집하고 저장하는 방법에 대해 고민해 보았다. 이 웹 페이지에 보여지는 숫자는 다른 웹 페이지(카카오톡 채널)로부터 가져온 것이다. 그렇다면 이를 주기적으로 가져와 서버에 저장해두고 요청이 있을 때마다 보내어 줄 것인지, 아니면 요청이 있을 때마다 카카오톡 채널 페이지로부터 새로운 데이터를 가져올 것인지 결정해야 했다.

전자의 방법은 만들고자 하는 서비스가 많은 요청을 수행해야 할 때에 유리하다. 데이터 fetch 주기보다 사용자의 요청 주기가 짧은 경우이다. 비교적 긴 텀을 두고 데이터를 미리 가져와 두면 그 후로 많은 요청에 대해 추가적인 fetch 없이 처리가 가능하다.

후자의 방법은 서비스가 고도의 실시간성을 요구하거나, 아니면 데이터를 캐싱해놓는 것이 의미가 없을 정도로 요청 빈도가 적은 경우이다. 가령 요청이 한 시간에 한 번만 들어온다고 하면, 데이터 fetch는 한 시간에 한 번 꼴로 일어나는 것이 적절할 것이다. 데이터를 미리 주기적으로 가져다 놓는 방식을 택한다면 비교적 짧은 주기(1분 가량)를 택해야 데이터의 정확성을 확보할 수 있을 것이다. 그런데 이렇게 하면 요청을 처리하지 않는 동안에도 불필요한 fetch가 많이 일어난다는 단점이 있다.

한 시간 가량 고민한 끝에 전자의 방법을 택하기로 했다. 그 이유는 다음과 같다:

  • 뭔가 멋져서.
  • 요청이 30초에 한 번 보다는 많을 것 같아서(희망사항이다. 30초에 한 번씩 최신 데이터를 긁어온다.).

프로젝트 구성

보통 풀스택 웹서비스 프로젝트 구성이 그러하듯 프론트를 위한 public이 있다.

  • bin/: 실행만 하면 서버가 돌기 시작하는 www 파일을 포함.
  • lib/: HTTP 서버와 관련 없는, domain~interfaces 레이어에 가까운 코드를 포함.
  • routes/: 라우터. URI마다 하나씩 있다.
  • public/: 프론트엔드에서 실행/해석될 파일들.
  • tests/: 테스트 소스 코드. 테스트 프레임워크는 없고 그냥 눈으로 보는 테스트.
  • app.mjs: 앱 엔트리 포인트.

배포

(구현 과정은 생략. 소스는 여기에 있다.)

이제 서비스가 예쁜 도메인 아래에서 24시간 살아 있어야 했다. 그래야만 데이터를 꼬박꼬박 가져올 수 있다.

가장 먼저 떠올린 Heroku는 실격이다. 한 달에 7$ 가량을 지출해야 24시간 유지해준다. 더군다가 Redis를 persistent하게 사용하려면 월 15$를 더 지출하라고 한다.

그래서 아마존으로 갔다. LightsailEC2중에 고민을 했는데, EC2가 더 저렴해서 거기로 갔다.

aptsystemd가 있는 우분투 18.04를 선택하였고, NodeRedis를 설정한 후 깃에서 클론으로 소스를 가져와 systemd 데몬을 만들어 돌렸다.

배포 자동화는 귀찮아서 하지 않았다. 다시 콘솔을 방문할 일이 없기를 바라며 수동 배포인 상태로 놓아 두었다.

도메인

도메인이 예뻐야 쓸 때에도 기분이 좋다. 이미 가지고 있는 potados.com 도메인에 붙이기로 하였다. 서브도메인은 bc로 하였다. 배민커넥트를 줄여서 bc.

bc.potados.com에서 볼 수 있다.

도메인 관리는 freenom이라는 곳에서 하고 있는데, 별로다. 혹여나 유로 도메인을 구매하시고자 한다면 GoDaddy가 3천배 낫다. 깔끔한 한글에 웹사이트도 빠르고 DNS 업데이트는 더 빠르다. 가격도 비슷하다.

마치며

표 그리는 데에 쓴 ChartJS, 처음 써봐서 한참을 헤맸다. 덕분에 당 떨어졌다.

댓글