미들웨어 기초

미들웨어 영역 다양한 유형의 솔루션

• 3-tier 구조에서 정적 콘텐츠(이미지 등)은 Web 서버에서 처리하는 것이 바람직하다
• 클라우드 전환 시 WAS 세션 Cluster는 외부 저장소 이용하는 방향으로 변경이 필요하다
• ESB(Enterprise Service Bus)는 기업 내의 다양한 디지털 서비스를 상호 간에 연결하기 위한 기술이다
• TP-Monitor 미들웨어는 트랜잭션 처리/관리에 특화된 제품이다

미들웨어 솔루션

• 정적 컨텐츠(이미지 등)는 web 서버에서 처리하거나 cdn에서 처리하는게 바람직
• node.js는 크롬 v8엔진을 기반으로 javascript를 서버 상에서 수행하여 응용 프로그램을 서비스한다
• jvm 기반의 was 미들웨어는 통상 multi-thread 기반이므로 multi-core 수량이 많아야 유리하다
• msa에서 비동기 통신을 위해서는 kafka나 rabbitMQ와 같은 메시징 큐를 사용한다

WEB/WAS 성능 관련 요소

• WEB 서버에서 MaxClients(MaxRequestWorkers) 설정은 일반적으로 사용자 한명이 Web Server Thread를 여러 개 사용한다(브라우저마다 차이는 있으나 보통 2~4개)
• WEB 서버의 keepalive 타임아웃을 너무 크게 설정할 경우 서버에 연결된 네트워크 연결 수가 크게 증가하게 되고 file descriptor 사용 수도 같이 증가하기 때문에 한계 도달 시 네트워크나 파일을 열 수 없어 에러가 발생한다.
• WAS 서버의 maxThreads를 너무 크게 설정하면 thread 간 context-switching이 빈번하게 발생하며 여유 thread 관리를 위한 오버헤드가 발생한다
• DB Connection Pool의 최대 연결 개수는 WAS의 최대 Thread 개수를 넘지 않도록 설정하고 불필요하게 DB Connection 을 생성해서 사용할 필요는 없다
• WAS와 DB 사이의 방화벽이 있거나 네트워크 장비의 idle session timeout이 짧게 설정되어 있는 경우 idle db connection이 비정상적으로 끊어져 응용 에러가 발생할 수 있다

web/was 주요 기능

• web server의 virtual host 기능은 하나의 web server를 이용하여 여러 개의 도메인 명을 호스트함으로써 마치 여러 개의 web server를 사용하는 것처럼 해주는 기능
• was를 업무 그룹 단위로 개별 인스턴스로 분리하여 구성하는 경우 web server에서 url 기반으로 was plug-in 을 통해 배분 구성하는 것이 일반적
• 과다한 세션 개수를 사용하거나 세션에 많은 데이터를 저장하는 경우 서비스 was나 세션 서버의 OutOfMemory 원인이 되기 때문에 session-timeout은 가능하면 짧게 설정한는 것을 권고
• WAS와 DB 사이에 방화벽이 있거나 네트워크 장비의 idle session timeout이 짧게 설정되어 있는 경우 idle DB connection이 비정상적으로 끊어져 응용 에러가 발생할 수 있다
• WAS의 JDBC Connection Pool 설정 중 validationQuery, testWhileIdle 등의 파라미터를 설정하여 주기적으로 DB connection 유효성을 체크해야 함

오픈한 시스템의 WAS 서버에서 아래와 같은 에러 메시지가 미들웨어 로그에서 간헐적으로 발견되어 대응이 필요하다

• web 서버와의 연계를 위한 thread pool의 최소/최대 설정값을 확인하고 최대 설정값을 줄여서 모니터링 함
• 미들웨어 구축/운영 중 일반적으로 발생하는 file descriptor 부족에 의한 에러 사례 기반 문항. nw 연결을 위한 socket은 전부 file로 처리하는 os의 특성을 이해하고 부족에 따른 조치 가능 여부 측정

API Gateway

MSA Outer Architecture 주요 요소로 API Gateway가 있다. API gateway 주요 기능으로 사용자 트래픽을 제한할 수 있는 rate-limit 기능이 있다. 이에 대한 설명

• leaky bucket은 유입되는 요청을 queue에 저장하고 하나씩 처리하는 방법으로 queue가 차게 되면 추가되는 요청은 유실된다
• 최신의 요청을 먼저 처리하는 fixed window는 호출 급증 시 요청이 두번 호출되는 경우가 발생할 수 있다
• 호출 회수를 정확하게 설정하기 위해 sliding log를 활용하기도 하나 로그를 저장하고 처리하기 위한 비용 부담으로 인해 대용량 처리에는 부적절하다
• sliding window는 fixed window 의 낮은 처리비용과 sliding log의 향상된 기능을 조합한 하이브리드 알고리즘으로 유연한 확장이 가능하고 타 알고리즘의 단점을 커버하는 알고리즘으로 대규모의 클러스터 환경에 권장하는 방식이다

API Gateway는 사용자 UI에서의 요청을 매우 효율적으로 microservice 기반 application에 전달할 수 있도록 한다. 대규모 환경으로 확장할 경우, mobile client, web client 등으로부터 다양한 요구사항을 처리하기 위해 많은 API가 추가되어야 하는데 이렇게 되면 사실상 기존 모놀로식 어플리케이션 아키텍처와 비슷하게 변모할 가능성이 있다. 개선방안

• API gateway를 비지니스나 client 앱 단위로 나누어 분산 or BFF(Backend ofr Frontend) 아키텍처 패턴 적용한다
• 대규모 환경에서 API Gateway 확장에 대한 문제로 API Gatway를 분리하여 구성하여야 하고 모든 내부 MicroService 에 대해 단일 API Gateway가 사용되는 것은 지양되어야 한다. API Gateway 계층에서 API Gateway를 여러 개로 분할하면 서로 다른 이기종의 클라이언트 앱 또는 상이한 비지니스 로직의 요청에 대해 다른 응답을 처리할 수 있다. 이러한 패턴을 BFF(Backend for Frontend) 패턴이라 한다