[VPC/EC2/RDS] 인프라 적용기

AWS 공부도 할겸 전에 주먹구구식으로 했던 AWS들 다 갖다버리고 처음부터 새로 하기로 하였다.

전체적인 구조는 저렇게 잡고 VPC부터 구축해서 EC2 랑 RDS 까지 적용하는 것이 이 글의 목적이다.

 

VPC

일단 VPC를 만들고 그 안에 public subnet 1개와 private subnet 2개를 만들어 넣었다.

Seoul region으로 VPC를 만들고 public과 private 한개는 2a 나머지 private 한개는 2b에 넣었는데,

이유는 서로 다른 AZ 간에 데이터를 주고받으면 교차 AZ 데이터 전송료라는 것이 있다고 하여서 같이 넣어서 데이터를 주고 받을 경우 하나랑 나머지 한 개를 백업용으로 저장을 해두려고 private를 2개 만들었다.

 

이제 EC2랑 RDS를 만들어서 저기에 넣어주면 끝인가 하고 생각을 했었다. 

하지만 IGW와 Route table이라는 것도 필요했다.

IGW & Route table

VPC를 처음 만든 상태는 고립된 가상 네트워크라고 생각하면 된다고 한다. 즉 인터넷과 소통할 수 없는 상태여서 외부 세상(인터넷)과 통신할 수 있는 공식 출입구를 만들어줘야 하는데, 그게 바로 IGW(Internet Gateway)이다.

 

이렇게 IGW를 만든다면 끝일까? 아니다. 서버들에게 밖으로 나가고 싶으면 저 IGW로 가라고 안내해주는 표지판 같은 역할을 해주는 것이 필요합니다. 이것이 바로 Route table 이다.

 

이 원리를 이용해서 afternote 프로젝트의 네트워크를 아래와 같이 설계했다.

 

 

Public Subnet (afternote-public-2a): EC2 서버가 있는 곳으로 이 구역은 afternote-public-rt라는 표지판을 따르도록 설정했다. 이 표지판의 끝은 오른쪽의 afternote-igw 대문으로 연결되어 있어, 인터넷과 자유롭게 통신할 수 있다.

 

afternote-public-rt에는 afternote-igw와 afternote-public-2a가 등록되어 있다.

Private Subnet (afternote-private-2a/2b): 보안이 최우선인 RDS(데이터베이스)가 있는 곳으로 이 구역은 afternote-private-rt라는 표지판을 따른다. 이 표지판은 대문(IGW)으로 가는 길이 없는데, 그래서 이 구역의 리소스들은 외부 공격으로부터 안전하게 보호받으며, 오직 VPC 내부의 리소스들과만 통신할 수 있다.

 

afternote-private-rt에는 afternote-private-2a/2b가 등록되어 있다.

 

이렇게까지 등록을 해주면 VPC는 끝이 난다고 볼 수 있다.

---

EC2랑 RDS를 처음 만들 때랑 VPC 등 간단한 개념들을 공부하고 만들 때랑은 차원이 달랐다. 그땐 하나하나 gemini한테 물어보던 시절이였는데, 지금은 그래도 subnet 등 connectivity 쪽은 내가 방향성을 가지고 하고 있는 것이 뿌듯했다.

 

그래도 조금씩 애로사항들이 있었는데, 

EC2 트러블 슈팅

처음엔 VPC를 만들었는데 왜 EC2 설정에서 security group을 왜 또 만져야 하는지 이해가 가지 않았다. 하지만 직접 구축해보니 그 이유를 알게 되었다.

내가 볼 때, VPC는 전체적인 네트워크 설계이고 security group은 인스턴스 개별의 보안 설계같다. 공부했던 화이트리스트가 적용되는 것이 바로 이 Security group 이였다는 것을 깨달았다. 그래서 들어오는 신호로 SSH, HTTP, HTTPS 까지 설정을 완료했다.

그 외에는 한번 만들어본것이다 보니 수월하게 만들었던거 같다.

RDS 트러블 슈팅

위의 사례를 겪고 RDS에 대한 security group을 만들고 들어갔다. RDS는 private subnet에 존재해야하므로 당연히 넣으면 되겠거니 하고 들어갔는데 왠걸 Subnet Group이라는 게 존재했다. 

