클라우드 컴퓨팅 설명: 반드시 알아야 할 11가지 아키텍처 개념 (4K 마스터클래스).

이 동영상에서 다루는 내용

• - 아키텍처 벽 및 마스터 청사진
• - 01. 수직 대 수평 스케일링
• - 02. 로드 밸런싱 아키텍처 (L4 대 L7 및 상태 확인)
• - 03. 자동 스케일링 및 탄력성
• - 04. 서버리스 (FaaS 및 Firecracker MicroVM)

번역된 스크립트

원래 영어 내레이션에서 번역되었습니다. 사용 가능한 오디오 및 캡션은 YouTube에서 제어합니다.

- 아키텍처 벽 및 마스터 청사진

0:00 모든 소프트웨어 엔지니어는 결국 클라우드 아키텍처의 벽에 부딪힙니다. 노트북에서 애플리케이션을 구축하고 프로덕션에 푸시하지만, 실제 사용자가 들어오는 순간 서버가 충돌하고, 데이터베이스 연결이 고갈되고, AWS 청구서가 전화 번호처럼 보입니다. 대부분의 개발자는 3백 가지 다른 AWS 제품 약어를 암기하여 클라우드 엔지니어링을 해결하려고 합니다. 그러나 실제 클라우드 컴퓨팅은 공급업체 카탈로그를 암기하는 것이 아니라, 11가지 기본 아키텍처 기본 요소 위에 구축됩니다.

0:34 이 마스터클래스에서는 스케일링 및 로드 밸런싱에서 서버리스, 이벤트 기반 디커플링, 스토리지 계층 구조 및 클라우드 네트워킹에 이르기까지 전체 엔터프라이즈 청사진을 살펴보겠습니다. 이 11가지 개념을 마스터하면 AWS, GCP 또는 Azure에서 모든 백엔드를 설계할 수 있습니다. 이것은 The Daily Diff, 후드 아래입니다. 첫 번째 개념: 스케일링.

- 01. 수직 대 수평 스케일링

0:57 애플리케이션에 트래픽 증가가 발생하면 로드를 처리하는 근본적으로 두 가지 다른 방법이 있습니다: 수직 스케일링 또는 수평 스케일링. 수직 스케일링 또는 스케일업은 기존 머신에 더 많은 리소스를 추가하는 것을 의미합니다: 4개의 CPU 코어에서 32개로 업그레이드하거나 32기가바이트의 RAM을 128기가바이트로 교체하는 것입니다. 수직 스케일링은 아키텍처 변경이 전혀 필요하지 않습니다: 코드는 및 데이터베이스는 완전히 동일하게 유지됩니다. 그러나 그것은 잔인한 하드웨어 한계에 부딪힙니다.

1:28 세상에 1만 개의 CPU 코어를 가진 단일 머신은 없으며, 최고급 인스턴스는 기하급수적인 가격 프리미엄을 수반합니다. 수평 스케일링 또는 스케일아웃은 서버를 작고 저렴하게 유지하지만, 라우터 뒤에서 여러 인스턴스를 병렬로 실행하는 것을 의미합니다. 하나의 인스턴스가 충돌하면 나머지 노드가 중단 없이 트래픽을 흡수합니다. 수평 스케일링의 황금률은 상태 비저장입니다: 애플리케이션 서버는 사용자 세션, 업로드된 파일 또는 상태를 로컬 디스크에 저장할 수 없습니다. 상태는 외부 데이터베이스 또는 캐시에 있어야 하며,

2:01 모든 노드가 모든 사용자 요청을 처리할 수 있도록 합니다. 두 번째 개념: 로드 밸런싱. 수평 스케일링은 이론적으로 훌륭하지만 즉각적인 문제를 야기합니다: 1만 명의 사용자가 도메인 이름에 접속할 때,

- 02. 로드 밸런싱 아키텍처 (L4 대 L7 및 상태 확인)

2:17 어떤 특정 서버가 그들의 트래픽을 수신합니까? 로드 밸런서는 공용 인터넷과 개인 백엔드 클러스터 사이에 위치한 리버스 프록시 역할을 합니다. 들어오는 TCP 또는 HTTP 연결을 수락하고, 정상 인스턴스에 요청을 분산합니다. 로드 밸런서는 두 가지 주요 네트워크 계층에서 작동합니다. 계층 4 네트워크 로드 밸런서는 전송 계층에서 작동하여, IP 주소와 포트를 기반으로 원시 TCP 및 UDP 패킷을 라우팅하며, 마이크로초 대기 시간과 초당 수백만 개의 요청을 처리합니다.

