개발/푸시 서버

마케팅 푸시 서버 구축기 3탄 - 예약기능

키드 뮤지션 2022. 5. 10. 13:57

많이 보고 싶었죠? 저도 보고 싶었어요!ㅎㅎ 

마케팅 자체 서버 구축기 2탄에 이어서 3탄 들어갑니다.

 

1탄 타켓팅(가장중요) => https://kid-dev.tistory.com/11 

 

마케팅 푸시 서버 구축기 1탄 -마케팅 푸시 알람의 꽃!! 데이터!!

어느 앱을 만드는 스타트업 이야기이다. 어느날 마케터가 서버 개발자에게 찾아왔다. 그녀는 똘망똘망한 눈을 하며 말했다. "특정 앱버젼을 지닌 한국인에게만 ios,android 기기에게 app push(앱 푸

kid-dev.tistory.com

2탄 push view => https://kid-dev.tistory.com/14

 

마케팅 푸시 서버 구축기 2탄 - 마케터를 위한 푸시view 만들기

드디어 자체 푸시 서버 구축기 2탄 사실 2편 연재를 안하려고 했었는데 생각보다 1편이 인기가 좋아서 연재를 하기로 마음 먹었다. 부지런하게 살아야 겠다. https://kid-dev.tistory.com/11 마케팅 푸시

kid-dev.tistory.com

3탄 예약기능(오늘 다눌 내용)

4탄 분산처리

5탄 결과 데이터 

 

1탄과 2탄을 읽고 오셔야 이해가 가능합니다! 꼭 읽고 오세요!

 

3탄 예약 기능

마케팅 푸시(marketing push)를 보낼때 중요한건 타이밍이다. 크리스마스 이브 오후 6시(퇴근시간)에 쿠팡에서 마케팅 푸시(marketing push)가 왔다.

'우리 쿠팡에 크리스 마스 상품이 잔뜩!!'

이때 우리는 한번 생각해봐야만 한다. 어떻게 딱 6시가 되니깐 푸시(push)가 오게 된것일까? 마케터가 12월 24일 오후 6시까지 push view에다 푸시(push) 어떻게 보낼지 다 설정해두고 6시 땅 됬을때 보내기 버튼을 클릭을 한걸까? 머 그럴수도 있다. 

하지만 그건 너무 비효율적이지 않은가? 그래서 우리는 저번에 이야기 했던 push view에 보내는 시간을 예약할수 있도록 셋팅 해두었다.

하지만 단지 push view에만 셋팅한다고 보내지는게 아니다. 당연히 타이머 기능을 백엔드에 추가해야만 한다. 그래서 서버개발자 시크(나)는 타이머를 기능을 제공하는 플랫폼을 찾기 시작했다. 하지만 타이머 기능을 제공하는 플랫폼은 존재하지 않았다. 내가 못찾은 것일수도 있다. 하지만 10시 10분이 땡 되면 보내는 기능을 가진 플랫폼은 찾을수 없었다. '직접 개발할까?' 10분정도 생각하다가 배보다 배꼽이 큰거 같아서 약간 편법을 사용했다. 타이머 기능을 제공하는 플랫폼은 없었을 지언정 스케줄링 기능을 제공하는 플랫폼은 많았다. 잠깐 여기서 의문이 있는 사람이 있을거다.

 

타미어 기능이랑 스케줄기능이랑 머가 다른데요?

스케줄링은 주기적으로 보내는 기능이다. 대표적인 예가 리눅스의 cronjob이다. 매일 6시마다 어떤 기능을 수행할수 있고, 매주 화요일 3시마다 기능을 수행할수있다. 자세한 내용은 구글에서 cronjob이라고 검색하면 많이 나올테니 참고 바란다. 

타이머 기능은 딱 그시간이 되면 보내고 끝내는 기능이다. 그냥 2022-05-09 6시에 그기능을 딱 한번 수행하고 그리고는 끝이다. 

 

스케줄링 기능을 사용하기로 결심했으니 관련 플랫폼을 찾아야만 했다. 그리고 3가지 대안을 마련했다.

 

리눅스 cronjob

kubernetes cronjob

google cloud scheduler

 

셋다 api를 제공했기 때문에 충분히 코드로 제어할수 있었다. 하지만 난 google cloud scheduler를 사용했다. 왜냐? 가장 간편했으니깐!! 물론 kubernetes를 사용하고 있다면 kubernetes를 사용해도 된다. 어떤걸 사용하던지 가용성만 제공되면 된다.

 

자 이제 스케줄러 플랫폼을 정했으니 예약기능 설계를 해보자.

 

 

1. 마케터가 push view에 시간 등을 입력하면 push view는 google cloud schduler는 해당 시간에 푸시 서버에 마케팅 푸시를 보낼것을 예약한다.

2. 스케줄러는 푸시서버에게 마케팅 푸시(markeing push)를 보낼것을 요청한다.

3. 푸시서버는 user client에게 푸시(push)를 보낸다. 

 

생각보다 간단하지 않은가? 사실 예약 기능은 별로 어려울게 없다. 하지만 이걸로 끝난걸까? 절대 그렇지 않다. 왜냐? cronjob은 주기를 설정하는 기능이다. 아마 다음년도 또는 다음달에 똑같은 push를 보내게 될것이다. 그래서 push를 보내고 나면 해당 cronjob은 삭제시켜줘야만 한다.

 

 

1. 마케터가 push view에 시간 등을 입력하면 push view는 google cloud schduler는 푸시 서버에 마케팅 푸시를 보낼것을 예약한다.

2. 예약시간이 되면 스케줄러는 푸시서버에게 마케팅 푸시를 보낼것을 요청한다.

3. 푸시서버는 user client에게 푸시를 보낸다. 

4. 다 보내진 푸시는 google cloud sheduler에서 삭제 시킨다.

 

만약 마케팅 푸시를 여러개 예약 했다면 어떻게 할까?그렇다면 스케쥴러에 어떤 cronjob을 삭제해야 할지 선택을 해줘야만 한다. 우리는 그래서 고유 아이디를 부여해야만 했고, 그걸 campaign_id라고 부르기로 했다. (물론 해당 스케줄러 api에서 cronjob을 삭제하는 기능을 제공해야만 한다.)

 

 

 

1. 마케터가 push view에 마케팅 푸시를 세팅한다. 그리고 push view는 고유한 campaign_id를 생성한다.

2. push view는 google cloud schduler는 푸시 서버에 마케팅 푸시(marketing push)를 보낼것을 예약한다.

3. 스케줄러는 푸시서버에게 마케팅 푸시(marketing push)를 보낼것을 요청한다.

4. 푸시서버는 user client에게 푸시(push)를 보낸다. 

5. 다 보내진 푸시의 cronjob은 campaign_id를 통해서 google cloud sheduler에서 삭제 시킨다.

 

정말 끝이다. 이 글을 다보고난 누군가는 별로 어렵지 않네... 라고 생각할수 있다. 그렇다 예약기능은 별로 어렵지 않다. 하지만 분산처리가 들어간다면 어떻게 될까? 이때부터는 짱구좀 굴려야 할것이다. 하지만 걱정하지는 말자! 여러분에겐 코드 오랑무탄 시크가 있다.

 

to be continue