로컬 vs 클라우드 차이: Networking

백엔드 개발을 처음 배울 때, Hello World 를 출력하는 앱을 만들어본다. 예를 들어, 아래와 같이 요청에 대해 “Hello World” 를 응답하는 것이다 (Spring Boot 사용).

@RestController
class DemoController { 
    @GetMapping
    fun getDemo() = "Hello World"
}

이 애플리케이션을 로컬 컴퓨터에서 구동한 후, 로컬 브라우저에서 localhost:8080 을 입력해 Hello World 를 브라우저 화면에서 확인할 수 있다. 애플리케이션을 AWS 에서 구동하는 것 역시 이와 거의 동일하다. 로컬 환경이 클라우드 환경으로 변한 것뿐이다. 아래 그림처럼 말이다. local vs cloud 그림에서 로컬 환경과 클라우드 환경을 비교해보면 크게 두 가지가 다르다.

  • 로컬 환경에서는 클라이언트와 서버 모두 동일한 네트워크에 속한다. 반면에, 실제 서비스에서는 당연히 클라이언트와 서버는 다른 네트워크에 속한다.
  • 로컬 환경에서는 서버 애플리케이션, 데이터베이스 등이 모두 동일한 컴퓨터에 속하지만, 클라우드에서는 모두 다른 컴퓨터에 속한다.

위 두 가지 차이를 보면, 결국 로컬과 클라우드의 차이점은 네트워크 통신임을 알 수 있다. 클라이언트와 서버가, 애플리케이션과 데이터베이스가 통신할 수 있도록 네트워크 설정이 필요하다.

이 글에서는 클라이언트가 클라우드에 있는 서버와 통신을 할 수 있도록 AWS 를 설정하는 방법에 대해 다룬다. 핵심인 네트워크를 다루기 위해 VPC 를 중심으로 설명한다.

VPC

Region & AZ

AWS Region, AZ(Availability Zone), VPC 에 대해 알아보자. 아래 그림에서 알 수 있듯이, Region 은 지리적 위치를, AZ 는 Region 에 속한 데이터 센터를, VPC 는 가상 네트워크를 의미하며, VPC 는 최소 한 개의 AZ 를 가진다. regions, availabiliy zones and vpcs VPC 와 관련된 Region, AZ 에 대해서는 알았으니, 다음은 네트워크 설정을 알아볼 차례다.

Subnet: Route Table

Subnet 은 VPC 에 속한 네트워크의 범위이며, 최소 한 개의 AZ 를 가진다. 참고로 AZ 와 subnet 이 일대일 대응이어야 한다는 건 아니다. 즉, 아래 그림의 AZ 가 모두 동일할 수도 있다. subnet 위 그림에서 Implicit VPC router 를 회색으로 표시했다. 이유는 AWS 사용자가 VPC router 를 설치/삭제하는 것이 불가능하기 때문이다. AWS 가 VPC router 를 VPC 에 자동으로 할당하며, AWS 사용자는 Route Tables 를 통해서만 VPC router 를 이용할 수 있다. Route Table 에는 ip 주소와 target 을 등록하는데, 이는 target 이 ip 주소로 outbound traffic 을 보낼 수 있도록 하는 설정이다 (inbound traffic 과 Route Table 은 무관하다).  

위 그림에서 어떤 outbound traffic 이 가능한지 살펴보자. Route Tables 를 보면, 172.16.0.4 ~ local target 을 확인할 수 있다. 즉, local → 172.16.0.4 traffic 이 가능하다. 그렇기 때문에 172.16.0.5 → 172.16.0.4 traffic 이 가능하다.  

Route Tables 는 inbound traffic 과 무관하기 때문에 클라이언트의 요청과도 무관하다. 그렇다면 클라이언트의 요청을 받으려면, 어떤 설정을 해야 할까?

Subnet: public vs private

VPC 밖에서 traffic 이 들어오고 VPC 로부터 traffic 이 밖으로 나가기 위해서는 Internet Gateway 가 필요하다. 아래 그림에서 알 수 있듯이, Route Table 을 통해 Internet Gateway 에 연결된 subnet 은 public subnet 이고, 그렇지 않으면 private subnet 이다. public vs private subnet

