실무 경험을 쌓기 전까지는 미들웨어가 상당히 낯설게 느껴졌다. 애플리케이션 레벨과 인프라 레벨 사이에서 작동하는 무언가 정도로만 막연하게 생각했을 뿐이다. 그러나 실제 업무에서 미들웨어를 접하고 다뤄보면서 흥미롭고운 분야라는 생각이 들었고, 제대로 정리해보고 싶었다. 그래서 오늘은 시스템에서 중추적인 역할을 수행하는 미들웨어에 정리해보려 한다.
What is Middleware?
미들웨어를 간단히 정리하자면 “서로 다른 시스템 간의 중개자 역할을 하는 소프트웨어”다. 애플리케이션, 데이터베이스, 사용자 인터페이스 등 서로 다른 컴포넌트들이 원활히 통신하고 협력할 수 있도록 돕는다. 우선 미들웨어(MW)의 사전적 정의는 다음과 같다.
💡 미들웨어는 양 쪽을 연결하여 데이터를 주고 받을 수 있도록 중간에서 매개 역할을 하는 소프트웨어, 네트워크를 통해서 연결된 여러 개의 컴퓨터에 있는 많은 프로세스들에게 어떤 서비스를 사용할 수 있도록 연결해주는 소프트웨어를 말한다. 3 계층 클라이언트/서버 구조에서 미들웨어가 존재한다. 웹 브라우저에서 데이터베이스로부터 데이터를 저장하거나 읽어올 수 있게 중간에 미들웨어가 존재한다.
여기서 핵심 키워드는 매개 역할 이라고 생각한다. 미들웨어(middleware)는 SW 애플리케이션 간의 중개자(매개) 역할을 하는 소프트웨어로서, 시스템 내에서 필수적으로 데이터 흐름과 통신을 조율하며, 이를 통해 시스템의 안정성과 확장성을 보장한다.
미들웨어가 등장한 배경
1-Tier 구조에서는 사용자의 요청과 데이터 처리가 하나의 서버에서 이루어진다. 기존의 웹 애플리케이션 운영 환경에서는 사용자의 요청이 유입되는 순간부터 비즈니스 로직 처리, 데이터 처리 등을 모두 한 곳의 물리적 환경(서버)에서 제공했다. 운영자의 입장에서 하나의 서버만 죽자고 운영하면 되니, 관리 포인트가 1개라는 장점이 있었다.
그러나 이 1개의 관리 포인트는 장점만 있지는 않았다. 통합 서버에 문제가 생길 경우, 전체 서비스 장애(Single Point of Failure, SPOF)로 이어질 수 있고, 장애 발생 시 원인 분석이 쉽지 않다.
한 발짝 더 나아가 데이터 처리를 분리하고 DBMS를 분리된 환경에서 제공하게 되면서 서비스 안정성이 증가하긴 했지만, 여전히 1) 사용자의 요청이 유입되는 순간과 2) 비즈니스 로직 처리는 통합된 서비스에서 제공해야 했다.
예를 들어, 우리가 구글에 접속했을 때 메인 페이지가 띄워지는 건 불과 5초 이내지만, 사실 그 뒤에는 무수히 많은 파일 호출과 네트워크 통신이 발생하고 있다. 우리 눈에 보이지 않는 곳에서 서버는 매우 바빴고, 이러한 요청이 동시다발적으로 쌓이게 되면 통합 서비스도 부하를 받을 수 밖에 없다.
따라서 효율적인 서비스 처리를 위해 다음과 같이 서비스를 나누게 되었다.
- 사용자 요청이 유입되는 순간 호출되는 앞단(FrontEnd)의 정적 페이지(html,css,js,png 등)를 전용으로 처리하는 서버
- 로그인, 검색 등 데이터를 가공하고 처리하는 뒷단(BackEnd)의 동적 페이지(jsp,servlet 등)를 전용으로 처리하는 서버
이렇게 3개의 관리 포인트로 쪼개진 것을 3-Tier 구조라고 하며, 위 두개의 서버는 각각 WEB과 WAS를 의미한다.
Middleware의 주요 역할
앞서 말했듯이 미들웨어는 SW 애플리케이션 간의 중개자(매개) 역할을 하는 소프트웨어이다. 미들웨어는 대표적으로 다음과 같은 역할을 수행할 수 있다.
✔️ 데이터 전송
클라이언트와 서버 간의 데이터 전송을 관리한다. 예를 들어 Nginx를 통해 클라이언트의 요청을 받아서 백엔드 서버로 전달하고, 서버의 응답을 다시 클라이언트에게 전달하는 역할을 할 수 있다.
✔️ 통신 관리
분산 시스템에서 여러 서버가 서로 통신해야 할 때, 통신을 관리한다. 예를 들어 RabbitMQ, Kafka 등을 통해 메시지를 비동기적으로 전송하고 수신하는 역할을 할 수 있다.
✔️ 웹 애플리케이션 처리
클라이언트의 요청을 처리하고 동적 웹 콘텐츠를 생성한다. 예를 들어 Tomcat은 사용자가 요청한 URL에 대해 적절한 서블릿을 찾아 실행하고, 그 결과를 클라이언트에게 반환하여 동적 페이지를 생성하는 역할을 한다. (Tomcat은 미들웨어보다는 WAS라고 설명하는 경우가 많긴 하다)
미들웨어 담당자는 왜 필요할까?
이 부분에 대해서는 너무 공감되게 정리된 글이 있어 가져와보았다.
💡 어차피 애플리케이션을 개발하고 운영하는 건 개발팀에서 하는데, 미들웨어 관리자가 따로 필요할까?
개발 조직에서의 관점
✔️ 비즈니스 로직에 집중해야 한다.
클라이언트의 요구사항이 중요한 SI/SM 업체의 경우 “비즈니스 로직을 끼워 맞춘다”라고 말할 정도로 개발의 효율성보다는 로직을 처리하는데 시간과 노력이 많이 소요된다. 특히 금융, 커머스, 포털 등 이용자가 많을 수록 서비스의 중요성은 높아진다. 이 상황에서 개발한 소스가 정상적으로 작동되게끔 만들고 거기에 성능 퍼포먼스까지 내라고 하면… 뒷말은 생략한다.
✔️ 장애 발생 시 문제 범위가 광범위 하다.
서비스 운영 중 과도한 요청으로 인해 페이지가 열리지 않는 장애가 발생할 수 있다. 이때 실 서버의 자원 사용률은 여유가 있지만 WEB/WAS에 설정된 동시 사용자 수 제한을 초과하거나, DB Connection Pool 부족 등의 소스 내부에서 검출할 수 없는 문제들이 발생할 수 있다. 개발 조직에서 광범위한 시야를 가지고 이런 문제를 직면해야 한다면 서비스 복구, 원인 분석에 많은 시간과 애를 먹을 것이다.
인프라 조직에서의 관점
✔️ 어떤 서비스가 유입되고 호출되는 지 모른다.
인프라 조직 내부에서도 NW, HW, Hypervisor, OS, DB, MW로 나뉠 만큼 레이어별로 쪼개져 있다. 미들웨어 담당자가 없는 상황에서 서비스 유입이 들어올 때 각 파트에서는 아래와 같은 반응일 것이다.
- NW : 해당 IP의 네트워크 트래픽 세션이 증가했네요.
- HW/OS : Disk I/O가 증가했구요. CPU/Memory 사용률이 상승했습니다.
- DB : Select 및 DML Query가 지속 유입되구요. Active Session이 증가했습니다.
이런 내용을 개발 조직과 커뮤니케이션 한다면, 서로 물음표만 가득할 것이다. 서로의 상황을 이해하기가 어려운 것이다.
정리하자면
- 개발 조직 : 소스 개발/운영에 집중하고 사용자를 고려한 서버 튜닝과 분석을 맡길 수 있다.
- 인프라 조직 : 실제 유입되는 서비스를 알아채고 특정 로직이 수행되면서 인프라 영역에 문제가 된다를 통역해 줄 수 있다.
결론적으로, 미들웨어는 개발과 인프라 조직 간의 중간 다리 역할을 수행하는 분야로써 필요하다고 생각한다. 이것이 바로 AA(Application Architect)의 역할 중 하나이다. AA는 TA(Technical Architect, 인프라 담당자), SE(Software Engineer, 응용 개발자) 사이에서 중간자 역할을 한다. 실무를 쌓아가면서 미들웨어의 중요성을 느끼고 있다.
Reference