[Tech-Talk] 미들웨어(Middleware)

꼭 알고 있어야 하는 것들중 하나인 미들웨어에 대해 알아보겠습니다 🤩

미들웨어 자체에 품고 있는 뜻이 너무나 방대하다 보니 웹 브라우저 기준 미들웨어에 대해 풀어보겠습니다 !

우선적으로 미들웨어의 정의입니다.

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

글 내용에서 알 수 있다 싶이 핵심만 간단 요약하면 ‘양 쪽을 연결하여 중간에서 매개 역할을 함 즉, 웹 브라우저에서 데이터 베이스(DB)로부터 데이터를 저장하거나 읽어올 수 있다.’가 되겠네요.

넓은 범위로는 매개체 간 연결해주는 레이어로써 매개체는 클라이언트(사용자) - 서버, 서버 - 서버 간의 통신이 될 수도 있습니다.

미들웨어가 탄생하게 된 배경 (3-Tier)

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

👉 과연 1개의 관리 포인트는 장점만 있을까요?

생각의 관점을 달리하면 1개의 통합 서버에 문제가 생겼을 때 전체 서비스 장애로 이어지고, 어느 포인트에서 장애를 일으켰는 지 분석이 쉽지 않습니다. 1-Tier어 구조일 때 말이죠.

더 나아가 DBMS의 경우 분리된 환경에서 제공되니 서비스 안정성이 증가했을텐데 간과한 부분이 있습니다. 아직 ‘사용자의 요청이 유입되는 순간', ‘비즈니스 로직 처리' 만큼은 통합된 서비스에서 제공하기 때문입니다.

www.naver.com을 입력하고 Enter를 치자마자 1.8초만에 231개의 요청이 발생했습니다.

이렇게 동시다발적인 사용자의 호출이 쌓인다면 통합된 서비스에서는 부하를 받을 것입니다. 따라서, 효율적인 서비스 처리를 위해 아래 기준대로 서비스를 나누게 되었습니다.

사용자의 요청이 유입되는 순간 호출되는 앞단(Front-End)의 정적 페이지(html, css, js, png 등)를 전용으로 처리하는 서버
로그인, 검색 등 데이터를 가공하고 처리하는 뒷단(Back-End)의 동적 페이지(jsp, servlet 등)를 전용으로 처리하는 서버

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

이 사진은 여러분들에게 매우 익숙할 거예요. ~~제가 자주 애용했거든요 ㅎㅎ~~

여기서 미들웨어는 Client와 Database 사이에 위치한 Web Server와 WAS를 관리합니다.

미들웨어 장점으로

표준화된 인터페이스 제공 가능합니다.
다양한 환경 지원, 체계가 다른 업무와 상호 연동이 가능합니다.
분산된 업무를 동시에 처리 가능하여 자료의 일관성이 유지됩니다.
부하의 분산이 가능합니다.

미들웨어 종류

1. 원격 프로시저 호출(Remote Procedure Call, 약칭 RPC): 클라이언트가 원격에서 동작하는 프로시저를 호출하는 시스템. 동기 또는 비동기를 지원합니다.

2. 메시지 지향 미들웨어(Message Oriented Middleware, 약칭 MOM): 클라이언트가 생성한 메시지는 저장소에 요청할 때 저장하면서, 다른 업무를 지속할 수 있도록 하는 비동기식 미들웨어입니다.

3. ORB(Object Request Broker): 객체지향 시스템에서 객체 및 서비스를 요청하고 전송할 수 있도록 지원하는 미들웨어입니다.

4. DB 접속 미들웨어: 애플리케이션과 데이터베이스 서버를 연결해주는 미들웨어입니다.

또다른 분류법

1. TP모니터(Transaction Processing(TP) monitor): 분산 시스템의 애플리케이션을 지원하는 미들웨어. 주로 C/S 시스템에 사용됩니다.

2. 웹 애플리케이션 서버(Web Application Server): 웹 애플리케이션을 지원하는 미들웨어입니다.

3. 엔터프라이즈 서비스 버스(Enterprise Service Bus): 메시지 기반으로 느슨한 결합형태의 표준 인터페이스 통신을 지원하는 미들웨어로 기업 안팎에 있는 모든 시스템 환경을 연동하는 미들웨어입니다.

TP모니터란?

각종 프로토콜에서 동작하는 세션과 시스템과 데이터베이스 사이의 최소 처리단위인 트랜잭션을 감시하여 일관성있게 보관 유지하는 역할을 하는 트랜잭션 관리 미들웨어입니다.

Front-End, Back-End 미들웨어

Front-End

모던애자일 3기 프로젝트 기술 스택 중 하나인 리덕스에서 미들웨어가 어떻게 사용되는지 간략하게 작성해 볼게요

~~(저는 Back-End 팀이라 Front-End는 자세히 모르..~~)~~

미들웨어는 액션(action)과 리듀서(reducer) 함수 사이의 중간자 라고 합니다. 미들웨어를 통해 전달받은 액션을 콘솔에 기록하거나 취소 혹은 다른 종류의 액션을 추가적으로 디스패치(dispatch)할 수 있습니다.

리덕스에서 미들웨어는 액션을 디스패치했을 때 리듀서에서 이를 처리하기에 앞서 사전에 지정된 작업들을 실행합니다.

리덕스 미들웨어의 구조

// 미들웨어 기본 구조
const loggerMiddleware = store => next => action => {
    // 하고자 하는 작업
};

