프론트 배포 이론

[ AWS 배포 방법들 ]

• AWS EC2를 활용한 배포
• AWS S3와 CloudFront를 활용한 배포
• AWS amplify를 활용한 배포
• Nginx를 활용한 배포

각 방법에 따라 배포할 수 있는 서버가 다르며 배포할수 있는 서버란 웹서버와 WAS를 말함

 

웹서버 vs WAS

웹서버

클라이언트(사용자)가 웹 브라우저에게 어떠한 페이지 요청을 하면 웹 서버에서 그 요청을 받아 정적 컨텐츠( 단순 HTML, CSS, JS, 이미지, 파일 등 즉시 응답한 컨텐츠 )를 제공하는 서버

웹 서버가 동적 컨텐츠를 요청 받으면 WAS에게 해당 요청을 넘겨주 WAS에서 처리할 결과를 클라이언트(사용자)에게 전달해주는 역할

 

WAS

웹서버와 웹 컨테이너가 합쳐진 형태로써 웹 서버 단독으로 처리할수 없는 DB의 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공

사용자의 다양한 요구에 맞춰 웹 서비스를 제공할 수 있음

 

Web Service Architecture 

요청 처리 방식에 따라 다양한 구조를 가질 수 있음

• 클라이언트(사용자) → Web Server → DB
• 클라이언트(사용자) → WAS → DB
• 클라이언트(사용자) → Web Server → WAS → DB

WAS는 DB 조회 및 다양한 로직을 처리하는데 집중해야하므로 WAS만 쓴다면 효율성이 떨어짐

만약 WAS만 쓰게 되면 WAS가 정적 컨텐츠 요청까지 처리하여 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지고 이로 인해 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어짐

따라서 단순한 정적 컨텐츠는 웹 서버에게 맡기면 기능을 분리시켜 서버 부하를 방지함

 

각 방법에 따라 배포할 수 있는 서버

• EC2: 웹서버, WAS 서버 배포 가능
• nginx: 정적 콘텐츠 배포
  • 정적 컨텐츠를 제공해주는 프록시 서버. 즉 nginx란 웹 서버 제품중 하나
• S3 + cloudfront: 정적 콘텐츠(프론트 서버)를 배포
• Amplify: 정적 콘텐츠(프론트 서버)를 배포
  • 기본제공 ci/cd 워크플로우를 통해 정적 웹 애플리케이션의 글로벌 배포 및 호스팅을 지원하는 완전관리형 시스템
  • S3 + clounfont 방법보다 간편하게 배포 가능하며 배포 자동화 자동으로 S3, cloundfront를 구현함

 

▶ 실전에서 사용할 S3와 CloudFront 알아보기

S3

Simple Storage Service의 약자로 파일 서버의 역할을 하는 서비스

즉 특정한 이미지, 동영상, 파일, 데이터 등의 파일을 저장하고 관리하는데 사용되는 웹 기반 스토리지 시스템

일반적인 파일 서버는 트래픽이 증가함에 따라 장비를 증설하는 작업을 해야하는데 S3는 이와 같은 것을 대행함

따라서 시스템적인 문제는 걱정할 필요가 없어지며 파일에 따른 접근 권한을 지정할 수 있어서 서비스를 호스팅 하는 용도로 사용하는 것을 방지할 수 있음

 

CloudFront

AWS에서 제공하는 CDN(Content delivery network) 서비스

CDN은 콘텐츠 전송 네트워크로써 지리, 물리적으로 떨어져 있는 사용자에게 컨텐츠를 더 빠르게 제공하는 시스템을 말함

사용자가 원격지에 있는 서버(Origin Server)로 부터 Content를 다운 받을 때 가까이 있는 서버에서 받는 것보다 시간이 오래 걸리기 때문에 사용자와 가까운 곳에 위치한 Cache Server에 해당 Content를 저장(캐싱)하고 Content 요청시 Cache Server가 응답을 해줌

즉 CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스. ClounFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됨

 

[ CI/CD ]

CI/CD 개념

CI

CI는 Continuous Integration으로 지속적인 통합이라는 의미

애플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합하는 것을 의미함

CI는 버그를 신속하게 찾아 해결하고 소프트웨어의 품질을 개선하고 새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는 것에 있음

결론적으로 CI는 새로운 소스코드의 빌드, 테스트, 병합까지를 의미함

 

CD

Continuous Delivery 혹은 Continuous Depolyment로 모두 축약어, 해석하면 지속적인 서비스 제공 혹은 지속적인 배포

Continuous Delivery는 공유 레포지토리로 자동으로 Release 하는 것을 Continuous Deployment는 Production 레벨까지 자동으로 deploy 하는 것

결론적으로 CD는 개발자의 변경 사항이 레포지토리를 넘어 고객의 프로덕션(Production) 환경까지 릴리즈 되는 것

 

CI/CD

코드를 빌드, 테스트, 배포하는 과정을 거쳐 소프트웨어 개발을 추친하는 프로세스이며 파이프라인이라고도 함

프로세스를 자동화함으로써 인적 오류를 최소화하고 소프트웨어 출시 방식에 일관된 프로세스를 유지하는 것을 목표로 함

 

▶ 실전에서 사용할 GitHub Action 알아보기

GitHub에서 제공하는 서비스로 빌드, 테스트, 배포 파이프라인을 자동화 할수 있는 CI/CD 플랫폼

 

workflow

프로젝트를 빌드, 테스트, 릴리즈 하기 위한 전체적인 프로세스

workflow는 하나의 job 이상으로 구성되고 event(on)에 의하여 실행됨

GitHub Action에서 workflow를 설정할때는 자신의 GitHub 레포지토리에서 .github/workflows 안에 .yaml 파일을 만들면 됨

 

events

workflow를 실행시킴

예를 들어 사용자가 commit 푸시 하거나 issue를 등록하거나 pull request를 날릴 때 workflow를 실행시킬 수 있음

또한 webhook을 사용하여 다른 이벤트를 날릴 수 있음

 

job

job은 동일한 runner에서 실행됨

기본적으로 workflow 에 다양한 jobs들은 병렬로 실행되지만 순차적으로 실행하게끔 변경할 수 있음

예를 들어 workflow에 빌드, 테스트 하는 job이 순차적으로 실행하게끔 되어있고 테스트 job이 빌드 job과 연관이 있다면 빌드 job 이 실패했을때에 test job은 실행하지 않게 됨

 

steps

step 실행 명령어에 따라 개별적으로 동작함

각각의 step은 job에 동일한 실행환경에 있어서 각각의 data가 공유됨

 

actions

actions는 독립적인 명령으로 step을 결합하여 job을 만들어낸것

actions는 아주 작은 wrokflow에 단위이므로 사용자가 actions를 만들 수 있고 또는 community에 있는 actions를 사용할 수 있음. 이러한 actions는 step안에 넣어서 사용할 수 있음 

 

runners

runner는 github actions에서 사용하는 서버

Gihub으로 hosting할 수 있고 자신만에 host에서도 가능함

runner는 수행 가능한 job을 듣고있고 job을 싱행하고 진행상황을 공유하고 log를 남기기도 함

 

배포 실습

https://hyeon-e.tistory.com/220

프론트 배포 실습