AWS를 이용하여 서버를 구축할 때 어떤 서비스를 이용하여 구축을 해야 할까요? 어떻게 구축해야 비용도 절감하고 안정적이게 구축을 할 수 있을까요?
이 질문에 대한 정답은 없습니다. 자신이 만들고자 하는 서비스를 고려하여 서버 아키텍쳐를 구성하면 됩니다. AWS에서 제공하는 서비스들을 보면 정말 많습니다. docker와 같은 container service도 지원을 하고 lambda와 같이 serverless 서비스들도 많이 지원하고 있습니다. 이번 글에서는 제가 AWS 서버 아키텍쳐를 구축할 때 가장 많이 사용하는 구조를 간락하게 설명해보려고 합니다. 정확한 실제 구조는 아니고 조금 간단하게 구축을 해보려고 합니다.
위의 사진을 보면 VPC, Subnet, Nat gateway, ALB, ASG 등등 여러 서비스들을 볼 수 있습니다. 그림만 봐서는 이해가 잘 되지 않습니다. 대략적으로 구조를 설명해 보겠습니다. VPC안의 private subnet 안에 ASG가 test용 실제 서버 용으로 각각 존재합니다. ASG 앞 단에는 Application load balancer가 존재하여 요청의 규칙에 따라 해당 asg로 보내줍니다. 또한 global accelerator를 이용하여 private subnet에 있는 alb에 접근 할 수 있게 해줍니다. 지금 당장 구조가 정확하게 이해가 안가더라도 실습을 해보면 조금 더 잘 이해가 될 것입니다.
이 글에서 AWS를 이용하여 직접 만들어 보면서 설명하겠습니다. 실습을 할려면 AWS 계정이 필요하기에 AWS 계정을 갖고 있어야 합니다.
실습
먼저, 안에 있는 autoscaling group이나 ec2를 만들기 전에 큰 틀이 되는 VPC, Subnet 등을 만들어 보겠습니다. VPC와 Subnet에 대한 설명은 https://www.44bits.io/ko/post/understanding_aws_vpc 위 블로그에 설명이 자세하게 잘 되어있기에 참고하시면 되겠습니다.
VPC 생성
→ VPC를 간략히 말하면 논리적인 독립 네트워크를 구성하는 리소스입니다.
AWS에 접속을 하여 서비스 검색란에 VPC를 검색을 해줍니다. 그러면 다음과 같은 화면이 보입니다. 여기서 VPC를 선택을 합니다.
VPC를 선택하면 다음과 같은 화면이 보입니다. EC2를 만든 적이 있다면 기본 VPC가 이미 존재합니다. 오른쪽 위에 있는 VPC 생성 버튼을 클릭해줍니다.
VPC 생성버튼을 클릭하면 다음과 같은 창이 보입니다.
이름 태그에는 원하는 VPC이름을 입력해 줍니다. IPv4 CIDR 블록 선택에서는 IPv4 CIDR manual input을 선택합니다. 두 번째 옵션을 선택할 경우에는 Amazon VPC IP Address Manager 서비스에 접속해서 IPAM을 생성해주면 됩니다. 간략하게 IPAM에 대해서 설명을 하자면 AWS 워크로드의 IP 주소를 더욱 쉽게 계획하고 추적하며 모니터링할 수 있도록 지원하는 새로운 기능입니다. 서울 리전도 지원해주기에 이 기능을 사용하고 싶으면 생성해서 사용하여도 됩니다. 다만, 무료로 사용할 수 있는 기능이 아니기에, 요금을 확인해서 필요한 경우에만 사용하면 됩니다.
IPv4 CIDR에는 IP대역을 입력하면 됩니다. 특별하게 범위에 대한 제약은 없지만, 인터넷 연결을 하여 다른 IP에 요청을 할 때 VPC 내부의 IP와 겹치는 일을 막기 위해서는 사설망 대역을 사용하는 것을 권장하고 있습니다. 사설망 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 있습니다. 이번 실습의 경우에는 10.0.0.0/16으로 생성해주었습니다.
다음과 같이 VPC가 생성됨을 볼 수 있습니다. 세부정보를 보면 DNS 호스트 이름이 비활성화 되어있다고 나와있습니다. 기본 VPC의 경우 DNS 호스트이름과 DNS확인 둘다 기본적으로 활성화 되어있지만, 새로 VPC를 생성을 하면 DNS 호스트 이름은 비활성화되어 있습니다. DNS hostname은 해당 VPC 내부에서 생성되는 Instance에 퍼블릭 DNS hostname를 할당해주는 기능입니다. 나중에 EC2를 생성할 때 더 자세하게 설명하겠습니다.
이와 같이 VPC를 생성해보았습니다. 하지만 이러한 VPC를 이용하여 할 수 있는것이 없습니다. instance를 만들기 위해서는 실제 가용존과 연결이 된 서브넷을 만들어야 합니다.
서브넷 생성
→ VPC 내부에서 물리적인 공간인 가용존과 연결
왼쪽에 있는 바에 VPC밑에 서브넷을 클릭하여 줍니다. 그럼 다음과 같은 창이 나옵니다. 이 창에서 서브넷 생성을 클릭합니다.
그럼 다음과 같은 창이 보입니다.
서브넷을 생성을 할 때에는 VPC를 선택해 주어야 합니다. 전체적인 VPC라는 논리적인 네트워크 안에서 물리적인 가용존이랑 연결을 하기에 VPC를 먼저 생성해주어야 합니다. 방금 전에 생성한 VPC를 선택해 줍니다.
VPC를 선택하였으면 서브넷 설정을 할 수 있게 입력 창들이 나옵니다. 서브넷 이름을 입력을 하고 가용영역을 설정해줍니다. 그 후 서브넷의 IPv4 CIDR블록을 생성해줍니다. 여기서 주의할 점은 IPv4 설정의 경우, 서브넷이 VPC 안에서 생성이 되기에 VPC CIDR 범위에서 설정을 해줘야 합니다. 또한 Subnet끼리 CIDR 주소가 겹치면 안됩니다.
이 실습에서는 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24로 4개 만들어 주고 2개씩 각각 가용존 ap-northeast-2a, ap-northeast-2c 이렇게 만들어 주겠습니다. 위와 같이 4개를 만든 이유가 있습니다. 먼저 제일 처음 아키텍쳐 그림을 보면 public subnet과 private subnet이 있습니다. public, private을 위해 2개의 서브넷을 만들었습니다.
그럼 나머지 2개는 왜 만들었을까요? 고가용성을 위해서 만든 서브넷입니다. public, private subnet 쌍이 2a와 2c 존에 있는 경우 2a나 2c 중 하나의 가용존에 문제가 발생하여도 나머지 가용존이 있기에 서버가 안정적으로 동작할 수 있습니다. 여기서 가용존은 2a, 2b, 2c등 이름만 다른 것이 아니라 실제로 물리적으로도 떨어져 있습니다.
만들어진 서브넷을 표로 보면 다음과 같습니다.
서브넷 이름 | 가용존 | CIDR 블록 |
public1 | ap-northeast-2a | 10.0.0.0/24 |
public2 | ap-northeast-2c | 10.0.2.0/24 |
private1 | ap-northeast-2a | 10.0.1.0/24 |
private2 | ap-northeast-2c | 10.0.3.0/24 |
여기서 2a, 2b를 선택할 수 있는데 왜 2a, 2c로 했는지 궁금할 수 있습니다. 2a, 2b로 해도 상관이 없지만, 나중에 실습에서 생성할 EC2 instance 종류가 t2.micro(프리티어 무료)인데 t2.micro가 서울 리전 2b 가용존에서 지원을 안하기에 2a, 2c로 하였습니다.
이렇게 생성이 되면 subnet 생성이 완료되었습니다.
서브넷 생성을 마치고 나면 궁금한 점이 있을 것입니다. 분명히 public subnet과 private subnet을 만들었는데, 2개의 subnet이 이름이랑 IP대역만 다르고 나머지는 다 똑같지 않냐고 생각할 겁니다. 맞습니다.!!! 현재 만든 subnet들은 이름이랑 ip만 다르고 하는 역할은 다 똑같습니다. 이제 이 서브넷들이 public subnet, private subnet으로 동작할 수 있도록 설정을 해줄 것입니다.
인터넷 게이트웨이 생성
→ 인터넷에 연결하기 위해 필요한 인터넷 게이트웨이
위에서 만든 VPC를 인터넷에 연결하기 위해서는 인터넷 게이트웨이가 필요합니다. 인터넷 게이트웨이 뿐만 아니라 라우팅 테이블에서 규칙을 추가하여 특정 서브넷을 인터넷과 연결시킬 수 있습니다. 인터넷 게이트웨이를 라우팅 테이블에 추가하는 것은 라우팅 테이블 세팅에서 하고 여기서는 인터넷 게이트웨이를 생성해 보겠습니다.
먼저, 인터넷 게이트웨이를 클릭해줍니다. 그럼 다음과 같은 창이 보입니다. 오른쪽 위에 인터넷 게이트웨이 생성을 클릭합니다.
생성을 클릭하면 다음과 같은 창이 보입니다.
이름 태그에 원하는 이름만 입력하고 인터넷 게이트웨이 생성 버튼을 클릭하면 생성이 됩니다.
생성이 완료되면 다음과 같은 창이 보입니다.
인터넷 게이트웨이 현재 상태를 보면 Detached라고 나와 있고 연결된 VPC ID도 없습니다. VPC에서 인터넷 연결을 위해 인터넷 게이트웨이에서 VPC에 연결해줍니다. 위에 VPC와 연결 버튼을 클릭합니다.
연결하고 싶은 VPC를 연결한 후, 인터넷 게이트웨이 연결 버튼을 클릭합니다.
연결을 완료하면 다음과 같이 상태에 Attached라고 보이고 연결된 VPC ID도 확인할 수 있습니다.
이렇게하면 인터넷 연결을 위해 인터넷 게이트웨이 생성을 완료하였습니다. 또한 인터넷 게이트웨이를 생성하여 연결하고 싶은 VPC에 연결도 해보았습니다.
인터넷 게이트웨이는 말그대로 인터넷을 연결하는것이기에 보통 public subnet에서 라우팅 테이블을 연결하여 사용하게 됩니다. private subnet의 경우에 인터넷과 바로 연결하지 않고 NAT gateway를 통해서 인터넷과 연결할 수 있게 설계합니다. 다음으로는 NAT gateway 생성을 해보도록 하겠습니다.
NAT 게이트웨이 생성
→ 네트워크 주소 변환 서비스로 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 사용
위의 설명대로 private subnet의 instance가 외부 서비스에 요청을 할 때는 가능하지만, 외부에서 private subnet의 요청을 할 때는 연결이 불가능하게 하는 역할을 합니다.
NAT gateway를 생성하는 것도 인터넷 게이트웨이만큼 간단합니다.
옆에 있는 선택 바에서 NAT 게이트웨이를 선택합니다. 오른쪽 위에 NAT 게이트웨이 생성을 클릭해줍니다.
클릭하면 다음과 같은 창이 보입니다.
이름 칸에는 원하는 이름으로 기입합니다. 다음은 서브넷을 선택합니다. 여기서가 중요합니다. NAT gateway의 목적이프라이빗 서브넷의 instance에서 인터넷 연결을 가능하게 하기 위함이므로 프라이빗 서브넷을 선택해야 한다고 생각합니다. 하지만 이렇게 하면 안됩니다. NAT gateway를 통하여 private instance들이 공용 IP와 port를 부여받고 인터넷에 연결되어야 하기에 internet gateway와 연결된 서브넷을 선택해야 합니다. 따라서 public subnet을 선택해줘야 합니다.자세한 내용은 routing table에서 설명하겠습니다.
그리고 연결 유형을 선택합니다. 퍼블릭으로 선택을 할 경우에 인터넷 연결이 가능하고 프라이빗 같은 경우는 또 다른 VPC 또는 온프레미스 네트워크에 연결을 할 때 사용합니다. 자세한 내용은 NAT gateway 글을 참고해 주세요.
연결 유형을 선택하고 나면 탄력적 IP를 할당해줘야 합니다. 사설 IP가 public IP로 바뀌어서 나가야 하기에 탄력적 IP를 할당 해주면 됩니다. 이미 탄력적 IP가 있는 경우에는 선택을 해주면 되고 아니면 탄력적 IP할당을 클릭하면 할당 받으면 됩니다. (※ 탄력적 IP를 할당할 때 오류가 생겼을 때 똑같은 탄력적 IP를 사용하고 있는지 확인해 보고 IP 갯수가 5개가 넘는지 확인을 해줍니다. 5개가 넘을 경우 더 사용하고 싶으면 AWS 측에 문의 메일을 남기면 더 증가시켜줍니다.) 다 생성을 하였으면 NAT 게이트웨이 생성을 클릭하여 생성해줍니다.
생성을 하면 다음과 같은 창이 보입니다.
서브넷을 생성할 때 고가용성을 위해서 2a와 2c 리전에 서브넷을 만들었기에 각각 nat gateway를 생성해주면 됩니다.
이제 NAT gateway 생성도 완료 하였습니다. NAT gateway와 탄력적 IP를 생성할 때는 요금이 들기에 사용하지 않을 때는 삭제를 해줘야 합니다. 자세한 요금에 대해서는 각 리전마다 AWS 요금 상세 페이지에서 확인할 수 있습니다.
이제 생성한 NAT gateway와 인터넷 게이트웨이를 이용하여 서브넷의 라우팅 테이블을 세팅해 보겠습니다.
라우팅 테이블 세팅
→ 서브넷과 연결되어 있는 리소스로 서브넷에서 네트워크를 이용할 때 라우팅 테이블을 사용해서 목적지를 찾습니다. 쉽게 말해서 네비게이션이라고 생각하면 됩니다.
퍼블릭 서브넷 용 라우팅 테이블과 프라이빗 서브넷 용 라우팅 테이블을 각각 만들어주면 됩니다. 퍼블릭의 경우에 퍼블릭 IP를 이용하여 인터넷에 접근이 가능하게 해야함으로 인터넷 게이트웨이를 연결해주면 되고, 프라이빗의 경우에는 nat gateway를 통해서 외부 리소스에 접근을 해야하기에 nat gateway를 라우팅테이블에 등록시켜주면 됩니다.
먼저, 라우팅 테이블을 클릭하면 다음과 같은 창이 보입니다.
VPC를 생성하면 기본적으로 라우팅 테이블이 생성이 됩니다. 오른쪽 위에 라우팅 테이블 생성을 클릭하여 라우팅 테이블을 생성할 수 있습니다.
그럼 다음과 같은 창이 보입니다.
라우팅 테이블 설정을 보면 이름을 설정하고 VPC를 설정해주면 됩니다. VPC를 설정하면 해당 VPC 안의 IP 대역에서는 local에서 찾는 규칙이 자동적으로 설정이 됩니다. 설정을 하고 라우팅 테이블 생성을 클릭하면 라우팅 테이블이 생성됩니다.
라우팅 테이블을 만들었으면 서브넷과 연결을 해줘야 합니다. 서브넷 연결 탭에 들어가서 명시적 서브넷 연결 옆에 서브넷 연결 편집을 클릭합니다.
클릭하면 다음과 같은 창이 나옵니다.
여기에 해당 VPC에 속해 있는 서브넷이 다 보여집니다. 현재 public subnet에 대한 라우팅 테이블을 만들고 있기에 public subnet을 선택해줍니다.
이제 서브넷 연결을 해주었으니 라우팅 편집을 해주면 됩니다. 라우팅 탭을 클릭한 후 오른쪽 라우팅 편집 버튼을 클릭해줍니다.
클릭하면 다음과 같은 창이 보입니다.
라우팅 편집에서 public subnet의 라우팅 테이블에 대한 편집이므로 10.0.0./16에서는 local에서 찾고 그 ip대역을 제외한 나머지 대역에서는 인터넷 게이트웨이로 향하게 해줍니다. 그렇게 라우팅 추가한 후 변경 사항 저장을 해줍니다.
private subnet 라우팅 테이블도 위에서 한 방법과 비슷합니다. 서브넷 연결을 private subnet으로 해주고 라우팅 편집 시 밑에 사진과 같이 NAT 게이트웨이에 대한 규칙을 추가해주면 됩니다.
라우팅 테이블에 대해 요약을 해보면 다음 표와 같습니다.
라우팅 테이블 이름 | 라우팅 | 서브넷 연결 |
public | 10.0.0.0/16 local 0.0.0.0.0/0 internet gateway |
public subnet1, public subnet2 |
private1 | 10.0.0.0/16 local 0.0.0.0.0/0 nat gateway1 |
private subnet(2a region) |
private2 | 10.0.0.0/16 local 0.0.0.0.0/0 nat gateway2 |
private subnet(2c region) |
이렇게 설정을 하면 서버 아키텍쳐에서 네트워크 설정을 다 한 것입니다!! 이제 네트워크 설정한 큰 틀에 instance를 만들어서 autoscaling group과 application load balancer를 만들면 됩니다. 글이 길어져서 EC2 설정은 다음 글에 적어보겠습니다.
※ 오타가 나거나 잘못된 내용이 있으면 댓글로 언제든지 물어봐주고 지적해주세요!!
참고자료
https://www.44bits.io/ko/post/understanding_aws_vpc
'AWS' 카테고리의 다른 글
[AWS] Public Subnet, Private Subnet, ALB, ASG 를 이용한 서버 아키텍쳐 구축(2) - AutoScaling Group 만들기 (0) | 2022.01.15 |
---|---|
[AWS Storage Service] S3 (Simple Storage Service) 버킷 정책 생성 및 권한 부여 (0) | 2021.09.13 |
[AWS Run Command]Run Command로 원격으로 명령어 실행하기 (0) | 2021.08.20 |
[AWS Session Manager] SSH 없이 Session manager로 EC2 instance에 접속 하기 (0) | 2021.08.18 |
[AWS CLI 설정] AWS Cli 설치 및 AWS CLI configure 설정 방법 (0) | 2021.08.17 |