3주 회고(3/4~3/23)

3주 회고(2019-03-04~2019-03-23)

• 늦은 회고
• EAI 구축
• VDI 환경 구축
• DB 메모리 락

늦은 회고

급작스러운 경주 출장으로 인하여 회고가 무려 3주치가 밀리게 되었다.

1. EAI 코드 신규 작성

갑자기 고객사쪽에서 EAI 고도화 사업을 추진한다고 EAI 인터페이스가 모조리 바뀐다는 소식이 본사로 날아들었다. 이게 왜 큰일인가하면..

• EAI 정의 - 영문위키

고객사쪽은 대략적으로 아래와 같은 구조를 가지고 있으며

SAP DB <-> RFC Function <-> EAI Server <-> 협력사 시스템

협력사 시스템에서는 EAI Server를 향해 사전 정의된 파라미터를 통해 URL로 호출하고 데이터를 받거나 전달하는 구조를 가지고 있다. 그런데 EAI Server의 인터페이스가 바뀌게 된다면 협력사 시스템에서 EAI Server를 호출하는 코드가 어찌되던간에 바뀐다는 이야기였다.

문제는 대부분의 협력사 시스템은 SAP DB에서 데이터를 참조하는게 대부분이며 여기에 접근하기 위한 EAI Server에 굉장히 의존적이라 EAI Server에 조금이라도 장애가 발생하면 아무리 협력사에서 대비한다한들 반드시 영향을 받게되는것이다. 하물며 인터페이스가 바뀌는데 그 영향은 이루 말할 필요도 없을것이다. EAI Server와 통신하는 코드를 다 뜯어고쳐하는것이다. 만약 고치지 못한다면?? 그날로 서비스 종료다.

무튼 이러한 이유로 본사에서 나를 긴급하게 경주로 보내게 되었다. 사태 파악과 코드 변경을 위해서였다. 빠르게 경주에 도착하여 한전 KDN쪽에서 제공하는 EAI Server와 통신을 위한 java 라이브러리 코드를 제공받았다.

파악결과 아래와 같은점이 변경되었다.

• Broker 기반에서 IData (참고 링크) 기반으로 변경

• 일관적인 인터페이스명 -> 접근하는 SAP 모듈에 따라 분류되어 새로운 명칭 부여

  • ex : PM 모듈이면 PM.XXXX

변경사항은 파악되었고 이제 작업을 할 시간이다. 이번에 중점을 둔 사항은 아래와 같았다.

1) 기존 백엔드 코드의 변경 최소화 : 당연한 이야기지만 백엔드 코드를 건드리게되면 겉잡을 수 없는 변경점이 발생하게 될것이다. (그리고 나는 디버깅 지옥에 빠지겠지)

2) 코드 가독성 확보 : 입사한 이래로 현 시스템과 EAI Server와 통신하는 코드는 한 페이지에 만줄이 넘어가는 라인이 다 들어가 있어서 디버깅이나 코드 수정이 너무 어려웠다.

3) 더이상 사용되지 않는 함수 삭제 : 개발이 진행되면서 더이상 사용되지 않는 코드들도 많아 정리가 필요하다.

라이브러리를 분석하고나니 그렇게 어려운 부분은 없었다. IData를 탐색하는 재귀함수를 작성하여 데이터를 리턴하게 하였고 호출 인터페이스 함수마다 별도의 클래스로 따로 코드를 분할하여 가독성을 향상시켰다. 다른부분은 몰라도 가독성을 향상시킨 부분만큼은 지금 생각해도 뿌듯하다. 그 외에 더이상 사용되지 않던 코드들도 이번 기회에 정리하였다.

2. VDI 환경 구축

사실 1번과 연계되는 사항인데.. 한참 EAI 코드 수정중에 현재 근무하고 있는 사무실의 PC를 모조리 교체하고 VDI 환경으로 바꾼다는것이다. 뭐 어쩌랴.. 을의 슬픈 현실이다. 바꾼다는데 별 도리가 없다. 만약 VDI 환경으로 바뀌게 되면 해당계정과 방화벽을 모두 새로 신청해야하는것이다. 물론 업무환경 + 개발환경을 다시 구축해야하는건 덤이다.

결국 1주일동안 아무것도 못하고 VDI환경 구축에 매달렸다. EAI는 코드는 다 만들었으나 EAI Server(개발) 과의 통신 테스트는 절반정도밖에 진행하지 못했다.

3. DB 메모리 락

지난달부터 괴롭혀온 데이터베이스의 쿼리 리턴이 엄청나게 느려진 원인을 파악할 수 있었다.

DB를 차근히 모니터링한 결과 대기중인 태스크가 순간적으로 폭증하여 평소에 거의 0에 가깝던 수치가 2000000 까지 상승하는것을 확인 할 수 있었다. 그럼 왜 대기중인 태스크의 수치가 폭발하고 있는것인가? 원인을 찾기위해 구글링중 이곳을 참조하여 찾을 수 있었다. sys.dm_os_waiting_tasks

이 쿼리를 실행하니 아래의 항목이 엄청난 대기시간을 가지고 있는것을 확인하였다.

RESOURCE_SEMAPHORE

다른 동시 쿼리로 인해 쿼리 메모리 요청을 즉시 허용할 수 없는 경우에 발생합니다. 대기 수가 많고 대기 시간이 길면 동시 쿼리 수 또는 메모리 요청 양이 과도하게 많은 것입니다.

그러니까 메모리가 부족하거나 메모리를 너무 많이 사용하고 있는것이라고 볼 수 있다.

이때까지 쌓인 정보로 추측하건데, SAP에서 자료를 동기화하는 과정에서 시스템 자체적으로 관리하는 버전이 너무 많이 쌓이게 되었으며, Partition By를 통해 데이터를 가지고 오는과정에서 메모리의 과다점유 현상이 발생한것이라고 보인다.

그래서 우리팀 개발자들과 머리를 맞대어 논의한 결과(물론 텔레그램으로) DB에 쌓인 쓸모없는 버전 데이터를 지우자고 결론이 났다. 물론 이걸 지우는작업은 또 다른 고민을 낳게 되어 사람 환장하게 만들게 되는데 이 이야기는 다음에 하기로 하겠다.

참조 DB 가이드