WEB서버 아키텍처에 대한 고민

고리·2022년 9월 15일
0
post-thumbnail

기업에서 제공하는 자료가 공항, 철도 등 민감한 자료이기 때문에 보안을 신경 써야 했다.

따라서 WEB - WAS(Web Application Server) - DB로 이루어진 3tier 아키텍처로 결정했고

이번 게시물에서는 WEB server 아키텍처를 살펴보겠다.


왜 WEB - WAS를 나누는 걸까?

WEB server는 정적 리소스를 제공하는 역할은 물론 가벼운 동적 리소스도 제공한다.

뒤에서 살펴보겠지만 WEB 서버는 WAS의 역할을 어느 정도 대신할 수 있다. 반대로 WAS도 WEB 서버의 역할을 대신할 수 있다. 그런데도 이 둘의 역할을 나누는 주된 이유는 보안 그리고 로드 밸런싱이다.

보안? 보안!

우리 서버에 접근하는 사용자들이 자신들의 정보를 감추는 것을 foward proxy라 한다. 이와 반대로 서버도 보안상 내부 구조를 감추고 싶을 수 있다. 파일이 어디에 저장되고 서비스가 몇 번 포트에서 돌고 있는지 등의 정보를 감추는 것을 reverse proxy라 한다.

사용자가 우리 서버에 데이터를 요청하면 WEB 서버가 WAS에 전달하고 내부 서버인 WAS가 DB서버에서 데이터를 받아서 사용자에게 전달한다. 이런 방식으로 reverse proxy가 동작하고 WEB서버reverse proxy 의 역할을 한다.

이렇게 함으로써 클라이언트가 직접 DB서버에 접근하는 것을 막을 수 있다.

로드밸런싱? 로드밸런싱!

위의 그림에서 WEB서버WAS로 요청을 보내는 것을 확인할 수 있다.
WEB서버는 정적 리소스, WAS는 동적 리소스를 제공하면 하나로 집중된 부하를 두 개로 나눌 수 있다.

만약에 서비스가 너무 잘돼서 트래픽이 급격하게 늘어날 때

이렇게 여러 클라이언트 서버를 둬서 사용자에게 트래픽의 책임을 넘기는 것보다는


여러 대의 WAS를 WEB서버에 연결해 트래픽을 분산시키는 게 옳다. 이 방식을 사용하면 WAS 한대에 문제가 생겨도 다른 WAS가 트래픽을 전담할 수 있고 트래픽이 집중될 때 WAS 서버를 늘려서 부하를 해결할 수 있다.

사실 리버스 프록시의 기능 중 하나다.


이번 프로젝트의 WEB server

이번 프로젝트는 다음의 WEB 서버 아키텍처를 갖는다.

EC2

EC2란 Amazon Elastic Compute Cloud의 줄임말로 AWS에서 제공하는 클라우드 컴퓨팅 서비스다.

독립된 컴퓨터 한 대를 대여해 사용할 수 있게 해준다.
그러나 실제 컴퓨터 한 대를 대여해서 사용하는 것과는 몇 가지 차이가 있다.

  1. 실제 컴퓨터를 구매해 서버를 운영하다 조기에 서비스를 종료하게 되면 컴퓨터는 더 이상 쓸모가 없게 된다. 하지만 EC2는 필요할 때 필요 없을 때 즉각 대여, 반납할 수 있기 때문에 불필요한 지출이 생기지 않는다.

  2. 한번 구매하면 모든 리소스의 크기가 정해지는 온프레미스 방식과는 달리 언제든 CPU, RAM, DISK의 크기를 변경할 수 있으므로 탄력적인 운용이 가능하다.

  3. AMI 기능 사용
    AMI는 이곳에 이해하기 쉽게 잘 정리되어 있었는데 그 내용은 다음과 같다.

    컴퓨터를 사용하면 프로그램도 설치하고, 파일도 저장하고, 설정도 변경하게 되는데, 이 OS 상태 그대로 저장하는 기능을 이미지(AMI) 라고 한다. 윈도우 백업 설정이라고 봐도 무방하다.

    이미지를 이용해서 새로운 컴퓨터를 만들면 이미지에 저장된 상태와 똑같은 컴퓨터를 빠르게 생성할 수 있다.

사실 이번 프로젝트의 규모가 크지 않아서 netlify 등의 호스팅 서비스만으로 충분하지만 국가중요시설에 관련한 데이터가 있는 만큼 보안에 강한 AWS를 사용하게 되었다. 테스트에는 netlify를 사용할 예정이다.


Amazon Linux2

Amazon Linux2란 AWS에서 개발한 Linux 운영 체제로 AWS EC2가 최적의 성능을 낼 수 있도록 튜닝되었다.

The default filesystem for the Amazon ECS-optimized Amazon Linux 2 AMI is xfs, and Docker uses the overlay2 storage driver. For more information, see Use the OverlayFS storage driver in the Docker documentation.

공식 홈페이지에 가보면 Amazon Linux2가 default file system으로 xfs를 선택한 것을 알 수 있는데

위 사진에서 보다시피 Docker가 지원하는 가장 stable한 Storage driver인 overlay2를 지원하므로 적합하다.

스토리지 드라이버는 이미지 및 컨테이너가 Docker 호스트에 저장 및 관리되는 방법을 제어한다.

그뿐만 아니라 OS 자체에서 문제가 있을 때 AWS로부터 바로 지원받을 수 있고 현업에서도 많이 쓰인다. 무엇보다 서버용으로 많이 사용하는 레드헷 계열 linux 배포판 중에 무료다.


Docker

도커는 아래 포스트에 설명해 두었다.

도커(Docker)란?

Amazon linux2에 Docker engine만 깔면 컨테이너를 실행할 수 있기 때문에 배포도 쉽고 개발환경 그대로 배포할 수 있기에 Docker를 사용했다.


Nginx

Nginx는 아래 포스트에 설명해 두었다.

Nginx란?

Nginx와 Apache 중에 어떤 것을 사용할지 고민을 많이 했다.

  1. 이번 프로젝트를 요청한 기업 직원 수가 대략 200명이다. 기업 내부에서 사용될 예정이라 트래픽이 많지는 않을 거라 예상된다.
  2. 오래된 기업이고 기업 내에서도 사용 인원의 변동이 크지 않아 확장성이 핵심 고려 사항은 아니다.
  3. 1개월에 1번 대용량 업로드가 필요하지만 처리가 가능하다.
  4. Nginx가 최신 레퍼런스가 훨씬 많다. Apache 커뮤니티가 엄청 크다고 했는데 왜 잘안보이지..?

Apache를 선택했을 때 가져갈 수 있는 대부분의 이점을 Nginx도 가져갈 수 있었고 무엇보다 Nginx가 최신 레퍼런스가 많아서 선택하게 되었다.


React

Vue도 있고 Flutter도 있는데 왜 React를 선택했을까?

우선 Vue는 프레임워크다. 그래서 확장자부터 .vue다.
사실 안쪽을 들여다보면 html, css, js만 알아도 크게 문제가 없지만 프로젝트 기간이 넉넉하지 않아서 학습 곡선을 줄일 수 있는 자바스크립트 라이브러리인 React가 좋았다. 같은 이유로 Dart를 공부해야 하는 Flutter도 배제했다.


이게 잘 만든 건지 확실히 모르겠다. 앞으로 계속 공부해보고 연동해보고 수정할 것이 있으면 수정해야겠다.

profile
Back-End Developer

0개의 댓글