서버 구축은 정글 입학 시험 때 한 번 해보게 된다.
그때는 가이드라인을 거의 그대로 따라가면 완성할 수 있기 때문에 정말 수월하게 서버를 구축할 수 있다.
하지만, 사설망이라고 하더라도 팀원들이 쓰는 서버, 더 나아가 배포용으로 쓸 서버를 잘 구축할 수 있을지 걱정이 된다.
프로젝트를 위해 조달된 aws서 조달?된 돈이 있기 때문에 돈 걱정은 덜하면서 서버 구축을 시작할 수 있다.
EC2
우선 프론트는 우분투 및 t3 micro 인스턴스를 쓸 예정이고
vpc도 따로 구축해서 쓸 예정이다.
앞선 포스트가 완성되지 않았음에도 고찰을 해야겠다고 생각하게 된 결정적 계기는 네트워크 설정 때문이다.
네트워크 설정
VPC
VPC부터 어려웠다.
VPC는 Virtual Private Cloud의 퍼블릭 클라우드 환경에서 제공되는 사용자 전용 가상 네트워크 공간이라고 한다.
서로 격리된 네트환경이라는 부연 설명이 있기 때문에 가상 메모리와 접근 방향을 비슷하게 하지 않아도 될까 생각했다.
그리고 이 VPC를 생성할 때 기본값을 쓸 수도 있고, 새로 생성할 수도 있는데, AI는 새로 생성하는 걸 추천했다.
보안을 위한 프라이빗 서브넷 구축 때문에 새 VPC 생성을 해야하나보다.
서브넷에 대한 개념은 후술하도록 하겠다.
이후 고려할 것은 CIDR 블록이다.
이 블록은'IP 주소/서브넷 마스크 비트 수'로 구분되는데
IP 주소는 0.0.0.0부터 255.255.255.255까지이므로 즉, 총 8비트씩 4번 총 32비트가 들어갈 수 있고, 서브넷 마스크 비트수는 뒤에서 할당되는 비트로
예를 들어 10.0.0.0/16이라고 돼 있으면
10.0.0.0부터 10.0.255.255까지 쓸 수 있고,
10.0.0.0/24라고 돼 있으면
10.0.0.0부터 10.0.0.255까지 쓸 수 있다.
따라서 서브넷 마스크 비트 수가 16이면 대략 6만5천개 (256 * 256), 24면 256개의 주소를 쓸 수 있다.
그 다음으로 정하는 것은 테넌시인데 자원 격리와 관련이 있다고 한다.
싱글 테넌시는 자원을 물리적으로 격리하는 것 같고 멀티 테넌시는 논리적으로 격리하는 것 같다.
보안 정책과 관련하여 높은 보안 수준이 요구되면 싱글 테넌시를 선택하는 듯하다.
서브넷
네트워크 설게에서 VPC 내부 IP 주소를 더 작게 나누는 단위라고 한다.
서브넷을 나누는 이유는 다음과 같다.
그리고 서브넷에는 퍼블릭과 프라비잇이 있는데, 퍼블릭은 외부 인터넷과 통신 기능이 있지만, 프라이빗은 내부 네트워크 전용으로 외부와 직접 통신이 불가하다.
그리고 AI가 추천하길
Bastion Host, 로드 밸런서용, 백엔드, 데이터 베이스 용으로 4개 만들라고 한다.
'복잡한 게 아니라, 표준'이라고 한다.
호되게 혼났다.
아무튼 public 2개(Bastion Host, 로드 밸런서),
private 2개(백엔드, 데이터 베이스)를 만들었다.
각 서브넷 설정마다 차이점이 있다면 CIDR이다.
비슷한 역할의 서브넷마다 IP주소가 256개씩 차이가 나도록 하는 것 같다.
-
그리고 현재 만들고 있는 인스턴스는 외부와 통신이 가능한 인스턴스이기 때문에, 퍼블릭 IP 자동할당을 체크했다.
보안 그룹 및 네트워크 구성 설정들은 AI가 추천하는 대로 수정했다.
이로써 프론트 서버 구축이 완료됐다.
백엔드 서버도 비슷하게 만들었다. vpc도 동일하게 설정하고 키페어도 같은 것을 사용했다
다만, 인스턴스의 사양이나 서브넷 주소, 보안 그룹, public ip 자동 할당 해제 등 차이가 있다.
끝난줄 알았으나
라우팅 테이블에서 라우팅을 편집해야 했다.
인터넷 게이트웨이를 추가하고 이를 VPC에 연결한뒤
라우팅을 편집해서 대상에 0.0.0.0/0을 추가한다.
이제 만들어진 rsa 키를 가지고
ssh -i [키 페어] ubuntu@[public ip 주소(인스턴스 확인)]
이런 식으로 접속한다.
질문이 나오면 yes를 치고
만약 키가 개인키가 아닐 경우에는
chmod 400 [키 페어] 하면된다.
[키 페어]에는 키를 그냥 끌어다놓아도 된다.
그렇게 해서 구성한 첫 번째 구조.
그런데 백엔드 서버와 통신해야하는 리액트 네이티브를 고려하지 못해서 이 구조는 탈락이다.
그래서 현업에서는 어떤 방식을 쓰냐고 물어봤더니
1. API 게이트웨이 + MSA 방식
2. API 게이트웨이 + ASW Lambda
이 두 방식을 쓴다고 한다.
구현하다보니 구조는 많이 바뀌게 되었다.
RDS
RDS는 aws에서 DB를 구축할 수 있는 서비스로 관계형 데이터베이스만 가능하다.
데이터 베이스를 선택하면 아래에 우리가 흔히 알고 있는 DB 설정이 나타난다.
DB 클러스터 식별자는 정말 유일한 이름으로 지정해줬던 것으로 기억한다.
얘도 EC2처럼 객체를 만들어줘야 하는데
아마도 버스터블 클래스가 가장 싼 인스턴스를 가지고 있던 것으로 기억한다. 나는 버스터블이라는 이름을 보고 굉장해보이는 이름이라 생각해서 가장 비쌀 것이라 생각했는데 아니었다.
아무튼 이 인스턴스는 기존의 EC2 백서버와 연결돼야하므로
EC2 컴퓨팅 리소스에 연결을 선택하고 선택한 EC2에 따라 선택할 수 있는 VPC 또한 달라진다.
ALB
load balancer는 클라이언트에서 온 요청에 맞게 트래픽을 분산시켜주는 서비스이다. 어떤 프로토콜과 어떤 포트에서 왔는지에 따라 리스너 및 규칙을 설정할 수 있다.
이 로드밸런서는
VPC의 경계와 VPC의 내부에서 동작할 수 있는데,
api를 백서버 1대만 있는 상황에서
지금 우리팀이 사용하는 로드밸런서는 사실상 프록시 역할만 하고 있다.
오토스케일링을 사용하게 된다면 상황이 바뀔 수도 있지만 아직은 계획에 없다.
그 밖에 VPC나 보안 설정은 늘 하던대로 하면된다.
S3
이번 프로젝트에서 버킷은 크게 두 가지 용도로 사용되었다. 첫 번째는 정적 웹사이트를 클라이언트에게 전달하는 용도이고, 두 번째는 이미지나 비디오 소스를 저장하는 용도이다.
버킷에서 중요하게 살펴볼 것은 하나이다.
이 퍼블릭 액세스 차단 설정인데, 외부 접근 가능 여부에 대해 다루고 있다. 보안, 개인 정보 보호 등의 이유로 퍼블릭 액세스를 차단한 형태로 버킷을 생성하는 것이 일반적이지만, 웹사이트를 전달할 때는 액세스 차단을 풀어야 한다.
Cloud Front
클라우드 프론트는 CDN(content delivery network)로 일종의 캐시 서버이다. S3만으로도 웹사이트를 전달할 수 있지만 https, 캐싱, 보안 등의 지원이 어려워지기 때문에 일반적으로 cloud front를 통해 전달한다.
또한 로드밸런서처럼 경로 패턴에 따라서 어떤 동작을 허용하고 실행할지 정할 수 있다.
https와 같은 프로토콜의 경우에는 domain을 구매해야만 사용할 수 있기 때문에 명심하자.
원본에는 S3와 로드밸런서를 연결하고
동작에는 /api나 /socket, 기본값에 따라서 로드밸런서 혹은 S3로 연결해야 한다.
또한 캐시 서버이기 때문에 데이터를 바꾼다고 해서 캐시 서버의 데이터들이 바로 바뀌는 것은 아니므로 빠른 수정이 필요하다면 무효화를 이용하여 캐시 서버의 데이터를 변경할 수도 있다.
