Spring, Django, Node.js와 같은 웹 프레임워크를 서버에서 실행할때 우리는 AWS에서 제공하는 서비스를 이용하여 클라우드 환경에서 쉽고 빠르게 구축할 수 있다.
AWS 계정 접속 후, 콘솔을 이용하여 서버(EC2)를 생성하는 것은 전혀 어렵지 않다. 생성 과정에서 선택할 것이 많아 복잡해 보이지만, 모든 값을 AWS가 제공하는 기본값으로 선택한다면, 30초도 걸리지 않고 생성이 가능하다.
EC2 생성을 완료하였다면, 웹서버를 실행시키기 위해 해당 서버에 코드를 적재하는 과정이 필요하다. 제일 간단히 코드를 적재하기 위해서 GitHub에 올린 프로젝트를 git clone으로 다운로드 한 뒤, 실행시킨다고 하자. 이 경우에는 다음과 같은 2가지 문제가 발생한다.
- CLI를 입력하기 위한 SSH 터미널 연결 설정
- git clone으로 코드를 다운로드하기 위해 인터넷망과 EC2 연결
AWS가 제공해주는 기본값으로만 인스턴스를 생성했다면 당연히 이 과정에서부터 막히게 되며, 필살 구글링을 통해 이것저것 찾아본다. 그리고 처음 보는 각종 용어로 인해 정신이 혼미해진다. VPC, Subnet, ACL, CIDR…. 그리고 땜질식 처방으로 설정을 하지만, 곧이어 변형된 네트워크 설정 작업이 필요하게 되는 때에는 곧바로 다시 구글링에 큰 시간을 소모하게 된다.
이런 지리한 설정 작업은 과연 언제 쓰이는 것이고, 왜 필요한 것일까?
이 글의 목표
- 웹 서비스를 운영하기 위해 필요한 최소한의 AWS 인프라 지식 알기
1. 보안 그룹(Security Group)
글 서두에서 생성한 인스턴스는 기본값으로만 생성하였다면, 모든 외부로부터의 입력이 차단된 Private 상태로 생성된다. 이렇게 생성한 서버는 SSH 터미널로 접속이 불가하며, 콘솔으로 작업을 한다고 하더라도 Inbound 포트가 열려 있지 않아 서버로써의 동작을 수행할 수 없다.
따라서, 인스턴스는 내부/외부의 통신 중 어떤것을 받아들이고 차단할지에 대해 규칙을 설정하는데 이를 AWS에서는 보안 그룹이라고 한다.
- 보안 그룹은 인스턴스 레벨의 접근을 제어
- 인바운드/아웃바운드 통신 모두 제어할 수 있지만, Stateful 성질 때문에 일반적으로는 인바운드 룰만 설정
- Stateful: 인바운드 룰으로 허용된 경우, 해당 트래픽에 대하여 세션 테이블로 기억 후 아웃바운드로 되돌아갈때도 자동 허용하는 룰
보안 그룹은 인스턴스 레벨의 통신 규칙을 정하므로 AWS 매니지드 서비스, EC2와 연결이 필요하다면 각 인스턴스마다 설정해주어야 한다. 아래는 로드밸런서와 EC2, 그리고 MySQL의 3가지 인스턴스 사이에서 보안 그룹으로 인바운드 포트를 열어주는 과정이다.
그렇다면 SSH 접속을 허용하기 위해선? SSH 접속을 위해선 보안 그룹 인바운드 룰에 22번 포트와 소스 IP를 지정해주면 된다. 특이사항으로 인스턴스와 보안그룹의 관계는 1:N 으로 필요 시, 하나의 인스턴스에서 다수의 보안그룹을 지정해줄 수 있다.
그럼 이제 보안그룹을 지정했으니, GitHub에서 코드를 다운받을 수 있을까? 하지만 아직 EC2는 인터넷망과 연결이 되어있지 않은 상태이기 때문에 불가능하다.
Q. 보안그룹에서 아웃바운드 룰을 설정하지 않았으니, 모두 허용되겠네요. 그럼 인터넷 연결이 되어야 하는거 아닌가요?
아직 아닙니다. EC2의 상위 개체에서 설정할 것이 필요합니다.
2. 서브넷(Subnet)
서브넷은 EC2 인스턴스들을 모은 상위 집합에 해당하는 개념이다. 아래처럼 하나의 서브넷에 다수의 EC2를 소유할 수 있다.
서브넷의 중요한 목적은 가용 영역(Availability Zone)을 설정하여 장애가 발생하여도 서비스를 지속시키는 것이다. 하나의 서브넷은 하나의 가용 영역에 속하며, 인스턴스보다 넓은 범위의 권한을 가지고 있다.
목적에 따라 내부 통신만 가능한 Private 서브넷으로 설정할 수도 있다.
2.1. Network ACL(Access Control List)
- 서브넷 단위의 트래픽 제어 주체
NACL은 EC2에 접근하기 전, 서브넷 레벨에서의 네트워크 룰을 정한다.
- EC2 인스턴스 보안 그룹 설정과는 상관없이 In/Out되는 모든 트래픽에 대한 제어
- 최초 생성 시 AWS 기본값은 모든 In/Out 트래픽 허용
- Stateless 하기 때문에 아웃바운드 룰을 설정해야 한다.
- Stateless: 허용된 Inbound 트래픽에 대해서도 Outbound 포트까지도 명시적으로 허용해야 통신이 가능
- 룰은 번호를 통해 우선순위를 정한다.
NACL의 룰은 낮은 번호의 정책부터 평가되며, 명시적으로 ALLOW/DENY 되는 정책까지 Overriding 되는 방식으로 정책이 평가된다. (최대 32766번의 정책 지정이 가능하며, 초기엔 100단위로 설정하는 것이 추천된다.) 즉 100, 200 번 룰에서 동일한 룰을 작성했다면, 200번 룰만 적용 된다.
그럼 이제 Outbound Rule으로 인터넷망을 지정하면 EC2 인스턴스에 준비해둔 서버에서 인터넷이 연결 가능할까? 아직은 불가능하다.
2.2. 인터넷 게이트웨이
NACL은 서브넷에서의 통신만 관련 있을 뿐, 실제로 인스턴스가 인터넷 연결을 하기 위해선 인터넷 게이트 웨이를 이용하여 통신한다.
인터넷 게이트웨이는 서브넷 바깥에 위치해 있으며, 아래에서 후술할 VPC 단위에서 관리된다.
2.3. 라우팅 테이블(Routing Table)
생성된 인터넷 게이트웨이를 사용하기 위해선 서브넷이 인터넷 게이트웨이와 연결되어야 한다. 이런 작업을 하는 서비스가 라우팅 테이블 이다.
- 서브넷간 라우팅(연결) 설정
모든 라우팅 테이블에는 VPC 내부 통신을 위한 로컬 라우팅이 포함되어 있다. 이 라우팅은 기본적으로 모든 라우팅 테이블에 추가되며, 삭제가 불가능하다.
라우팅 테이블에 인터넷 게이트웨이를 할당하여 외부 인터넷과의 연결이 가능하다. 외부 인터넷과의 연결이 가능한 라우팅 테이블이 설정된 서브넷은 Public 하며, 아닌 경우는 Private 서브넷이라고 부른다.
서브넷:라우팅 테이블 = N:1 의 관계이며, 하나의 라우팅 테이블을 여러개의 서브넷에 연결 시킬 수 있다.
3. VPC(Virtual Private Cloud)
사실 위에서 본 서브넷, 라우터, 인터넷 게이트웨이 설정에서 한가지 중요한 문제가 하나 빠져 있다. 바로 각 인스턴스가 어떤 IP 주를소 가지고 있느냐 하는 것이다. 라우터를 지나는 패킷들은 모두 Source IP, Destination IP가 지정되어 있어야 올바르게 Network ACL, 보안그룹의 인바운드룰을 거치며 인스턴스에 도착 할 수 있다.
이러한 IP 주소를 AWS에서는 사설망 형태로 제공한다. 이러한 사설망을 가진 커다란 하나의 단위를 VPC라고 하며 이는 마치 독립된 클라우드 환경으로 여겨진다.
- 하나의 구역처럼 여겨지는 독립된 가상의 클라우드 네트워크
- 계정 생성 시, Default VPC가 1개 할당된다. 하지만 별도의 커스텀 VPC를 추가하여 작업하는 것이 좋다.
VPC내의 모든 인스턴스들은 VPC 내에서 통용되는 Private IP가 부여된다. 만약 외부로 공개할 IP가 필요하다면 EC2에 Public or Elastic IP 할당이 가능하다.
- Public IP: 재시작 시 IP가 변경됨
- Elastic IP: 재시작 시에도 IP 고정됨
Q. VPC 없이 클라우드를 구성할 수 있나요?
VPC를 사용하지 않는 서비스로만 구성할 순 있습니다. 하지만 서버리스 서비스인 Lambda도 VPC 내부에 생성이 필요합니다. 사실상 VPC는 거의 모든 서비스에 필수입니다
Q. 서브넷이 EC2를 묶은 개념이라고 들었습니다. VPC는 굳이 필요 없는거 아닌가요?
VPC 이외에 서브넷을 추가로 설정한 이유는 가용 영역(Availability Zone)을 설정한다는 점에 있습니다. 각 Region의 VPC는 가용 영역을 할당받게 되고, 서브넷 생성 시 가용 영역을 설정하여 서비스 신뢰도를 높일 수 있습니다.
그럼 Private IP는 임의로 부여되는 것일까? Private IP는 VPC를 생성할 때에 CIDR를 입력하여 블록을 지정해줄 수 있다.
3.1. CIDR(Classless Inter-Domain Routing)
사이더란 클래스간 구분을 하지 않는다는 개념이다. 최초 설계된 Classfull 방식은 아래 그림처럼 네트워크 구분을 A, B, C와 같이 클래스 형태로 구분하기 때문에 IP 고갈 현상이 발생했다.
사이더는 IP 고갈 현상을 해소하기 위해 등장한 개념이며, 서브넷 마스크와 동일한 뜻이다.
- IP뒤에 192.168.10.0/24 ← 와 같은 것이 사이더 표기법
- 143.7.65.203/24 라고 표현되었다면, 24비트 이후에 오는 4번째 옥텟을 전부 사용할 수 있다는 표현
- 143.7.65.0 ~ 143.7.65.255 까지 사용이 가능하다는 뜻이다.
- VPC 생성 시에는 사이더 블록을 반드시 지정해야 하며, 공인IP와의 충돌을 방지하기 위해 사이더 블록은 RFC 1918에서 정의한 Private 대역을 사용할 것이 권장된다.
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- 한번 생성된 CIDR는 변경이 불가능하다. 따라서 IP중복을 고려, 필요에 따라 CIDR블록 숫자를 조절하여 서브넷팅(더 적게 쓰기) or 슈퍼넷팅(더 많이 쓰기) 할 수 있다.
- AWS의 모든 사이더 블록에서 5개 IP는 Reserved 이며, 사용할 수 없다.
Q. 어차피 CIDR 블록의 내부 IP는 VPC 내부에서만 쓰일 텐데, IP중복을 고려할 필요 없을 것 같아요
VPC Peering이라는 서로 다른 VPC간의 통신 서비스가 존재합니다. 이 서비스 사용 시, Peering 연결 방식(active, pending-acceptance)에 따라 CIDR 블록 중복 이슈가 발생할 수 있습니다.
3.2. VPC Peering, VPC Endpoint
VPC 내부에 존재하는 인스턴스들끼리는 라우터를 이용하여 통신한다는 것을 이제 알고 있다. 그렇다면 다른 VPC 혹은 외부의 온프레미스와의 통신은 어떻게 할 수 있을까?
VPC Peering은 리전/AWS 계정에 상관없이 VPC간 통신을 지원하는 서비스이다. VPC Peering이 진행되면 하나의 VPC처럼 취급되는 만큼 라우팅 테이블을 이용하여 서브넷간의 연결을 할 수 있다.
만약 VPC외부에 있는 서비스와 통신이 필요하다면 VPC Endpoint를 사용할 수 있다. VPC Endpoint를 이용하면 인터넷망이 아닌 안전한 연결이 보장된다.
이외에도, 연결 주체에 따라 Direct Connect, VPN connections와 같은 방식으로 연결하는 등 서비스마다 제공하는 방식으로 연결할 수 있다.
4. Route 53
VPC에 서브넷과 EC2 인스턴스를 생성했다면, 이제 EC2에 접속하기 위해서는 공인 IP를 할당 받은 뒤, 보안그룹 Inbound 룰을 설정하여 SSH 접속을 하면 된다.
하지만 당연히 일반 사용자들이 IP를 이용하여 서버에 접속하지 않는다. 인터넷상의 서비스들은 모두 도메인을 가지고 있으며, 도메인 주소는 DNS(Domain Name System) 과정을 거치며 IP를 획득 후, 해당되는 주소로 접속하게 된다.
AWS에서 제공하는 Route 53은 이러한 도메인을 구입/등록할 수 있는 서비스이다(정확히는 GandiAuthoritative 업체의 리셀러). Route 53에 도메인을 등록하면 해당 도메인은 SLD 업체 → TLD 업체를 거치며 도메인으로 등록되게 되고, ISP(Internet Service Provider) 통신사 네임 서버에 캐시로 일정 기간 동안 보관된다. 보통 2일이 걸린다.
DNS에 등록된 도메인 주소가 존재할시, 사용자 OS의 DNS Resolver가 도메인으로부터 IP주소를 획득할 수 있으며, 그제서야 EC2 인스턴스로 접속을 하여 원하는 리소스를 가져올 수 있다.
Route 53 에서는 도메인의 하위 도메인 트래픽을 라우팅 하며, A 레코드를 생성 후 로드밸런서와 연결할 수 있다. 로드밸런서와 연결되는 EC2는 Elastic IP를 사용할 수 없음에 주의한다.