2:47 계층 7 애플리케이션 로드 밸런서는 HTTP 프로토콜 자체를 검사합니다: URL 경로, 요청 헤더, 쿠키 및 HTTP 메서드를 읽습니다. 이를 통해 경로 기반 라우팅이 가능합니다: /api 요청을 백엔드 클러스터로 보내고 /static 요청을 객체 저장소로 보냅니다. 결정적으로 로드 밸런서는 활성 상태 확인을 수행합니다. 몇 초마다 밸런서는 모든 인스턴스에 대한 상태 엔드포인트를 핑합니다. 인스턴스가 세 번 연속 500 오류를 발생시키거나 응답하지 않으면 요청이 드롭되지 않고 자동으로 풀에서 제거됩니다.

3:25 세 번째 개념: 자동 스케일링. 웹 앱이 새벽 3시에 두 대의 서버가 필요하지만, 정오 출시 시 20대의 서버가 필요하다면 클라우드 콘솔에서 수동으로 버튼을 클릭하는 것은 다운타임과 파산으로 가는 지름길입니다. 자동 스케일링은 수평 서버 풀에 동적 탄력성을 제공합니다.

- 03. 자동 스케일링 및 탄력성

3:45 자동 스케일링 그룹은 평균 CPU 활용률, 네트워크 I/O 또는 큐 백로그 깊이와 같은 성능 지표를 모니터링합니다. 평균 CPU가 정의된 임계값을 초과하면 — 예를 들어, 3분 연속 70% — 자동 스케일러는 자동으로 새로운 가상 머신을 시작하고, 로드 밸런서에 등록하고, 트래픽 라우팅을 시작합니다. 마찬가지로 중요한 것은 스케일인입니다: 트래픽이 줄어들면, 자동 스케일러는 초과 인스턴스를 종료하여 유휴 컴퓨팅에 대한 비용 지불을 중단합니다. 서버가 빠르게 생성되고 파괴되는 플래핑을 방지하기 위해,

4:19 자동 스케일러는 종료할 인스턴스를 선택할 때 쿨다운 기간 또는 종료 정책을 사용합니다. 네 번째 개념: 서버리스. 애플리케이션에 대한 요청이 들어올 때마다 전용 서버에서 애플리케이션 코드를 실행하는 대신, 서버리스는 클라우드 공급자가 관리하는 공유 인프라에서 코드를 실행합니다. 이는 코드 배포, 확장 또는 서버 패치에 대해 걱정할 필요가 없음을 의미합니다. 서버리스는 FaaS (Functions as a Service) 및 MicroVM과 같은 다양한 형태로 제공됩니다. 무한한 격렬한 루프에서 파괴되는 것을 방지하기 위해 클라우드 설계자는 재사용 기간을 구성합니다. 네 번째 개념: 서버리스.

- 04. 서버리스 (FaaS 및 Firecracker MicroVM)

4:53 수년 동안 마케팅 팀은 서버리스를 하늘에서 실행되는 마법의 코드라고 홍보했습니다. 현실에서는 서버리스도 여전히 서버를 사용하지만, 코드가 실행되지 않을 때는 소유하거나 패치하거나 비용을 지불하지 않습니다. AWS Lambda 또는 Google Cloud Functions와 같은 Function-as-a-Service를 사용하면, 독립 실행형 핸들러 함수를 작성합니다. HTTP 요청, S3 파일 업로드 또는 데이터베이스 변경이 발생하면, 클라우드 런타임은 Firecracker와 같은 임시 마이크로 가상 머신을 5밀리초 미만으로 부팅합니다.

5:23 코드가 실행되고 응답을 반환한 다음 종료됩니다. 3개월 동안 아무도 웹사이트를 방문하지 않으면 컴퓨팅 비용은 정확히 0달러 0센트입니다. 백만 명의 사용자가 동시에 접속하면 공급자는 백만 개의 동시 마이크로 VM을 실행합니다. 엔지니어링 트레이드오프는 실제로 존재합니다. 즉, 새 런타임을 시작할 때 콜드 스타트 지연 시간, Lambda의 엄격한 15분 실행 제한, 엄격한 무상태성입니다. 서버리스는 이벤트 파이프라인 및 산발적인 API에 탁월하지만, 영구적인 웹소켓 또는 여러 시간 동안 실행되는 학습에는 적합하지 않습니다.

5:55 다섯 번째 개념: 이벤트 기반 아키텍처, 또는 EDA. 기존 아키텍처에서는 서비스가 동기적으로 통신합니다.

