코드프레소 백엔드 개발자 양성 과정
AWS로 서비스 배포하기 1
지난 몇 주간은 회원 가입, 로그인, 글 쓰기 기능 등을 구현한, 트위터 형식의 간단한 소셜 네트워킹 플랫폼을 개발했다. 이것을 아마존 웹 서비스를 통해 클라우드 환경에서 서비스를 배포하는 실습을 해보겠다.
가상 사설 클라우드를 빌려 그 안에 웹 서버와 데이터베이스 서버를 분리하여 배치하는 가장 기본적인 설계를 구현해보았다. 각 단계마다 개념을 알아보고 과정을 설명한다.
가상 사설 클라우드 (Virtual Private Cloud)
아마존 웹 서비스에서 가상 사설 클라우드(Virtual Private Cloud, VPC)라는 것은 이용자가 대여하고 통제할 수 있는, 논리적으로 격리된 클라우드 공간이다. 이 공간에 한해서 이용자는 IP 주소 범위를 선택할 수 있으며, 서브넷, 라우팅 테이블 및 네트워크 게이트웨이 등을 구성 및 설정할 수 있다.
서브넷, 라우팅 테이블 등의 요소에 대해서는 차츰 살펴보겠다. 관건은 VPC라는 것은 아파트라는 공용 환경에서 각 호(戶)처럼 개개인이 통제할 수 있는 분리된 공간이라는 것이다.
VPC는 오가는 통신을 두 겹으로 제어할 수 있어 보안이 우수하며, 불과 몇 분만에 사용자가 완전한 제어권을 쥐는 클라우드 공간을 부여받을 수 있다는 장점이 있다.
나만의 VPC를 만들어본다. 우선 VPC 대시보드에 접속한다. 간편하게 마법사를 이용해보겠다.
다양한 형태의 VPC를 만들 수 있는데, 위에 도식화되어 있듯, 내가 구현하고자 하는 구조는 한 VPC 안에 공공 서브넷과 사설 서브넷이 하나씩 있고 둘이 NAT 게이트웨이라는 것으로 연결된 모양이다. 마법사 인터페이스에서 두 번째 옵션이다.
두 번째 형식을 고르고 나면 세부 사항을 지정하는 창으로 넘어간다.
최상단에서는 사이더(Classless Inter-Domain Routing, CIDR)와 VPC 이름 등을 지정해 줄 수 있다. 사이더 블록은 기본 설정으로 두었고, VPC 이름은 social_media_project_vpc라고 지어주었다.
그 아래에서는 공공 서브넷과 사설 서브넷의 가용 영역(Availability Zone)과 이름, 사이더 블록 등을 정해줄 수 있다. 가용 영역이란 아마존 웹 서비스의 한 지역 (Region) 내에서 또 한 번 물리적으로 분리되어 있는 데이터 센터를 뜻한다.
서울 지역의 경우 가용 영역이 ap-northeast-2a, ap-northeast-2b, ap-northeast-2c로 세 개가 있는데, 실험했을 때 ap-northeast-2b에서는 (나중에 다룰) EC2 인스턴스를 생성할 수 없다고 뜨는 바람에 ap-northeast-2b를 배제한 나머지 가용 영역에 서브넷을 만들어 주었다.
공공 서브넷은 ap-northeast-2a에, 사설 서브넷은 ap-northeast-2c에 만들어 준 것을 볼 수 있는데, 같은 가용 영역에 생성하여도 문제될 것은 없다. 이름은 각각 social_media_project_public_subnet과 social_media_project_private_subnet으로 지어주었다.
마지막으로 NAT 게이트웨이에 부착한 탄력적 IP 주소의 ID를 입력해주면 VPC를 만들 수 있다. 서브넷, NAT 게이트웨이, 탄력적 IP에 대해서는 차츰 알아보도록 한다.
다시 대시보드로 돌아오면 방금 생성한 social_media_project_vpc가 사용 가능한 상태로 표시되어 있음을 확인할 수 있다. 나만의 가상 클라우드 공간이 생긴 것이다.
현재까지의 진도를 도식화하면 이렇다.
하위 연결망 (Subnet)
하위 연결망 혹은 서브넷(sub-network, subnet)은 VPC에서 정의한 사이더 블록을 구간으로 나눠 담은 용기(容器)이다. 이렇게 구간별로 IP 네트워크를 쪼개어 하위 네트워크를 만들면, 각 하위 네트워크에 다른 접근 규칙을 지정할 수 있어 보안에 유리하다. 예를 들어, 위에서 생성한 VPC의 경우, 공공 서브넷은 인터넷에 연결할 수 있도록 하는 반면, 사설 서브넷은 그렇지 않게 설계해 민감한 정보를 감추는 데 사용된다.
VPC를 아파트 건물에서 한 호(戶)에 비유했다면, 서브넷은 그 호 안에서 방 한 칸에 해당한다. 집에도 손님을 맞는 응접실이 있고, 바깥 사람은 들이지 않는 안방이 있는 것과 마찬가지로, 주어진 공간을 구분 지으면 용도에 맞게 효율적으로 사용할 수 있다. 서브넷이 그런 역할을 한다.
서브넷을 만들어보겠다.
사실 방금 사용한 VPC 마법사에서 설정한 대로 공공 서브넷과 사설 서브넷이 이미 생성되어 있음을 대시보드에서 확인할 수 있다.
목록에서 서브넷을 선택하면 상세 정보를 볼 수 있다. 서브넷의 이름, 소속 VPC의 ID와 이름, 사이더 블록과 가용 영역이 앞서 설정해 준 그대로인 것을 확인할 수 있다.
마법사를 사용하지 않아 서브넷을 처음부터 만들어야 하는 상황이라도 걱정할 것 없다. 방법은 매우 간단하다.
우선 서브넷 생성하기 단추를 누른다.
이번에는 social_media_project_tutorial_subnet이라고 이름을 지어줬다. 서브넷은 방과 같다고 했으니 당연히 내가 지금 정의하는 방이 위치할 아파트 호수도 알려줘야 한다. social_media_project_vpc에 생성해보겠다.
가상 클라우드 상에서 서브넷이 위치할 VPC를 설정해주었다면, 서브넷이 물리적으로 위치할 가용 영역도 지정해주어야 한다. 가용 영역은 필수 입력 사항은 아니지만 ap-northeast-2b에서 안 좋은 기억이 있었기에 일부러 피해줬다.
마지막으로 사이더 블록을 지정해준다. 해당 VPC 내에서 사용 가능한 IP 범위를 벗어나거나 유효한 사이더 블록이 아니면 오류가 발생한다. 사이더를 깊게 이해하고 있고, 특정한 의도를 가지로 IP 주소를 분할하고 싶은 게 아니라면 예시로 들어준 10.0.0.0/24를 그대로 입력하거나, 10.0.1.0/24, 10.0.2.0/24처럼 살짝 바꾸어 입력해도 무방하다.
대시보드로 돌아오면 설정한 대로 생성되었음을 확인할 수 있다.
이제 VPC라는 나만의 공간에 용도별로 구분 지은 방이 생긴 것이다.
네트워크 주소 번역 관문 (NAT Gateway)
네트워크 주소 번역 관문 혹은 NAT (Network Address Translation) 게이트웨이는 사설 서브넷 안에 생성될 연산 자원으로 하여금 인터넷이나 다른 AWS 서비스에 접근할 수 있도록 해준다. 하지만 외부인이 인터넷을 통해 사설 서브넷에 접속하는 것은 여전히 방지함으로써 안전성은 유지한다. 두 마리 토끼를 다 잡는 것이다.
VPC를 아파트 한 호에, 서브넷을 방에 비유했다면, NAT 게이트웨이는 방문 정도로 볼 수 있다. 외부인을 들이지 않기 위해 침실을 응접실로부터 구분했다고 해도, 침실에 문은 있어야 하는 법이다.
그럼 서브넷 간에 관문을 뚫어 사설 서브넷 안의 자원의 보안은 유지하되 가용성은 저하되지 않도록 해보자.
대시보드에서 NAT 게이트웨이 생성하기 단추를 누른다.
NAT 게이트웨이가 설치될 서브넷을 지정한다. 맨 위 설계도에서 볼 수 있듯, NAT 게이트웨이는 VPC에서 외부 인터넷이 통하는 공공 서브넷에 생성하여야 한다.
사설 서브넷의 사설 IP 주소로는 직접 외부와 통신할 수 없으므로, NAT 게이트웨이가 사설 IP 주소를 공공 IP 주소와 대응 및 연결해주어야 하기 때문이다.
그리고 탄력적 IP 주소라는 것을 할당해준다. 생성을 마친다.
NAT 게이트웨이 생성에는 시간이 좀 걸릴 수 있다. 몇 분 후 대시보드를 새로 고침해보면 social_media_project_vpc의 social_media_project_public_subnet에 탄력적 IP 주소를 할당받은 NAT 게이트웨이가 생겼음을 볼 수 있다.
참고로 NAT 게이트웨이는 과금 대상이다. NAT 게이트웨이를 보유하고 있는 것만으로도 서울 지역에서는 시간당 $0.059(약 70원)가 부과되며, NAT 게이트웨이를 통과하는 데이터 1GB마다도 $0.059의 비용이 청구된다.
연습하기 위해 만들었다면 삭제하는 것을 잊지 않는 것이 좋다.
NAT 게이트웨이를 구축함으로써 아래와 같은 구조가 되었다.
지금까지 가상 사설 클라우드 공간의 구조를 어느 정도 확립해보았다. 다음 글에서는 VPC와 서브넷이라는 구조에 가동할 서버를 구축한다.
