AWS 클라우드 인프라 구축의 시작(2) - VPC 테라폼 구성

## Paul의 글과 헷갈리지 말것~
VPC 용어편 : https://midasitwebop.tistory.com/71

AWS 클라우드 인프라 구축의 시작 - VPC

개요

이제 서버를 운영하기 위한 기틀인 VPC를 직접 구축해본다.
방법은 Paul이 사용하는 테라폼을 활용한다.
IaC의 한 종류인 테라폼은 코드로 인프라를 구축, 관리하는 형태이다.

테라폼에 관한 자세한 설명은 다른 카테고리에서 다루도록 하겠다.
(나도 이제 테라폼 걸음마 단계이기 때문에 처음 시작하시는 분들은 같이 따라오면 좋을 듯하다.)

대상

• VPC
• nACLs
• NAT Gateway
• Route Table
• Subnets
• DHCP option sets
• Internet Gateway

목표

앞에서 다뤘던 아키텍처 구상도에 따라서 최종 형태는 아래와 같이 될 것이다.

내가 그린 기린 그림 아닌 아키 그림

간략한 설명을 붙이면,
A zone, C zone으로 Multi-AZ 환경을 구상하고
각 zone에는 Public과 Private 2개의 서브넷이 존재한다.
그리고 각 서브넷에는 2개의 group이 존재한다.

하나의 서브넷을 좀 더 깊게 보면,
Public 그룹 1 : 이 곳은 임시로 비워둔다. (IP의 앞 번호는 시스템(?) 용도로 많이 할당된다고 한다. 그냥 버퍼)
Public 그룹 2 : Load Balancer가 위치하며, 보통 httpd를 여기다 위치하기도 한다.
Private 그룹 1 : WAS가 위치한다.
Private 그룹 2 : RDS, Redis와 같은 데이터 환경이 위치한다.

IaC를 통한 구축

테라폼은 모듈화 까지 진행하였다. 
해당 페이지에서는 구축 완료된 모습만 살펴보도록 한다.

• VPC
  (혹시 몰라 관련 정보는 제거하였지만, tag는 남겨서 그 연결관계는 확인 가능토록 하였다.)
  
  VPC가 하나 생성되면 '삭제 불가능한' 기본 nACL이 생성된다.
  우리는 정책으로 VPC의 default nACL을 private nACL로 가져가기로 하였다.
  Route table과 DHCP 옵션 셋 각 설정이 원하는대로 생성되었고,
  Flow Logs와 CIDR 까지 확인해준다.
  
  
• nACLs
  nACL은 Private과 Public 둘을 가져가기로 정책을 설정하였다.
  
  
  
  Private과 Public 모두 Inbound Rules, Outbound Rules를 지정해 줘야하는데
  이건 저마다 정책에 따라서 가져가야 한다.
  
  그리고 생성된 Private 서브넷과 Public 서브넷을 각각 nACL에 associate 해 주었다.
  
  하지만 대략적인 예시나 모두가 공통적으로 따라줘야 하는 룰(NAT나 Internet Gateway 사용 시)은
  아래 매뉴얼에서 확인 가능하다.
  
  https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-recommended-nacl-rules.html

VPC에 권장되는 네트워크 ACL 규칙 - Amazon Virtual Private Cloud

• NAT Gateway
  NAT Gateway는 Private 그룹을 사용하는 zone의 개수만큼 생성한다
  
  - kr-dv-ng-infra-a1
  - kr-dv-ng-infra-c1
  
  우리는 A와 C zone에 환경을 구축하기에 두 개를 생성해 주었다.
  
  
  우선 NAT Gateway를 생성하려면 고정 IP를 할당 받아 지정해 주어야 한다.
  NAT Gateway는 Public Group2에 생성된다.
  Private을 위한 용도이지만, Private 그룹에 생성되지 않음에 주의하자.

• Route Table
  Route Table은 Public은 Zone 구분 없이 공용으로 '하나'만 구축하고
  Private의 경우는 Zone 별로 '하나씩' 구축하여준다.
  
  - kr-dv-rt-infra1-a-private
  - kr-dv-rt-infra1-c-private
  - kr-dv-rt-infra1-public
  
  Route Table은 private과 public에 따라 Routes 설정이 달라지는데,
  Public은 Target이 Internet Gateway를 향하고,
  Private은 Target이 NAT Gateway를 향한다.
  (해당 설명은 전 페이지와 위의 아키텍쳐를 참고한다.)
  
  Private 예시)
  
  그리고 해당하는 Subnet을 associate 해주면 된다.

• Subnets
  서브넷은 VPC를 쪼개는 개념이기 때문에 VPC에 사용되는 CIDR을 잘 나눠서 사용하면 된다.
  우리의 경우는 [test.test.0.0/16]이 VPC CIDR 영역이기 때문에, 서브넷은 [test.test.custom.0/20] 으로 구분한다.
  
  아키텍쳐대로 한 zone 당 총 4개의 subnet을 가져가는데 custom의 단위를 16으로 가져갔다.
  예를들어 CIDR 영역이 24.555.0.0/16 이라고 가정하였을 때
  - private-a-group1 : [24.555.0.0/20]
  - private-a-group2 : [24.555.16.0/20]
  - public-a-group1 : [24.555.32.0/20]
  - public-a-group2 : [24.555.48.0/20]
  
  과 같이 구성하여 주었다.
  
  
• DHCP option sets
  기본적으로 DHCP option sets은 Default를 따르는 것 같지만,
  우리는 특별한 이유로 새로 만들어서 VPC와 연결하였다.
  자세한 사항은 아래에 잘 정리해주신 블로그를 참조하면 되겠다.
  
  https://soul0.tistory.com/538

20181122 AWS DNS issue - 내부 네트웍크이슈 확인 방법 및 대처방안

• Internet Gateway
  가장 생성하기 쉽다. 그냥 생성할 때 Name 태그만 설정해 주고,
  Route Table에서 잘 타겟팅 되었는지 확인하면 된다.
  
  

끝으로

우선 위와 같이 하나씩 구조설계를 진행하였다면 이제 인프라의 틀이 완성되었다.
이제 다음부터는 직접 만든 VPC 안에서 인스턴스부터 LB, ASG등을 생성하여 서비스 제공까지 도전해보자.