중복 로그인 체크 오류

SI 업체에서 진행한 프로젝트를 인수인계 받아서 운영하던 초기에 간헐적으로 자신의 아이디가 중복 로그인되어 로그인이 끊어진다는 민원이 들어왔다. B2C 사이트이고 뭔가 보안에 문제가 있을 수도 있으니 얼른 프로그램들을 검토해 보았으나 특이점이 없었다.

 

일반적으로 동시에 동일한 아이디를 사용하지 못하게 하는 부분은 jSessionId와 사용자 아이디 등의 조합으로 체크하여 현재 접속해 있는 jSessionId와 다른 값으로 동일한 사용자 정보로 거래를 시도하면 먼저 로그인 해있던 접속을 종료시키는 방법을 흔히들 사용한다.

 

일단은 먼저 해당 현상을 재현해 보려고 하였으나 재현이 되질 않았다. 사실 프로그램을 봐도 너무 단순한 비교를 하고 있어서 의도와 다르게 동작하는 경우가 잘 떠오르질 않았다.

 

처음 의심이 된 부분은 제우스의 세션 클러스터링 부분 이었다. 대용량 서비스이다 보니 AP가 여러 대로 이중화되어 있었고 세션 복제가 정상적으로 이루어지지 않으면 해당 고객의 접속 인스턴스가 변경이 될 때 위와 같은 오류가 발생할 수 있을 것 같았다.

 

하여 프로젝트에서 철수하지 않은 AA와 엔지니어 쪽으로 문의하였으나 세션 클러스터링 기능은 정상적으로 설정되어 있고 동작도 확인이 되었다고 한다. 더구나 스위치 설정도 Sticky라 고객이 동일한 접속을 사용할 경우 접속 인스턴스가 변경되지도 않을 것 같았다.

 

그러던 차에 CS팀의 협조를 얻어 고객 한 분의 접속 시간 대와 IP 주소를 제공 받을 수 있었고, 해당 정보로 인터맥스로 특이사항을 찾아보니 해당 오류가 있었던 시간에 해당 고객의 접속 인스턴스가 변경되어 있었다!!

일반적으로 Sticky 설정에서 접속 인스턴스는 유지되지만 Class 적용으로 인한 WAS Restart나 운영 상의 이유로 Rstart가 필요한 경우 롤링 방식으로 진행하기 때문에 그 시간과 맞아 떨어지면 인스턴스가 변경이 되기도 한다.

 

하지만 인스턴스가 변경이 되더라도 세션 복제가 정상적으로 수행된다면 문제가 되지 않을 부분이었으므로 임시적으로 운영 서버에 관련 로그를 남기고 모니터링을 해서 원인을 찾을 수 있었다. 제우스는 인스턴스 별로 jSessionId 뒤 쪽에 .으로 구분해서 인스턴스의 아이디도 남긴다고 한다.

xxxxxxxxxxxxxxxx.yyyy 같은 식이다. 하여 . 앞 부분은 인스턴스가 변경되어도 동일하나 뒷 부분은 인스턴스 별로 관리되는 값이라고 한다.

 

프로그램을 변경하여 . 앞 부분만 비교하도록 변경하여 해당 건도 무사히 대응할 수 있었다.