- 05. 이벤트 기반 아키텍처 (EDA 및 디커플링)

6:05 결제 서비스가 결제를 호출하고, 결제가 재고를 호출하고, 재고가 사기를 호출하고, 사기가 이메일을 호출합니다. 이것은 동기식 재앙의 연쇄를 만듭니다. 타사 이메일 공급자가 네트워크 장애를 겪고 응답하는 데 10초가 걸리면, 고객의 전체 결제 요청이 시간 초과되어 오류가 발생합니다. 이벤트 기반 아키텍처에서는 서비스가 완전히 분리됩니다. 고객이 구매를 클릭하면 결제 서비스는 하위 서비스를 호출하지 않습니다. 단순히 OrderPlaced라는 이벤트를 중앙 이벤트 버스(예: Amazon EventBridge 또는 SNS 토픽)에 게시합니다.

6:37 결제는 50밀리초 내에 완료됩니다. 결제, 재고 차감, 이메일 영수증을 위한 하위 작업자는 각각의 전용 SQS 대기열에서 메시지를 독립적으로 가져옵니다. 이메일 서비스가 한 시간 동안 중단되더라도 메시지는 단 한 건의 주문도 누락되지 않고 대기열에 안전하게 버퍼링되어 기다립니다. 여섯 번째 개념: 컨테이너 오케스트레이션. Docker는 패키징을 해결했습니다. 즉, 애플리케이션 코드, 시스템 라이브러리, 구성 및 런타임을 변경 불가능한 이미지로 묶어 MacBook과 클라우드에서 동일하게 실행됩니다. 하지만 컨테이너를 패키징하는 것은 쉽습니다.

- 06. 컨테이너 오케스트레이션 (Docker 및 Kubernetes)

7:13 50개의 물리적 가상 머신에서 500개의 컨테이너를 실행하는 것은 엔지니어링이 무너지는 지점입니다. 이것이 Kubernetes 및 AWS ECS와 같은 컨테이너 오케스트레이터가 존재하는 이유입니다. 오케스트레이터는 제어 평면을 제공합니다. 즉, API 서버, etcd 상태 저장소 및 지능형 스케줄러입니다. 원하는 상태를 선언합니다. 즉, 각 2기가바이트의 RAM을 가진 인증 서비스의 복제본 10개가 필요합니다. 스케줄러는 클러스터를 검사하고, 사용 가능한 메모리가 있는 노드에 Pod를 배치하고, 내부 네트워킹을 구성하며, 지속적으로 현실을 조정합니다.

7:41 노드에 하드웨어 장애가 발생하면 Kubernetes는 손실을 감지하고 모든 분리된 Pod를 즉시 정상 노드로 재스케줄링합니다. 일곱 번째 개념: 클라우드 스토리지 계층. 초보자는 종종 클라우드 스토리지를 파일을 덤프하는 단일 버킷으로 취급합니다. 프로덕션 아키텍처에서는 액세스 패턴 및 지연 시간을 기준으로 스토리지가 네 가지 별개의 기둥으로 나뉩니다. 첫째는 Amazon S3 또는 Google Cloud Storage와 같은 객체 스토리지입니다. 간단한 PUT 및 GET 호출을 사용하여 HTTP REST API를 통해 파일에 액세스합니다. 월 기가바이트당 2센트의 무한한 수평 용량을 제공하여

- 07. 4가지 클라우드 스토리지 기둥 (S3, EBS, DB 및 Redis)

8:16 비디오, 사용자 업로드, 로그 및 백업에 이상적입니다. 둘째는 Amazon EBS와 같은 블록 스토리지입니다. 이는 고속 상호 연결을 통해 특정 가상 머신에 직접 마운트되는 가상 하드 드라이브입니다. ext4와 같은 표준 파일 시스템으로 포맷되어 데이터베이스 엔진에 필요한 빠른 무작위 읽기 및 쓰기 액세스를 지원합니다. 셋째는 관리형 데이터베이스입니다. 즉, RDS의 PostgreSQL과 같은 관계형 엔진은 ACID 트랜잭션 및 복잡한 조인을 제공하고, DynamoDB와 같은 NoSQL 엔진은 대규모로 한 자리 밀리초 지연 시간을 제공합니다. 그리고 넷째는 Redis와 같은 인메모리 캐시입니다.

