문제 1
회사가 클라이언트와 백엔드 간에 트래픽이 복호화되지 않는 암호화된 경로가 필요한 서비스를 구축하려고 합니다. gRPC 프로토콜을 TCP 포트 443으로 구현하며, 수천 개의 동시 연결을 지원해야 합니다. 백엔드는 Amazon EKS 클러스터에 호스팅되고 Kubernetes Cluster Autoscaler와 Horizontal Pod Autoscaler가 구성되어 있습니다. 클라이언트와 백엔드 간 양방향 인증을 위해 Mutual TLS가 필요합니다. 어떤 솔루션이 이 요구사항을 충족합니까?
- A. AWS Load Balancer Controller for Kubernetes를 설치하고, 이를 사용하여 Network Load Balancer를 포트 443 TCP 리스너로 구성하고 백엔드 서비스 Pod IP 주소로 트래픽을 전달합니다.✓ 정답
- B. AWS Load Balancer Controller for Kubernetes를 설치하고, 이를 사용하여 Application Load Balancer를 포트 443 HTTPS 리스너로 구성하고 백엔드 서비스 Pod IP 주소로 트래픽을 전달합니다.
- C. 대상 그룹을 생성하고 EKS 관리형 노드 그룹의 Auto Scaling 그룹을 대상으로 추가한 후, Application Load Balancer를 포트 443 HTTPS 리스너로 구성합니다.
- D. 대상 그룹을 생성하고 EKS 관리형 노드 그룹의 Auto Scaling 그룹을 대상으로 추가한 후, Network Load Balancer를 포트 443 TLS 리스너로 구성합니다.
해설
【핵심 용어】 ▸ gRPC over TCP 443 — 응용 계층 프로토콜, TLS는 전송 계층에서 처리되어야 함 ▸ Mutual TLS — 클라이언트와 서버 모두 인증서를 제시하는 양방향 인증 ▸ Network Load Balancer (NLB) — L4 로드 밸런싱, TLS/SSL 암호화 통로 역할 【정답 포인트】 ▸ gRPC는 TLS를 end-to-end로 유지해야 함 → NLB의 TCP 리스너 선택 ▸ ALB는 L7에서 HTTPS를 처리하면서 복호화 → 요구사항 위배 ▸ AWS Load Balancer Controller는 EKS Pod를 직접 타게팅 가능 → 관리형 노드 그룹이 아닌 Pod IP 사용 ▸ "Pod의 IP 주소로 전달"이 핵심 → A가 유일한 선택 【오답 체크】 (B) ALB는 Layer 7에서 HTTPS를 해석하므로 클라이언트-ALB 간 TLS와 ALB-Pod 간 별도 TLS가 됨 → 트래픽이 ALB에서 복호화됨 (C) (D) 노드 그룹의 Auto Scaling 그룹을 대상으로 하면 Pod 수준의 가변성을 반영 불가, 수천 개 동시 연결 요구사항에 미흡 【시험 포인트】 ▸ EKS + Mutual TLS → NLB(L4) + AWS Load Balancer Controller + Pod 타게팅 ▸ 트래픽 복호화 금지 → ALB(L7) 제외, NLB의 TCP/TLS만 가능