[1주차] AWS CloudFront, S3에 대한 이해
이 문서는 [월간-CS][24년 4월] React, Next 배포와 배포 자동화 A부터 Z를 위해서 작성된 문서입니다. 이 문서에는 그 어떤 저작권이 없으며, 편하게 참고 및 사용하셔도 됩니다.
개요
본 문서에서는 콘텐츠의 유형을 분류하는 법을 이해하고 이러한 특징에 따라서 React에 적합한 아키텍처인 CloudFront, S3를 설계해보겠습니다.
사전 지식
본 문서의 내용을 이해하기 전에 콘텐츠의 유형을 분류하는 법을 기본적인 정의와 실제 예시를 통해서 알아보겠습니다.
정적 콘텐츠 vs 동적 콘텐츠
캐치 테이블로 보는 콘텐츠 분류
그 외의 특수한 콘텐츠들
정적 콘텐츠 vs 동적 콘텐츠
웹 사이트에 접속하면 텍스트, 이미지, 대화형 버튼 등 다양한 요소들을 접하게 됩니다. 이것들을 콘텐츠(Content)라고 부르며, “콘텐츠를 어떻게 전달하는가?”가 사용자 경험(UX, User Experience)에 큰 영향을 미칩니다.
이러한 콘텐츠는 “사용자의 행동이 변화에 영향을 미치는지”에 따라서 2가지로 구분됩니다.
정적 콘텐츠(Static Content)
사용자의 행동 및 실시간 이벤트에 관계없이 모든 사용자에게 동일하게 유지동적 콘텐츠(Dynamic Content)
사용자 행동, 위치 또는 기타 요인에 따라 실시간으로 생성 및 변경
캐치 테이블로 보는 콘텐츠 분류
아래는 전화 없이 편리하게 레스토랑을 예약할 수 있는 캐치 테이블의 메인 홈입니다.
여기서 종족 콘텐츠와 동적 콘텐츠를 어떻게 구분할 수 있을까요?
더 정확한 건 요구 사항에 따라 달라질 수 있겠지만, 개인적으로 아래와 같다고 생각합니다.
정적 콘텐츠
HTML, CSS, JavaScript 등의 페이지의 기본 구성요소동적 콘텐츠
서버에 저장 되어 있는 데이터를 가공해 만들어진 결과물
애매한 부분
[어디로 가시나요?]의 경우, 하드 코딩 되어 있을 수도 있습니다. 이 경우 정적 콘텐츠에 해당합니다.하지만 캐치 테이블의 콘텐츠 매니저가 수동으로 해당 콘텐츠를 가공하거나, AI 기술로 주기적으로 자동으로 가공하는 경우에는 동적 콘텐츠에 해당합니다.
사이트에 처음 접속하는 모달(Modal)의 경우 어떻게 구분할 수 있을까요?
이 부분도 요구 사항에 따라 달라질 수 있겠지만, 아래와 같이 구분할 수 있을 것 같습니다.
정적 콘텐츠
모달을 구성하는 기본적인 HTML, CSS, JavaScript동적 콘텐츠
특정한 이벤트에 따라서 일시적으로 생성되는 이미지
즉, 대부분의 경우 이벤트 와의 관계성으로 콘텐츠 유형을 구분할 수 있어 보입니다.
그 외에 특수한 콘텐츠들
추가적으로 텍스트(Plain Text)와 비-텍스트(Non Text)로 구분할 수 있을 것 같습니다.
이번 장에서는 약간의 계산의 편의를 위해 1,024가 아니라 1,000Byte를 1KiB으로 계산하겠습니다.
대부분의 서비스의 RESTful API에서는 최대 1,000자 미만의 길이 제한을 가집니다.
1,000자의 텍스트는 Windows에서 1,000 Byte의 용량을 가지게 되며, 이는 1 KB에 해당합니다.
블로그나 소설의 경우 10,000자 ~ 100,000자 이내의 글자가 사용되어 있을 것입니다.
이는 10 KB ~ 100 KB에 해당합니다.
잠깐!
구글링을 하다보면 10 KiB라는 단위가 나옵니다.
10 KiB는 2진수 연산을 했다는 뜻이며, 10 × 1024 Byte를 의미합니다.
10 KB는 10진수 연산을 했다는 뜻이며, 10 × 1000 Byte를 의미합니다.
하지만 동영상은 화질에 따라 5초 정도만 촬영해도 10 MB 단위가 훌쩍 넘어가게 됩니다.
이는 일반적인 텍스트의 10,000배에 해당하는 큰 용량입니다.
하지만 실제로 HTTP/S 통신은 데이터를 패킷(Packet)으로 나누어서 전송하기 때문에, 용량이 커질수록 병목현상을 발생시킵니다.
왜 병목이 발생하는가?
작업자 수의 부족
서버에는 첫 패킷을 받고 마지막 패킷을 기다릴 수 있는 1,000명의 작업자가 있습니다.
이 중에 10,000배 큰 동영상이 500개가 들어오면, 500명의 작업자만 남습니다.
이로 인해 요청을 받을 수 있는 작업자가 줄어들거나 없을 수 있습니다.네트워크 I/O의 부족
대부분의 입출력 기계에는 성능 상한선이 존재합니다.
대용량의 미디어 파일의 경우 많은 I/O를 소모하고 이로 인해 서버에서 제일 많이 발생하는 데이터 조회를 위한 I/O가 부족해집니다.
즉, 모든 동적 데이터를 서버에서 직접적으로 처리해서는 안됩니다.
대용량 동적 데이터는 다른 방법을 사용해서 처리해야 합니다.
인프라 아키텍처 설계 접근법
인프라 아키텍처란?
이는 인프라(Infrastructure)와 아키텍처(Architecture)가 합쳐진 단어입니다.
IT 업종에서는 사용자에게 서비스를 제공하기 위해 기반(인프라)이 되는 구조(아키텍처)를 인프라 아키텍처라고 부릅니다.현실 세계의 구조와 동일하게 다양한 원칙과 명확한 수치에 따라서 이를 설계하게 됩니다
사전 지식을 바탕으로 인프라 아키텍처를 설계하기 위한 접근법을 안내합니다. 해당 방법은 이론 지식을 기반으로 하여, 본인이 구축한 아키텍처에 대한 이해도를 높이는데 도움이 됩니다.
이해도가 높아진다면, 추후 이를 응용 및 활용하는데 큰 도움이 됩니다.
React CSR과 배포 방식
정적 콘텐츠를 제공할 방법?
Amazon S3에 대한 이해
정적 콘텐츠, 캐시(Cache) 그리고 엣지(Edge)
정적 콘텐츠 캐싱하는 방법?
Amazon CloudFront에 대한 이해
HTTP & HTTPS의 정의 및 차이
TLS/SSL Certificate 발급 방법?
AWS Certificate Manager에 대한 이해
TLS/SSL Certificate 소유주 인증
도메인 구매하기
Route53에 대한 이해
React CSR
이화랑 블로그 (Blog) | 배포 하면서 배우는 CSR(React)과 SSR(Next.js)을 보면, 다음과 같이 나와있습니다.
React는 정적 콘텐츠와 관계된 HTML, CSS, JavaScript 등을 한꺼번에 빌드합니다.
그리고 동적 콘텐츠를 필요한 순간에만 요청함으로써, 클라이언트(사용자) 측에서 랜더링하게 됩니다.
즉, React를 사용하게 되면 아래의 2가지 부분만 고민하시면 됩니다.
정적 콘텐츠를 제공할 방법을 찾는 것
사이트를 HTTPS로 만드는 것
정적 콘텐츠를 제공할 방법?
“AWS에서 정적 콘텐츠를 제공하기”라고 검색했을 때, 최상단에 Amazon S3가 노출됩니다.
Amazon S3에 대한 이해
하지만 저희는 Amazon S3가 무엇인지 모르기 때문에, Amazon S3라고 검색해보았습니다.
Amazon S3는 고확장성, 고가용성, 고내구성을 가지고 있는 객체 기반의 스토리지 서비스입니다.
확장성(Scalability)
추가 스토리지가 필요할 때, 알아서 추가 스토리지가 늘어납니다.가용성(Availability)
서비스가 “항상” 사용가능한 지를 나타내는 지표
퍼센트(%)로 표기할 수 있으며, 서비스 별로 가용성 보장에 대한 서비스 수준 규약(SLA, Service Level Agreement)도 존재합니다.내구성(Durability)
S3에 일단 저장된 데이터는 “대부분의 상황에서 보존”됩니다.
내구성이 높다는 의미는 데이터 손상이 되지 않음을 의미합니다.객체 및 성능
S3는 객체기반 스토리지입니다.일반적인 HDD, SSD 스토리지와 다르며 I/O 병목 지점이 거의 발생하지 않습니다. 단, 객체의 키(Key) 설계의 분포가 낮을 경우 I/O 병목이 발생할 수 있습니다.
아래 영상들로 S3의 구조/기능적 발전과 주요 사용 사례에 대해서 추가 학습이 가능합니다.
이를 실제 수치로 보면 다음과 같습니다.
내구성 : 99.999999999% (9, 11개)
약 1000억개 중 1개의 데이터가 손상됨가용성 : 99.99% (9, 4개)
일/주/월/분기/연도 별로 각각 다음과 같이 다운타임 발생 가능
서비스 수준 규약 : 99.9% (9, 3개)
일/주/월/분기/연도 별로 각각 다음과 같이 다운타임 발생 가능
정적 콘텐츠, 캐시(Cache) 그리고 엣지(Edge)
서울에서 부산으로 매일같이 빵을 100개씩 가져온다고 상상해봅시다.
그렇다면 대구 즈음에 빵을 많이 가져다 놓으면 훨씬 더 빠르고 효율적으로 빵을 제공할 수 있지 않을까요?
이것을 캐시 부릅니다.
그런데 전국에서 한 번 팔린 빵은 높은 확률로 다시 팔린다면 어떨까요?
그러면 전국 방방 곳곳에 캐싱을 할 수 있는 무언가?를 두면 되지 않을까요?
이것을 엣지라고 부릅니다.
React는 정적 콘텐츠이면서 특정한 소수의 파일들을 다수의 사용자에게 제공할 것입니다.
따라서 캐시와 엣지 기능이 결합된 서비스인 CDN을 사용하는 것이 옳아보입니다.
정적 콘텐츠 캐싱하는 방법?
앞서 배운 키워드들로 아래의 검색어를 만들었습니다.
AWS에서 정적 콘텐츠 캐싱하기
AWS에서 CDN으로 정적 콘텐츠 전달하기
해당 검색어 모두 최상단에 CloudFront가 노출됩니다.
Amazon CloudFront에 대한 이해
역시나 CloudFront도 잘 모르기 때문에, Amazon CloudFront라고 검색해보았습니다.
Amazon CloudFront는 엣지 로케이션과 캐싱을 활용하여 최저 지연 시간의 경로로 정적 및 동적 콘텐츠를 제공해주는 서비스입니다.
엣지
CloudFront의 엣지 기술은 2가지로 구성되어 있습니다.
1. 지역 접속 지점(PoP, Points of Presence)
2. 지역 엣지 캐시(REC, Regional Edge Cache)
Viewer → PoP → REC → Origin(e.g. S3) 순으로 전달됩니다.
자세한 내용은 AWS Posts (Blog) | AWS Edge Locations:What They Are and Where to Find Them을 참고해주세요.캐싱(Cache)
PoP과 REC은 모두 캐싱 기능을 포함하고 있습니다.
정적 및 동적 웹 콘텐츠(Static & Dynamic Web Content)|
가장 대중적으로 접할 수 있는 S3 사용 사례는 아래 2가지입니다.웹 사이트 배포 ＝ 정적 콘텐츠
이미지 및 동영상 파일 제공 ＝ 동적 콘텐츠
즉, CloudFront를 통해서 전세계로 사이트를 최저 지연시간으로 제공할 수 있습니다.
HTTP & HTTPS의 정의 및 차이
HTTPS(Hyper Text Transfer Protocol Secure)은 HTTP의 보안 버전입니다.
HTTP는 웹 브라우저와 웹 사이트 간에 데이터를 그대로 전송합니다. 따라서 여러 가지 보안 취약점이 발생할 수 있습니다.
HTTPS는 데이터 전송 단계에 암호화 방식을 도입하여, 전송되는 데이터를 암호화하여 보내는 것입니다. 이 과정은 TLS/SSL Handshake라고 부릅니다.
즉, HTTPS 구현을 위해서 AWS에서 TLS/SSL 인증서를 발급받아야 합니다.
TLS/SSL Certificate 발급 방법?
“AWS TLS/SSL 인증서 발급받기”라고 검색하면 2번째에 ACM(AWS Certificate Manager)가 노출됩니다.
AWS Certificate Manager에 대한 이해
역시나 Certificate Manager에 대해서 모르기 때문에, Certificate Manager라고 검색해보았습니다.
AWS Certificate Manager는 TLS/SSL 인증서를 발급해주는 서비스입니다. AWS 내의 타른 서비스와 강한 통합을 제공합니다.
주요한 장점은 다음과 같습니다.
자동 인증서 갱신
TLS/SSL 구매, 업로드 및 갱신에 드는 소모적인 수동 프로세스를 자동화
(AWS 통합의 경우) 만료 예정 TLS/SSL 인증서의 자동 재발급
CNAME 레코드 자동 생성
Route53에 CNAME 레코드를 자동으로 생성하고 동기화
다양한 HTTPS 통합 제공
CloudFront, ELB, API Gateway 등 지원
TLS/SSL Certificate 소유주 인증
누구나 어떤 도메인 이름(e.g. naver.com)으로 TLS/SSL 인증서를 발급받을 수 있습니다.
따라서 TLS/SSL Certificate 소유주 인증 절차가 필요합니다. 일반적으로 2가지 방법이 존재하며, ACM은 둘 모두 지원합니다.
DNS 인증 방식
TLS/SSL Certificate의 Key, Value를 도메인의 호스팅 존에 CNAME 레코드로 등록
이메일 인증 방식
도메인 소유주의 이메일로 인증 메일 발송
개별 방식의 장/단점 및 선택 기준은 AWS FaQ (Blog) | AWS Certificate Manager FaQ # DNS Validation을 참고해주세요.
동일 계정 아래, AWS Route53 호스팅 존과 ACM을 사용하면 DNS 등록이 자동으로 이루어집니다.
도메인 구매하기
결국 HTTPS를 구현하려면 도메인이 필요함을 알았습니다.
따라서 “AWS 도메인 구매”라고 검색하면 아래와 같은 방법이 나옵니다.
무료로 할 수 있는 방법은 없나?
No-IP에서 무료 도메인을 발급받고 Certbot에서 TLS/SSL 인증서를 발급받고 ACM에 등록하거나 다른 오픈 소스 툴을 사용해서 HTTPS 구축을 할수도 있을 것입니다.
하지만 이 방법은 실무에서 쓰기엔 문제가 많고 토이 프로젝트 레벨에서 쓸 법 하기 때문에 추천하지 않습니다.
특히 ACM, CloudFront와의 호환이 되는지 검증(PoC)이 되지 않았습니다.
Route53에 대한 이해
역시 Route53에 대해서 잘 모르기 때문에, “AWS Route53이란?”이라고 검색해보았습니다.
Route53으로 도메인을 구매하고 여러 리소스로 트래픽 라우팅을 할 수 있습니다. 또한 상태 확인(헬스 체크)을 통해 장애 알림을 구성할 수 있습니다.
도메인 등록
필요한 도메인이 있는 경우, AWS Route53에서 도메인 등록을 진행할 수 있습니다.
Route53 도메인 구매 시, AWS 크레딧 사용 불가
값싸게 도메인 구매하는 방법
가비아에서 도메인 구매 후 아래 절차 진행 시 500원 지출
1. Route53 호스팅 존 생성
2. Route53 호스팅 존의 NS 레코드 4개 복사
3. 가비아의 NS 레코드 3개를 Route53걸로 변경
단, 무통장 입금 사용 시 인증까지 NN분~ N일 걸릴 수 있음DNS 라우팅
총 12개의 레코드 유형을 지원하지만, 1주차에서는 아래의 4개의 레코드만 등록됩니다.
SOA
도메인 및 호스팅 영역에 대한 메타 정보를 제공해줍니다.호스팅 영역에 대한 네임 서버 식별하는데 사용됩니다.
DNS 리졸브 과정에서 사용 되며, MMAprogrammer.log (Blog) - DNS 동작 원리를 참고해주세요.CNAME 레코드는 일반적으로 DNS 쿼리를 다른 DNS 쿼리 방향으로 매핑하는데에 사용됩니다.
Route53과 ACM 관계에서만 TLS/SSL Certificate 검증을 위해서 사용되며, 이는 특수한 경우입니다.example.com 루트 도메인
case-b.example.com 같은 루트 도메인을 공유하는 서브 도메인
example.co.kr 다른 루트 도메인
case-c.example.co.kr 다른 루트 도메인의 서브 도메인
IPv4 주소를 사용하여 트래픽을 라우팅합니다.
작성일(2024.04.16) 기준 별칭 기능이 제공되며 AWS 내부에서 사용되는 도메인 주소를 사용한 라우팅이 지원됩니다.IPv6 주소는 AAAA 레코드를 사용합니다.
상태 확인
헬스 체크 기능이 지원됩니다.
라우팅 대상이 이상할 경우, 알림(CloudWatch + SNS Topic)을 발생시킬 수 있습니다.
인프라 아키텍처 설계
이번 장에서는 툴 선택 및 설계 결과물을 공유합니다.
여기서는 인프라 아키텍처 설계이지만, 실제로는 다양한 개발 설계 과정에 쓸 수 있는 방식입니다.
툴 선택하기
설계 결과물 공유
툴 선택하기
종이/타블렛, Miro, Figma 등을 통해서 설계를 해본 적이 있으며, 각각의 장단점을 표로 정리하였습니다.
개인적인 의견
범용적으로 사용하기에는 Miro가 좋아보입니다.
면접이나 즉석 토론 등의 특수한 경우에만 종이/타블렛(혹은 칠판) 등이 좋습니다.
지극히 개인적인 의견이며 사용해보시고 좋은 툴을 쓰시길 바랍니다.
구분 | 작업 시간 | 재사용성 | 총 생산성 | 의견 |
|---|---|---|---|---|
종이/타블렛 | 짧음 | 없음 | 높음 | 단시간에 빠르게 설계하는데 좋습니다. |
Miro | 보통 | 약간 | 보통 | 스터디나 토론회 등에서 쓰는게 좋아보입니다. |
Figma | 김 | 많음 | 낮음 | 본인이 Figma에 익숙하면 좋아 보입니다. |
설계 결과물 공유
설계 Tip
클라이언트한테 가까운 부분부터 설계하는 것이 좋습니다.
데이터베이스, 서버 보다는 Route53, CloudFront 등부터 좌→우 순으로 그려나가야 리터치가 적어집니다.
인프라 아키텍처 설계 접근법을 통해서, 이미 모든 리소스에 대한 기본적인 이해를 쌓았습니다.
그 내용들을 기반으로 아래 인프라를 분석하고 그 내용을 적어보는 것도 좋아 보입니다.
