고가용성 및 확장성 Quiz!

Q1. EC2 인스턴스를 r4.large에서 r4.4xlarge로 확장하는 것을 .....................................(이)라고 합니다.

1. 수평 확장성
2. 수직 확장성

➡️ 수직 확장성(Vertical Scaling, Scale Up/Down)은 기존 인스턴스 자체의 성능을 높이거나 낮추는 것

---

Q2. EC2 인스턴스 수를 확장 및 축소하는 Auto Scaling Group에서 애플리케이션을 실행하는 것을 .....................................(이)라고 합니다.

1. 수직 확장성(Vertical Scalability)
2. 수평 확장성(Horizontal Scalability)

➡️ 수평 확장성(Horizontal Scaling) → 인스턴스 개수를 조절

---

Q3. ELB는 ..................................을(를) 제공합니다.

1. 애플리케이션에서 사용할 수 있는 static IPv4
2. 애플리케이션에서 사용할 수 있는 static DNS 이름
3. 애플리케이션에서 사용할 수 있는 static IPv6

풀이💡

1. Static IPv4?

   ELB는 내부적으로 여러 가용 영역(AZ)의 여러 IP를 가지고 있어서 고정된 IP를 보장하지 않음

   요청이 들어올 때마다 다른 IP로 라우팅될 수 있음 → ❌

2. Static DNS 이름?

   ELB는 DNS 이름을 제공하고, 이 DNS 이름을 통해 항상 ELB에 접근할 수 있음

   ELB 뒤의 실제 IP는 변할 수 있지만, DNS 이름으로는 항상 접근 가능 → ✅

3. Static IPv6?

   IPv6도 ELB의 경우 마찬가지로 IP가 고정되지 않음 → ❌

---

Q4. 여러분은 ELB가 전면에 있는 10개의 EC2 인스턴스에서 웹 사이트를 실행하고 있습니다. 사용자는 웹 사이트 페이지 간에 이동할 때 웹 사이트에서 항상 재인증을 요청한다는 사실에 대해 불평하고 있습니다. 그러나 해당 웹사이트는 한 개의 EC2 인스턴스가 있는 개발 환경과 컴퓨터에서는 제대로 작동하기 때문에 의아합니다. 이 현상이 발생하는 이유는 무엇일까요?

1. ELB에 Sticky Session이 활성화되어 있지 않음.
2. 여러 EC2 인스턴스에서 호스팅할 때 웹 사이트에 문제가 있음.
3. EC2 인스턴스는 사용자가 자신의 IP 주소를 볼 수 없기 때문에 로그아웃 하는 대신 ELB IP주소를 수신.

풀이💡

1. ELB에 Sticky Session이 활성화되어 있지 않음 ✅
   ELB는 기본적으로 라운드로빈 방식으로 요청을 분배합니다.
   즉, 같은 사용자의 요청이라도 다른 EC2 인스턴스로 라우팅될 수 있음

   웹 애플리케이션이 세션 정보를 서버 메모리(Instance Local)에 저장하고 있다면, 다른 인스턴스로 요청이 가면 세션 정보가 없어 재인증 요청이 발생

   해결 방법: Sticky Session(세션 유지, Session Affinity) 활성화 → 사용자가 항상 같은 인스턴스로 요청이 가도록 함

2. 여러 EC2 인스턴스에서 호스팅할 때 웹 사이트에 문제가 있음. ❌

   여러 인스턴스 자체가 문제가 아니라, 세션이 인스턴스 간 공유되지 않아서 발생하는 문제입니다.

   즉, “호스팅 환경이 여러 대라서 문제”라는 표현은 정확하지 않아요.

3. EC2 인스턴스는 사용자가 자신의 IP 주소를 볼 수 없기 때문에 로그아웃 하는 대신 ELB IP주소를 수신. ❌

   사용자의 IP는 ELB를 거치면서 X-Forwarded-For 헤더로 전달 가능

   이 때문에 로그아웃이 일어나는 건 아님 → ❌

---

