3-Tier Architecture - 웹 서버, WAS, 그리고 미들웨어의 역할

3-tier architecture는 클라이언트-서버 시스템을 3개의 논리 계층으로 분할하는 아키텍처 패턴입니다.

1. 3-Tier Architecture

🔄 3-Tier 아키텍처의 구성 요소

1. Presentation Tier (프레젠테이션 계층)
   • 사용자 인터페이스와의 상호작용을 담당합니다. 사용자의 요청을 받고, 결과를 표시합니다.
   • 웹 브라우저에서 실행되는 HTML, CSS, JavaScript로 구성된 클라이언트 애플리케이션.
2. Logic Tier (비즈니스 로직 계층)
   • 애플리케이션의 핵심 비즈니스 로직을 처리합니다. 사용자의 요청을 처리하고, 데이터베이스와 통신하여 요청된 데이터를 가공하거나 추가적인 비즈니스 로직을 수행합니다.
   • 웹 애플리케이션 서버(WAS)에서 동작하는 Java, .NET, Python 등으로 작성된 비즈니스 로직.
3. Data Tier (데이터 계층)
   • 데이터베이스 서버로부터 데이터를 읽고, 저장하고, 관리합니다.
   • 데이터베이스 관리 시스템(DBMS)인 MySQL, Oracle, PostgreSQL 등.

📍 Tier와 Layer의 차이

• Tier: 물리적인 분리를 의미합니다. 예를 들어, 각 계층을 다른 서버나 환경에 배포하여 물리적으로 분리합니다.
• Layer: 논리적인 분리를 의미합니다. 같은 물리적 서버에서 계층을 논리적으로만 나누는 경우가 해당됩니다.

💎 3-Tier 아키텍처의 장점

• 각 계층의 독립적인 업데이트 가능
  • 한 계층의 변경이 다른 계층에 영향을 미치지 않기 때문에, 특정 계층의 기술 스택을 쉽게 업데이트할 수 있습니다.
• 전문성 분리
  • 각 계층의 개발을 별도의 팀이 담당할 수 있어, 팀의 전문성에 따른 업무 분담이 가능합니다.
• 확장성 (Scalability)
  • 특정 계층의 성능을 높이거나, 서버를 추가하여 스케일업 및 스케일아웃이 가능합니다.
• 신뢰성 및 독립성 강화
  • 각 계층이 독립적으로 구성되기 때문에, 특정 서비스나 서버의 문제로 인해 전체 시스템이 중단되는 위험이 줄어듭니다.
• 코드 관리 용이성
  • 프레젠테이션 코드와 비즈니스 로직이 분리되어 있어, 로직 변경이 프레젠테이션 계층에 영향을 미치지 않습니다.

💎 3-Tier 아키텍처의 배경

• 1-Tier 아키텍처
  • 초기 웹 애플리케이션 구조에서는 모든 요청을 하나의 서버에서 통합적으로 처리했습니다. 사용자의 요청을 받고, 비즈니스 로직을 수행하고, 데이터베이스와의 통신까지 모두 한 서버가 담당했습니다.
  • 장점: 단일 서버 관리로 인해 관리 포인트가 1개라는 점에서 운영이 간편했습니다.
  • 단점: 단일 서버에 문제가 생길 경우 전체 서비스가 장애를 겪을 수 있고, 정확한 장애 원인 파악이 어려웠습니다.
• 2-Tier 아키텍처
  • 서비스 안정성을 위해 데이터 처리를 데이터베이스(DBMS)로 분리했습니다.
  • 장점: 데이터 관리와 비즈니스 로직이 분리되면서 데이터베이스의 안정성이 증가했습니다.
  • 단점: 여전히 사용자 요청을 처리하는 프론트엔드와 비즈니스 로직을 처리하는 백엔드가 하나의 통합 서비스로 제공되었습니다. 이로 인해 동시다발적인 요청이 몰릴 경우 큰 부하가 발생할 수 있습니다.
  • “웹서버 + DBMS”
