AWS VPC를 디자인해보자(1) - Multi AZ와 Subnet을 활용한 고가용성

AWS VPC를 디자인 해보자(1) - Multi AZ와 Subnet을 활용한 고가용성

[Contents]

  1. VPC를 디자인해보자 (1) - Multi AZ를 활용한 고가용성

  2. VPC를 디자인해보자 (2) - Network ACL과 Security Group을 활용한 보안 강화

  3. VPC를 디자인 해보자 (3) - Private Network을 위한 NAT Gateway 와 Bastion 서버

  4. VPC를 디자인 해보자 (4) - VPC Peering을 활용한 Multi VPC 사용하기

 VPC(Virtual Private Cloud) 서비스는 AWS 사용자가 직접 가상 네트워크 환경을 구성하는 서비스이다. 이 서비스를 이용하면 Public / Private network 환경을 사용자가 원하는대로 디자인하고 구축할 수 있게 되며, 다양한 부가 기능을 통해 VPC 환경 내 네트워크 흐름을 제어할 수 있다. 

 먼저 VPC를 이해하려면, 기존의 물리 IDC 환경을 디자인 할 때 상황을 비교해서 생각해 보면 쉽게 이해할 수 있다. 이번 포스팅에는 데이터 센터 구성에서도 Multi 데이터센터 구성과 AWS의 VPC 서비스를 비교해 보고자 한다. 

---

1. Multi AZ VPC를 활용한 Multi 데이터센터(IDC) 구성 효과

  Multi 데이터센터는 지진같은 천재지변으로 인한 데이터센터 장애나 데이터센터 자체의 전력, 네트워크 장애에 대비하기 위한 이중화 구성이다. 하지만 물리적으로 데이터센터를 이중화 하려면 굉장히 많은 비용이 든다. 데이터센터 상면 비용에서 부터 데이터센터간 network latency 를 보장하기 위한 전용선 확보까지 비용적 부담이 매우 크다. 그래서 왠만큼 큰 규모의 서비스가 아니면 시도하기도 쉽지 않다. 또한 DB 의 경우는 DBMS 이중화와 데이터센터 이중화를 복합적으로 고민해야 한다. 

 이러한 현실을 고려하다 보면 Multi 데이터센터 구성은 쉽지 않은게 현실이다. 

VPC를 활용해 Multi 데이터센터 구성을 한다면?

VPC 를 디자인 하기 위해서는 먼저 Region 과 Availability Zone 에 대한 개념을 이해해야 한다. 

AWS 서비스의 가장 큰 단위는 Region이다. 

Region이란 AWS의 서비스가 위치한 지리적인 장소이며, 글로벌 기준으로 지역적 위치를 묶어서 관리하는 단위이다.

하나의 Region 안에는 다수의 Availability Zone 으로 구성되어 있다.

Availability Zone(이하 AZ) 이란 Region 내에 실제 컴퓨팅 리소스들이 물리적으로 분리되어 있는 단위이다. 