Q5. Application Load Balancer를 사용하여 EC2 인스턴스에서 호스팅되는 웹 사이트로 트래픽을 분산하고 있습니다. 웹 사이트는 실제로 Application Load Balancer의 IP 주소인 프라이빗 IPv4 주소에서 오는 트래픽만 보는 것으로 나타났습니다. 웹사이트에 연결된 클라이언트의 IP 주소를 얻으려면 어떻게 해야 할까요?

1. 사용자가 모든 요청에서 자신의 IP를 보내도록 웹사이트의 프런트엔드를 수정
2. X-Forwarded-For 헤더에서 클라이언트 IP 주소를 가져오도록 웹사이트의 백엔드를 수정
3. 웹사이트의 백엔드를 수정하여 X-Forwarded-Port 헤더에서 클라이언트 IP 주소를 가져옴
4. 웹사이트의 백엔드를 수정하여 X-Forwarded-Proto 헤더에서 클라이언트 IP 주소를 가져옴

풀이💡

1. 사용자가 모든 요청에서 자신의 IP를 보내도록 프런트엔드 수정 ❌

   사용자가 IP를 “보내도록” 하는 건 현실적으로 불가능

   HTTP 요청에는 이미 클라이언트 IP가 포함돼 있고, ALB가 이를 전달해줌 → ❌

2. X-Forwarded-For 헤더에서 클라이언트 IP 주소를 가져오도록 백엔드 수정 ✅

   ALB는 X-Forwarded-For 헤더에 실제 클라이언트 IP를 담아서 EC2로 전달

   따라서 백엔드에서 X-Forwarded-For 헤더를 읽으면 실제 클라이언트 IP 확인 가능 → ✅

3. X-Forwarded-Port 헤더에서 클라이언트 IP 가져오기 ❌

   X-Forwarded-Port는 요청이 들어온 포트 번호를 나타냄

   클라이언트 IP와는 관련 없음 → ❌

4. X-Forwarded-Proto 헤더에서 클라이언트 IP 가져오기 ❌

   X-Forwarded-Proto는 요청 프로토콜(http/https)을 나타냄

   IP와는 관련 없음 → ❌

---

Q6. ELB가 전면에 있는 일련의 EC2 인스턴스에서 애플리케이션을 호스팅했습니다. 일주일 후 사용자는 애플리케이션이 때때로 작동하지 않는다고 불평하기 시작합니다. 문제를 조사한 결과 일부 EC2 인스턴스가 때때로 충돌하는 것을 발견했습니다. 사용자가 충돌하는 EC2 인스턴스에 연결하지 못하도록 보호하려면 어떻게 해야 할까요?

1. ELB Stickiness 활성화
2. SSL Termination 활성화
3. ELB Health Checks 활성화
4. Cross-Zone Load Balancing 활성화

풀이💡

1. ELB Stickiness 활성화 ❌

   Sticky Session은 같은 사용자가 항상 동일한 인스턴스로 요청을 보내도록 하는 기능

   오히려 충돌한 인스턴스로 계속 연결될 수 있음 → ❌

2. SSL Termination 활성화 ❌

   SSL Termination은 SSL 암호화를 ELB에서 해제하는 기능

   트래픽 보호와는 관계 없음 → ❌

3. ELB Health Checks 활성화 ✅

   Health Check를 활성화하면 인스턴스 상태를 주기적으로 확인

   상태가 Unhealthy로 판단되면 ELB는 해당 인스턴스에 트래픽 전송을 중단

   충돌 인스턴스가 있어도 사용자는 문제 없이 다른 Healthy 인스턴스로 연결 가능 → ✅

4. Cross-Zone Load Balancing 활성화 ❌

   Cross-Zone LB는 여러 가용 영역(AZ) 간에 트래픽 분산

   충돌 인스턴스 차단과는 직접 관련 없음 → ❌

---

Q7. 여러분은 회사의 솔루션 아키텍트로 일하고 있으며 초당 수백만 건의 요청을 수신할 고성능, 저지연 애플리케이션을 위한 아키텍처를 설계해야 합니다. 어떤 유형의 ELB를 선택해야 할까요?

1. Application Load Balancer
2. Classic Load Balancer
3. Network Load Balancer

풀이💡

1. Application Load Balancer (ALB) ❌

• L7 계층 (HTTP/HTTPS)

