Web service Architecture

최근 웹서비스는 Front-end와 Back-end로 분리되어 개발되지만, 그 전엔 Web, Web Application Server, Database로 구성되어 개발되었습니다.

Web, WAS, Database가 어떤 것인지 알아보겠습니다.

web_was_db

WAS?

개발 경력이 꽤 되시는분들은 백엔드라는 용어보다는 WAS(Web Application Server)라는 용어를 더 많이 사용하시는 경향이 있으신 것 같습니다.

이를 계기로 관련 용어에 대해 좀 더 자세히 알아보기로 했습니다.

Web - Web Application Server - Database 구조 설명

3가지는 대략 아래와 같은 구조로 이루어져 있고 Web - WAS - DB 구조로 의존합니다.

web_was_db_diagram

Web

Web server를 의미하며, 브라우저로부터 요청을 받아 정적 정보(html, css, js, image, etc…)를 응답합니다.

여기서 브라우저는 오직 Web server하고만 통신합니다.

WAS

WAS 즉, Web Application Server는 동적인 정보를 응답합니다.

서버의 로직을 처리하거나 DB와 통신하여 DB에 기록된 데이터를 조작 및 가져와 Web server에 전달하고 다시 브라우저에 새로운 정보를 응답합니다.

DB

Database(DB)는 데이터를 저장하는 곳입니다.

데이터베이스는 데이터를 저장, 수정, 삭제, 조회하는 역할을 합니다.

데이터베이스와 통신하기 위한 DB 서버는 데이터베이스와의 통신만을 담당하는 서버입니다.

대략 아래와 같은 구성을 가집니다.

  • DB 테이블 : 시스템에서 데이터가 저장되는 형태로 데이터의 종류와 형식을 확인 가능함. 일종의 엑셀 시트
  • 컬럼(Column) : DB테이블의 열로 같은 종류로 묶인 항목 (예시 : 번호, 이름, 반, 점수)
  • 레코드(Record) : DB테이블의 행으로 항목이 1개씩 포함된 데이터 묶음
  • 쿼리(Query) :DB에 정보를 조회 요청하는 것
  • SQL (Structured Query Language) : 관계형 DB에 정보를 관리(등록/삭제/변경/조회)하기 위한 언어

굳이 이렇게 나누는 이유

생각해보면 위의 모든 기능들은 하나의 서버 인스턴스에서 다룰 수 있지만, 각각의 뚜렷한 역할 분리와 함께 서버 효율을 위해 서버(Web, WAS, DB)가 나뉘는 경우가 많습니다.

여러 가지 이유가 있겠지만, 대표적으로 아래와 같은 이점들이 자주 언급됩니다.

Web server - WAS

Web server와 Web Application Server가 분리된 이유에 대해 알아보겠습니다.

  • WAS에 대한 서버 부하를 줄여 효율적이고 안정적으로 운영하기 위함.
    • 로직을 처리하지 않는 Web server에 대한 컴퓨팅 자원을 최소화할 수 있음.
      • WAS가 Web server까지 겸하면 컴퓨팅 자원을 크게 할당할 수 밖에 없음 = 비효율적
    • Web server에 load balancing 기능이 있다면 WAS 인스턴스의 부하 분산 가능. = 안정적인 서버 운영
  • static 데이터 요청에 대한 응답 최적화
    • 수많은 HTML, CSS, JS 등의 static file들에 대한 요청 분담 및 캐싱 담당.
      • 수많은 네트워크 I/O만을 전문적으로 처리하는 Web server에게 WAS의 부하를 덜어주어 성능 향상 -> 네트워크 요청 자체를 줄여주는 것도 있지만 이벤트 루프 방식으로 비동기처리(Network I/O)를 처리하는 Nginx가 JVM보다 비동기처리에 유리 = 서버의 비동기처리 전문화
      • 최근 CDN으로 여러 static asset들에 대한 응답들을 최적화하는 것처럼 Web server가 static file들에 대한 응답을 최적화하는 역할 가능.
  • 보안 강화
    • Web server는 WAS에 대한 직접적인 접근을 막아줌. = 접근 제어
    • 외부를 위한 SSL/TLS 인증서만을 전문적으로 다루어 보안 강화
  • web 1.0에서 쓰이던 Web server에 web 2.0으로 발전되며 추가된 것이 WAS이고, 그렇게 서버가 분리가 되었다.(?)

WAS - DB server

이번엔 WAS와 DB server가 분리된 이유에 대해 알아보겠습니다.

  • 부하 분산 및 컴퓨팅 자원 분배 효율화
    • WAS는 로직 처리로 인해 CPU를 더 많이 사용하고, DB는 데이터 처리로 인해 메모리를 더 많이 사용함. = 서로 필요로하는 컴퓨팅 자원을 적절히 분배
    • DB 서버는 DB와 단순 통신만으로도 부하가 상당히 크기 때문에, 이를 분리해 독립적으로 운용
  • 명확한 역할 분담
    • DB lock이나 트랜잭션 처리 등 복잡한 DB와 관련된 일만을 DB server에게 맡김.
  • 보안 강화
    • DB server에만 DB에 대한 접근 권한을 부여하여 보안 강화.

각 구성 요소들의 대표적인 기술들

Web => Apache, Nginx

WAS => Tomcat, JBoss, WebLogic, WebSphere

Database => MySQL, Oracle, PostgreSQL, MongoDB

지금은 왜 WAS란 용어가 잘 사용되지 않을까?

다양한 이유가 있겠지만, Web server가 WAS의 역할까지 수행할 수 있게 되면서 그 개념이 모호해진 것이 원인이라고 생각합니다.

  • 기존 HTTP는 정말 static한 문서만 주고 받을 수 있는 Protocol이었음.
  • 그러나 HTTP의 발전으로 파일 송수신뿐 아니라 제한적이지만 실시간으로 데이터 통신도 가능해졌고, HTTPS로 보안까지 처리할 수 있게 되면서 하나의 서버에서 WAS + Web server의 역할을 모두 수행할 수 있게 됨.
  • 대표적인 예로 Next.js, Nuxt.js 같은 프론트엔드 SSR(Server Side Rendering) 프레임워크들이 WAS의 역할까지 수행할 수 있음.

정리

혹자는 이런 개념을 보고 이렇게 생각할 수 있습니다.

  • 굳이 이렇게 복잡하게 나눌 필요가 있느냐?
  • 이런 개념까지 알아야 하는가?
  • 그냥 단순 업계 은어로 자기들끼리만 소통하기 위한 용어고 실상은 아무 의미 없는 것 아니냐?

하지만 업계에서 오랜 기간 사용되어 온 용어들은, 단순한 소통 이상의 지식과 지혜를 담고 있다는 사실을 자주 느낍니다.

더 좋은 서비스를 위해 치열하게 고민을 하는 지금, 당시의 지식과 환경 속에서 최선의 해결책으로 문제를 해결했던 업계의 선배들의 지혜를 또 한번 배울 수 있던 시간이었습니다.

ref.