🧭 웹 어플리케이션 배포의 역사

기존의 웹 어플리케이션

클라이언트(브라우저 요청)
->
서버의 웹 어플리케이션 데이터베이스 서버와 통신해서 데이터를 가져오고 html,css,js 파일을 만들어 클라이언트에 제공
->
제공받은 파일들을 브라우저에 사용

여러 라이브러리를 사용한 현재 애플리케이션

vue, react 등의 라이브러리(혹은 프레임워크) 를 사용하면서 프론트와 백엔드를 구분해서 독립적인 개발이 가능해졌다.

정적 웹페이지를 렌더링 : 브라우저 <-> 프론트 엔드 서버
API 요청 : 브라우저 <-> 백엔드 서버 <-> 데이터베이스

즉 특정 웹사이트에 접속했을때 http 요청을 프론트 서버에 보내고, 프론트 서버는 브라우저가 이해할 수 있는 트랜스파일링 되어있는 코드를 보내주어 브라우저에 렌더링 할 수 있다. 만약 사용자 인터렉션 및 서버 요청이 일어나게 되면 브라우저는 백엔드 서버에 요청을 보내 받아온 데이터를 보여준다.

웹 서버(WS)

웹서버는 브라우저가 클라이언트 역할을 한다. 사용자가 브라우저에 url 를 입력해서 페이지 요청을 하면 그 http 요청을 받아들여 정적 콘텐츠를 전달해주는 역할을 한다. (html, 이미지 등)
동적인 요청이 들어오면 해당 요청을 WAS 에 요청한다.
동적 컨텐츠 제공을 위해 웹서버 내에 프로그래밍 기능이 들어가는 방식인 cgi(php,perl 등) 이 있지만 규모가 큰 웹에서는 구현하기 어렵다고 한다.
ex) nginx, apache, IIS 등

웹 어플리케이션 서버(WAS)

was 도 http 기반으로 동작한다.
서버 사이드 코드를 처리할 수 있어 동적인 컨텐츠를 전달할 수 있다. 주로 데이터베이스 서버와 같이 수행된다.
ex) 톰캣, JBOSS 등

프론트엔드 서버

웹서버 라고도 한다.
어떤 주소에 대한 요청이 오면 마크업 언어(-html css js) 를 응답해서 사용자에게 GUI 환경(react,next,styled-component 등)을 제공한다.
브라우저는 이렇게 제공된 빌드 파일을 실행해서 페이지에 렌더링한다.

백엔드 서버(api 서버)

프론트엔드 서버와 통신하는 컴퓨터.
프론트엔드 서버에서 인터렉션이 생긴다면 연산과 데이터 저장 등의 과정을 거친다.

WAS, WS, 프론트 서버 관계

웹 서버 : http 요청 시 정적 파일을 제공하는 서버(로드 밸랜서로만으로도 쓸 수 있다고 한다.)
프론트엔드 서버 : 사용자의 요청을 받아 백엔드 서버로 전달하거나 백엔드에서 처리된 데이터를 중계한다. 로드밸랜서, 캐시 서버 기능을 수행한다. 즉 정적 파일 제공 외에도 백엔드와 통신하거나 캐싱 등을 해준다.
WAS: api 를 실행하고 관리하는 서버. 클라이언트의 요청을 받아 비즈니스 로직을 처리하고 데이터베이스와 상호작용을 통해서 데이터를 조작, 전송한다.

사실 아직도 완벽하게 이해하진 못했지만 서로 분리해서 이해하기 보다 포함 관계에 있다고 생각해야겠다.

| 레퍼런스
웹 애플리케이션 배포
ws,was
fe,be 서버, ws,was 관계

✅ AWS 배포

❓ S3 는 정적 배포인데 동적 리소스 제공이 가능한 이유는?

이전에 S3로 배포했을때 S3 가 정적 배포라는 말을 들었다. 그런데 정적 배포이면 사용자 인터렉션에 따른 동적 리소스 제공이 불가능할텐데 어떻게 지난번에는 가능했지? 라는 의문이 들었다.
요약하면 S3 는 정적인 웹사이트를 제공하는게 아니라 정적 웹 사이트 호스팅을 제공하는 거였다.

S3 에는 빌드된 html, css, js 파일이 올라간다.
웹사이트는 API 호출을 통해 서버에서 동적 데이터를 받아 다른 정보를 보여주지만 , 내부의 css, html, js 코드 자체는 항상 동일하여 정적이라고 할 수 있다.

api 호출로 불러온 데이터는 동적인 데이터 이기 때문에 정적 파일 저장소인 S3 가 아니라 다른 백엔드 서버로 제공해야 한다.

🚘 프론트엔드 배포 방식의 차이

ec2 + webserver(nginx)

  • ec2 는 하나의 가상 서버이고 nginx 는 os 에 웹을 띄우기 위한 웹서버 이다.
    웹 서버를 관리하는 서비스 관리자가 필요하다. 즉 리눅스 명령어를 숙지해야 한다.
  • SPA 앱을 이용할때는 추가적인 설정이 필요하다.
    브라우저 라우터는 url 주소가 바뀔 때 실제 페이지를 불러오는게 아니라 리액트 앱 경로를 읽기 위해 리액트 내부적으로 사용하기 때문에 nginx 로 들어오는 모든 웹 요청 경로를 실제 리액트 앱의 index.html 로 치환해주는 try-files 옵션이 필요하다.
  • ec2 서버가 있는 지역이 아닌 다른 지역의 클라이언트가 ec2 서버로 정적 페이지를 요청한다면 응답시간이 더 오래걸릴수 있다. (클라와 서버간의 물리적인 거리 때문!)

