Introduce
비디오 업로드 전용 서버를 구현하기 위해 웹훅 방식으로 구현하라는 선임의 말씀을 듣고 생각했다.
웹훅이 뭐지? 들어만 봤는데
자, 그러면 지금부터 알아보도록 하자.
API Polling vs Webhook
사실 이 그림 한방이면 설명이 끝난다.
API Polling은 어떤 이벤트에 대해 지속적으로 클라이언트가 API 호출을 통해 해당 이벤트 발생 여부를 지속적으로 요청하여 응답을 받아내는 방식이고, Webhook은 요청을 보내놓고, 이벤트가 발생했을 때 응답을 받아내는 방식이다.
각각 어떤 것인지 알아보자.
API Polling
위에 대략적으로 설명해 놨지만, 이벤트가 발생했다는 응답이 올 때까지 계속 서버를 찌르는 것이다.
위의 예시 대로라면 ‘치킨을 먹는다’ 라는 결심이 설 때까지 친구가 무한정 먹자고 API Polling을 하고 있는 것이다.
멋진말로 표현하자면,
클라이언트가 특정 데이터를 정기적으로 요청하고(예를 들어, 매 x 초마다), 서버가 요청된 데이터를 응답하는 과정
이라고 한다.
굳이 코드까지 써가며 설명하지 않아도 이해했을 거라고 생각한다.
Webhook
위의 API Polling방식에서 치킨먹자고 하는 친구의 입장이 되어보자. 치킨을 먹을 친구를 구하기 위해 계속해서 치킨먹자고 제안하게 되는 이 상황이 굉장히 비효율적이고 많은 시간을 낭비하게 한다.
아무런 연락도 취하지 않고 기다리고 있는데, 친구가 치킨을 먹겠다고 마음을 먹었을 때 문자로 당신에게
야 치킨먹자
라고 연락이 온다면 굉장히 편리하게 친구랑 치킨을 먹을 수 있지 않겠는가 (쓸데없이 웅장하게 적은 것 같기는 하다)
“치킨을 먹겠다고 마음을 먹는다”라는 이벤트가 발생했을 때, 당신에게 알려주는 이 방식이 바로 Webhook이다.
웹훅의 작동 방식(?)
- 웹훅을 설정할 때, 어떨 때 알림을 받을 것인지 특정 이벤트를 지정한다. (치킨을 먹겠다는 마음)
- 이벤트가 발생하게 될 때 데이터를 보낼 URL(받을 서버의 endpoint)을 설정한다. (내 전화번호)
- 이벤트가 발생하면, 웹훅은 아까 지정한 URL로 HTTP API 요청을 보낸다. (치킨 먹고싶다고 문자 해주는것)
- 이벤트를 받은 서버는, 해당 이벤트가 발생하면 하고자 했던 처리를 수행한다. (치킨을 먹으러 가는 것)
잠깐 이렇게 간단하게만 살펴 봐도, 웹훅의 장점은 확실히 보인다.
이벤트가 발생하자마자 바로
HTTP API Request를 보내기 때문에, 실시간이라는 특징이 잘 반영된다.
- 그러면
API Polling도 미친듯이 요청을 넣으면 실시간성이 보장되지 않나? → 헛소리. 쓸데없이 자주 요청 넣어봤자 자원만 낭비되고, 낭비해서 요청하더라도 우리가 인지하지 못하는 딜레이가 발생한다.- 대표적인 예시로, 구글링 조금만 해봐도 나오는 Slack이나 Discord가 사람들이 웹훅을 많이 사용하는 곳이다.
Callback
위에서 살펴봤듯, API Polling 은 특정 이벤트가 발생했는지 계속해서 물어보는 것, Webhook은 가만히 있다가 먼저 특정 이벤트가 발생했다고 알려주는 것이다.
그렇다면 갑자기 주인장이 들고온 이 Callback 은 또 뭘까?
(내가 이해한 방식대로 설명하는 것이라 이상한 설명이 있는 것 같으면 피드백 바랍니다.)
위의 상황으로 또 대입해보자. 치킨 먹자고 연락을 남겨놓고, 치킨 먹겠다는 결심을 하겠다고 Callback 해주는 것을 예시로 들 수 있겠다.
Callback 은 서버에 이벤트가 발생했는지 물어본 후에, 이벤트가 발생했을 때 클라이언트에 말그대로 응답해주는 것이다.
조금 전공자답게 표현해보자면, “콜백함수”를 등록해 놓고, 이벤트가 발생하여 자신이 호출되기를 기다리는 것이라고 볼 수 있다.
자 그럼 이제 이 개념들을 어떻게 써먹었을까
나의 적용방식
우선 내가 개발해야될 상황을 정리해보자. (+ Vimeo API 를 사용하는 비디오 업로드 서버를 개발 중이었다.)
- 메인서버(편의상 이렇게 표현하겠다. 앱이 API를 호출하는 API 서버이다) 에서 비디오 업로드 서버로 업로드 요청을 보내면, 해당 비디오를 Vimeo 에 업로드한다.
- Vimeo에 업로드하면 폴더 ID와 비디오 ID 값이 나오는데, 해당 값을 메인서버에 보내줘야 한다.
- Vimeo에서는 업로드 이후 다양한 해상도, 다양한 환경에서의 재생을 지원하기 위해
transcoding을 거친다. 이 작업이 끝났다는 사실 또한 메인서버에 알려줘야 한다.
문제 상황과 알맞은 해결방법
- 업로드 작업은 파일의 크기에 따라 걸리는 시간이 천차만별이다.
- 일반적인 방식으로 업로드가 끝날때까지 쓰레드를 붙잡아두고 있기에는 병목현상이 반드시 발생할 것이 뻔하다.
- 비디오 업로드 서버는 DB에 접근 권한이 존재하지 않는다.
- 비디오를 저장하고 얻는 세부적인 정보들을 DB에 직접 저장할 수 없다.
→ 해결책 : 업로드 작업은 백그라운드에서 수행한다. 그리고 Callback방식을 적용하여 업로드 후 나오는 저장해야 될 세부적인 정보들을 메인 서버에 보낸다.
transcoding(Optimizing)작업은 대개 업로드보다 더 오래 걸리곤 하는데, 이transcoding이 언제 끝나는지 Vimeo는Webhook을 제공해주지 않는다.
→ 해결책 : 울며 겨자먹기로 transcoding완료 여부를 API Polling을 통해 해결한다.
또한, transcoding 이 완료되면 메인서버에 특정 비디오가 준비되었다고 Webhook 처럼 요청을 넣는다.(실시간이 아닌데 이걸 웹훅이라고 할 수 있을까….)
최종 로직
위와 같은 고민 끝에 결정한 클라이언트를 제외한 서버간의 로직만 작성해보겠다. 코드는 다 작성해서 여기 담기엔 너무 많다…
비디오 업로드
- 메인 서버(편의상 이렇게 표현하겠다) 에서 비디오 업로드 서버로
MultipartFile과 함께 업로드 요청을 받는다. - 일단 냅다 메인서버의 요청에
OK Response를 반환해버린다. 업로드 작업 접수했다는 뜻이다. - 백그라운드에서
async(비동기) 방식으로 업로드 로직을 시작한다. MultiparFile를FilePart방식으로 받게 되기 때문에, 아래의 부가 작업들을 한다.ByteArray로 파일을 변환한다.- 파일의 크기에 따라
ByteArray를 chunk 단위로 나눈다. - Vimeo 내부에서의 폴더관리를 위해, 개발 환경과 업로드를 요청한 클라이언트에 따른 비디오를 저장할 폴더 ID를 구한다.
- c에서 구한 폴더에 해당 비디오를 저장할 공간을 만들고 비디오 ID를 구한다.
- 위의 작업들에서 구한 폴더 ID, 비디오 ID를 메인 서버로
Callback한다. - 이제 chunk별로 나눈 비디오들을 업로드한다.
- 업로드가 완료된다.
Transcoding 확인 로직
- Vimeo에 미리 태그를 달아놓은 내 비디오들만 스케줄링 설정하여 30초마다 조회한다. (
API Polling) transcode.status가 “complete”인 것들만 따로 변수로 모아둔다.- 메인서버에 2번에서 모아둔 것들을 API 요청을 통해 전달한다.
- (+) 메인 서버는 해당 데이터들을 DB에 알맞게 업데이트한다.
결론
웹훅이란 상당히 매력적인 기술이다. 자원을 효율적으로 사용하게 해 줄 뿐더러, 실시간으로 처리를 해준다는 것이 마음에 든다. 물론 나는 웹훅다운 웹훅을 구현한 것이 아니지만… (이건 다 Vimeo 잘못이다.)
API Polling, Webhook, Callback 의 차이를 이해하고 적절히 사용하는 판단이 필요하다.
이러한 것들에 대해 처음 알아보고 구현해보았는데, 올바르게 잘 적용했는지 모르겠다. 다음 번에 이런 기술들을 사용하여 무언가를 개발할 상황이 생긴다면, 조금 더 자세히 알아보고 적용해보자.