• 기능: URL 기반 라우팅, Host 기반 라우팅, WebSocket 지원 등

• 장점: 애플리케이션 로직 기반 라우팅

• 단점: 초당 수백만 요청 같은 극한 성능, 저지연 처리에는 최적화 아님 → ❌

2. Classic Load Balancer (CLB) ❌

• 초기형 ELB, L4 + L7 지원

• 기능 제한, 성능 최적화 부족, 새로운 기능 부재

• AWS에서는 신규 서비스 권장 아님 → ❌

3. Network Load Balancer (NLB) ✅

• L4 계층 (TCP, UDP)

• 특징:

  • 초고성능 (수백만 요청/초 처리 가능)

  • 극히 낮은 지연(latency)

  • 정적 IP, Elastic IP 지원

  고성능, 저지연 애플리케이션 요구사항에 최적 → ✅

---

Q8. Network Load Balancer의 지원에 포함되는 프로토콜은?

1. HTTP
2. HTTPS
3. WebSocket
4. Network Load Balancer

---

Q9. Application Load Balancer는 조건에 따라 트래픽을 다른 대상 그룹으로 라우팅할 수 있는데 그 조건이 아닌 것은?

1. 호스트 이름
2. 고객의 위치(지역)
3. 요청 URL 경로
4. 소스 IP-주소

풀이💡

1. 호스트 이름(Host Header)

   ALB에서 지원 ✅

   예: www.example.com → 대상 그룹 A, api.example.com → 대상 그룹 B

2. 고객의 위치(지역)

   ALB는 클라이언트 지역 기반 라우팅을 지원하지 않음 ❌

   위치 기반 라우팅을 하려면 Route 53 지리 위치 라우팅(Geo DNS) 사용 필요 → 정답 ✅

3. 요청 URL 경로(Path)

   ALB에서 지원 ✅

   예: /images/ → 대상 그룹 A, /api/ → 대상 그룹 B

4. 소스 IP 주소

   ALB는 IP 주소 기반 라우팅을 지원하지 않음 ❌

   IP 기반 제어는 Security Group, NACL, WAF 사용

   근데 왜 정답이지..?😢 => 라우팅 조건으로 직접 쓸 수 없지만, WAF나 Security Group에서는 제어 가능해서(좀 애매따리하다..)

---

Q10. Application Load Balancer의 대상 그룹에 등록된 대상이 아닌 것은?

1. Network Load Balancer
2. Lambda 함수
3. 비공개 IP 주소
4. EC2 인스턴스

풀이💡

1. Network Load Balancer (NLB) ✅

   대상 그룹에 NLB를 등록할 수 없음

   ALB → EC2, Lambda, IP 주소만 라우팅 가능

   NLB는 다른 ELB, 즉 서로 다른 계층의 로드밸런서이므로 등록 대상 아님

2. Lambda 함수

   ALB는 Lambda 함수를 대상으로 직접 호출 가능 ✅

3. 비공개 IP 주소(Private IP)

   ALB 대상 그룹에는 EC2 인스턴스의 IP나 VPC 내 Private IP 등록 가능 ✅

4. EC2 인스턴스

   가장 일반적인 대상 ✅

---

Q11. 규정 준수를 위해 최종 사용자에게 고정 static IP 주소를 노출하여 규제 기관에서 승인한 안정적인 방화벽 규칙 작성 시 어떤 유형의 ELB를 선택하시겠습니까?

1. Elastic IP가 연결된 Application Load Balancer
2. Network Load Balancer
3. Classic Load Balancer

---

Q12. Application Load Balancer에서 사용자 지정 애플리케이션 기반 쿠키를 생성하려고 합니다. 다음 중 쿠키 이름으로 사용할 수 있는 것은 무엇일까요?

1. AWSALBAPP
2. AWSALBTG
3. APPUSERC
4. AWSALB

---

Q13. us-east-1의 몇몇 EC2 인스턴스에 트래픽을 분산하는 Network Load Balancer가 있습니다. us-east-1b AZ에 2개의 EC2 인스턴스와 us-east-1e AZ에 5개의 EC2 인스턴스가 있습니다. us-east-1b AZ의 EC2 인스턴스에서 CPU 사용률이 더 높다는 것을 확인했습니다. 추가 조사 후 트래픽이 두 AZ에 균등하게 분산되어 있음을 알 수 있습니다. 이 문제를 어떻게 해결하시겠습니까?

