깃허브 맞팔 탐지기 [04] - 저장할 데이터 분석 후 캐시 저장소 선정

 

<캐시할 데이터 용량 분석>

https://backend-newbie.tistory.com/46 , 이전 포스팅에서 분산락 도입을 끝냈다. 이번에는 실제로 API 응답을 위해 필요한 데이터들을 캐시하기 위해서 캐시 설계를 진행할 생각이다.

 

 

 

<저장할 데이터 분석>

 

 내가 캐시에 저장해야 할 데이터는 GitHub의 follower와 following 조회 API 응답 중 필요한 필드만 골라낸 값이다. 팔로워 리스트와 팔로잉 리스트, 그리고 스냅샷 시각으로 이루어져있다.

 

 여기서 보통 실제 팔로우 리스트에 들어있는 깃허브 유저 데이터 하나는 40~80 byte 정도의 용량을 갖고 있다. 크게 id, usertag, 프로필 url이 필요한데 id의 경우 Integer로 정해져 있고 4 byte 고정이다.

 

 

 

<Github userTag>

 

 GitHub 응답의 login에 해당하는 usertag는 최대 39자까지 사용할 수 있으며, 영문 알파벳만 허용된다. 따라서 이 필드는 최대 39byte의 문자열 데이터로 표현된다. 다만 실제 사용자명은 대부분 10~15자 이내로 끝나는 경우가 많으므로, 평균적인 용량은 약 15byte 정도로 산정하였다.

 

 

 

<프로필 이미지에 해당하는 avatar_url>

 

 깃허브 프로필 이미지는 위와 같이 고정된 url에 담겨서 온다. 내가 깃허브 프로필 이미지를 변경해도 해당 url은 변하지 않는다. 깃허브 id는 Integer로 제공된다.

 

 id가 2147483647인 유저의 프로필 이미지 url의 경우, https://avatars.githubusercontent.com/u/2147483647?v=4 가 될 것이고 49 byte의 데이터이다.

 

 

 

 

<유저 한 명당 용량 추정>

 

 대략 팔로워 한명을 저장하기 위해서는 70byte의 용량이 필요하다는 것을 알 수 있다. 팔로워가 100명, 팔로잉이 100명인 경우 대략 14KB의 용량을 갖게 된다.

 

 

 

 

<깃허브 GraphQL을 이용한 한국 사용자 팔로워, 팔로잉 분석>

 

 

 

<깃허브에서 가장 팔로워가 많은 유저>

 

 현재 깃허브에서 가장 많은 follower를 보유하고 있는 유저의 팔로워 수는 25만명이다. 만약 이런 유저가 우리 서비스를 이용한다고 하면 팔로워를 불러오기 위해서 깃허브 API 호출만 2500번을 수행해야 한다. 대략 18MB의 팔로워 정보를 우리 캐시에 저장해야 한다.

 

 

 

<깃허브 API Limit>

 

 

 그러나 이런 사람이 우리 서비스를 이용할 것 같지는 않고, 깃허브 API에는 한 사람이 1시간에 5000번 이상의 요청을 호출할 수 없도록 API Limit가 설정되어 있다. 

 

 우리 서비스는 깃허브 사용자와 깃허브 사이에서 여러가지 추가기능을 제공하는 서비스로 대부분의 API, 배치작업을 위해서 반드시 깃허브 API 호출이 필요하다. 따라서 이렇게 팔로워 불러오기 한번에 2500번의 API 호출 기회를 사용하는 유저는 우리 서비스를 이용할 수 없다.

 

 

 

 

 

<Github 프로필 Location 설정>

 

 

 하지만, 우리 서비스는 한국유저들 상대로만 서비스 할 계획을 갖고 있다. 깃허브 프로필에는 Location을 설정 할 수 있는 필드가 있는데, 해당 Location에는 사용자가 임의로 원하는 문자열을 입력할 수 있다.

 

 

 

{
  search(query: "location:Korea sort:followers-desc", type: USER, first: 100) {
    edges {
      node {
        ... on User {
          location
          followers {
            totalCount
          }
          following{
            totalCount
          }
        }
      }
    }
  }
}

 

 그래서 깃허브 GraphQL에 location에 "korea" 라는 문자열이 포함되어 있고, follower가 많은 순으로 Top 100명의 팔로워, 팔로잉 수를 확인해 봤다.

 

 물론, 프로필 Location에 아무것도 입력하지 않은 유저나, korea가 포함되지 않은 유저는 통계 데이터에 잡히지 않겠지만 그래도 유의미한 지표로 활용 할 수 있을것 같았다. 아쉽게도 following 많은 순 정렬은 제공되지 않았다.

 

 

 

 

<Top3>

 

 팔로워가 가장 많은 유저는 대략 4000명 정도의 팔로워를 보유하고 있었다. 응답 데이터를 쭉 살펴본 결과 38등 부터는 팔로워가 1000명을 넘지 않는 것을 확인 할 수 있었다.

 

 팔로잉순으로 통계내는 쿼리는 지원하지 않는것 같았는데, 팔로워가 Top 100인 유저들의 데이터를 쭉 분석한 결과, 대부분은 압도적으로 팔로잉 수가 팔로워 보다 적은 편이었고 가끔씩 팔로잉이 6000, 4000명인 대형 유저들도 존재 했다.

 

 

 

 

 

 

 모든 한국 유저를 대상으로 한 데이터분석은 아니라서 정확하지 않을 수 있겠지만, 대략 한국 유저들 중에는 팔로워 + 팔로잉 수를 모두 합쳐도 10000명을 넘는 유저는 존재하지 않을 것 같았다. 따라서 우리 서비스를 이용하기 위한 사용자의 깃허브 팔로워 + 팔로잉 조건을 10000명으로 잡기로 결정했다. 최악의 경우 한 유저의 팔로잉, 팔로워 정보를 캐시하기 위해서는 0.7 MB의 용량이 필요하다고 판단했다. 

 

 

 

 

 

