배경
•
Confluent Cloud Kafka 토픽 → Redis (ElastiCache)로 집계 데이터를 적재하기 위해 Redis Sink Connector를 구성하려고 했음
•
사내 시스템은 모두 VPC 내부 전용 자원이라 Confluent Cloud → AWS VPC PrivateLink 경로를 사용하려고 시도하면서 AWS에 설정했던 부분들을 공부할겸 정리
주요 컴포넌트 및 용어
CIDR (Classless Inter-Domain Routing)
•
CIDR은 IP 주소와 서브넷 마스크를 한 줄로 표기하는 방식
•
IP 주소의 범위(네트워크 대역)를 표현하기 위해 사용되는 표기법
10.0.0.0/16
Plain Text
복사
•
10.0.0.0: 네트워크 주소 (시작점)
•
/16: 앞 16비트는 네트워크를 구분하는 데 사용하고, 나머지 16비트는 호스트에 할당
CIDR | 호스트 수 (사용 가능 IP 개수) | IP 범위 예시 |
/32 | 1개 (고정 IP 하나) | 10.0.0.5/32 → 단일 IP |
/24 | 256개 | 10.0.1.0 ~ 10.0.1.255 |
/16 | 65,536개 | 10.0.0.0 ~ 10.0.255.255 |
/8 | 16,777,216개 | 10.0.0.0 ~ 10.255.255.255 |
Target Group (대상 그룹)
•
로드 밸런서가 실제 트래픽을 전달할 대상 백엔드 서버들의 그룹
•
역할
◦
로드 밸런서 리스너가 받은 요청을 대상 그룹에 속한 여러 서버에 분산 전달
◦
서버의 헬스체크를 통해 비정상 상태 서버는 자동으로 트래픽에서 제외
•
유형
◦
IP 타입: 각 인스턴스의 Private IP 주소 직접 지정해 대상 서버 등록
◦
Instance 타입: EC2 인스턴스 ID로 지정여 등록 (인스턴스가 IP 변경 시 자동 반영되며, EC2 인스턴스 관리에 편리)
Load Balancer
여러 대의 서버(혹은 IP) 앞단에 위치하여 클라이언트의 요청을 자동으로 분산 처리하는 서비스
역할
•
트래픽 분산시켜 특정 서버에 요청이 몰리는 현상을 방지
•
백엔드 서버의 헬스체크
•
서버 수를 동적으로 조정해도 로드 밸런서를 통해 동일한 방식으로 접근 가능
•
여러 서버 중 일부가 장애가 나도 서비스 지속 가능
Network Load Balancer(NLB)
•
TCP/UDP 기반 네트워크 계층(Layer 4) 에서 동작하는 로드 밸런서
•
IP 주소, 포트 번호 등 기본적인 네트워크 정보로만 트래픽을 분산
•
네트워크 계층에서만 작동하기 때문에 지연이 적어 빠른 응답속도가 중요한 서비스에 적합
•
백엔드 서버에서 클라이언트의 실제 IP를 그대로 볼 수 있음
•
Redis, Kafka, RDS 등 TCP 기반 서비스에 사용
Application Load Balancer (ALB)
•
HTTP/HTTPS 기반 애플리케이션 계층(Layer 7) 에서 동작하는 로드 밸런서
•
경로/호스트 기반 라우팅
•
TLS 종료 및 인증서 관리 가능
•
쿠키 기반의 세션 고정 지원
•
Web 애플리케이션, REST API, 마이크로서비스 아키텍처에 사용
NLB vs ALB
항목 | NLB | ALB |
작동 계층 | L4 (TCP/UDP) | L7 (HTTP/HTTPS) |
라우팅 기준 | IP, 포트 | URL, 헤더, 쿠키 등 |
성능 | 매우 빠름 (고성능) | 상대적으로 느림 (기능 다양) |
클라이언트 IP 유지 | 기본 유지됨 | 별도 설정 필요 |
TLS 종료 | 선택적 | 기본 지원 |
적합한 예 | Redis, DB, TCP 기반 시스템 | 웹 서비스, API 서버 등 |
로그 분석 | 거의 없음 | 상세 요청 로그 가능 |
Listener (리스너)
•
로드 밸런서가 외부(Client)로부터 수신할 포트·프로토콜 설정
◦
예시: TCP 6379 리스너 → Target Group으로 포워딩
•
들어오는 요청을 어떤 프로토콜과 포트로 받을지, 그리고 어떤 동작(포워딩)을 할지 지정
Security Group (보안 그룹)
•
VPC 내에서 인스턴스(ENI)별로 적용되는 가상 방화벽
•
인바운드 규칙: 외부에서 이 리소스로 들어오는 트래픽 허용/차단
•
아웃바운드 규칙: 이 리소스에서 외부로 나가는 트래픽 허용/차단
예시: NLB 앞단 보안그룹 인바운드에 TCP 6379 허용 → PrivateLink Endpoint ENI 또는 VPC CIDR에서 오는 트래픽만 처리
AWS PrivateLink & Endpoint Service
AWS PrivateLink
•
VPC 내부 간, 또는 VPC
AWS 서비스 간의 안전한 연결을 지원해주는 서비스
AWS 서비스 간의 안전한 연결을 지원해주는 서비스 •
퍼블릭 IP 없이 AWS 내부망을 통해 다른 VPC나 서비스와 통신 가능하게 만들어줌
구성요소
구성요소 | 설명 |
Interface Endpoint (ENI) | PrivateLink의 진입점 역할
서비스 소비자 쪽에서 생성하는 VPC 내 네트워크 인터페이스 (ENI) |
Endpoint Service | 서비스 제공자 쪽에서 생성
NLB를 바인딩하여 PrivateLink 소비자들이 접근할 수 있는 프라이빗 서비스를 게시 |
Network Load Balancer (NLB) | 서비스 트래픽을 내부 대상(IP/인스턴스)으로 전달 |
Endpoint Service
•
VPC에 있는 서비스를 다른 VPC에 PrivateLink를 통해 노출할 수 있게 해주는 구성 요소
•
즉, 내 VPC 안의 로드밸런서 뒤에 있는 서비스(예: Redis, 웹 서버 등)를 다른 VPC에서 퍼블릭 인터넷 없이 통신 가능
•
Confluent, Snowflake 같은 SaaS 제공자들도 이 방식을 사용해 VPC 기반 통신 지원
flowchart TB
subgraph Consumer_VPC["서비스 소비자 VPC"]
Application["Application"]
ENI["Interface Endpoint (ENI)"]
Application --> ENI
end
ENI --> PL["PrivateLink (AWS 내부망)"]
subgraph Provider_VPC["서비스 제공자 VPC"]
EndpointService["Endpoint Service (with NLB)"]
TG1["Target Group: private IP 1"]
TG2["Target Group: private IP 2"]
EndpointService --> TG1
EndpointService --> TG2
end
PL --> EndpointService
Mermaid
복사