• 3-Tier 아키텍처
  • 사용자의 요청을 처리하는 프론트엔드와 비즈니스 로직 처리, 그리고 데이터 관리를 각각 분리하여 3개의 독립적인 계층으로 나누었습니다.
  • 프론트엔드(Front-end): 사용자의 요청을 받고 정적 페이지(html, css, js)를 제공하는 역할 (WEB 서버).
  • 백엔드(Back-end): 비즈니스 로직을 수행하고 데이터를 가공하여 동적 페이지(jsp, servlet)를 제공하는 역할 (WAS).
  • 데이터베이스(Data Tier): 데이터를 저장하고 관리하는 역할 (DBMS).
  • “웹서버 + WAS + DBMS”

2. 미들웨어

미들웨어는 3-Tier 아키텍처에서 각 계층 간의 연결을 담당하는 중간 계층 소프트웨어입니다. 클라이언트(프레젠테이션 계층)와 서버(로직 계층), 서버(로직 계층)와 데이터베이스(데이터 계층) 간의 데이터를 주고받을 수 있도록 중간에서 연결 및 통신을 돕습니다.

미들웨어는 보통 웹 서버(WEB Server)와 웹 애플리케이션 서버(WAS: Web Application Server)를 포함하며, 클라이언트와 서버 간, 또는 서버와 데이터베이스 간의 데이터 교환을 원활하게 해주는 역할

미들웨어 관리자는 3-Tier 아키텍처의 중간에 위치한 WEB 서버와 WAS 서버를 관리합니다.

💡 WAS(Web Application Server)란?

WAS(Web Application Server)는 웹 서버와 웹 컨테이너 기능을 모두 갖춘 동적 콘텐츠 제공을 위한 서버입니다. Tomcat, Jeus, Websphere 등 다양한 WAS가 존재하며, 보통 웹 서버와 웹 애플리케이션을 동시에 관리합니다.

• 규모가 커질수록 웹 서버와 WAS를 분리합니다.
• 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 웹서버와 WAS를 대체로 분리합니다.

🔄 WAS의 주요 기능

1. 동적 콘텐츠 처리: JSP, Servlet 등 동적 페이지를 실행하고, 비즈니스 로직을 수행하여 결과를 클라이언트(웹 브라우저)에게 전송합니다.
2. 프로그램 실행 환경 및 데이터베이스 접속 제공: 애플리케이션이 동작할 수 있는 환경을 제공하고, DBMS와의 연결 및 트랜잭션 관리를 수행합니다.
3. 비즈니스 로직 수행: 웹 애플리케이션의 다양한 비즈니스 로직을 실행하여 클라이언트의 요청을 처리합니다.
4. 웹 서버 기능 제공: WAS는 웹 서버 기능을 내장하고 있어, 정적 콘텐츠도 제공할 수 있습니다. - 이 때문에 톰캣이라는 WAS 하나만 설치하고 이용이 가능하다. 톰캣이 가지고 있는 웹서버가 충분한 기능을 하고 있기 때문에

🔎 WAS와 웹 서버의 차이점

• 웹 서버: 정적인 콘텐츠(HTML, CSS, JavaScript, 이미지 파일 등)를 클라이언트에게 제공하는 역할을 수행합니다.
• WAS: 웹 서버가 처리하지 못하는 동적 콘텐츠(JSP, Servlet 등)를 실행하여 비즈니스 로직을 수행한 후, 결과를 웹 브라우저에 전달합니다.

  • 웹 서버: Apache, Nginx, AWS S3
  • WAS: Tomcat, Node.js (Express), Spring Boot, Django, Flask

💡 WAS와 웹 서버의 관계

• WAS는 웹 서버의 기능을 포함하고 있지만, 성능이나 무중단 운영 측면에서는 웹 서버와 WAS를 분리하여 사용하는 것이 유리합니다.
• 대규모 애플리케이션에서는 무중단 운영을 위해 웹 서버와 WAS를 분리하여, 웹 서버가 WAS의 장애를 관리하고 요청을 효율적으로 분배하는 역할을 수행합니다.

[사용자 브라우저]
    ↓ (요청: www.example.com)
[정적 웹 서버 (Nginx, Apache)]
    ↓ (React 애플리케이션 제공)
[클라이언트 (React)]
    ↓ (API 요청: GET/POST 등)
[WAS (Express, Spring Boot)]
    ↓ (DB와 통신 및 비즈니스 로직 수행)
[데이터베이스 (MySQL, MongoDB)]

참고

3-Tier-아키텍처

미들웨어-개념을-알아보자

웹서버와-WAS