Github API의 느린 응답 이슈 개선을 위한 스케줄링을 통한 DB 업데이트

문제 상황 & 접근

매우 느린 Github API를 사용해야 했으며 바로 데이터를 response 해야 함

Github Repository의 기여자들의 기여도(커밋, addition, deletion)와 기여자 정보를 가져오는 API

 

• Github Repository -> Insights -> Contributors 탭에 브라우저를 통해 들어가면 매번 분석을 위해 어느정도 Delay 이후 정보를 확인할 수 있다. 사용하고자 하는 Github API가 해당 정보들을 가져오기 때문에 느린 것으로 예상된다.

Repository -> Insights -> Contributors 탭에서 확인 가능한 정보들

 

• 문제가 생긴 Github API 의 특징
  • 맨 처음 호출시 202 상태코드 response 및 계산 시작
  • 계산이 끝나면 그 다음 호출시 데이터 반환하며 비동기 호출 방법을 제공하지 않음
  • 평균 7초 이상 소요되며 최대 10초 가량 소요

최적화 고민

• 한 번 조회한 부분은 이후에는 빠르게 response할 수 있으면 좋겠다 판단
• DB에 저장하여 데이터가 있는 경우 해당 데이터를 사용하는 방법 구상

시도1 -> DB 활용

• 이미 DB에 데이터가 존재하는 경우 해당 데이터를 response 하도록 구현
• 성능적으로는 좋아졌지만, 데이터의 동기화 관점에서 Github API 서버와 동기화가 전혀 되고 있지 않음.

어떻게 동기화 할까?

• 개선할 방안이 2개 떠올랐다.
  • 방안 1: 조회시 비동기로 해당 Repository 만 업데이트하여 다음 조회시 업데이트 된 정보 조회
  • 방안 2: 스케줄링을 통해 일괄 업데이트
• 방안 1의 경우 오래동안 조회가 안되는 Repository의 경우 문제가 동일하게 발생한다.
• 따라서 방안 2를 선택하기로 했다.

시도2 -> 스케줄링으로 업데이트

• DB에 존재하는 데이터를 스케줄링을 통해 2시간 마다 일괄 업데이트 진행하였다.
  • 운영 시 설정한 값이다. 당시 총 업데이트할 데이터가 100개 이상 쌓였고, 동기로 각 데이터를 순차 업데이트하여 약 10분 소요됐다. 배치 서버에 대한 이해도가 아직은 부족하여 싱글 스레드 기반 업데이트 하였다.
    • 8s * 100 = 800s (13m)
  • 사용자가 급격히 증가 중이지는 않았기에, 10배인 최대 1000개를 가정하면 1시간 30분 안에는 마무리될 것이라 계산했으며, 넉넉히 2시간 이내에는 완료될 것이라 기대했다. 배치에 대한 이해도가 늘어나면, 더 빠르게 배치 job을 처리할 수 있을 것이다. 기회가 된다면 이러한 아쉬운 부분을 개선하고 싶다.
• 데이터 sink 문제도 어느정도 해소됐다.

결론

• 부하테스트를 통해 평균 Latency를 확인하였다.
• 첫 호출 이후부터는 DB조회만 수행하면 되어 개선된 latency 제공할 수 있었다.
• 하지만, 아직 개선할 부분이 보인다. Github API는 시간당 5천 회의 호출만 가능하다.

매번 API 호출 [7.72s]

 

DB 조회 [49.26ms 15.67배 개선]

개선할 사항

• 캐시와 비슷한 성격을 띠고 있으므로 캐시에 저장하도록 수정을 고려하려고 한다.
• 히트율과 Github API 호출 제한 고려
  • Github API를 호출 제한 발생 전까지만 호출할 수 있기에, Github Repository의 스타 수가 많은 경우만 스케줄링을 통해 갱신한다.
    • 스타 수가 많은 경우 조회하는 횟수가 더 많을 것이라 예상
  • 회원 본인의 Repository는 앱 실행시 한 번 모두 갱신한다.
    • 본인의 Repository는 본인이 조회할 가능성이 높으므로, 로그인시 갱신함으로써 히트율을 높인다.