위 코드의 화살표 함수를 풀어서 쓴다면 다음과 같은 구조입니다.

const loggerMiddleware = function loggerMiddleware(store){
    return function(next) {
    return function(action){
         // 미들웨어 기본 구조

        };
    };
};

미들웨어는 결국 함수를 반환하고 함수를 반환하는 하나의 함수입니다.

여기에 있는 함수의 파라미더들은 어떤 역할을 하는가?

store

리덕스 스토어 인스턴스이며 애플리케이션의 전역 상태이고, dispatch, getState, subscribe 등 내장 함수들이 존재합니다.

next

액션을 다음 미들웨어에게 전달하는 함수이며, next(action) 형태로 사용합니다.

next(action)을 호출하면 그다음 처리해야 할 미들웨어에게 액션을 넘겨주고, 만약 그다음 미들웨어가 없다면 리듀서에게 액션을 넘겨주는 형태입니다.

action

action은 현재 처리하고 있는 액션 객체를 의미합니다.

미들웨어를 직접 만들어서 사용해도 되지만, 오픈 소스 커뮤니티에 올라와 있는 redux-logger를 사용하는 것이 훨씬 좋습니다.

브라우저 콘솔에 나타나는 형식이 깔끔하며 잘 만들어진 라이브러리입니다.

redux-logger

Logger for Redux. Latest version: 3.0.6, last published: 5 years ago. Start using redux-logger in your project by running `npm i redux-logger`. There are 2428 other projects in the npm registry using redux-logger.

www.npmjs.com

Back-End

웹 개발에서 일반적으로 미들웨어라 함은 라우트 핸들러가 클라이언트의 요청을 처리하기 전에 수행되는 컴포넌트를 말합니다.

💡 라우트 핸들러는 웹프레임워크에서 사용자의 요청을 처리하는 엔드포인트(쉽게 이야기해서 URL)마다 동작을 수행하는 컴포넌트를 말합니다.

라우트 핸들러가 요청 경로와 컨트롤러를 매핑해 준다고 이해하면 됩니다.

Nest의 미들웨어는 기본적으로 Express의 미들웨어와 동일합니다. Express 문서에는 미들웨어가 다음과 같은 동작을 수행할 수 있다고 기술되어 있습니다.

어떤 형태의 코드라도 수행할 수 있습니다.
요청과 응답에 변형을 가할 수 있습니다.
요청-응답 주기를 끝낼 수 있습니다.
여러 개의 미들웨어를 사용한다면 next()로 호출 스택상 다음 미들웨어에게 제어권을 전달합니다.

요청-응답 주기를 끝낸다는 것은 응답을 보내거나 에러처리를 해야 한다는 뜻입니다. 만약 현재 미들웨어가 응답 주기를 끝내지 않을 것이라면 반드시 next()를 호출해야 합니다. 그렇지 않으면 어플리케이션은 더이상 아무것도 할 수 없는 상태(hanging이라고 표현합니다)가 됩니다.

nest에서 미들웨어를 활용하여 다음과 같은 작업들을 수행할 수 있습니다.

쿠키 파싱: 쿠키를 파싱하여 사용하기 쉬운 데이터 구조로 변경합니다. 이를 이용하면 라우터 핸들러가 매번 쿠키를 파싱할 필요가 없습니다.
세션 관리: 세션 쿠키를 찾고, 해당 쿠키에 대한 세션의 상태를 조회해서 요청에 세션 정보를 추가합니다. 이를 통해 다른 핸들러가 세션 객체를 이용할 수 있도록 해 줍니다.
인증/인가: 사용자가 서비스에 접근 가능한 권한이 있는지 확인합니다. 단, Nest는 인가를 구현할 때 가드(Guard)를 이용하도록 권장하고 있습니다.
본문(body) 파싱: 본문은 POST/PUT 요청으로 들어오는 json 타입뿐 아니라 파일 스트림과 같은 데이터도 있습니다. 이 데이터를 유형에 따라 읽고 해석한 다음 파라미터에 넣는 작업을 합니다. 앞서 컨트롤러 장에서 보았던 본문은 이렇게 분석된 결과가 포함되어 있습니다.

그 외 원하는 기능이 있다면 직접 구현도 가능합니다. 커스텀 미들웨어를 잘 만들면 도메인에 관심사를 집중하여 어플리케이션을 작성할 수 있습니다.

Logger 미들웨어

미들웨어는 함수로 작성하거나 NestMiddleware 인터페이스를 구현한 클래스로 작성할 수 있습니다. 들어온 요청에 포함된 정보를 로깅하기 위한 Logger를 미들웨어로 구현해 봅시다.

import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';

@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log('Request...');
    next();
  }
}

미들웨어를 모듈에 포함시키기 위해서는 해당 모듈은 NestModule 인터페이스를 구현해야 합니다. NestModule에 선언된 configure함수를 통해 미들웨어를 설정합니다.

logger.middleware.ts

import { MiddlewareConsumer, Module, NestModule } from '@nestjs/common';
import { LoggerMiddleware } from './logger/logger.middleware';
import { UsersModule } from './users/users.module';

@Module({
  imports: [UsersModule],
})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer): any {
    consumer
      .apply(LoggerMiddleware)
      .forRoutes('/users');
  }
}

/users 경로로 들어오는 요청을 수행해 보면 콘솔에 Request... 이 찍히는 걸 확인할 수 있습니다.