8:49 RAM에서 데이터를 읽는 데는 밀리초가 아닌 마이크로초가 걸립니다. 캐시는 데이터베이스 앞에 위치하여 반복되는 읽기 트래픽으로부터 데이터베이스를 보호하고 휘발성 사용자 세션 토큰을 관리합니다. 여덟 번째 개념: 고가용성, 또는 HA. 가용성은 한 가지 질문에 답합니다. 즉, 애플리케이션이 작동하고 사용자에게 연결 가능한 시간의 비율은 얼마입니까? 엔터프라이즈 계약에서는 가용성을 '나인'으로 측정합니다. 두 개의 나인, 즉 99% 가용성은 매년 3.5일 이상의 다운타임을 허용합니다. 네 개의 나인은 허용되는 다운타임을 52분으로 줄이고,

9:21 다섯 개의 나인은 매년 총 5분 미만의 다운타임을 허용합니다. 고가용성을 달성하려면 오류 도메인 전반에 걸쳐 단일 실패 지점을 제거해야 합니다. 클라우드에서는 여러 가용성 영역에 배포하는 것을 의미합니다. 가용성 영역은 단일 랙이 아니라 독립적인 전원 및 냉각 장치를 갖춘 수 마일 떨어진 하나 이상의 별개의 물리적 데이터 센터입니다. 동기식 데이터베이스 복제를 통해 영역 A와 영역 B에서 활성 인스턴스를 실행함으로써, 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다.

- 08. 고가용성 및 나인 (Multi-AZ Failover)

9:44 가용성 영역은 단일 랙이 아니라 독립적인 전원 및 냉각 장치를 갖춘 수 마일 떨어진 하나 이상의 별개의 물리적 데이터 센터입니다. 동기식 데이터베이스 복제를 통해 영역 A와 영역 B에서 활성 인스턴스를 실행함으로써, 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 동기식 데이터베이스 복제를 통해 영역 A와 영역 B에서 활성 인스턴스를 실행함으로써, 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다.

10:15 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다. 전체 물리적 시설을 중단시키는 번개 또는 광섬유 절단으로 인해 자동 장애 조치가 발생합니다.

10:50 인적 개입 없이 30초 만에요.

- 09. 내구성 대 가용성 (왜 11 나인이 가동 시간이 아닌가)

10:53 개념 9: 내구성 대 가용성. 이것은 클라우드 아키텍처 인터뷰에서 가장 흔한 개념적 함정입니다. 엔지니어들은 이 단어들을 자주 혼용하지만, 이 단어들은 완전히 다른 속성을 측정합니다. 가용성은 가동 시간을 측정합니다. 지금 바로 데이터를 읽거나 쓰기 위해 API 호출을 할 수 있습니까? 지금 당장? 내구성은 보존을 측정합니다. 내 데이터가 영구적인 비트 부패, 손상 또는 파괴 없이 10년 동안 생존할까요? 10년 동안?

11:24 Amazon S3 Standard를 보세요. 서비스 수준 계약은 99.9%의 가용성을 제공하며, 이는 매월 약 43분 동안 API 요청이 500 오류를 반환할 수 있는 다운타임을 허용합니다. API 요청이 500 오류를 반환할 수 있습니다. 그러나 S3는 11개의 9 내구성, 즉 99.999999999% 99.999999999% 를 약속합니다. S3에 천만 개의 파일을 저장한다면, 통계적으로 만 년마다 평균 한 개의 파일을 잃을 것으로 예상할 수 있습니다.

11:56 만 년마다 평균 한 개의 파일을 잃을 것으로 예상할 수 있습니다. S3는 개체를 지우기 코딩하고 최소 3개의 지리적으로 분리된 데이터 시설에 청크를 복제하여 이를 달성합니다. 최소 3개의 지리적으로 분리된 데이터 시설에 청크를 복제하여 이를 달성합니다. 주요 지역 네트워크 중단 중에는 S3가 일시적으로 사용 불가능할 수 있지만, 데이터는 절대 파괴되지 않습니다.

- 10. 코드형 인프라 (Terraform 대 콘솔 드리프트)

12:14 개념 10: 코드형 인프라, 또는 IaC. 클라우드 컴퓨팅 초기에는 엔지니어들이 AWS 웹 관리 콘솔에 로그인하여 수동으로 가상 머신을 만들고, 가상 머신을 만들고, 서브넷을 구성하고, 보안 그룹을 연결했습니다. 서브넷을 구성하고, 보안 그룹을 연결했습니다. 업계에서는 이를 ClickOps라고 부르며, 프로덕션에서는 완전한 재앙입니다. 수동 콘솔 변경은 감사 추적이 없고, 롤백 메커니즘이 없으며, 스테이징과 프로덕션 환경 간에 필연적으로 구성 불일치를 야기합니다. 스테이징과 프로덕션 환경 간에 필연적으로 구성 불일치를 야기합니다. Terraform, OpenTofu, Pulumi 또는 AWS CDK와 같은 코드형 인프라 도구를 사용하면,

