타입스크립트에서 JAR, EXE 파일 실행 제안

내용

현재 국민은행이 JAVA를 사용해 WAR(java 웹서버)로 구현되어 있는 방식을
타입스크립트로 서버를 띄울 수 있도록 변경 제안

기존 문제점

이전 리눅스 서버로 옮기면서 WAR파일, 톰캣 서버에 대해 알아야 변경 가능
또한 디버깅을 할 때 이클립스를 열어 java문제인지 확인해야합니다.
때문에 JAVA 개념 및 디버깅을 알아야함(유지보수 어려움)
담당자가 변경될 때 이클립스, 자바, 톰캣 설정을 따로 해줘야 하는 부분에도
많은 시간 소요(인수인계 어려움)
회사는 JAVA, WAR를 따로 쓰지 않기 때문에 유지보수에 용이하지 않다고 생각

개선

java로 관리하는 서버를 타입스크립트로 사용하는 방법을 구현
타입스크립트만 알면 유지보수가 가능

개선 이력

1. ikvm로 jar파일을 c#으로 읽어오려고 했지만 jar -> dll이 제대로 변환되지 않는 문제때문에 실패(jar자체에서 다른 라이브러리를 사용하는데 그런 코어 참조 라이브러리까지 dll로 변환이 불가능해 보입니다.)
   참조링크
2. nodejs로 jar파일을 불러오도록 구현.
   집에서 테스트 구현 완료했지만 회사에서 시도해보니 환경문제 발생
   문제 npm i java 가 안되는데 원인 찾기가 어렵습니다. 인증서 문제로 보입니다
   => 원인 확인 및 설치 완료. 테스트 구현은 X
   문제 해결 참조 링크(https://rottk.tistory.com/entry/nodejs-%ED%8C%A8%ED%82%A4%EC%A7%80-%EC%84%A4%EC%B9%98-%EC%98%A4%EB%A5%98%EB%93%A4)
   해당 방식으로 해결한 방법 도출 원리가 궁금해 댓글로 따로 질문드렸습니다.
3. 2번을 구현하는 도중 국민은행에서 exe파일로 서비스를 제공하는 방법이 있었습니다. 이 부분이 더 쉬워보여 ts로 exe파일을 사용하도록 구현(성공)

에러 발생 및 해결

중간 문제
그 전 에 켜진 파일들이 에러가 나 꺼지지않은채 메모리 확보 -> 메모리가 점점 줄어들어 에러가 계속 나고 있었던 상황
꺼지지 않은 모든 프로세스 킬
문제 및 솔루션 보고 메모리 확인 및 자바 힙, 스택 사이즈 조정

보고 결과

지금 회사 전체가 윈도우에서 리눅스로 이관중.
특별한 이유가 있으면 윈도우 서버를 열어주겠다.
그럼 기존에 비해 성능이 많이 좋아지나?

이 때 개발자의 유지보수만 생각하고 성능에 대해서 제대로 확인하지 못한 점을 깨닫고 그 뒤 성능테스트를 들어갔습니다.

성능 테스트

한 번에 API 호출 조회 가능한 수가 최대 100개(기능상 100개까지 조회하도록 제공)
exe를 10개 돌리는 것과 상관없이 하나의 exe를 명령어로 처리해 100개의 exe 프로세스가 생기는 상황 (CPU 100)
이미 컴퓨터에 부하가 걸려 문제되는 상황. 현재 띄어져있는 스테이지용 리눅스 jar도 가끔 실패, 성공할 때 오래걸림(로그 따로 없음)

java 서버 100개 1분
(java 서버 병렬처리제외하고는 요청 한번만 있고 DB조회도 많이 않아 그 외 작업시간은 아무리 길어도 5초가 넘지 않을 것 같습니다 100개 처리만 대략 55초로 예상)
CPU 부하는 테스트 서버로 체크(아래 글 참조)

로컬 PC - i5 8500 RAM 32G - 6코어 램32기가
exe사용하지 않을때(다른 프로세스들 사용) CPU 10퍼
5개씩 0.1초 슬립(CPU 피크 100 많이쳐서 시간 따로 X)

5개씩 0.3초 슬립(CPU 90 ~ 95 피크) 43초

2개씩 0.2초 슬립(CPU 평균 50~60 피크 70) 1분 17초

센터 리눅스와 동일 사양인 윈도우 서버(4코어 8기가) 58초
처리할동안 CPU 50~60 지속

현재 실 운영중인 서버와 사양이 같은 테스트 리눅스 서버 100개 돌렸을 때 cpu 약 15%

톰캣 서버 띄어 api 호출 방식

jar 외부 라이브러리를 참조해 서버를 띄어 해당 함수를 사용하는 개념으로 한번 연결 후 실행되고 요청을 계속 받는 방식이라 CPU 점유율 낮음
exe - 꺼져있는 프로그램을 실행시키는 방식

exe파일 실행 방식

exe파일이 실행될 때 마다 프로그램을 켜 매번 연결하고 요청 응답 후 종료해 cpu점유율이 높은것으로 보입니다.
매번 연결해 이 부분 차이가 큰 것으로 보입니다.

아래는 라이브러리 소스 일부

 

위 결과 확인 후 결론

결국 개발자 소스 유지보수는 편해질 수 있더라도 성능차이가 심하기 때문에 해당 제안은 폐기 되었습니다.

 

위 내용이 성능문제로 반영되지 않았지만 덕분에 많은 것을 얻었습니다.

무언가 제안을 해야할 때 그에 대한 확실한 근거들이 있어야 하는 점을 깨달았습니다.

그리고 개발자라면 당연히 성능먼저 확인을 해야한다는 부분을 놓쳤습니다.

성능은 당연히 기본적인 부분이라는 것을 간과했다가 이 번 기회에  확실하게 알게 되었습니다.