미들웨어가 무엇이죠?🤭

IT기업에 입사를 하고 처음엔 미들웨어라는 용어 자체가 생소했다. 더군다나 구글링을 통해 이론적으로만 봤던 미들웨어는 도저히 이해할 수 없었다. OS, DBMS는 각각의 역할이 있음을 분명히 느꼈지만 미들웨어라는 용어는 너무나 광범위한 분야였기 때문이다.

먼저 사전적 정의를 잠깐 살펴보자면,

미들웨어는 양 쪽을 연결하여 데이터를 주고 받을 수 있도록 중간에서 매개 역할을 하는 소프트웨어, 네트워크를 통해서 연결된 여러 개의 컴퓨터에 있는 많은 프로세스들에게 어떤 서비스를 사용할 수 있도록 연결해 주는 소프트웨어를 말한다. 3계층 클라이언트/서버 구조에서 미들웨어가 존재한다. 웹 브라우저에서 데이터베이스로부터 데이터를 저장하거나 읽어올 수 있게 중간에 미들웨어가 존재하게 된다.

광범위한 설명이지만 운영을 하면서 느낀 바에 따르면, 위에 표시한 2개의 키워드가 미들웨어의 역할이라고 생각한다.

1. 양쪽을 연결
2. 중간에서의 매개 역할

큰 범위로 보면 매개체 간 연결해주는 레이어로써, 매개체는 클라이언트(사용자) - 서버, 서버 - 서버 간의 통신이 될 수도 있다.
통상적으로 기업에서 말하는 미들웨어 환경은 웹/어플리케이션 서버를 의미한다.

미들웨어가 나오게 된 배경 (feat. 3-Tier)

기존 웹 어플리케이션 운영 환경에서 사용자의 요청이 유입되는 순간부터 비즈니스 로직 처리, 데이터 처리 등을 모두 한 곳의 물리적 환경(서버)에서 통합 제공했다. 운영자의 입장에서 하나의 서버만 죽자고 운영하면 되니 관리 포인트가 1개라는 장점이 있었다.

👉🏻 과연 1개의 관리 포인트는 장점만 있을까?
바꿔서 생각하면 그 1개의 통합 서버에 문제가 생겼을 때 전체 서비스 장애로 이어지고, 어느 포인트에서 장애를 일으켰는 지 분석이 쉽지 않다.
여기까지가 1-Tier 구조 일때의 얘기다.

한 발자국 더 나아가 데이터 처리 분리를 하고 DBMS 만큼은 분리된 환경에서 제공하니 서비스 안정성이 증가했을 것이다.
그러나 간과한 부분이 있다.

우리에겐 아직 "1) 사용자의 요청이 유입되는 순간, 2) 비즈니스 로직 처리" 만큼은 통합된 서비스에서 제공 하기 때문이다.

예를 들어 우리가 네이버에 접속을 했을 때, 메인 페이지가 띄워지는 건 불과 5초 이내지만
사실은 무수히 많은 파일 호출, 네트워크 통신 등 우리 눈에 보이지 않는 곳에서 서버는 매우 바빴다.

www.naver.com을 입력하고 Enter를 치자마자, 단 2초만에 약 170개의 File Open이 발생되었다.

이렇게 동시다발적인 사용자의 호출이 쌓이게 되면 통합된 서비스에서도 부하를 받을 것이다.
따라서, 효율적인 서비스 처리를 위해 아래 기준대로 서비스를 나누게 되었다.
1️⃣ 사용자의 요청이 유입되는 순간 호출되는 앞단(Front-end)의 정적 페이지(html, css, js, png 등)를 전용으로 처리하는 서버
2️⃣ 로그인, 검색 등 데이터를 가공하고 처리하는 뒷단(Back-end)의 동적 페이지(jsp, servlet 등)를 전용으로 처리하는 서버

👉🏻 이렇게 3개의 관리 포인트로 쪼개진 것을 3-Tier 구조라고 하며, 위 두개의 서버는 각각 WEB Server / WAS를 의미한다.

미들웨어 담당자는 아래 그림에서의 Client - Database 사이에 위치한 WEB Server / WAS를 관리한다.

미들웨어 관리자가 왜 필요한가요?🤔

어차피 어플리케이션을 개발하고 운영하는건 개발팀에서 하는데 미들웨어 관리자가 따로 필요하나요?

맞는 말이다. (사실 필요 없다ㅎㅎ라고 말하면 일자리를 잃을 것 같다.)
하지만 크게 두 가지 관점에서 바라볼 때 적어도 MSA/DevOps가 도입된 클라우드 환경이 아닌 레거시 환경에서 운영을 하고 있다면 미들웨어 담당자는 "필요하다"라는 결론을 내고 싶다.

💻 개발 조직에서의 관점

👉🏻 비즈니스 로직을 구상하여 개발하기 바쁘다.
클라이언트의 요구사항이 중요한 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이 증가했습니다.

이런 내용으로 개발 조직과 커뮤니케이션한다면 서로 물음표만 가득할 것이다.

📢 결론

개발 조직 👉🏻 소스 개발/운영에 집중하고 사용자를 고려한 서버 튜닝과 분석을 맡길 수 있다.
인프라 조직 👉🏻 실제 유입되는 서비스를 알아채고 특정 로직이 수행되면서 인프라 영역에 문제가 된다를 통역해줄 수 있다.

즉, 미들웨어라는 분야답게 개발 <> 인프라 조직 간 중간 다리 역할을 수행하는 분야로써 필요하다고 생각한다.

Reference
1) https://ko.wikipedia.org/wiki/%EB%AF%B8%EB%93%A4%EC%9B%A8%EC%96%B4#:~:text=%EB%AF%B8%EB%93%A4%EC%9B%A8%EC%96%B4(%EC%98%81%EC%96%B4%3A%20middleware)%EB%8A%94,%EC%9D%84%20%EC%88%98%ED%96%89%ED%95%98%EB%8A%94%20%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EC%9D%B4%EB%8B%A4.
2) https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html