Request를 최소로 해야되는 이유

최근에 42서울에 있는 모든 사람들의 유저 데이터를 가져와야되는 이유가 생겼다. 그래서 42API로 전체를 가져오는 로직을 제작하고 있었는데, 이 과정에서 너무 많은 시간이 걸리는 것을 인지하고 최적화에 나섰다. 

처음 시도한 방법은 기본적인 API요청을 기반으로 요청을 작성하였는데, 기본적인 페이지 사이즈는 30이었다. 즉, 한번 GET요청을 던지면 서버에서는 30명의 정보를 내게 리턴해주는 방식으로 작동하였다. 사실 30명이라는 사이즈가 그렇게 크지는 않았지만 전체인원(42를 그만두거나 블랙홀에 빠진 인원)을 포함하여 모두를 가져오다보니, 총 요청이 270번 정도 작동하는 문제가 있었다.

 

컴퓨터에서 비용은 레지스터 << 캐시 <<< 메인 메모리 <<<< 저장공간 <<<<<<<<<<< 네트워크 순으로 큰데, 이 네트워크 비용을 약 270번이나 지불해야된다는 것은 큰 제약이었다. 다행히도, 찾아보니 42API에서는 쿼리를 기반으로 더 많은 데이터를 한번에 요청할 수 있었고, 이를 기반으로 100명의 인원을 가져오도록 로직을 변경하였다.

30명씩 요청하는 경우 약 8분 39.43초가 걸린다.

100명씩 요청하는 경우 약 4분 54초가 걸린다.

 

데이터 전처리, 데이터베이스와의 연결 등등 다른 요소들도 많지만, 이 로직 하나 변경이 전체 프로그램 성능 향상에 크게 기여하는 것을 확인할 수 있었다. 즉, 큰 놈을 가장 작게 줄여야 가장 효과가 좋다는 것을 확인할 수 있다.

 

한국에서 보낸 API 서버로 보낸 핑

내 파리 서버에서 API서버로 보낸 핑

사실, 더 최적화를 하고 싶으면 네트워크 패킷 자체의 총 이동 거리를 줄이는 방법이 효율적이다. 파이에 있는 서버에서 API요청을 실시하고 이를 모아서 한번에 내 서울에 있는 데이터베이스에 넣어주는 방법을 이용하면 가장 효율적으로 데이터 모으는 로직을 실행시킬 수 있다. 한국에서 해당 서버에 접속하는데 드는 비용보다 파리에서 해당 서버에 접속하는 비용이 약 200배정도 빠르기 때문이다.

 

하지만, 이 방법은 내 파리 서버에 남은 메모리 용량이 크지 않아서 보류하기로 했다. 현재 파리 서버에서는 배포된 서비스가 돌아가고 있는데, 이 서비스가 아직 컨테이너에 들어가있지 않아 내가 이 데이터를 모으는 과정에 패키지가 꼬인다거나 하는 문제가 생기면 큰일나기 때문이다.

 

이렇게, 오늘도 최적화를 진행 할 때에는 최대한 큰 녀석부터 최적화를 진행해서 전체 프로세스를 효율화해야된다는 것을 확인했다.

---

전체 데이터를 가져오는 로직(RUBY)