1. Sticky Session 활성화
2. Cross-Zone Load Balancing 활성화
3. ELB Health Checkes 활성화
4. SSL 종료 활성화

로드밸런서가 AZ(가용영역) 단위로 먼저 트래픽을 똑같이 나눈다 = 트래픽이 두 AZ에 균등하게 분산되어 있음

풀이💡

1. Sticky Session 활성화

   NLB는 세션 기반 서비스가 아니고, 세션 스티키와 무관

2. Cross-Zone Load Balancing 활성화

   트래픽을 전체 인스턴스 기준으로 균등 분산해 CPU 불균형 해결

3. ELB Health Check 활성화

   문제는 “건강 상태”가 아니라 부하 불균형이므로 오답

4. SSL 종료 활성화

   트래픽 분산과 무관. NLB는 대부분 L4 TCP/UDP 로드밸런서라 SSL 종료도 일반적이지 않음.

---

Q14. Application Load Balancer와 Network Load Balancer의 어떤 기능을 통해 하나의 리스너에 여러 SSL 인증서를 로드할 수 있습니까?

1. 서버 이름 표시(SNI, Server Name Indication)
2. TLS 종료
3. 호스트 헤더
4. SSL 보안 정책

---

Q15. 다음 호스트 이름을 기반으로 트래픽을 3개의 대상 그룹으로 리디렉션하도록 구성된 Application Load Balancer가 있습니다: users.example.com, api.external.example.com 및 checkout.example.com. 이러한 각 호스트 이름에 대해 HTTPS를 구성하려고 합니다. 이 작업을 수행하려면 ALB를 어떻게 구성해야 할까요?

풀이💡

1. HTTP에서 HTTPS로의 리디렉션 규칙 사용
2. 보안 그룹 SSL 인증서 사용
3. SNI 사용

호스트 이름별(Host header) 로 트래픽을 서로 다른 대상 그룹으로 라우팅하려고 하고, 각 호스트에 대해 HTTPS(각기 다른 TLS 인증서) 를 적용하려고 함

Application Load Balancer(ALB)는 하나의 HTTPS 리스너(포트 443)에 여러 TLS 인증서를 연결할 수 있고, 클라이언트가 TLS 핸드쉐이크 시 서버명(Host)을 제시하면 ALB가 해당 호스트에 맞는 인증서를 선택해 응답. 이 방식이 SNI(Server Name Indication)

---

Q16. 목표 용량과 최대 용량을 모두 3으로 구성한 Auto Scaling Group에서 관리하는 EC2 인스턴스 집합에 호스팅되는 애플리케이션이 있습니다. 또한, CPU 사용율이 60%에 도달하면 ASG를 확장하도록 구성된 CloudWatch Alarm도 생성되어 있습니다. 이 애플리케이션이 갑자기 많은 트래픽을 수신하여 CPU 사용율이 80%라면 어떤 현상이 발생할까요?

1. 목표 용량은 4까지 올라가고 최대 용량은 3으로 유지된다.
2. 아무 일도 일어나지 않는다.
3. 목표 용량은 4까지 올라가고 최대 용량은 4으로 유지된다.

풀이💡

스케일 아웃(인스턴스 확장)은 최대 용량을 초과할 수 없음

---

Q17. ApplicationLoad Balancer가 전면에 있는 Auto Scaling Group (ASG)이 있습니다. ALB Health Checks을 사용하도록 ASG를 구성했는데 하나의 EC2 인스턴스가 비정상으로 보고되었습니다. EC2 인스턴스는 어떻게 될까요?

1. ASG는 인스턴스를 계속 실행하고 애플리케이션을 다시 시작합니다.
2. ASG는 EC2 인스턴스를 분리하고 계속 실행합니다.
3. ASG는 EC2 인스턴스를 종료합니다.

풀이💡

1. ASG는 인스턴스를 계속 실행하고 애플리케이션을 다시 시작 → ❌

   ASG는 Health Check 결과를 기준으로 인스턴스를 교체하는 구조

   단순히 애플리케이션 재시작은 하지 않음

