문제 발생
진행중이던 프로젝트 '입기 좋은 날' 을 쿠버네티스 환경을 도입해 진행하다가 문제가 발생했다.
발생한 문제는 다음과 같다.
쿠버네티스 환경에서 백엔드의 pod 수를 3개로 지정했을때, 소셜로그인이 제대로 동작하지 않는 결과가 발생.
백엔드의 pod 수가 1개일 때에는 잘 동작되는 것으로 보아, 서버의 문제로 생각을 했다.
그래서 생각했던 문제점은 아래의 그림처럼 생각을 했다.
해당 백엔드의 pod가 3개라 로그인을 요청한 곳으로 가지 않게 되면 소셜 로그인 자체에서 실패가 되는 경우
단순히 생각과 추측상에서 이루어진 결론이기에 틀린 부분이 있으면, 언제든 말해주세요.해결방법
찾아본 해결 방법으로는 2가지 정도가 발견되었다.
1. 스티키 세션
2. 세션 클러스터링
둘 다 세션을 관리해주는 것인데, 조금 다른 행위를 가진다.
스티키 세션은 요청한 서버로만의 응답을 한다.
대화하던 사람이랑만 대화하는 것과 비슷하다.
도입하는 방식은 2가지로
Ingress에 적는 방법과 Service에 적는 방법이 존재한다.
차이점은 아래와 같으니 참고만 해보자.(GPT와 함께하는)
스티키 세션의 단점은 한 pod에 과부하가 걸릴 가능성이 있다는 점이다.
하나의 pod로만 요청이 지속되면 해당 서버에 부하가 증가하여 서버 다운까지 일으킬 수 있다.
따라서 권장되진 않는다는 이야기가 많았다.
세션 클러스터링은 모든 pod가 공유한다.
공용의 저장소를 가지고 공유하는 것이다.
데이터베이스를 공유하듯이 우리는 레디스를 이용해서 세션의 정보를 담아 공유한다.
이렇게 하면, 모든 pod들은 다른 pod에서 있었던 세션들의 정보를 알고 있어서 세션 정보의 부재로 인한 문제점은 발생하지 않는다.
보통 레디스를 이용해서 관리를 하게된다.(레디스는 신이야..)
이 또한, 단점이 존재했다.
결국 다른 통신 포인트가 생기는 것이므로 응답시간이 지연될 수도 있다는 점이다.
로딩 시간에 따른 사용자 이탈에 관한 구글 리서치 자료에 따르면
- 3초 이상 32%
- 5초 이상 90%
- 6초 이상 106%
- 10초 이상 123%
로 이탈하게 된다고 한다.
이 점만 주의하면 될 것 같다.
결론
나는 위의 두 가지의 방법 중에 레디스 세션 클러스터링을 택해서 도입했다.
MSA와 쿠버네티스 환경을 구축했을 때에는 레디스 세션 클러스터링이 필수일 것 같다는 생각이 들었다.
쿠버네티스와 MSA에 관해서는 각각 해보았지만 둘 다 한 번에 도입한 적은 없어서 도전해보고 싶은 생각이 들었다.
