[week4] 19. 서버리스

HyeGyeong/Scalability & High Availability/ELB Custom.md

@@ -0,0 +1,150 @@
+
+# Sticky Session (Session Affinity)
+
+쿠키를 통해 클라이언트 요청이 로드밸런서를 거치더라도 **같은 EC2 인스턴스에 지속적으로 연결**되도록 하는 기능이다. **CLB**, **ALB**, **NLB**에서 사용할 수 있다.
+
+## 동작 과정
+
+1. 클라이언트가 로드 밸런서에 요청 시 **쿠키를 받음**
+2. 이후 요청 시 이 쿠키를 사용하면 **같은 인스턴스에 라우팅 됨**
+3. 쿠키가 만료되면 라우팅 대상이 바뀔 수 있음
+
+## 그 쿠키는 어떻게 만드나요?
+
+1. Application Cookie
+   어플리케이션이 직접 만든 쿠키를 사용할 수 있다.
+2. Duration-based Cookies
+   로드밸런서가 만들어주는 쿠키를 사용할 수 있다. 이때 쿠키는 AWSALB, AWSALBAPP와 같은 이름으로 만들어진다. 따라서, 저 이름을 어플리케이션에서 사용하면 안된다.
+
+---
+
+# Cross-Zone Load Balancing
+
+**여러 Availability Zone**에 인스턴스들이 있어도 로드밸런서가 **트래픽을 고르게 분산**하는 기능이다.
+
+## 작동 방식
+
+아래 그림을 이해하면 된다.
+
+만약 Cross-Zone Load Balancing 기능이 활성화 되어있지 않다면, AZ 1에 있는 인스턴스들은 25씩의 부하를 받게되고, AZ 2의 인스턴스들은 6.25씩 받게된다.
+
+이런 상황을 막기 위해 로드밸런서가 다른 AZ로 트래픽을 전송하여 고르게 분배되도록 하는 것이다.
+![[Pasted image 20250504212253.png]]
+
+## 로드 밸런서별 요금과 기본 값
+
+| 로드 밸런서 유형 | 기본 상태    | 비용 발생 여부               |
+| --------- | -------- | ---------------------- |
+| **ALB**   | **활성화**  | **X** (AZ 간 전송 무료)     |
+| **NLB**   | **비활성화** | **O** (활성화 시 전송 요금 발생) |
+| **GWLB**  | **비활성화** | **O** (NLB와 동일)        |
+| **CLB**   | **비활성화** | **X** (활성화해도 무료)       |
+
+### 상황별 예시
+
+- **트래픽 균형이 중요한 경우** -> 사용하는게 좋다.
+- **요금이 민감하거나 AZ 구조가 대칭적일 경우** -> 사용하지 않는게 좋다.
+- **ALB를 사용하는 경우** -> 기본으로 활성화되며 추가비용도 없으니 사용하는게 좋다.
+
+---
+
+## SSL/TLS 인증서
+
+### 기본 개념
+
+SSL은 연결의 양 끝단에 있는 클라이언트와 서버만 복호화 할 수 있게 암호화하는 기술이다. 이를 In-flight encryption라고 부른다.
+
+### 작동 방식
+
+1. 클라이언트가 **HTTPS**로 로드 밸런서에 트래픽 전송
+2. 로드밸런서는 요청을 복호화함. 이를 **SSL 종료(SSL Termination)라고 한다.**
+3. 이후 백엔드(EC2 등)에서는 Private IP를 사용하므로 **HTTP** 요청으로 전달해도 안전하다.
+
+### ACM
+
+AWS Certification Manager로 인증서 발급과 관리를 담당한다. 물론 자체 발급 인증서를 업로드 할 수도 있다.
+
+## SNI (Server Name Indication)
+
+   Server Name Indication의 약자로, 여러개의 인증서를 웹서버에 로드해서 사용할 수 있는 기술이다. 
+
+ALB의 두개의 타겟 그룹이 서로 다른 도메인을 가지고 있다. 하지만 SSL 인증서는 도메인 단위로 발급되기 때문에, 아래 그림과 같은 상황에서는 SNI가 지원되어야만 한다. 클라이언트가 SSL 핸드셰이크를 보낼 때 요청 도메인 정보를 확인해서 올바른 인증서를 로드한다.
+![[Pasted image 20250504214611.png]]
+
+### SNI 지원 로드 밸런서
+
+| 로드 밸런서 유형 | SNI 지원 여부 | 다중 인증서 지원 |
+| --------- | --------- | --------- |
+| **ALB**   | ✅         | ✅         |
+| **NLB**   | ✅         | ✅         |
+| **CLB**   | ❌         | ❌         |
+
+- **ALB/NLB**: 여러 도메인용 인증서 → 하나의 리스너에서 처리 가능
+- **CLB**: 도메인마다 로드 밸런서를 따로 만들어야 함
+
+---
+
+# Connection Draining (Deregistration Delay)
+
+인스턴스를 로드밸런서에서 제거할 때, **기존 연결을 즉시 끊지 않고 일정 시간 동안 유지**하여 **이미 활성 요청을 마무리**할 수 있도록 하는 기능이다. **CLB**에서는 Connection Draining라고 부르고, **ALB와 NLB**에서는 Deregistration Delay라고 부른다.
+
+### 작동 방식
+
+1. 인스턴스가 **로드밸런서 등록 취소 또는 비정상 상태**가 됨.
+2. 로드 밸런서는 해당 인스턴스에 **새 요청을 더이상 보내지 않음.**
+3. 기존 연결은 **지정된 시간 동안 유지**.
+4. 모든 연결이 종료 되면 인스턴스 제거.
+
+### 설정
+
+- **지연 시간 설정 범위**: `1 ~ 3,600초` (최대 1시간)
+- **기본값**: `300초` (5분)
+- **0초 설정 시**: 기능 비활성화 (인스턴스를 즉시 종료)
+
+-> 요청에 걸리는 평균 시간에 맞게 적절히 설정해주면 된다. 보통의 경우 요청이 1초안에 끝난다면 30초 정도로 설정해주면 좋다.
+
+---
+
+# ASG
+
+Auto Scailing Group의 약자로 현재 부하에 맞게 **EC2 인스턴스를 자동으로 생성하거나 제거**하는 기술이다.
+- **스케일 아웃**: 부하 증가 → 인스턴스 추가
+- **스케일 인**: 부하 감소 → 인스턴스 제거
+
+## 동작 방식
+
+1. 최소 용량, 희망 용량, 최대 용량을 설정.
+2. Launch Template을 정의.
+   EC2를 생성할 때 어떻게 생성할지를 정의하는 것이다.
+   포함 내용: AMI, 인스턴스 타입, 사용자 데이터, 보안 그룹, IAM 역할 등
+3. CloudWatch 설정
+   어떤 Metric을 기준으로 부하를 모니터링 할지 정하는 것이다. CPU 사용량 등 원하는 Metric을 지정할 수 있다. CloudWatch에서 Alarm이 울리면 Scale-In이나 Scale-out이 수행된다.
+![[Pasted image 20250504220237.png]]
+## 스케일링 정책
+
+### 유형
+
+| 정책 유형               | 설명                                   |
+| ------------------- | ------------------------------------ |
+| **Target Tracking** | 메트릭을 설정값(예: CPU 40%) 근처로 유지하도록 자동 조절 |
+| **Simple**          | CloudWatch 알람 기반으로 인스턴스를 증가/감소       |
+| **Step**            | 임계값을 초과하는 정도에 따라 인스턴스 수를 조절          |
+| **Scheduling**      | 특정 시간에 스케일 조정 (예: 금요일 17시에 최소 용량 증가) |
+| **Predictive**      | 과거 부하를 학습해 미래 스케일링을 **미리 예약**        |
+
+### Metric의 종류
+
+| 메트릭               | 설명                                  |
+| ----------------- | ----------------------------------- |
+| **CPU 사용률**       | 가장 일반적인 기준, 평균 CPU가 높으면 확장          |
+| **ELB의 타깃당 요청 수** | 평균 미해결 요청 수 기반으로 확장 (L7 애플리케이션에 유용) |
+| **네트워크 사용량**      | 인/아웃 바이트 수를 기준으로 스케일                |
+| **사용자 정의 메트릭**    | CloudWatch에서 정의한 커스텀 메트릭 사용 가능      |
+
+### Cooldown
+
+인스턴스를 추가하거나 제거한 후 메트릭이 안정되기를 기다리는 것이다. 쿨다운 시간이 되면 **ASG는 일정 시간 동안 새로운 작업을 보류**한다.
+
+- **기본값**: `300초 (5분)`
+	- **EC2 설정 속도가 빠르다면** 쿨다운 시간 단축 가능
+    - CloudWatch의 **고해상도 모니터링(1분 단위)을 함께 사용하면 민첩한 대응 가능