이해하기 쉽게, AZ 하나가 물리적인 데이터 센터와 맵핑된다고 생각해도 무방하다. 

 그렇다면, AZ간 물리적으로 떨어져 있음으로 인해 생기는 latency는 어떠할까.

 AWS 측에서는 같은 Region 내 AZ간에는 low-latency link 로 연결되어 있기 때문에 물리적으로 떨어져 있음으로 생기는 latency 에 대해 보장해준다. 

                         [ 출처 : http://docs.aws.amazon.com/ ]

 그렇다면 VPC와 Region은 어떠한 관계인가.

 VPC를 생성할때는 반드시 Region을 지정해야 한다. 즉, VPC는 반드시 하나의 Region에 속하게 된다.

 또한 VPC는 Region내 다수의 AZ를 이용해 설계가 가능하다. 

 만약 VPC 를 디자인 할때 Multi AZ를 기반으로 구성한다면, 사용자는 물리적으로 다수의 데이터센터를 이용하는 것과 같은 효과를 볼 수 있다. 

  실제로 VPC 를 구성할때 어떻게 Multi AZ 형태로 구성하는지 알아보자. 

  그러기 위해서는 먼저 VPC 설계의 가장 기본인 Subnet에 대해서 알아보자

 Subnet 이란

  VPC에는 Subnet 이라는 개념이 있는데, 흔히 알고 있는 대로 IP block을 구분짓는 그 Subnet과 동일하다. 

  Subnet의 특징은 반드시 하나의 AZ 에 속해야 한다는 것이다. 그렇기 때문에 VPC 내부에 다수의 Subnet 을 생성하여 각각의 AZ에 분산 배치 하면 아래와 같이 하나의 VPC에 Multi AZ 를 사용하도록 디자인 가능하다. 

 

  위 VPC 는 서울 Region에 구성한 것으로, 서울 Region에는 두개의 AZ가 존재한다. 각 AZ에 아래와 같이 subnet을 배치해 보았다.  

• AZ (ap-northeast-2a) : subnet-01 / subnet-03

• AZ (ap-northeast-2c) : subnet-02 / subnet-04 

 

  VPC와 Subnet을 구성할때는 반드시 CIDR을 설정해야 하는데, 위 VPC 경우에는 10.10.0.0/16 으로 생성하였다. Subnet CIDR은 당연히 VPC에 포함되도록 해야 한다. 각 subnet의 CIDR은 아래와 같이 설정해 보았다. 

• subnet-01 : 10.10.1.0/24

• subnet-02 : 10.10.2.0/24, 

• subnet-03 : 10.10.101.0/24

• subnet-04 : 10.10.102.0/24 

 이제, 위와 같이 구성된 VPC에 Instance 를 배포한다고 가정해보자. 

 만약 웹서버 두대를 배포한다고 가정하면, 위 VPC의 구성에서는 AZ가 분산되도록 subnet-01과 subnet-02에 분산하여 배포하면 된다. 그리고 이 instance에 ELB를 연결해 서비스한다. 이렇게 되면 만약 AWS의 AZ 하나에 장애가 발생되더라도 다른 AZ에서 서비스가 되기 때문에 고가용성이 유지될 수 있다. 

  

  ELB (Elastic Load Balancer) 는 Region 내 Multi-AZ 로 설정이 가능하다. 

  * 참고로 ELB는 Region을 벗어나는 로드밸런싱 설정이 불가하다. 이때는 ELB가 아닌 Route53을 이용한 DNS Load balancing 과 같은 방법을 이용해야 한다. 

  

 * LB를 만들때 보면, 위와 같이 고가용성을 위해 두개 이상의 subnet을 선택해 LB를 생성하기를 권고하는 메시지를 볼 수 있다. 

2. Public / Private network 존 구분

  데이터 센터를 디자인 할때 네트워크단에서 반드시 고려 하는 것이 Public / Private network 존을 나누는 것이다.

 서비스를 구축할때 외부와 통신이 직접적으로 필요한 Web 서버 같은 Front-end layer의 경우, Public 존에 위치 하도록 한다. 하지만 Back-end나 DB의 경우 외부와의 통신이 직접적으로 필요하지 않으며, 단지 Public 존에 위치한 Front-end 서버와의 통신만 필요로 하는 경우가 많다. 이런 경우에는 외부와의 통신이 제한된 Private 존에 위치하도록 한다. 이는 보안상 부적절한 접근을 네트워크 레벨에서 원천적으로 차단하기 위함이다. 

 만약 물리 IDC의 경우라면, Public / Private 존을 나누기 위해서는 각각의 존을 구성하는 Switch 같은 물리 장비가 필요할 것이다. 또한 VLAN등을 이용해 네트워크 영역을 분할하는 작업도 해야하며, Router를 이용해 IP대역에 대한 routing table을 직접 구성해야 할 것이다. 

 만약 AWS의 VPC를 이용한다면 어떨까.

 

 아래 그림은 위에서 구성한 VPC 환경의 Subnet 중 01/02 의 역할을 Public 으로, 03/04 는 Private 으로 설계한 것이다.

[ Public ]

• public-subnet-01 (ap-northeast-2a) : 10.10.1.0/24
• public-subnet-02 (ap-northeast-2c) : 10.10.2.0/24

[ Private ]

• private-subnet-01 (ap-northeast-2a) : 10.10.101.0/24
• private-subnet-01 (ap-northeast-2c) : 10.10.102.0/24

 public subnet 과 private subnet도 각각의 AZ에 분산해서 배포하였다. 

 그리고 subnet-01과 02에는 외부와 통신이 필요한 Web 서버만 배포하도록 정책을 세우고, subnet-03 과 04 에는 외부와 통신이 제한되는 DB 서버만 배포하도록 정책을 세우면 된다. 

이제 실제적으로 subnet-01과 02가 외부와 통신을 하기 위한 추가적인 설정을 해야한다. 

VPC 를 생성하면 기본적으로 외부 통신과 단절된 상태로 생성된다. 또한 모든 network가 private IP로 설정되어 있기 때문에 외부로 통신이 불가한 상태다. 이때 외부로 통신하기 위해 VPC 에서는 Internet Gateway 라는 기능을 제공한다. 

 

 Internet Gateway

  VPC 에서 제공되는 Internet Gateway 라는 기능을 이용하면 원하는 Subnet을 외부 통신이 되도록 설정이 가능하다. 

  구성 방법은 매우 간단하다. 

  먼저 외부 통신을 위한 Internet Gateway (이하 IGW) 를 생성 한후, 생성된 IGW를 VPC에 Attach한다.

  * 참고로 하나의 VPC 에는 하나의 IGW 만 attach 할 수 있다. 

  그리고 route table 을 생성 한 후, 외부 통신을 위한 public-subnet-01 과 02 에 route table 을 assign 한다. 

  [ route table을 생성 후 위와 같이 외부 통신을 위한 두 subnet을 추가한다 ]

  마지막으로 route table에 모든 traffic이 생성한 IGW로 가도록 설정 해주면 된다.

  

   [ routing 경로로 위에서 생성한 IGW 를 지정해준다 ]

  그리고 Private 을 위한 route table 도 추가로 생성 한 후, private-subnet-03 과 04 에 assign 하면 된다. private의 경우에는 외부 통신을 제한해야 하므로 IGW로 routing 설정을 추가하지 않는다. 그럼 자연스럽게 내부통신만 가능하다.

  

  그림으로 보면 아래와 같은 구성이 되겠다. 

 VPC 를 초기에 구축할때는 위와 같이 Multi AZ와 Public / Private Subnet 을 구분하여 디자인하는게 고가용성과 보안성을 위해 좋은 설계 방향이다. 이미 인스턴스가 배포되고 서비스가 운영되고 있는 상황에서 새롭게 VPC를 구성하여 마이그레이션 하기에는 굉장히 번거로운 작업들이 필요하기 때문이다. 

 이후 포스팅에서는 VPC의 보안 강화를 위해 Network ACL과 Security Group, Flow log 기능을 활용하는 방법을 알아보자.

VPC를 디자인 해보자(2) - Network ACL과 Security Group을 활용한 보안 강화

[참고]

• http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_Introduction.html