문제 인식

저는 운영 서버에 같은 서비스 기능을 하는 스프링부트 서버 2개를 띄우고 Nginx 서버에서 로드밸런싱을 하고 있었습니다.

팀에서 Oauth2로 소셜 로그인을 구현이 되어 개발 서버에서 테스트하고 운영 서버에 반영을 했습니다.

그런데, 개발 서버에서 잘 되었던 소셜 로그인이 확률적으로 성공하는 현상이 발생했습니다.

확률적으로 성공하는 소셜 로그인은 실제 서비스에선 있을 수 없는 일이라 생각했기 때문에 빠르게 해결하고자 했습니다.

 

문제 파악

구현한 소셜 로그인 동작에 대해 생각해보니 백엔드 서버는 크게 3가지 요청이 있었습니다.

  • 클라이언트에게 위임 요청
  • 받은 위임으로 인증 서버에 토큰 요청
  • 받은 토큰으로 리소스 서버에 사용자 정보 요청

그렇다면 받은 위임과 받은 토큰으로 요청하는 것이기 때문에 이전 요청에 대한 응답을 가지고 있어야 정상적으로 작동할 것이라 생각했습니다.

즉, Nginx의 로드밸런싱으로 중간에 원래 소셜 로그인 동작을 하던 스프링부트가 아닌 다른 포트 번호의 스프링부트 서버로 요청을 했기 때문에 일어난 일이라 생각할 수 있었습니다.

 

문제 해결

저는 Nginx에서 특정 요청은 특정 포트 번호의 서버로 요청이 가게끔하면 되지 않을까라는 생각으로 해당 방향으로 알아봤습니다.

알아보니, Nginx에서 ip_hash라는 것을 사용하면 특정 ip는 같은 포트 번호로 요청을 보낼 수 있는 방법이 있었습니다.

적용한 결과, 운영 서버에서도 정상적으로 소셜로그인을 할 수 있게 되었습니다.

 

※ 개발 서버에서는 비용 문제로 1개의 스프링부트 서버만 띄우고 있어서 잘 동작한 것이었습니다.

 

 

개선점

ip_hash는 한 지역에서 많은 트래픽을 보내면 한쪽 서버으로 트래픽이 몰릴 확률이 존재합니다.

그래서 OAuth 인증 서버에서 받은 토큰을 Redis 같은 스토리지에 저장하여 공유하도록 하면 한 지역에서 많은 트래픽을 보내도 부하 분산이 가능하고 제가 겪었던 문제도 해결할 수 있는 좋은 방법이 될 것이라 생각합니다.

+ Recent posts