HyeGyeong/Scalability & High Availability/ELB.md

@@ -0,0 +1,113 @@
+
+## 로드 밸런서란?
+![[Pasted image 20250503235709.png]]
+- 하나의 엔드포인트로 클라이언트 요청을 받아서 **백엔드 서버들(EC2 등)로 분산 처리**하는 역할을 함.
+
+### 기능과 장점
+
+1. **트래픽 분산**
+   각 유저의 요청을 다른 인스턴스로 자동 분배
+2. **Health Check**
+   특정 인스턴스가 응답하지 않으면 해당 인스턴스로는 요청 전송 ❌
+   예: HTTP 4567 포트의 `/health`에서 상태 체크
+3. **SSL 종료 (SSL Termination)**
+   HTTPS 트래픽을 로드 밸런서에서 처리하여 EC2는 HTTP로 통신
+4. **고정 세션 (Sticky Session)**
+   쿠키 기반으로 클라이언트 요청을 동일 인스턴스로 유지 가능
+5. **보안 강화**
+   로드 밸런서는 `0.0.0.0/0`에서 80, 443 포트 허용하고, EC2는 **로드 밸런서 보안 그룹**만 허용
+   -> EC2는 오직 로드밸런서에서 오는 요청만 받게됨
+
+### ELB의 종류
+
+| 이름                    | 프로토콜                   | 특징             |
+| --------------------- | ---------------------- | -------------- |
+| **CLB** (Classic)     | HTTP, HTTPS, TCP       | 지금은 Deprecated |
+| **ALB** (Application) | HTTP, HTTPS, WebSocket | L7 로드 밸런싱      |
+| **NLB** (Network)     | TCP, UDP, TLS          | L4 고성능 트래픽     |
+| **GWLB** (Gateway)    | L3 (IP 기반)             | 보안 어플라이언스 통합용  |
+
+---
+
+# ALB
+
+7계층인 Application Layer에서 작동하는 로드밸런서이다. 하나의 ALB로 **여러 애플리케이션 트래픽**을 처리 가능하다는 특징이 있어서 MSA와 컨테이너 기반 애플리케이션에 아주 적합하다!
+
+### 주요 기능
+
+![[Pasted image 20250503235913.png]]
+
+1. **경로 기반 라우팅 (Path-based Routing)**  
+   `/users` → 대상 그룹 A, `/search` → 대상 그룹 B
+2. **호스트 기반 라우팅 (Host-based Routing)**  
+   `one.example.com` → 그룹 A, `other.example.com` → 그룹 B
+3. **쿼리 스트링 / 헤더 기반 라우팅**  
+    `?platform=Mobile` → 모바일 전용 그룹
+
+### Target Group (대상 그룹)
+
+ALB가 요청을 분배하는 단위를 말한다. 아래 요소들이 타겟 그룹이 될 수 있다. 또한, **Health Check는 타켓 그룹 레벨에서 수행된다.**
+- EC2 인스턴스
+- ECS 작업(Task)
+- Lambda 함수
+- 사설 IP 기반 온프레미스 서버
+
+### 클라이언트, ALB, EC2의 통신
+
+- ALB에는 **DNS Name**이 부여됨. 예를 들어,`abc.amazonaws.com`
+- 클라이언트의 실제 IP는 직접 전달되지 않음  
+![[Pasted image 20250504000004.png]]
+1. 클라이언트가 ALB의 Public IP로 요청을 보냄. (DNS Name을 통해 이루어짐.)
+2. ALB와 EC2는 각자의 Private IP로 통신하며 클라이언트 요청을 수행함.
+   따라서, EC2는 클라이언트의 실제 IP를 알 수 없음.
+3. `X-Forwarded-For`, `X-Forwarded-Port`, `X-Forwarded-Proto` 헤더로 클라이언트의 정보를 확인 가능.
+
+
+---
+# 네트워크 로드 밸런서 (NLB)
+
+- **4계층**인 TCP, UDP 기반으로 동작하는 **엄청! 고성능인 로드밸런서**이다. 초당 **수백만 건의 요청 처리**가 가능하며, 지연 시간도 짧다. 중요한 특징으로는, 하나의 Availability Zone마다 하나의 고정 IP를 할당받는다. (물론 Elastic IP를 가지고 있다면 사용할 수 있다!)
+
+## 시험에 어떻게 나오는가?
+
+1. 애플리케이션이 하나, 두 개 또는 세 개의 다른 IP로만 접근할 수 있다고 할 때
+2. 극한의 성능, TCP 또는 UDP, 고정 IP가 나올 때
+
+## ALB와 비교
+
+작동 방식이 ALB와 아주 유사하다. 보안 그룹과 Target Group을 사용하는 것과 Health Check가 이루어지는 것도 모두 같다. 그래서 ALB를 맨 처음에 배우나보다.. 아래는 NLB만의 차이점이다.
+
+1. **TCP, UDP 지원**
+   어플리케이션은 여전히 HTTP로 작동하지만, 클라이언트는 TCP로 요청을 보낼 수 있다.
+2. **고정 IP 지원**
+   ALB는 로드밸런서에 고정 IP가 생기는 것이 아니라 DNS Name이 할당된다. 따라서 DNS Name에 할당 된 IP가 변할 수 있으므로 고정 IP가 아니다. 반면, NLB에는 고정 IP가 할당된다.
+3. **대상 그룹**
+   ALB에서 설명한 대상 그룹 모두 동일하게 쓸 수 있다. 단, NLB에서는 ALB를 대상 그룹으로 사용할 수 있다. 이때는 NLB가 ALB 앞에 있는 구조가 된다. 
+
+1, 2, 3번을 조합하면 아래 그림과 같은 구조이다.
+NLB는 고정 IP를 제공하고, 빠른 속도로 부하를 처리하는 역할을 수행하고, 뒷 단에 있는 ALB는 HTTP 트래픽을 세부 라우팅 하는 역할을 수행한다.
+   ![[Pasted image 20250504004326.png]]
+
+---
+
+# GWLB
+
+**3계층인 IP** 기반으로 작동하는 로드밸런서이다. 다른 것들과는 조금 성격이 다르다. 모든 트래픽이 GWLB를 통과하게 해서 서드파티 보안 어플라이언스를 (방화벽 등) 거치게 하는 것이 주된 목적이다.
+
+## 동작 방식
+
+아래 그림을 이해하는 것이 가장 중요하다.
+1. 유저가 보내는 **모든 트래픽이** GWLB를 통과한다.
+2. GWLB를 통해 Target Group인 서드파티 보안 어플라이언스로 트래픽이 전송된다.
+3. 보안에 위배된 트래픽은 버려지고, 적합한 트래픽만 다시 GWLB로 돌려보내진다.
+4. GWLB는 돌아온 트래픽을 ALB나 어플리케이션에 전달한다.
+![[Pasted image 20250504205406.png]]
+
+## 시험에 나오는 내용
+
+- Target Group은 보안을 담당하는 서드파티 어플라이언스이다.
+  이런 어플리케이션이 돌아가는 EC2 ID나 Private IP를 등록하면 된다.
+- 포트는 6081번, 프로토콜은 **GENEVE**
+- EC2나 ALB 앞 단에 보안 계층 추가가 필요하면 GWLB 고려
+
+

