Zoom ThirdParty API 트러블 슈팅과 회고

내가 재직 중인 회사는 실시간 멘토링 서비스를 위해 Zoom의 thirdparty api를 이용한다.

그중 멘토링 클래스에 참여한 참여자들의 참석시간을 실시간으로 관리하며

내부 admin 및 고객 측에 제공하는 자료로 활용 중인데

해당 참석시간이 찍히지 않는 버그가 생겼고 이를 해결한 과정에 대해 작성해 보고자 한다.

 

아래 그림은 해당 기능에 관련된 flow 차트이다

위 flow 간 문제를 탐색하는 과정은 데이터가 보이지 않는 View file code에서부터 역산하며 탐색을 진행했다.

 

Flow 간 문제 탐색 과정

1️⃣. DB(registrant) ← Contoller(zoom_webhook)

• View file에서 보이지 않는 zoom 참석시간의 데이터는 registrant 테이블의 joined_at column을 통해 조회한다.
• joined_at 이 업데이트되는 코드는 webhooks_controller.rb의 join_live 함수에서 실행된다.

2️⃣. Controller ↔︎ Third Party API (Zoom Webhook)

• 위 1번 join_live 함수에서 객체 정보 update를 위한 객체 setting 의 기준은 zoom webhook에서 request 보내는 참석자의 registrant_id를 통해 db에서 해당 properties[“registrant_id“] 를 갖는 registrant 데이터를 조회하여 객체로 세팅한다.  
• 그러나 해당 버그 발생 클래스들의 경우 properties 들이 업데이트되어 있지 않았음을 확인했다.
  
  그렇다면 다시 Properties 가 저장되는 시점을 탐색해봐야한다.

3️⃣. DB ← Cron <-> Third Party API (Zoom)

• properties 가 업데이트되는 시점을 다시 역산해서 찾으면
• 해당 시점은 cron 에 의해 event 들을 호출하는 부분이 있는데 이 내부의 함수 중에 존재하고 있다.
• 그 내부 함수를 살펴보면 add_registrant라는 Zoom 의 third party api 를 통해 request를 보내고 response 받는 data 정보들을 객체에 저장하여 db 의 해당 registrant 테이블의 properties column 으로 저장시킴을 확인했다.
  
  
• 그리고 해당 third party api 가 실행되며 Zoom 서버에 참석자가 등록되면 기존에 만들어 놓은 Webhook 서버에 트리거로 작동하고 해당 Webhook 서버에서 관련된 data 들을 payload 에 담아 우리 제품 서버에 request 날린다.
• 그러면 Webhook 서버에서 request 날린 data 와 우리 db에 저장된 정보를 바탕으로 객체를 세팅하는 것이다.
• 하지만 이슈 된 경우의 로그를 보니 Cron에서 add_registrant 함수 자체가 실행되지 않았음을 확인했다.

문제 원인 

• 근본적인 원인은 add_registrant 함수의 윗줄에 존재하는 add_speaker 함수 내부에서 실행되는 third party API가 404를 뱉으며 종료되어 버려 정작 필요한 콜백 함수는 실행되지 않았다.
• 이 문제 자체는 처음 제품을 설계할 당시 담당자들의 의도와는 다르게 제품이 사용되었기 때문인데 Zoom 에서 제공하는 meeting 의 타입에는 meeting, webinar 두 가지가 있다. 간단히 설명하면 webinar는 유희열의 스케치북(일부 스피커와 운영자 위주로 해당 기능이 진행), 미팅은 우리가 평소에 일상에서 활용하고 있는 온라인 미팅 정도로 생각할 수 있다.
  근데 불가피한 사유로 최초의 의도와 다르게 webinar 를 위해 만들어 놓은 제품의 기능을 활용하는 경우가 생겼고 이 경우에는 meeting_type이 meeting 임에도 webinar api가 실행되어 에러가 발생한 것이다.

해결 과정

• 해당 third party api 와 관련된 코드 페이지가 워낙 방대하고 작성 당시의 개발자가 회사 내부에 아무도 없기에 근본적인 원인을 탐색하는데 시간이 오래 걸릴 것이라 판단됐다. 
  그래서 Zoom의 api를 통해 강제로 data 동기화시키는 기능을 내부 admin 페이지 내부에 추가해 급하게 핫픽스 배포하여 고객으로부터 클레임이 들어오는 것을 미연에 대응하였다.
• 이후 위의 flow 탐색과정을 세팅하고 flow 별 탐색 후 근본적인 문제 원인을 발견 한 뒤에는 meeting_type이 webinar가 아니면 탈출하는 코드 한 줄을 추가해주어 근본적인 문제를 해결했다.

회고

회사에 입사할 때부터 해당 제품을 설계하고 만들어놓은 개발자분들은 회사 내부에 존재하지 않았고, 회사 입사 후 8개월 동안 두 번의 사수님들이 퇴사하는 이벤트를 겪었다. 사실 나도 이 과정에서 이직을 너무 많이 고민했었다.

첫 회사로 해당 회사를 선택할 때에 Front 부터 server 까지 전부 ruby on rails 로 작성하지만, 프론트 개발 경험을 이 0년 차 1년 차가 아니면 언제 또 해볼 수 있을까 싶나 하는 생각 때문이었으나 단순히 프론트를 개발하는 경험 외에도 문제를 해결하며 많은 배움이 있었다.

해당 이슈를 해결하며 느낀 것은 API 명세에 대한, 개발 문서화의 중요성.. Flow를 간단하게 작성했지만 실제로 코드의 복잡도는 더 높다. 이에 대한 문서화가 전혀 없어, 당시의 github history에 의존하며 문제 원인을 추론해 나가는 과정이 순탄치는 않았다. 개발은 유지보수가 80%라고 하지 않던가, 이를 위해 지금부터라도 내손에서 개발 문서화를 우리 회사에 뿌리내리게 만들고자 다짐했던 순간이었다.