여기서 의문이 하나 생긴다. Private subnet 과 클라이언트간 traffic 이 오고 가려면 어떻게 해야 할까? 결론부터 말하자면 NAT Gateway 를 통해서다 (NAT Gateway 는 2015년에 출시됐다. 그 전에는 AWS 사용자가 직접 NAT 용 EC2 인스턴스를 만들었다고 한다). 그림에서 확인할 수 있듯이, Internet Gateway 와 연결된 subnet (public subnet) 에 NAT Gateway 를 위치시키고, Route Tables 를 통해 private subnet → public subnet 및 NAT Gateway → 0.0.0.0/0 (모든 ip 주소) traffic 이 가능하도록 한다. 이렇게 하면 클라이언트와 private subnet 간 traffic 이 오고 간다.  

위 그림에서는 NAT Gateway 가 하나만 있지만, public subnet 마다 NAT Gateway 를 만들 수도 있다. 하지만 NAT Gateway 의 사용료는 비싼 편이기 때문에 주의하자.

또 하나의 의문이 생긴다. 클라이언트와 통신을 해야 하는데 왜 public subnet 이 아니라 private subnet 을 사용할까? 이는 보안 때문인 것 같다. 모든 subnet 이 public 이면, 모든 subnet 에 대한 해킹 공격이 가능할 것이다. Private subnets 비중을 늘려 해킹 공격이 가능한 대상을 줄일 수 있다.  

이제 VPC 에 대해서 중요한 것들은 모두 알았으니, 클라이언트가 VPC 에 위치한 server app 과 어떻게 상호작용하는지 살펴보자.

ALB

Server App & ALB

Server App 에 클라이언트가 요청을 직접 보낼 수도 있다. 하지만 더 좋은 방법은 클라이언트가 Application Load Balancer (ALB) 에 요청을 보내게 하는 것이다. 이 방법이 더 좋은 이유는 크게 두 가지가 있다. SSL certificate 를 load balancer 에만 설치해 클라이언트와의 통신을 HTTPS 로 할 수 있다. Load balancer 가 없다면 각각의 서버에 SSL certificate 에 설치해야 한다. 또한 요청이 하나의 서버에 몰리지 않도록 부하를 분산할 수 있다.
alb with target group 위 그림을 살펴보자. 클라이언트는 ALB 의 ip 주소를 DNS 로부터 획득한다. 그 다음 클라이언트는 획득한 ip 주소로, ALB 로 요청을 보낸다. ALB 는 클라이언트의 요청을 지정된 규칙 Listener’s rule 에 따라 처리한다.

예를 들어, alb 의 Listener’s rule 이 다음과 같다고 하자.

  • protocol: https
  • port: 443
  • target group: EC2 instance 로, Spring boot app 이 여기에서 실행 중
  • action: forward

이 때 클라이언트가 https://www.example.com:443 로 요청을 보내면, 클라이언트는 DNS 를 조회해 www.example.com 의 ip 주소를 획득한다. 획득한 ip 주소 (alb 의 ip 주소) 를 xxx.xxx.xxx.xxx 라 하면, 클라이언트는 https://xxx.xxx.xxx.xxx:443 으로 요청을 보낸다. Alb 는 이 요청을 Spring boot app 이 실행되고 있는 EC2 instance 로 넘긴다. 그리고 alb 는 EC2 instance 로부터 응답을 받아 클라이언트에 넘긴다.

ALB & Auto Scaling Group

Auto scaling group 의 이름을 보면 무엇이 생각날까? 마치 target group 처럼 EC2 instance 와 관련이 돼 있는 것 같다. 하지만 직접적으로는 상관이 없다. Auto scaling group 은 configuration 일뿐이다. Auto scaling group 을 생성할 때, 관련된 target group 과 alb 를 지정하는 식이다. alb with auto scaling 위 예시에서는 target group 이 EC2 instance 이다. Auto scaling group 설정에 따라 EC2 instance 의 이상이 감지될 경우, auto scaling group 은 target group 에 EC2 instance 를 추가로 생성한다. 추가된 EC2 instance 는 auto scaling group 에 의해 alb 와 연결된다.

References