[2주차] AWS ELB, EC2, CodeDeploy에 대한 이해 (백업용)
이 문서는 [월간-CS][24년 4월] React, Next 배포와 배포 자동화 A부터 Z를 위해서 작성된 문서입니다. 이 문서에는 그 어떤 저작권이 없으며, 편하게 참고 및 사용하셔도 됩니다.
개요
사전 지식
지난 주차에는 AWS CloudFront, S3를 통해서 정적 파일을 제공하는 법을 배웠습니다.
이 과정에서 사용한 AWS S3(Simple Storage Service)는 객체 기반의 스토리지 서비스입니다. 이를 활용하여 광범위한 영역에서 데이터를 제공할 수 있습니다.
이번 주차에는 여기서 한 걸음 더 나아가서 스토리지(Storage)와 컴퓨트(Compute)에 대해서 깊이있게 알아보고자 합니다. 이를 통해서, 다양한 상황에서 적합한 서비스를 선택하는 방법을 배울 수 있었으면 좋겠습니다.
이후 AWS ELB, EC2를 통해서 동적 파일을 제공하는 법을 배워서 Next.js를 SSR 방식으로 제공하고자 합니다.
최종적으로는 CodeDeploy를 사용해서 무중단 배포 자동화를 설계하려 합니다.
스토리지? 컴퓨트?
일반적으로 사용하는 컴퓨터(노트북)
일반적으로 사용하는 컴퓨터는 CPU, SSD, 모니터, 마우스 등이 모두 결합되어 있습니다.
내/외부로 다양한 부품이 있으나, 가장 중심이 되는 부품을 2가지만 고른다면 어떨까요?
저는 데이터를 저장할 스토리지(Storage)와 데이터 처리를 위한 컴퓨트(Compute)라고 생각합니다. 많은 전자기기는 스토리지, 컴퓨트 혹은 그 조합으로 구성되어 있습니다.
물론 완벽하게 스토리지 혹은 컴퓨트만 있는 경우는기 어려울 물리적으로 존재하 것이라 생각합니다. 하지만, 이 문서에는 편의를 위해서 중심이 되는 부분에 대해서 다루고자 합니다.
스토리지만 있는 경우
컴퓨트만 있는 경우
스토리지와 컴퓨터를 함께 있는 경우
스토리지, 컴퓨트 그리고 조합
물리적으로는 일부의 컴퓨트, 스토리지가 포함되어 있을 것입니다.
하지만 AWS은 사용한 부분만큼 비용이 지불되는 구조(On-demand)이기 때문에, 청구 유형에 따라서 다음과 같이 3가지로 구분하여 보았습니다.
스토리지만 청구 되는 경우
AWS에서는 S3, ELB, EFS와 같은 스토리지 서비스를 제공합니다.
대부분의 경우 저장 공안, 데이터 입력 및 출력에 대한 비용이 지불되는 구조입니다.컴퓨트만 청구 되는 경우
때로는 Kinesis 및 Athena 계열의 서비스 처럼 컴퓨트 서비스를 필요로 하기도 합니다.
주로 실시간 데이터 처리 및 분석 분야에서 많이 쓰이곤 합니다.스토리지와 컴퓨터를 청구 되는 경우
이는 스토리지 서비스인 EBS, EFS 등과 함께 사용하는 것이 특징이며 EC2, EB, ECS, EKS, RDS 등의 독자적인 운영체제를 포함한 하나의 컴퓨터라고 생각하면 편합니다.
어떻게 선택하는가?
다양한 변수에 의해 비용이 천차만별이지만, 일반적으로 다음이 비용 부담이 커집니다.
스토리지(A 유형) < 컴퓨트(B 유형) < 스토리지 + 컴퓨트(C유형)
특히 AWS는 사용한 부분만큼 비용이 지불되는 구조(On-demand)이기 때문에, 이를 사용 유형에 따라서 분리하는 것이 좋습니다.
가장 대표적인 예시가 프론트엔드는 CloudFront, S3를 통해 배포하고 백엔드는 EC2, EBS를 통해 배포하는 사례입니다.
기본이 되는 리소스 설명
지난 주차와 다른 점은 CloudFront, S3 대신에 ELB, EC2, EBS를 사용한다는 점입니다.
EC2, EBS
EBS는 데이터를 동일한 크기의 블록으로 저장하고 기존의 파일 시스템과 유사한 계층 구조로 변환합니다. 여기서 말하는 기존의 파일 시스템은 NTFS, APFS, ext4 등을 의미합니다.
Win, Mac, Linux 순으로 NTFS, APFS, ext4가 대표적이지만 다른 많은 파일 시스템을 지원합니다. 파일 시스템 별로 작동 방식이 다르고 이에 따라서 성능이 다릅니다.
가장 대표적인 예는 NTFS에서는 복사가 느리지만 ext4에서는 복사가 순식간에 이루어집니다. 혹은 심볼릭 링크를 이용해서 효율을 극대화할 수 있습니다.
EC2는 여러 개의 EBS과 연결하여 선택한 운영체제(Linux,Ubuntu 등)에 맞는 파일 시스템을 구성하게 됩니다. 이때 선택하는 옵션은 다음과 같습니다.
운영 체제(Ubuntu 고정)
네트워크 설정(실습에서 신경쓰지 않음)
스토리지 설정(EBS)
참고 자료
ELB(ALB, L7)
만약 서버가 단일 EC2에만 있으면, 안정성을 보장하기 어려울 것입니다.
이 때 여러 개의 EC2를 배포하게 되면 사용자의 요청(HTTP/S)을 규칙에 따라 부하를 배분할 필요가 있습니다.
이런 부하 배분을 위한 서비스 중 하나가 ELB입니다.
해당 ELB는 ALB, NLB, CLB 등이 있지만 여기서는 ALB를 사용하고자 합니다.
ALB는 7계층의 어플리케이션 계층에서 작동하는 로드 밸런서 중 하나입니다.
참고 자료
CodeDeploy
AWS CodeDeploy 공식문서에 따르면, CodeDeploy는 다음과 같이 소개되고 있습니다.
CodeDeploy는 일정한 라이프 사이클 훅(Lifecycle Hooks)에 따라서 실행되며, 이를 이용해서 안전하게 서버 및 코드를 배포할 수 있습니다.
인프라 설계
아래의 2주차 실습에서 배포할 인프라에 대한 설명입니다.
[2주차] GitHub Action 환경에서의 AWS ELB, EC2 배포 설정 및 배포 자동화 (Next SSR) - CLI
[2주차] GitHub Action 환경에서의 AWS ELB, EC2 배포 설정 및 배포 자동화 (Next SSR) - Console
네트워크
서버
배포 파이프라인
결론
우리는 설계된 아키텍처를 통해서 SSR 방식으로 제공되는 Next.js를 배포할 수 있을 것이라고 기대하고 있습니다. 실제로 개념 증명(PoC, Proof of Concept)을 통해서, 설계된 아키텍처를 통해서 탬플릿 프로젝트를 배포해보겠습니다.
