Infra) 인터넷경계 로드밸런서(Load Balancer)는 어디에 위치할까?
결론 : 인터넷 경계 로드 밸런서는 물리적으로 Subnet 안에 있는 것으로 추론했다.
로드밸런서는 어디에 있을까?
들어가기 앞서 밑에 다룬 모든 내용은 모두 AWS의 인터넷경계 로드밸런서를 기본으로 한 내용임을 알린다.
다음의 AWS 아키텍처를 살펴보자.
해당 아키텍처에는 LB가 VPC 안에 있는 것으로 확인된다. 또한 ALB가 인터넷 게이트웨이와 직접 연결되고 이를 분산해주는 일종의 Bastion(NAT) Node로 보이기도 한다. 필자 역시 부트캠프 수업을 통해 어느 Subnet에 국한되지 않고 VPC 안에 있는 것으로 학습을 하였다.
근데 VPC 안에 있다면 설명이 안되는 부분들이 있다. 다음은 인터넷 경계 ALB를 생성할 때 private subnet을 매핑하려 시도하면 나타나는 문구이다.
선택한 서브넷에 인터넷 게이트웨이가 없다..? 로드 밸런서가 인터넷 트래픽을 수신하지 못한다..? 로드 밸런서는 VPC 서비스인데 왜 이런 Subnet에 종속된 문구가 나오는지 모르겠다. 해당 서브넷의 Route Table을 이용해 인터넷 게이트웨이로 연결되는 거면 Subnet에 종속된 서비스가 아닌가? 또한 위 아키텍처에 따르면 LB는 VPC 안에 있고 Private Subnet에도 접근하여 밸런싱을 해주어야 하는 것처럼 보인다. 왜 이런 현상이 벌어졌을까?
vpc 안에 있다?
다시 말하지만 인터넷 경계 로드밸런서가 vpc에 내에 있다면 직접적으로 private subnet의 인스턴스들에도 접속할 수 있어야 한다. 하지만 불가능하다. 그렇다면 vpc 밖에 위치한 서비스인 것인가?
vpc 밖에 있다?
그렇다면 인터넷 경계 로드밸런서는 VPC 밖에 위치한걸까? 얼핏 생각하면 인터넷 트래픽을 수신할 수 있고 Private Subnet에 직접 접근을 못하니 맞는 말 같다. 하지만 다음 글을 읽어보자.
위 사진은 ALB 체계의 정보 탭을 누르면 나오는 정보이다. 인터넷 경계 로드 밸런서는 모두 프라이빗 IP 주소를 사용하며 대상 요청을 라우팅한다고 한다. 프라이빗 IP는 VPC 내부에 있어야 할당 받을 수 있으니 LB가 VPC 내부에 위치해있다는 것을 추론할 수있다. 그렇다면 인터넷 경계 LB가 서브넷 안에 있는 서브넷 종속적인 서비스인가? 아니면 어느 서브넷에도 속하지 않은 서비스인가를 생각해볼 차례이다.
LB가 서브넷에서 ip를 할당받을까?
다음은 내 VPC 화면이다.
가용 영역 A에 public subnet과 private subnet이 함께 있고, C에는 private subnet만, D에는 public subnet이 있다.
우리는 A의 private-subnet-03과 C의 private-subnet-02에 인터넷 게이트웨이를 연결해볼 것이다. 또한 EC2가 있는 서브넷과 없는 서브넷도 차이가 있는지 테스트를 해보기 위해 EC2를 private-subnet-01, private-subnet-02에 생성해줄 것이다.
LB 생성 전, 현재 private-subnet들의 가용 IP 개수를 살펴보자.
현재 EC2가 생성된 두개의 서브넷은 250개의 가용 IP, 생성하지 않은 서브넷은 251개의 사용 가능한 IP를 갖고 있는 것을 볼 수 있다. 그리고 private-subnet-02와 private-subnet-03에 로드밸런서를 매핑해주고 방금 생성한 EC2들을 대상 그룹으로 만들어 연결해주자.
그리고 다시 서브넷의 사용 가능 IP를 확인해보면..!
private-subnet-01은 그대로지만, private-subnet-02와 private-subnet-03의 내부 IP가 추가로 하나씩 할당된 모습을 볼 수 있다. 이를 통해 로드 밸런서가 매핑한 subnet에 하나씩 생성된다는 것을 알 수 있다.
결론
로드 밸런서는 물리적으로는 매핑한 서브넷들 안에 생성되기 때문에 해당 subnet들이 public인지 private인지가 인터넷 연결의 여부를 결정한다는 결론에 도달하게 되었다. 그리고 다음과 같은 아키텍처도 존재하는 걸 보면, AWS가 설명의 이해를 돕기 위해 아키텍처를 간소화한 것으로 보인다.