RDS 를 만들기 전에 혹시나 물리적인 데이터 센터 장애가 발생했을 때 RDS가 자동으로 다른 가용 영역(AZ)으로 복구될 수 있도록 하기 위해 private subnet을 일부로 2개 만들어서 연결을 하면 좋겠다고 생각을 했었는데, 그것이 바로 Subnet group으로 진행이 되는 것이였다. 

 

그래서 위에서 만든 afternote-private-2a/2b를 한 subnet group으로 묶고 연결을 한뒤 RDS의 inbound에 EC2의 security group을 등록을 한 후에 RDS를 성공적으로 만들었다!

 

Security group 트러블 슈팅

 

이렇게 성공적으로 만든 후, 점검을 하려고 Security group을 들어갔는데 내가 만들지 않은 security group이 3개나 있었다.

첫번째 경우는 사실 VPC를 만들면 자동으로 생기는 기본 보안 그룹이라고 해서 무시해도 됐지만, 문제는 나머지 2개의 경우였다.

대충 안의 내용을 살펴보니 EC2랑 RDS를 서로 이어주는 보안그룹이 있었던 것이다. 원래는 그냥 써도 되지만 나는 이미 만들어놨었기 때문에 의문이 들었던 것인데, 원인을 찾다가 바로 AWS RDS의 '자동 생성(Managed)' 기능이 만든 security group이라고 하길래 내가 체크를 잘못했구나 깨닫고 연결을 끊고 바로 삭제했다.

 

IPv6 트러블 슈팅

이제 test를 해볼려고 SSH로 들어가서 DB test를 해보려고 했는데 ssh 접속이 잘됐지만 sudo apt update가 오류가 나면서 잘안되는 것을 발견할 수 있었다. 

1. Cannot initiate the connection to ... (2406:da12:...) - connect (101: Network is unreachable)

어떤 오류인지 감이 안잡혀서 검색을 해보았더니 최신 리눅스 모델은 자동으로 신식인 IPv6가 더 좋다고 거기로 자동으로 방향이 간다는 소리였다. 문제는 내가 설정해준 VPC는 IPv4로 다 해놓아서 오류가 뜨는 것이였다.

/etc/gai.conf 이라고 시스템이 특정 도메인의 IP 주소를 가져올 때 어떤 규칙을 따를지 정의하는 설정 파일이 있는데 

이 파일은 IPv4와 IPv6의 점수중 더 큰 점수가 기본값이 된다고 하여서 아래와 같이 고쳤다.

precedence ::ffff:0:0/96  100

점수를 100으로 하여서 IPv6보다 크게 하여서 방향을 돌렸다.

apt update 트러블 슈팅

그래서 진짜 다 고친 줄 알고 Test 를 해보려고 할 때, sudo apt update가 오류가 나면서 안되는 것을 볼 수가 있었는데, 

Could not connect to ... (13.124.245.230), connection timed out

밖으로 나가는 길목이 막혔다는 오류였다. 그래서 나는 내 네트워크들에서 문제가 생겼나 하고 계속해서 살펴봤지만 아무리 봐도 문제가 없었다. EC2 security group의 Outbound Rules와 VPC route table의 0.0.0.0/0를 확인하라는 답밖에 안들려와서 헤매고 있을 때,

 

DNS(도메인 주소 찾기) 설정이 아직 옛날 주소를 바라보고 있다. 라는 원인이 떨어졌었다. 

 

알아보니VPC의 DNS Resolution을 내가 안 건들였기 때문에 VPC DNS가 오류가 난 것이였다. 

일단 resolv.conf라는 문서에 8.8.8.8을 직접 적어줘서 해결을 했었는데, 이는 AWS가 제공하는 시스템(VPC DNS)을 아예 거치지 않고, 공용 인터넷 망을 타고 구글 서버로 직접 달려가게 만든 것이다.

 

이렇게 해결을 하고 너무 억울해서 찾아보니

내가 하나하나 만들어야지 라고 선택했던 VPC only 에는 따로 또 들어가서 추가설정을 했어야 했던것...

저 more 옵션으로 들어가니 아래처럼 당연하게 있는 것을 볼 수 있었다.

인스턴스가 도메인 주소를 해석하지 못한다면, VPC 생성 직후 반드시 Actions > Edit VPC settings 메뉴에 진입하여 DNS resolution과 DNS hostnames가 활성화되어 있는지 확인해야 한다는 것을 깨달았다. 또한 생성 화면에 없다고 해서 자동으로 설정되는 것이 아니라는 점도 확실히 느꼈다.