🎉 berenickt 블로그에 온 걸 환영합니다. 🎉
DevOps
클라우드 배포 전략

1. 클라우드 배포 전략

개인별 도메인이 필요합니다. 웹 호스팅 업체에서 도메인을 구매해 주세요

💡 클라우드 서비스 제공자(Cloud Provider)

  • Amazon의 AWS : 시장 점유율 70%, 거의 대부분 아마존을 사용

    • 4GB 정도 한달 내내 키면 5만원 쯤

    • 8GB 정도 한달 내내 키면 10만원 쯤

  • Google의 GCP : 비용이 아마존보다 저렴
    • 4GB 정도 한달 내내 키면 4만원 쯤
    • 8GB 정도 한달 내내 키면 8만원 쯤
    • 이 비용들은 추측치이고, 컴퓨터를 쓰든 안쓰든 켜져있으면 비용이 부과됨
  • MicroSoft의 Azure

2. 정적페이지와 동적페이지 배포 가이드

배포 단계는 보통 크게 4단계로 나눌 수 있으나, 회사마다 다를 수 있습니다.

1단계 : 정적페이지

  • DNS(Domain Name System)를 이용한 서비스
  • 회사 소개 홈페이지, 데이터가 없는 소개 페이지들에서 사용
  • 문제점 : Dynamic Rounting이 지원이 안됨
    • 즉, index.html과 폴더명이 명확할 떄만, 주소를 가져올 수 있음

2단계 : 1개의 서버만 존재

  • 데이터가 있는 페이지들을 위해서는 서버가 결국 필요합니다.
  • Dynamic Rounting이 필요해서 컴퓨터가 1대만 있으면, 2단계입니다.
  • 그러나 2단계가 가진 문제점은 컴퓨터가 1대라는 점입니다.
    • 1개의 컴퓨터에 API 요청이 너무 많아 부하가 많으면, 컴퓨터가 여러 대 필요합니다.
    • 부하를 분산시켜주기 위해 부하 분산기(Load Balancer)라는 와이파이 공유기 비슷한 기계를 설치해야 합니다.
    • 로그 밸런서는 클라우드 서비스에서도 똑같이 제공을 해줍니다.

3단계 : 로드밸런서로 여러개의 서버 존재

  • 여러 대의 컴퓨터를 두고 로드 밸런서를 통해 부하를 분산시켜주는 단계
    • 분산하는 방법에는 Round-Robin, Least-Connection 등의 알고리즘이 존재
  • CPU 사용률이 80%이상이거나, Memory가 70% 이상이면, 자동으로 컴퓨터를 복제(Auto Scaling)함
  • 큰 회사같은 경우에는 별도의 DevOps 팀이 존재 : 배포팀, (개발과 운영) 클라우드를 같이하는 팀
  • 이 단계에서 발생하는 문제점은 컴퓨터가 많아지면서,
    • 각각의 컴퓨터에 에러는 없는지, yarn start가 잘 작동하고 있는지
    • 갑자기 특정 컴퓨터의 메모리 사용량이 급격하게 올라간다는 등의
    • 컴퓨터가 전부 잘 작동하는지 안하는지 모니터링을 해줘야 한다는 점입니다.

4단계 : CDN으로 정적, 동적 페이지 구분

  • 3단계의 문제점을 해결하기 위해서는…
    • 결국 서버를 두는 이유는 동적인 페이지를 위함입니다.
    • 그래서 동적페이지의 정보는 서버에 두고, 정적페이지는 DNS를 통해 보여주는 등 권한을 분리합니다.
    • 그래서 Cloude Front(CDN)를 도입했습니다.
    • CDN은 분기하는 역할을 수행합니다.
    • 3단계처럼 모든 컴퓨터를 모니터링하는 일을 아예 없앨 수는 없지만, 가급적 줄일 수 있습니다.
  • CDN은 정적페이지면 스토리 주소로, 동적페이지면 로드밸런서를 통해 보냅니다.
    • 로드밸런서는 받아온 페이지들을 각각의 컴퓨터에 보내주겠죠.