HyeGyeong/Scalability & High Availability/Scalability & High Availability.md

@@ -0,0 +1,26 @@
+## 확장성 (Scalability)
+
+조정을 통해 시스템이 더 많은 양을 처리할 수 있는 능력
+
+### 수직 확장 (Vertical Scaling)
+단일 인스턴스의 퍼포먼스를 올리는 것. 예시로 t2.micro → t2.large
+- 주로 분산이 어려운 DB 등에 사용
+- 하드웨어 업그레이드에 한계가 존재
+
+### 수평 확장 (Horizontal Scaling)
+인스턴스 수를 늘리는 것.
+- 작업 분산 처리 가능
+- 로드 밸런서 필요
+- 클라우드 환경에서 용이        
+
+## 고가용성 (High Availability)
+
+시스템의 일부에 장애가 발생해도 계속 서비스를 제공할 수 있는 능력 
+- **여러 Availability Zone에 인스턴스 분산
+- RDS 다중 AZ, ELB + Auto Scaling Group
+
+여기서도 스케일링과 동일하게 Vertical Scaling과 Horizontal Scaling을 사용한다.
+- Vertical Scaling으로 인스턴스의 퍼포먼스를 늘리거나 줄이면?
+  -> Scale up / Down
+- Horizontal Scaling으로 인스턴스의 수를 늘리거나 줄이면?
+  -> Scale Out / In