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

 

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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

300x250

'Trouble shooting' 카테고리의 다른 글

Sequence order 옵션에 따른 성능  (0) 2022.06.25
Partition truncate 시 온라인 거래 지연 이슈  (0) 2022.06.24
WAS Connection Pool 부족 현상  (0) 2022.06.24
MAX + 1 채번 이슈  (0) 2022.06.22
JS UI Rendering, Data bind  (0) 2021.10.06

몇 년 전 모 프로젝트에서 지원 요청이 와서 가서 보고, 얼마 전에 내 프로젝트에서도 발생한 걸 보면 아주 기초적인 사항임에도 생각보다 잘 지켜지지 않는 사항인가보다.

대기업 SI 프로젝트에 몸담고 있다보면 요즘 트렌드에 맞는 UI Framework는 써보기가 힘들고 매번 jQuery 기반으로 프로젝트를 하게 되는데 (인력 수급이 아직까지는 가장 용이함), jQuery 기반의 프로젝트에 업무 화면이 복잡해져서 하나의 프로그램에서 수행하는 XHR이 많아질 경우 생각보다 자주 발생하곤 한다.

 

'화면의 특정 영역에 데이터가 나오다가 말다가 해요'

 

A라는 해당 문서의 DOM을 초기화하는 함수가 있다.

B 함수는 서버에서 데이터를 받아와 DOM에 Binding 하는 함수이다.

 

function A() {

    //특정 조건에 따라 UI에 특정 영역을 더하거나 뺀다

}

 

function B() {

    //$.ajax 등의 함수로 서버와 통신하여 UI에 데이터를 Binding 한다.

}

 

생각보다 많은 개발자들이 아래와 같이 작성하고, 대부분의 경우에 올바르게 동작한다.

A();

B();

 

하지만 모바일 프로젝트를 하다보면 아주 많은 경우의 수가 발생한다.

휴대폰이 구형이라 브라우저 동작 자체가 느린 환경도 있고, 접속이 잘 안되는 Wi-Fi 를 사용해서 인터페이스가 느린 경우도 있다. 하여 순서가 반드시 보장되어야 하는 코드들은 정확한 타이밍에 callback 형식으로 작성하도록 한다.

위와 같은 경우에도 A에서 생성해야 할 Element가 생성되지 않은 상태에서 B 함수에서 Data Binding이 수행되는 경우가 발생하면 데이터가 표시되지 않는 경우가 발생한다.

 

function A(callback) {

    //특정 조건에 따라 UI에 특정 영역을 더하거나 뺀다.

    if (callback && typeof callback == 'function') callback();

}

 

function B() {

    //$.ajax 등의 함수로 서버와 통신하여 UI에 데이터를 Binding 한다.

}

 

A(B);

 

위와 같이 작성하면 UI Rendering이 완료된 후에 B 함수를 실행하므로 올바르게 동작한다.

300x250

+ Recent posts