<UI & 기능 요구 사항 분석>
이번 프로젝트에서 위와 같이 우리 서비스에서 사용자의 깃허브 팔로우 관계를 탐지하고 관리할 수 있는 기능을 담당하게 되었다.
위의 API를 구현하기 위해서 위와 같이 사용자의 followers, following을 모두 조회하는 API를 이용했다. 깃허브에는 나만 팔로우중인 유저 리스트 조회, 맞팔로우 중인 유저 리스트 조회, 상대만 나를 팔로우 중인 리스트 조회를 위한 API는 따로 제공하지 않는다.
해당 API들은 사용자의 Follower와 Following이 너무 많다면 한 요청에 100명의 응답을 준다는 제약 조건을 가지고 있다.
UI를 분석해 보면, 우선 사용자의 전체 팔로잉, 팔로워 리스트가 있어야 보여줄 수 있는 "00명과 맞팔로우 중입니다." 와 같은 통계 정보와 슬라이스로 구현된 유저 리스트가 필요하다.
여기서 중요한 건 "00명과 맞팔로우 중입니다." 와 같은 데이터는 모든 팔로워, 팔로잉 리스트가 우리 서버측에 있어야 보여 줄 수 있다는 점이다. 사용자의 총 팔로워, 팔로잉 수가 몇명이든 적어도 처음 한 번은 모든 데이터를 가져와야 한다.
예를 들어 팔로워 260명, 팔로잉 600명 이라면, 한 요청에 100개의 데이터를 받아 올 수 있기 때문에 Get Follower 3번, Get Following 6번의 요청을 Github API 서버에 요청해야 한다. 이에 따른 9번의 Network I/O가 발생할 것이다. 그러면 아래와 같이 3가지 큰 문제가 발생한다.
- 사용자는 9번의 깃허브 API 호출로 매우 긴 시간을 기다리게 됨.
- 사용자의 Github API Limit가 매우 빠르게 소진됨.
- 무분별한 Github API 호출로 네트워크 비용 증가함.
"00명과 맞팔로우 중입니다" 같은 통계 데이터를 확보했다면 우리 API 서버에서 사용자에게 Slice 처리된 응답을 제공하기 위해서 매번 깃허브에서 다시 모든 follower, following 리스트를 받아올 필요는 없을 것이다. 우리 API 서버측에서 캐싱해 두고 캐시 오염이 되지 않게 잘 관리해 주면서 사용해 볼 수 있을 것이다.
깃허브 유저 리스트는 깃허브 회원 id 순 정렬이 적용되어 있다. 위와 같은 화면에서 사용자가 스크롤을 내리다가 다음 페이지를 요청한다면, 깃허브 API를 이용하는 게 아니라, 캐시에서 데이터를 받아온 후 가공한 다음, 사용자의 화면에 존재하는 마지막 깃허브 회원 id 다음 유저부터 슬라이스 사이즈 만큼 데이터를 보내주면 된다.
언팔로우 이벤트가 발생할 경우 위와 같이 캐시 오염이 되지 않게 처리를 해주면 될 것이다. 팔로우 이벤트의 경우 위의 시나리오와 반대로 진행하면 된다.
문제는 우리 서버측에 캐시를 도입할 경우, 사용자가 깃허브에서 직접 팔로우, 언팔로우를 진행하거나, 다른 사용자에 의해 팔로우, 언팔로우 되는 이벤트가 발생하는 것을 우리 서비스에서 알 수있는 방법이 없고 깃허브 데이터와 싱크가 안 맞아서 실시간 맞팔 탐지기에 오류가 생기게 된다.
그렇다고 캐시를 포기하기에는 우리 서버측에서 네트워크 비용이 너무 많이 나오기 때문에 위와 같이 사용자가 맞팔 탐지기를 신뢰 할 수 없으면 강제 동기화 버튼을 누르거나 캐시 된 데이터의 수명이 다할때 마다 최신 데이터가 강제 갱신 되도록 대응 할 수 있을 것이다.
캐시 TTL은 추후 조정하겠지만 15 ~ 60분 정도로 생각하고 있다. 사용자가 강제 갱신을 직접 요청하지 않더라도 1시간 단위로 깃허브에서 실제 데이터와 싱크를 맞추도록 조정할 수 있을 것이다.
<API 설계>
이제 어떤식으로 기능을 구현할지 대략 감이 잡혔으니 프론트 측에 어떻게 API를 제공할지 고민을 해봤다. 이 때, 프론트 개발자분이 클라이언트가 오랜 시간 동안 대기해야 하는 API는 없었으면 좋겠다는 요구사항을 추가해 주셨다.
어떤 사용자의 깃허브 팔로워, 팔로잉이 너무 많거나 맞팔 탐지기 조회쪽 트래픽이 증가하는 환경에서는 Blocking 방식의 깃허브 API 호출을 Executor, @Async, 가상스레드등의 도움을 받아 비동기 처리를 진행한다고 해도 처리할 수 있는 수의 한계가 있기 때문에 응답 속도가 느려질 수 밖에 없다.
따라서 API를 어떻게 설계해야 할까 고민하다가 깃허브 API 중에서 우리와 비슷한 API가 있는 것을 발견했다. 해당 API는 깃허브 Repo의 커밋데이터 통계를 분석해서 보여주는 계열의 API인데 사용자가 처음 조회 요청을 보내면 202 Accept를 먼저 응답으로 보내주고, 다시 조회했을 때 데이터가 준비되면 200 OK와 데이터를 보내주는 API이다.
우리 API 서버에서도 위와 같이 캐시에 응답을 내려줄 수 있는 데이터가 준비되면 200을, 데이터가 없다면 202를 응답으로 보내 주기로 했다.
캐시에 아무런 데이터가 없을 경우 비동기로 팔로우, 팔로워를 깃허브에서 수집해 오는 동시에 클라이언트에게는 202 Accepted 응답을 전달할 계획이다.
캐시를 강제로 Refresh 해야 하는 경우에도 마찬가지로 진행한다.
하지만 이런 구조에서 캐시에 데이터가 없는데 클라이언트가 조회, 강제갱신 API를 계속 호출하게 된다면 캐시에 데이터가 채워질 때 까지 동일한 작업이 계속 비동기로 발생할 것이다.
이를 방지하기 위해서 서버 내부에 특정 사용자에 대한 락을 두고 이를 획득한 경우에만 실제 데이터 수집 작업을 진행하고 락을 획득하지 못한 경우에는 202 응답만 내려주는 방식을 생각해 봤다.
하지만, 우리 서비스는 API 서버에 트래픽이 많아질 경우 오토스케일링을 통해 서버 인스턴스가 계속 늘어나도록 설정 되어있기 때문에 특정 서버 내부에 존재하는 락을 획득하는 것은 무의미할 것이다. 해당 작업을 진행하기 위한 특정 사용자에 대한 락을 서버 외부에 둬야 할 것 같다. MySQL 혹은 Redis 기반 분산락을 사용하게 될 것 같다.
'토이 프로젝트 > 깃허브 맞팔 탐지기' 카테고리의 다른 글
| 깃허브 맞팔 탐지기 [05] - Redis 글로벌 캐시 도입 (0) | 2025.08.28 |
|---|---|
| 깃허브 맞팔 탐지기 [04] - 저장할 데이터 분석 후 캐시 저장소 선정 (0) | 2025.08.27 |
| 깃허브 맞팔 탐지기 [03] - Redisson 분산락 도입 (0) | 2025.08.24 |
| 깃허브 맞팔 탐지기 [02] - MySQL 네임드 락 도입 고민 (0) | 2025.08.23 |