왜 Spring 5를 업그레이드 해야했을까?
2022년 카카오 장애를 다들 기억할 것이다. 카카오톡 뿐만이 아닌, 많은 카카오 서비스가 안되었다. 그리고 안된 것은 카카오 서비스 뿐만이 아니였다. 카카오 로그인을 활용한 국내의 많은 서비스들이 정상적으로 동작하지 않았었다. 이 중 가장 문제가 심했던 것은 카카오 로그인이 안되었 던 것이지 않을까 싶다.
이 과제를 받을 당시에도 인증/인가와 관련된 팀이였기에 해당 장애가 더더욱 와닿았고 팀에서도 각종 장애를 대비하여 유연한 시스템을 만들기로 하였다. 팀에서는 Redis의 Dependency를 줄이는 작업을 진행하였다. 인증/인가는 필연적으로 Redis와 의존도가 가장 높았고 장애가 자주 나서 해당 Dependency의 우선순위는 매우 높았다. 팀에서 작업 후, Redis를 장애를 재현하였다. 정말 슬프게도,,,, 원하는 대로 동작하지 않았다. Jedis 때문이였다.
왜 Jedis가 문제일까?
Jedis는 멀티스레드 클라이언트이다. Jedis는 성능을 확보하기 위해 풀을 같이 사용하는 경우가 많다. 이때, 가장 많이 사용하는 풀은 Common DBCP이다.
자세히 보실 분은 해당 링크를 확인해주세요! D2 Naver Common DBCP Jedis & Jedis with Pool & Lettuce performance
Jedis의 설정 중 Client Abort Time, retry가 있다. 또한 DBCP의 MaxWaitMillis이 있다. 만약 성급한 최적화를 한다면 문제는 다음과 같이 발생할 수 있다.
- Redis의 장애
- Client Abort Time동안 Pool의 쓰레드가 기다림
- 기다린 후, Retry 설정에 의해 N번 시도
- 모든 Pool이 점유
- 모든 Redis 요청이 MaxWaitMillis동안 기다림
이렇게 되면 최악의 경우 사실상의 500ms내로 응답해야하는 정상적인 SLA를 보장할 수 없으며 이는 시스템의 전반적인 장애로 귀결된다.
팀에서는 안타깝게 이러한 설정들을 쓰고 있었기에 문제가 되었다. 더이상의 최적화는 힘들기에 결국 lettuce 이전을 하기로 하였다. 사내에서는 이를 wrapping한 Inhouse SDK를 사용해야했었고 최소 요구사항은 Spring 5였다. 하지만 팀에서 쓰고 있는 Spring의 버전은 4였다. 그렇게 나는 Spring 5로 업그레이드를 시작했다.