반응형
티스토리 에디터 진짜 한숨만 나옴 에디터를 잘 만들어 줄 수 없다면 노션에서 붙여넣기라도 예쁘게 갖다넣게 해주세요ㅠ
좀 전에 올렸던 세션 타임아웃의 연장선 !
개발자 분께 세션 관련해서 안내를 드리는 중간에 받은 충격적인 질문 ...
이중화를 하면..로그인한 상태에서 새로고침을 하면
다른 서버로 연결되어서 다시 로그인해야 하는 상황이 생기진 않나요?
음...
잠시 할 말을 잃었지만 빠르게 찾도록 한다.
네, 그런 일은 발생하지 않습니다.
인프라의 입장과 개발단의 입장은 다르므로, 이런 질문이 나오게 된 이유를 곰곰이 생각해 보았다.
새로고침할 때마다 세션이 새로 맺어진다고 생각하시는 걸까?
그렇게 생각하시게 된 데는 이유가 있을 거라 생각해서 소스를 뜯어보니
세션을 1초마다 날려버리거나 invalidate를 숨쉬듯 때리거나 하지는 않는 것으로 보였다.
그러면 로드밸런서에서 세션을 숨쉬듯 날려버리고 connection close 처리를 한다고 생각하시는 걸까?
그렇다면 이해가 가능하다. 혹시 티스토리의 세계에도 비슷한 생각을 하고 계신 분이 있을 수 있어 정리해 보았다.
해당 서비스는 운영환경에서 다중화로 구성을 하게 되면
LB에서 앞에 VIP(virtual ip)를 세워놓고 뒷단에 n대의 웹서버가 request를 받기 위해 대기하고 있는 형태가 될 것이다.
이 구조에서의 상황을 문답식으로 정리해 보도록 하자.
Q. 서버가 여러 대일 땐 제가 요청을 보냈던 서버에 어떻게 다시 요청을 보낼 수 있나요?
A. 로드밸런싱 로직에는 RR(round robin), weighted RR, ip hash, url hash, least connection 등
다양한 로직이 존재합니다. ip hash로 ip별로 꽂아줄 서버를 다르게 관리할 수도 있고(nginx에도 이 기능이 있어요),
나머지 방법으로 로드를 분산하면서 sticky session 등의 방식으로 커넥션을 맺었던 곳과 연결해 줄 수도 있습니다.
아니면 connection timeout 정책을 루즈하게 줘서 연결을 끊지 않는 방법도 존재합니다.
저희 운영환경은 그 중 {{ 대외비 }} 로직에 {{ 대외비 }} 정책을 추가하여 기존 서버와의 커넥션을 유지합니다.
따라서, 새로고침하셔도 tcp connection이 established 된 상태이므로 기존 서버에 다시 요청을 보냅니다.
관련된 읽기 추천:
https://www.f5.com/services/resources/white-papers/cookies-sessions-and-persistence
https://support.f5.com/csp/article/K13004262
Q. 제가 세션을 죽이지 않는 한 connetion은 영원히 유지되는 건가요?
A. 그렇지는 않습니다. 회사의 정책에 따라 달라지지만 로드밸런서는 기본적으로 부하를 분산하는 데 목적이 있으므로
timeout 정책이 있어 풀 멤버인 서버의 세션 타임아웃 정책과는 별개로
connection timeout이 일어나게 됩니다.
connection timeout 설정이 엉뚱하게 되어 있는 경우라면
잠시 작업을 하다가 한 5~6분 뒤에 돌아와 다시 작업을 하려고 하면 로그인이 풀려 있는(다른 서버로 연결된)
현상이 발생할 수 있습니다. 저희 환경은 이를 방지하기 위해 {{ 대외비 }} 정책을 차용하여
{{ 대외비 }} 마다 {{ 대외비 }} 하여 connection timeout을 방지합니다.
제가 알기로 F5에서 제공하는 디폴트 설정은 idle time 5분을 기준으로 하고 있습니다. (아니면 죄송.. 설정하기 나름임)
그래서 디폴트값 그대로 유지했다면 저희도 첫 질문같은 작업하다 중간에 로그인 풀리는 현상이 발생할 수 있었겠죠?
그렇다고 저걸 무한대로 유지하도록 한다면 그건 그거대로 문제입니다. current connection이 안 빠지는 기적을 발견할 수 있음
Q. 그럼 어차피 세션관리는 어플리케이션단에서 할 테니까 엄청 보수적으로 connection timeout 정책을 가져가도 되겠네요?
A. LB는 무슨 죄인가요?ㅠㅜ
+ F5 기준으로.. TCP connection established 상태인 애들을 current connections로 잡는데
이게 계속 유지되면 무중단 배포가 불가능해집니다. 커넥션이 안 빠진 상태에서 배포하시면
해당 서버에 물려있던 사용자들에게는 장애가 발생합니다. 항상 connection의 수를 최소로 가져가는 것을 타겟으로
정책을 고려하시면 되겠습니다 :)
반응형