💡 참고

규모가 커지면서 4단계까지 갔지만, 가장 많이 쓰이는 모델은 2단계입니다.

  • 2단계를 쓰다가 접속량이 많아지면 3단계로 넘어가고
  • 3단계에서 너무 커져서 비용과 트래픽을 줄이고, 안전성을 높이려면 4단계로 넘어갑니다.
  • 처음부터 4단계로 가는 게 아닙니다.
  • 시작은 1, 2단계를 쓰다가 넘어가는 겁니다.

3. 배포 방식에 따른 데이터 흐름

클라이언트를 배포하는 방식에는 여러가지 방법이 존재합니다. 크게 SSG Only, SSG+SSR, SSR Only로 분류할 수 있고, 서비스 특성과 규모에 따라 배포 방식이 결정됩니다. 각 배포 방식에 따라 요청이 전달되는 흐름과 특성에 대해 알아보겠습니다.

3.2.1 정적 배포

정적 배포

  • CloudFront(CDN)를 이용하여 S3 엔드포인트에 접근하도록 하는 방법
  • 유저가 Route 53(DNS)으로 DNS 레코드를 요청하면, Route 53은 CloudFront의 도메인을 안내합니다.
  • 이후 유저는 CloudFront로 연결하고, CloudFront는 S3으로 요청과 응답을 중계합니다.
  • CDN을 이용하여 캐싱된 파일들이 빠르게 제공되기 때문에,
    • 퍼포먼스에 집중해야 하거나 마케팅 페이지 / 제품 목록 등과 같이
    • 정적으로 생성하여 각 요청에 동일한 문서를 반환하는 서비스에 주로 사용되는 배포 방법입니다.
  • 단, CloudFront에 캐싱된 데이터가 렌더되기 때문에
    • 변경사항을 자주 확인해야 하는 경우(개발단계 등)에는 적합하지 않은 방식

3.2.2 동적 배포( 분기처리 x )

정적+동적 배포( 분기처리 x )

  • CloudFront(CDN)를 이용하지 않고, S3 엔드포인트에 접근하도록 하는 방법
  • 유저가 Route 53(DNS)으로 DNS 레코드를 요청하면, Route 53은 S3 엔드포인트 주소를 안내합니다.
  • 이후 유저는 즉시 S3로 연결하여 요청과 응답을 주고받습니다.
  • S3에 변경된 사항이 있을 경우 즉시 확인이 가능하기 때문에 개발 단계와 같은 상황에서는 적합하지만,
  • CloudFront(CDN)를 이용하지 않기 때문에 1-1의 방법보다 퍼포먼스가 다소 좋지 못하며,
  • CloudFront를 이용하지 않아서 SSL 인증서 적용이 어렵기 때문에 보안상으로도 취약한 부분이 발생할 수 있습니다.

3.2.3 정적+동적 배포( 분기처리 o )

정적+동적 배포( 분기처리 o )

  • SSG와 SSR을 혼합하여 클라이언트를 배포하는 방법
  • S3에 업로드된 빌드 파일을 CloudFront를 이용하여 캐싱하여 빠른 속도로 최초 화면을 표시한 다음,
  • 나머지 페이지와 데이터들은 SSR 방식으로 전달합니다. 그렇기 때문에 사용자는 빠르고 역동적인 경험이 가능합니다.
  • 또한, 잦은 변경이 필요하지 않은 파일(기본 레이아웃 및 디자인 등)들을 S3로 분리하여
  • EC2 인스턴스에 대한 부하를 줄일 수 있으며,
  • 이를 통해 안정적인 서비스 제공 및 비용 절감 효과를 도모할 수 있습니다.
AWS 서비스 종류프론트 단계별 AWS 배포