<location에 korea가 포함된 깃허브 유저 수>

 

 Location에 korea라는 문자열이 포함되는 깃허브 유저 수는 92000명 정도 존재했다. 그래서 location이 korea인 유저들 중에서 follower가 많은 순으로 100명씩 데이터를 받아보면서 팔로워, 팔로잉 수 체크를 진행했다.

 

 

 

 

 

 그 결과, 10번째 페이지의 마지막에 존재하는 팔로워가 1000번째로 많은 유저의 팔로워 수가 122명인 것을 확인할 수 있었다. 그 이후로는 더 이상 데이터가 나오지 않았지만 대략 위의 스크린샷과 비슷한 분포를 보였다.

 

 즉, location에 korea가 포함된 유저가 92000명인데 팔로워가 많은 순으로 1000명만 봐도 팔로워가 100명이 넘어가는 유저가 굉장히 드물다는 것을 알 수 있었다. 

 

 

 

 

 

<팔로워 + 팔로잉, 상위 1%유저 분석>

 

 대부분의 사용자들은 팔로워가 팔로잉 보다 압도적으로 많았지만, 아닌 케이스도 존재했으니 팔로워 수 == 팔로잉 수로 잡고 가정을 해봤을 때, 대충 90000명 중에서 상위 1% 정도에 속하는 유저들의 팔로워 + 팔로잉 수가 300명 정도라는 계산이 나왔다.

 

 이 말은, 100명의 사용자가 신규 가입을 하면 정말 팔로워 + 팔로잉 수가 많아야 1명 꼴로 그 합이 300명 정도 된다는 거라고 생각을 했고 대부분의 사용자는 팔로워 + 팔로잉을 모두 합쳐도 100명이 안될거라는 계산을 했다.

 

 

 

 

 

<평균 유저 캐시 데이터 구조>

 

 데이터 분석을 진행한 모집단이 전체 한국인 깃허브 사용자가 아니라, location에 korea가 포함된 유저였던 점, follower-desc 순으로 데이터를 분석했다는 점을 고려해서 완전히 정확한 데이터 분석은 아닐 수 있기 때문에 예외 경우들을 고려해서 평균적인 우리 서비스를 이용하는 사용자의 팔로워 + 팔로잉 수는 100으로 더 높게 잡았다.

 

 

 

 

 

 

 

<해당 캐시 데이터가 이용될 부분>

 

 우리 서비스를 사용하는 유저들의 팔로워와 팔로잉 데이터를 캐싱했을 때, 대부분의 캐시 데이터 크기는 7KB 미만으로 추정된다. 따라서 약 3,000명의 사용자가 비슷한 시간대에 팔로우 관계 탐지기나 팔로잉 목록 중 Moyoy 회원 랭킹 보기와 같은 기능을 동시에 이용한다고 가정하더라도, 캐시에 저장되는 데이터의 총량은 약 21MB 수준에 불과하다.

 

 이러한 수치는 캐시 서버와 API 서버 간의 네트워크 비용 측면에서나 캐시 서버의 메모리 용량 측면에서 모두 매우 여유로운 수준이다.

 

 

 

 

<현실적인 비용 문제와 타협>

<인프라 비용>

 

 나는 AWS를 통해서 서비스를 배포할 생각이다. 프리티어 200$를 이용해서 이것저것 만져보느라 비용이 과도하게 많이 나오기는 했지만, 그 중에서 MySQL을 위한 RDS, Redis를 위한 ElastiCache는 모두 상위권에 있다. 심지어 RDS, ElastiCache는 모두 백업, 클러스터 등등이 전혀 없는 싱글 노드임에도 굉장히 많은 비중을 차지하고 있는 상황이다.

 

 

 

 

 

 

<오토 스케일링을 통해 늘어나는 EC2 인스턴스>

 

 우리 API 서버는 평소에는 단일 인스턴스 이지만 트래픽이 많아질 경우 오토스케일링을 통해서 Scale-Out을 진행할 예정이다. 따라서 각 API 서버의 메모리 단에서 로컬캐시를 이용할 수는 없는 상황이다.

 

 즉, 위의 그림처럼 글로벌 캐시를 도입해야 하는 상황이다. 나는 추가적인 인프라 비용이 발생하는 것을 막고 싶어서 분산락을 도입하느라 추가된 Redis를 글로벌 캐시로 사용하기를 간절히 바랬다.

 

 

 

 

 

<캐시 하고 싶은 데이터>

 

 

 내가 캐시하고 싶은 데이터의 소스는 깃허브이다. 즉, 데이터 동기화를 위해서 캐시에 존재하는 데이터를 삭제하고 다시 깃허브로 부터 데이터를 받아와 저장하는 과정이 필요하다.

 

 또한 최종적으로 위와 같은 형태의 데이터를 저장해야 하는데 RDB에 이를 저장하자니 쉽지 않은 데이터 구조와 주기적으로 직접 캐시를 청소해줘야 한다는 불편함이 있었다.

 

 해당 데이터는 NoSQL을 이용해서 해결하는게 좋아보였고 TTL을 적극 활용할 생각이었다. MongoDB, DynamoDB, Redis등의 저장소가 떠올랐는데 캐시되는 데이터의 크기가 작다는 점, Redis는 HDD/SSD가 아닌 InMemory 기반이라 초고속 처리를 지원하는 점, 위에서 본 인프라를 추가로 늘릴 비용이 없다는 점을 모두 고려해 Redis를 우리 서버의 글로벌 캐시로 사용하기로 했다.