12:48 Terraform, OpenTofu, Pulumi 또는 AWS CDK와 같은 코드형 인프라 도구를 사용하면, OpenTofu, Pulumi 또는 AWS CDK와 같은 코드형 인프라 도구를 사용하면, Git에 저장된 선언적 구성 파일로 전체 클라우드 아키텍처를 정의할 수 있습니다. 열려 있는 포트나 데이터베이스 복제본에 대한 모든 변경 사항은 풀 리퀘스트와 동료 검토를 거칩니다. 풀 리퀘스트와 동료 검토를 거칩니다. terraform plan을 실행하면 아무것도 건드리지 않고도 정확한 API 차이를 미리 볼 수 있으며, 프로덕션 스택의 동일한 복제본을 실행하는 데 4주 대신 4분이 걸립니다. 스택의 동일한 복제본을 실행하는 데 4주 대신 4분이 걸립니다.

- 11. 클라우드 네트워킹 (VPC, 서브넷, NAT 및 보안 그룹)

13:20 개념 11: 클라우드 네트워킹 및 가상 사설 클라우드. 클라우드에 서버를 배포할 때, 서버는 공개 인터넷에 그대로 노출되지 않습니다. 서버는 VPC라고 불리는 소프트웨어 정의의 격리된 경계 안에 있습니다. VPC라고 불리는 소프트웨어 정의의 격리된 경계 안에 있습니다. VPC 내부에서 10.0.0.0/16과 같은 사설 IP 주소 공간을 할당하고, 10.0.0.0/16과 같은 사설 IP 주소 공간을 할당하고, 이를 공용 및 사설 서브넷으로 나눕니다. 공용 서브넷은 인터넷 게이트웨이로의 직접 경로를 가집니다.

13:51 애플리케이션 로드 밸런서 및 NAT 게이트웨이와 같은 공용 자산을 보유합니다. 공용 IP 주소를 가진 네트워크의 유일한 부분입니다. 애플리케이션 서버 및 프로덕션 데이터베이스는 공용 IP가 없고 인터넷으로부터의 인바운드 경로가 없는 사설 서브넷에 엄격하게 존재합니다. 인터넷으로부터의 인바운드 경로가 없는 사설 서브넷에 엄격하게 존재합니다. 백엔드 서버가 보안 업데이트를 다운로드해야 할 때, 아웃바운드 트래픽은 공용 서브넷의 NAT 게이트웨이를 통해 라우팅됩니다. 각 인스턴스를 둘러싸는 보안 그룹: 최소 권한 원칙을 강제하는 스테이트풀 가상 방화벽입니다. 가상 방화벽은 최소 권한 원칙을 강제합니다.

- 12. 전체 엔터프라이즈 청사진 및 평가

14:28 데이터베이스 보안 그룹은 포트 5432에서 애플리케이션 서버의 보안 그룹으로부터의 연결만 허용하여, 5432에서 애플리케이션 서버의 보안 그룹으로부터의 연결만 허용하여, 외부 침투를 수학적으로 불가능하게 만듭니다. 확대해서 보면, 이 11가지 기본 요소가 하나의 응집력 있는 시스템으로 연결됩니다. DNS는 공용 서브넷의 로드 밸런서로 라우팅되고, 자동 확장 그룹은 여러 가용 영역에 걸쳐 트래픽 급증을 처리하며, 이벤트 버스는 백엔드 워커를 분리하고, 전체 스택은 코드형 인프라를 사용하여 Git에서 배포됩니다. 코드형 인프라를 사용하여 Git에서 배포됩니다.

15:02 오늘 마스터클래스의 평결: SHIP IT. 수백 개의 클라우드 마케팅 약어를 외우는 것을 멈추세요. 이 11가지 아키텍처 패턴을 마스터하고, 상태를 분리하며, 실패할 수 없는 시스템을 구축하세요. 처음 시작할 때 가장 큰 골칫거리였던 클라우드 개념이 무엇이었는지 댓글로 알려주세요. 댓글로 알려주세요. 그리고 전체 아키텍처 치트 시트를 받으려면, The Daily Diff.dev에서 뉴스레터를 구독하세요.

15:28 아래 링크. 그리고 오늘의 차이점은 여기까지입니다. 저는 Axrisi의 Niko입니다. 책임감 있게 병합하세요.

출처

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io