2. ASG는 EC2를 분리하고 계속 실행 → ❌

   ‘분리’라 함은 트래픽에서 제거하는 것을 의미할 수 있음

   하지만 ASG 정책상 Unhealthy 인스턴스는 종료 후 새 인스턴스로 교체

3. ASG는 EC2 인스턴스를 종료 → ✅

   정확한 동작:

   ALB Health Check 실패 → ASG가 인스턴스를 Unhealthy로 판단

   트래픽에서 제거 → 종료 → 새로운 Healthy 인스턴스 생성

---

Q18. 여러분의 상사가 애플리케이션이 데이터베이스에 전송하는 분당 요청 수를 기반으로 ASG을 스케일링하도록 요청했습니다. 어떻게 해야 할까요?

1. 정중하게 불가능하다고 말한다.
2. CloudWatch 사용자 지정 지표를 생성한 다음 이 지표에 대한 CloudWatch 경보를 생성하여 ASG 확장.
3. 세부 모니터링을 활성화한 다음 CloudWatch 경보 생성해 ASG 확장.

풀이💡

• 2️⃣ CloudWatch 사용자 지정 지표 생성 후 경보를 만들어 ASG 확장 ✅

  정확한 방법:

  애플리케이션에서 DB 요청 수를 CloudWatch Custom Metric으로 전송

  해당 지표에 CloudWatch Alarm 설정

  Alarm 기준으로 ASG Scaling Policy 적용

  이 방법이면 요청 수 기준으로 자동으로 Scale Out/In 가능

• 3️⃣ 세부 모니터링(Enhanced Monitoring) 활성화 후 경보 생성 → ❌

  세부 모니터링은 EC2 인스턴스 자체 CPU, 네트워크, 디스크 등 기본 지표 해상도 향상

  DB 요청 수 같은 애플리케이션 레벨 지표는 제공하지 않음

  따라서 세부 모니터링만 활성화한다고 원하는 기준으로 스케일링 불가

---

Q19. 애플리케이션은 Application Load Balancer 및 ASG과 함께 배포됩니다. 현재 ASG를 수동으로 확장하고 EC2 인스턴스에 대한 평균 연결 수가 약 1000개인지 확인하는 확장 정책을 정의하려고 합니다. 어떤 스케일링 정책을 사용해야 할까요?

1. 단순 스케일링 정책
2. 단계 스케일링 정책
3. 스케줄 스케일링 정책
4. 대상 추적 정책

풀이💡

1. 단순 스케일링 정책(Simple Scaling) → ❌

   단일 CloudWatch Alarm에 따라 정해진 수만큼 인스턴스 증감

   문제: 연결 수가 목표치와 달라도 인스턴스 증감량이 고정 → 목표 달성 어려움

2. 단계 스케일링 정책(Step Scaling) → ❌

   특정 지표 범위(Step)에 따라 인스턴스 증감량을 조정

   연결 수가 약간 변동해도 대응 가능

   문제: 목표치를 정확히 맞추는 정책은 아님 → 조정 필요

3. 스케줄 스케일링 정책(Scheduled Scaling) → ❌

   특정 시간/요일에 자동 증감

   연결 수 기반은 아님 → 이번 시나리오와 무관

4. 대상 추적 정책(Target Tracking Scaling) ✅

   특정 지표(Target Value)를 기준으로 ASG 자동 조정

   예: Average ALB Connections = 1000 → ASG가 인스턴스 수를 자동으로 조정

   목표치를 정확히 유지하려는 경우 가장 적합

---

Q20. Auto Scaling Group에서 관리하는 EC2 인스턴스에서 호스팅되는 애플리케이션이 갑자기 급증한 트래픽을 수신하여 ASG가 확장되고 새 EC2 인스턴스가 시작되었습니다. 트래픽은 지속적으로 증가하지만 ASG는 새 EC2 인스턴스를 즉시 시작하지 않고 5분 후에 시작합니다. 이 동작의 가능한 원인은 무엇일까요?

1. 쿨다운 기간
2. 수명 주기 후크
3. 대상 추적 정책
4. 템플릿 시작