cloudfront + s3

  • s3 는 내구성, 가용성, 확장성에 유리하다
  • 스케일 업(서버의 인스턴스 성능을 올리는 것)이 가능하다.
  • cloudfront 는 웹 콘텐츠의 빠른 배포를 지원하는 CDN 서비스를 제공하며 https 사이트 구축을 가능하게 한다.

s3 를 리소스 원본(origin)으로 두고 cloudfront 서버와 연동하면 엣지 로케이션으로 배포가 가능해서 다른 지역의 브라우저에도 빠른 호스팅 서비스가 가능하다.
다양한 지역에 걸쳐 데이터가 분산되어 있어 특정 지역에 문제가 발생해도 서비스가 지속된다는 장점이 있다.
- SPA 구축 시 403,404 리다이렉트 설정이 필요하다.
- 초기 설정이 복잡하다.
- nginx 와 ec2 처럼 여러 정적 웹사이트들을 호스팅 할 수 있으나 s3 호스팅은 버킷의 가장 위 index.html 만을 바라보기 때문에 버킷의 서브 디렉터리 접근 시 index.html 을 생략할 수 없다. 엔드포인트를 설정하거나 클라우드 프론트의 함수를 설정하여 제거가 가능하지만 요청 요금이 늘어날 수 있다고 한다.

+) amplify

클라우드 프론트 + S3 로 구성되어 있으며 빌드 시 자동 배포된다.
깃허브 연결만으로 쉽게 배포되나 트래픽 요금도 비싸지고 빌드 시간이 오래걸리는 프로젝트의 경우 과금될 수 있다.

🐡 로드밸랜서

서버에서 가해지는 트래픽을 여러대의 서버에 균등하게 분산하는 것.
스케일 아웃(서버를 여러대로 나눠서 트래픽을 처리하는 것)

로드밸랜서는 지속적으로 ip 주소가 바뀌기 때문에 도메인 기반으로 사용해야한다.

🐠 nginx

웹 서버와 리버스 프록시 소프트웨어이다.

클라이언트로부터 요청을 받았을때 정적 파일을 응답해주는 Http 웹 서버로 활용

말 그대로 웹 서버로 활용(url 접속-> 빌드 파일 제공)

리버스 프록시 서버로 활용

-> 리버스 프록시는 인터넷과 서버 사이에 존재하는 프록시 서버를 의미한다.
클라이언트의 요청을 서버가 직접 받지 않고 리버스 프록시가 받아 서버에 전달한다. 즉 클라이언트는 프록시 뒤 서버의 존재를 모르게 된다.

-> 로드 밸랜서(집중적으로 발생하는 부하를 여러 서버로 나눠 보냄), 무중단 배포, 보안 강화 등의 역할을 한다.

포트 포워딩

SSL 터미네이션


브라우저와는 https 로 연결하고 서버와의 통신은 http 로 통신하는 방법.

백엔드 무중단배포

//TODO: 로드밸랜서, nginx 의 역할 및 활용 내용 수정

우리는 하나의 인스턴스에 프론트엔드와 백엔드 서버를 같이 올렸기 때문에 nginx를 gateway 역할로만 이용해줬다.

🧹 정리

S3

S3 는 버킷이라는 컨테이너를 놓을 리전을 선택 후 컨테이너 내부에 객체 형태의 데이터를 저장한다. 객체의 최대 크기는 5TB 이며 저장할 수 있는 수의 제한이 없다.

ec2 는 aws 에서 제공하는 클라우드 컴퓨팅 서비스 이다.
클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공해주는 것 으로 , 가상의 컴퓨터 한 대를 빌리는 것 이다.
→ AWS에서 원격으로 제어할 수 있는 가상의 컴퓨터를 한 대 빌리는 것

| 레퍼런스
정적 웹 호스팅의 의미
프론트엔드 배포 방식의 차이
nginx
S3
ec2

💭 기타 개념

도메인

아이피 주소를 특정 도메인으로 연결시켜주기 위해서는 도메인을 구매해야한다.
그런데 왜 도메인을 구매해야하는지 궁금했다. 중개 사이트? 를 거치지 않고 바로 도메인을 신청하면 안되나?
-> 개인이 ICANN 이라는 비영리기구(모든 도메인을 관리하는 곳)에서 도메인을 만들 수 있다고 한다. 하지만 굉장히 비싸고 많은 증빙자료들이 필요하기 때문에 가비아와 같은 사이트에서 구매하는게 훨씬 편하다고 한다.

🐳 도커

도커란 컨테이너 환경에서 독립적으로 애플리케이션을 실행할 수 있도록 컨테이너를 만들고 관리하는 것을 도와주는 도구이다.
의존성 설정을 해주고, 버전 문제 등을 동일하게 해줄 수 있어서 서버마다 다른 환경을 가져서 생기는 문제점을 해결할 수 있다.

도커가 나온 배경

하나의 물리 서버에서 여러 애플리케이션을 실행하면 각각의 애플리케이션이 잡는 리소스의 크기 조율이 어렵다. 따라서 그 이유로 새로운 물리서버를 증설해야 하는데 , 새로운 물리서버를 증설하는 작업은 매우 비싸기 때문에 가상화를 도입하게 된다.

단일 물리서버의 CPU 에서 여러 가상머신(VM)-(aws 에서 가상머신은 인스턴스라고 부른다.)
VM 은 동일한 OS 에서 가상의 머신을 만든다.

컨테이너 ..

도커 원리

레퍼런스
도메인

현재 우리 프로젝트의 배포 프로세스

//TODO: 확정되지 않았음. 추후 수정

0개의 댓글