aws로 그럴듯한 인프라 만들기 1 - 네트워크 망 구성
1. 망 구성하기
Last updated
Was this helpful?
1. 망 구성하기
Last updated
Was this helpful?
에 참여하고 있다. 총 4주 과정으로 매 주마다 진행해야할 미션이 주어지고, 미션을 단계별로 해결하면서 인프라에 대한 지식을 자연스럽게 습득하고 경험해볼 수 있다. 매 주 경험하게될 주제는 대략 아래와 같다.
그럴듯한 인프라 만들기
안정적인 인프라 만들기
조회 성능 개선하기
확장하는 인프라 만들기
오늘은 그 첫번째 주차인 "그럴듯한 인프라 만들기" 라는 주제로 과제를 진행했던 과정과 그 속에서 겪었던 어려움들을 기록하며 배운 점들을 조금 더 오래 기억하고자 한다.
1주차는 그럴듯한 인프라를 구축해보는 미션이 주어졌다. 아래와 같이 진행될 예정이다. 이번 글에서는 1번과 2번을 다룬다
미션을 시작하기 전에, 나의 PEM 키를 생성하여 이후 구축할 모든 서버에서 해당 키를 사용한다.
우리가 구성할 인프라는 대략 아래와 같다. 각 요소별로 만족해야하는 조건이 주어졌기 때문에 그에 맞춰 순서대로 구축을 진행해볼 것이다.
VPC : CIDR은 C class(x.x.x.x/24)로 생성
Subnet
외부망으로 사용할 Subnet : 64개씩 2개 (AZ를 다르게 구성)
내부망으로 사용할 Subnet : 32개씩 1개
관리용으로 사용할 Subnet : 32개씩 1개
Internet Gateway 연결
Route Table 생성
Security Group 설정
외부망
전체 대역 : 8080 포트 오픈
관리망 : 22번 포트 오픈
내부망
외부망 : 3306 포트 오픈
관리망 : 22번 포트 오픈
관리망
자신의 공인 IP : 22번 포트 오픈
서버 생성
외부망에 웹 서비스용도의 EC2 생성
내부망에 데이터베이스용도의 EC2 생성
관리망에 베스쳔 서버용도의 EC2 생성
베스쳔 서버에 Session Timeout 600s 설정
베스쳔 서버에 Command 감사로그 설정
위의 그림은 툴을 이용하여 AWS 네트워크 망을 어떻게 구성할 것인지 간단히 설계도를 작성한 것이다. 오른쪽에는 전체적으로 기본적으로 인터넷망부터 VPC, Availability Zone, Subnet, Server, IGW, NAT gateway 까지 필요한 요소들을 적절하게 배치하여 전체적으로 우리 서비스가 어떤 흐름을 통해 사용자들과 소통할 수 있는지를 그려본다.
왼쪽의 표는 각 서비스별로 기억해야할 name 별칭과 ip 들이다. AWS 는 워낙 다양한 서비스들을 제공하고 있어서 저렇게 name 으로 별칭을 정해두지 않으면, 서비스가 성장하고 시스템이 커질수록 각 요소들을 적절하게 관리할 수 없게 된다.
의외로 네이밍을 대충하는 개발자들을 종종 봤는데, 저 네이밍이 잘 되어있으면 시스템을 파악해야하는 뉴비 입장에서는 정말 감탄스럽다. 맨 처음 일했던 회사에서 이사님과 함께 네트워크 구축을 하며 배웠던 것인데, [기업의 서비스명]-[AWS 요소]-[public/private여부]-[az영역] 으로 네이밍을 하면, 처음보는 사람도 해당 구성요소에 대해서 많은 정보를 얻을 수 있기 때문에 참 좋은 방법이라고 생각했다. 이후로도 계속 그 방법을 사용하고 있다. (다만, 이번 과제에서는 다른 사람들와 AWS 계정을 공유해서 사용하고 있기 때문에 내 리소스임을 드러내야하므로, 나의 gitub 아이디나 나를 표현할 수 있는 단어를 prefix 로 두어야했다.)
서브네팅도 왼쪽의 표를 작성할 때, 아예 함께 진행한다. 그래야 논리적으로 한번에 계획하고, 나중에 AWS 콘솔 상에서 작업할 때에는 마음 편하게 저 표만 보면서 구성할 수 있다. 그때그때 생각하려면 골치아프고 실수할 가능성도 높아진다.
VPC는 Virtual Private Cloud 의 약자이다. VPC를 구성한다는 것은 결국 지구상 존재하는 드넓은 네트워크 망 중에서, "나는 이 땅에다가 내 집을 만들거야", "여기까지는 내 공간이야, 침범하지마!"하고 공헌하는 것이라는 생각이 들었다. 한번 땅을 사고 나면, 그 내부에서 집을 지을지, 빌딩을 세울지, 방을 어떻게 나눠서 쓸지, 외부와 소통할 수 있는 창문을 낼지, 손님이 들어올 수 있는 문을 만들지, 아니면 우리 가족들끼리만 소통하게 할지 그 세부적인 것은 오로지 그 땅 주인 마음이다.
이렇게 명확하게 영역을 구분하여 선을 긋는 땅따먹기(?)를 하면 니땅 내땅을 주장하며 싸울 논란의 여지도 없고, 좁은 땅을 좀 더 효율적으로 구분하여 사용할 수 있게 된다. 애매한 공간은 필요한 다른 사람에게 주고, 필요없으면 다시 땅을 팔아도 된다.
사실상 위처럼 설계 계획을 세웠다면, 이제 나머지는 표에 맞게 구축하는 것만 남았다. AWS 콘솔 > VPC 메뉴로 가서 VPC 를 생성해보자.
생성할 리소스 : VPC만
"VPC 등"을 선택하면 서브넷 등 필요한 요소를 한꺼번에 설정하고 생성할 수 있도록 도와주는데, 문제는 내가 잘 모르는 부분까지 AWS 가 알아서 구축해준다는 점이다. 결국 구성하는 내가 잘 모른다면, 나중에 디버깅해야할 때, 어떤 부분에서 문제가 생겼는지 파악하기가 어렵다. 때문에 나는 수동으로 하나하나 설정을 했다.
위의 설계도에 따라 이름태그, IPv4 CIDR, 태그(Name) 등을 기입한다.
VPC가 내 집을 만들기 위한 토지를 확보하는 과정이라면, Subnet은 집을 짓고 방을 만드는 과정이다. 집에 아무리 넓어도 공간을 효율적으로 분리해야 프라이버시도 보존하고, 많은 사람들이 더 효율적으로 살 수 있다.
역시 위의 설계도에 따라 Subnet 을 생성한다.
서브넷을 생성하면서 가용영역(availability zone) 역시 같이 설정하는데, 보통 시스템의 안정을 위해 다양한 가용영역에 서브넷을 분산하여 만들어둔다. 보통은 A-C, B-D를 페어링하여 구성하는 것 같다.
우리는 A와 C 영역에 public subnet 1개씩을 만들고, A영역에 Bastion 서버가 위치할 public 서브넷, 데이터베이스가 위치할 private 서브넷을 하나씩 만들었다. 역시 위의 설계도에 따른 것이다.
VPC에서 토지를 확보하고, Subnet 으로 집 내부의 방을 나눴다면, IGW 는 집에서 바깥세상으로 향하는 문을 만드는 것과 같다는 생각을 했다. 외부로부터의 모든 요청들, 외부로 향하는 모든 요청들은 바로 이 IGW 를 통과한다.
Nat gateway 는 igw 와 연결되어 내부에서 외부의 인터넷망을 쓸 수 있도록 해주는 것이다. public subnet 에 위치하며, private subnet 이 이와 연결되면, nat gateway -> public subnet -> igw -> internet 까지 접속이 가능해진다.
라우터 테이블은 택배기사분이 경비실에서 목적지를 찾는 과정 같다는 생각을 했다. 사용자로부터 전달된 소포(패킷)을 가지고 있는 택배기사님은 어디쪽으로 전달되어야할지 아파트의 정확한 동과 호수를 경비실에서 한번 확인한다. 경비실에서는 정확한 위치가 파악되면, 그 위치를 알려주되, 위치를 모르겠다면, 그냥 경비실에 맡겨주도록한다.
아파트 주민이 택배를 보낼 때도 마찬가지이다. 아파트 주민은 서로 간의 거래라면 당근 직거래처럼 직접 만나서 소통하고 교환할 수 있겠지만, 외부의 사람들과 거래해야할 때면, 아파트 경비실에 맡겨둔다. 경비아저씨가 세상 바깥으로 그 물건을 전달해준다.
public rt 에는 public subnet 2개와 igw 를,
bastion rt 에는 bastion 용 public subnet 1개와 igw 를
그리고 내부망을 위한 internal rt 에는 priavet subnet 1개와 nat gateway 를 연결해준다.
보안그룹은 말 그대로 우리 인프라에 대한 보안정책을 설정하는 곳이다. 예전에는 네트워크 ACL처럼 서브넷 단에서도 보안정책을 생성했다고 하는데, 이 보안정책이라는게 복잡하게 구성하면 한도끝도 없어지는지라, 요즘에는 그냥 서버 단위로 정책을 설정하는 것이 일반적이라고 한다.
설계도에 맞게 구성한다.
보안그룹을 설정할 때, 보통은 특정 프로토콜, 포트, IP 를 허용할 것인지 설정하도록 되어있는데, 이렇게 IP 주소를 기반으로 할 경우에는 서버의 대수가 늘어날 때마다 계속 추가 설정해주어야 하는 불편함이 있다. 이때 우리가 보안그룹을 기반으로 설정하면, 보다 간편하게 설정이 가능하다.
예를 들면 위와 같은 식이다.
bastion server의 보안 정책인 mhson-sg-bastion 은 이미 서버와 연결되어있다.
즉, mhson-sg-bastion 와 연결된 bastion 서버의 private ip 주소를 기반으로 하는 트래픽은 public server 에 허용된다는 것이다.
따라서 bastion 서버의 private ip 를 통해서 public 서버에 접근할 수 있다는 말!
그래서 나의 public server 보안그룹 mhson-sg-public 은 아래와 같은 보안 규칙을 가지고 있다.
ICMP 와 SSH 는 bastion 서버에서만, user 들이 접속하는 포트는 80과 443만 전체 대역대로 허용
다만 한 가지 주의할 점은 private ip 를 기반으로 처리되기 때문에 AWS 리소스만 추가할 수 있고, 외부 리소스, public ip 는 사용 불가하다는 점이다. aws 서비스만 소스에 그룹을 넣어 반영이 가능하다. 외부 ip의 경우는 적용이 되지않는다.
서버는 아래와 같이 구성하도록 하자.
이름 : 미리 설계도에서 네이밍 해둔대로 적는다.
어플리케이션 및 OS 이미지 : 우분투 22.0 버전, 64비트 선택
인스턴스 유형 : git 과 연동하여 어플리케이션 운영해야하므로 t3.medium 으로 생성
키페어 : 미리 생성해준 PEM 키 선택
네트워크 설정
적절한 VPC, 서브넷 선택
퍼블릭 IP 자동할당 비활성화
방화벽 (보안그룹) : 기본 보안그룹 중 서버에 맞게 선택
스토리지 구성 : 30GB까지는 프리티어 요금제로 사용 가능하다.
지금은 고급 세부정보를 건드리지 않지만 종료나 삭제 방지 등 필요한 부분을 나중에 수정할 수 있다.
네트워크 망에서 구성하는 베스천 서버도 그와 비슷한 역할을 한다. 보통 퍼블릭 서브넷 상에 퍼블릭한 서버로 베스천 서버를 구성하고, 베스천 서버를 통해서 다른 서버로 접근할 수 있도록 구성을 한다. 외부에서 서버로 직접 접근하는 것이 아니라 꼭 배스천 서버를 통해서만 접근 가능하도록 하는 것이다.
이렇게 구성하면 대략 아래와 같은 이점이 있다.
보안 설정을 베스천 서버에만 집중하고, 나머지 서버는 베스천 서버를 통해 접근할 수 있도록 하여, 랜섬웨어, 악성 루트킷 등의 피해를 줄인다.
배스천 서버가 공격당할 경우, 이 서버만 재구성하면 되니까, 전체 인프라에 미치는 영향력이 적어지게 된다.
보안상 매우 중요한 22번 포트를 전체 서버가 아니라, 배스천 서버로만 오픈하여 보안 정책을 더 엄격하게 유지할 수 있다.
동시에 서버가 auto scaling 등으로 대수가 늘어나고 확장되더라도 보안 정책에 엄격하게 유지될 수 있다.
서비스 정상 트래픽과 관리자용 트래픽을 구분할 수 있다.
서비스가 DDos 공격을 받아 대역폭을 모두 차지하고 있다고 하더라도 관리자는 22번 포트를 통해 배스천 -> 서버 루트로 접근할 수 있게 된다.
통신 확인은 다음과 같은 과정으로 진행한다.
먼저 bastion 서버(mhson-ec2-bastion-2a)에 ssh + pem key 로 원격 접속하기
mhson-ec2-bastion-2a 서버에서 public 서버인 mhson-ec2-public-2a 로 접속하기
mhson-ec2-bastion-2a 서버에서 private 서버인 mhson-ec2-internal-2a 로 접속하기
bastion server -> public server, bastion server -> internal server 로 접근을 확인하면, 통신 연결 완료!
보안정책대로 잘 처리되는지 확인한다.
만약 SSH 프로토콜로 접속시 오류가 있다면, ping test 를 통해 서버가 정상 운영되고 있는지 확인한다.
디버깅은 보통 아래와 같이 진행한다.
SSH 로 접속 시도
접속되지 않고 터미널이 그 상태로 응답없이 있다면, 취소하고 ping test
ping test 결과, 정상적으로 패킷을 받는다면, 보안 정책상 막힌 것은 아닌지 살펴본다.
pint test 결과, 정상적으로 패킷을 못받는다면, 서버가 running 상태인지 확인한다.
예전에 설정할 때, 분명 보안정책을 보안 그룹으로 설정했던 기억이 있어서 그대로 진행했다. 그런데 접속하려니 계속 오류가 나는 것이 아닌가...? 알고보니 보안그룹 설정에 대해서 제대로 알지 못해서 발생한 이슈였다.
내가 간과한 것은 private ip 였다.
bastion 서버 + bastion 보안그룹 설정을 완료했고
public 서버 설정을 완료한 뒤, public 보안그룹 설정에 bastion 보안그룹을 연결시켜주었다. 따라서 bastion 서버는 pulbic 서버에 접근이 가능하다.
그런데 bastion -> public 으로 접근할 때, private ip 를 기반으로 접근을 해야하는데, 나는 자꾸 public ip 로 접속을 시도해서 접속이 안되는 현상이 있었다.
접속 ip 를 public 서버의 private ip 로 바꾸어주니 정상 접속 할 수 있었다.
PEM 키의 권한이 400보다 너무 오픈되어있다면, 아래와 같이 오류 메시지가 뜬다.
Session Timeout 설정을 하여 일정 시간 작업을 하지 않을 경우 터미널 연결이 자동으로 해제되도록 한다.
보안에도 좋고, 불필요한 커넥션을 끊을 수도 있다는 점도 좋다.
서버마다 쉘 프롬프트를 변경하여 관리자가 Bastion 등 서버를 보다 쉽게 구분할 수 있도록 한다. 실수를 사전에 방지할 수 있다.
서버에 직접 접속하여 작업할 경우, 작업 이력 히스토리를 기록해두어야 장애 발생시 원인을 분석할 수 있다. 감사로그를 기록하고 수집하여 장애 상황을 대비해보자.
첫 회사 재직시절부터 네트워크 망 설계를 할 때, 좀 더 빠르고 직관적인 툴이 없을까 이런 저런 소프트웨어들을 기웃거렸다. 그렇게 여러 곳을 방황하다가 결국 정착한 것은 google 의 서비스이다.
는 단순히 네트워크 망 설계 뿐만 아니라 마인드맵, 조직도, ERD 등 굉장히 다양한 용도로 사용될 수 있는 툴이다. 개인적으로는 인터넷 브라우저 상에서 작업이 가능하고, 여러 명이 동시에 작업할 수 있다는 점, 반응 속도도 (데이터가 일정 수준 이하이면) 꽤 나쁘지 않다는 점, 쉽게 요소를 추가하고 삭제하는 것이 가능하다는 점, 그리고 AWS 관련 서비스 아이콘들을 제공해준다는 점 등 다양한 이점 때문에 이 툴을 초기 인프라 설계할 때나 데이터 베이스 모델링 할 때도 사용하고 있다. (강추...👍)
이때, public server 인 mhson-sg-public 을 구성할 때, 만약 bastion 서버의 보안정책인 mhson-sg-bastion 를 선택한다면, .
베스천(bastion) 이라는 단어는 원래는 보루, 요새라는 뜻으로, 중세 시대에 영주나 왕이 살고 있는 중요한 기지인 성을 둘러싸고 있는 방어막을 의미한다고 한다. ()
에 따르면 보안그룹으로 보안정책을 설정할 경우, 접근은 연결된 리소스의 "Private IP"를 기반으로 허용이 된다.
