아키텍처 구성
지난 항해99 실전 프로젝트에서 적용했던 아키텍처 구성은 아래와 같다.
로드밸런서 역할로 ELB - 그 중에도 Application Load Balancer 로 설정하기 위해 여러가지 내용을 참고했는데, 생각보다 정말 오래걸렸다. 그 과정을 다시 기록해보려 한다.
네트워크 구성
로드 밸런서를 설정하려면 VPC를 우선 설정해야되는데, 이번 프로젝트에서 설정한 내용은 아래 4가지이다.
- VPC
- n개의 서브넷
- 1개의 라우팅 테이블
- 인터넷 게이트웨이
VPC
VPC는 아마존에서 제공하는 서비스인 동시에, VPC는 설정해야할 항목 중에 하나이기도 하다. 아마존에서 제공하는 설명을 보면 아래와 같다.
Amazon Virtual Private Cloud(VPC)를 사용하면 AWS 클라우드에서 논리적으로 격리된 공간을 프로비저닝하여 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다.
논리적으로 격리된 공간을 프로비저닝 한다는 것이 핵심이다. 리전별로, 계정별로 각 ec2는 분리된 것 처럼 보인다. 하지만 아마존의 서버에서는 바로 옆집에 살고 있을 수도 있다. 같은집에 방만 나누어 쓸수도 있다. 논리적으로 공간을 격리하여, 다른 사용자가 내 서버에 곧장 들락거릴수 없게 막는 것이다.
설정은 아래와 같이 진행했다.
유저가 입력할 부분은 이름 태그부분과, IPv4 CIDR 블록 수동 입력 항목이다.
IPv4 CIDR의 정의를 찾아보면 아래와 같이 설명하고 있다.
CIDR 블록은 IP의 범위를 지정하는 방식입니다. CIDR 블록은 IP 주소와 슬래시(/) 뒤에 따라오는 넷마스크 숫자로 구성되어있습니다. 이 숫자는 IP 범위를 나타냅니다.
스크린샷에서 지정한 것과 같이, 172.31.0.0 을 /16 으로 지정하면 범위가 아래와 같이 지정된다.
172.31.0.0 ~ 172.31.255.255
이렇게 지정한 IPv4 CIDR 블록은, 4개의 가용 영역(AZ)에서 4갈래로 나눠가질 예정이다. 외부 인터넷에서 접속 가능하도록, 사설망 대역에 연결가능하도록 아래 IP들 중에서 하나로 설정하자.
사설망 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
서브넷
VPC를 사용하기 위해 반드시 서브넷이 필요하다. 어느 가용 영역(AZ)에 EC2 인스턴스를 위치시킬 지를 저장하는 것이라고 보면 된다.
아마존에서는 서브넷을 2개 이상 둘 것을 권장하고 있다. 서울 리전은 현재, A~D까지의 지역을 지원하고 있는데, 이는 재해 대응을 위해 물리적으로도 구분되어 있다고 한다. 어느 한 쪽이 어떠한 문제로 서비스되지 못할 때, 다른 지역에 올라와있는 서버가 대신 버텨줄 것이다.
서버를 아마존이 대신 관리해주고 클릭 몇 번으로 서버를 구성하고 추가하고 제거하는 것은, 장점이기도 하지만 마냥 장점이기만 하지는 않다고 생각이 든다. 과거 아마존의 내부 DNS 오류로 국내 주요 서비스들이 접속되지 않는다거나, 전세계가 아마존 서버 이슈로 서비스가 중단되는 상황은 솔직히 정말 무서웠다. 서비스를 하는 입장에서 무엇을 할 수 있을까?
서브넷 설정은 아래와 같이 진행한다.
위에서 설정한 vpc를 선택하고, 서브넷 이름을 정해준다.
하단의 가용 영역을 선택한다. 현재 운영중인 서버는 ap-northeast-2 (서울) 리전에 속해있으므로, 4개의 가용 영역이 있다. 그중에서 a, c로 설정해보겠다.
IPv4 CIDR 블록은 172.31.0.0/20 으로 설정한다. 이 경우 IP대역은 아래와 같이 받게된다.
172.31.0.0 ~ 172.31.15.255 까지의 내부망 IP수 4096개를 할당할 수 있게 된다.
이후 서브넷을 동일한 방식으로, c영역까지 만들어 주어 하나의 VPC에 두 개의 서브넷을 생성하면 된다.
라우팅 테이블
라우팅 테이블은 실제로는 서브넷과 연결된다. 하지만 VPC에도 연결이 되어있는데, 여기에 연결된 라우팅 테이블이 VPC에 속한 서브넷을 생성할 때 서브넷과 자동으로 연결된다.
라우팅 테이블은 기본적으로 하나의 룰을 가지고 있고, 이는 VPC 내부에서 VPC 내부의 다른 자원을 찾을 때 사용하는 규칙이다.
라우팅 테이블이 VPC, 서브넷과 연결된 걸 확인할 수 있다.
라우팅 테이블 생성을 눌러 생성을 시도해보자.
상대적으로 간단하다. 이름을 입력하고, VPC만 위에서 설정한 것으로 연결하면 된다.
인터넷 게이트웨이
외부 접속이 가능하게끔 인터넷 게이트웨이를 설정해야한다. 이 과정을 빼먹고 할 경우, EC2 인스턴스 생성은 가능하지만 Git Bash 등으로 원격 접속이 불가하다.
마찬가지로 이름을 설정하고 완료하면 된다.
여기서 끝내면 안되고, 위에서 만든 라우팅 테이블로 다시 가서 외부 인터넷을 열어주는 작업이 필요하다. 왼쪽 메뉴에서 라우팅 테이블을 눌러, 만들어둔 라우팅 테이블을 선택한다.
선택하여 들어와보면, 하단에 라우팅 항목에 0.0.0.0/0 항목이 없다. 라우팅 편집 버튼을 눌러 추가한다.
첫번째 입력란에 0.0.0.0/0 을 설정하고, 두번째 입력란에 인터넷 게이트웨이를 선택하면 자동으로 igw- 가 붙고, 생성해둔 인터넷 게이트웨이가 보인다. 그것을 클릭하여 추가하고 변경 사항 저장을 눌러 빠져나온다.
로드밸런서 설정
로드밸런서 설정을 위해 시작한 글인데, 중반부가 되어서야 나왔다. 위에서 설정한 모든 것들이 필요하기 때문이다.
타겟 그룹 설정
미리 만들고 가면 매우 편하다.
어느 EC2가 로드밸런서에 붙어 부하를 분산시킬 지 정하는 것이다. 여기에 설정하는 타겟 그룹으로, 추후 설정할 Auto scaling에도 활용할 수 있다.
인스턴스를 대상으로 타겟 그룹을 삼을 것이므로, Instances 를 선택한다.
ALB가 인스턴스들의 어느 웹서버 주소와 연결될 지를 정하는 것이다. 각 인스턴스에 띄우는 웹서버들은, 3000->80 포트로 포트포워딩 되어있고 http 구성이므로, HTTP : 80을 그대로 유지한다.
인스턴스의 웹서버가 살아있는지 체크하는 경로이다. 기본 경로에 간단하게 hello world 메시지를 뿌리게 되어있어, 기본 경로로 둔다.
이 타겟 그룹에 속할 인스턴스를 고르는 페이지다. 기존에 띄워둔 인스턴스가 있다면 연결하고, 아닌 경우에 그대로 넘길 수 있다.
로드 밸런서 생성
이 모든 과정을 거쳐야 로드 밸런서를 막힘없이 생성할 수 있다.
2022년 4월 신 콘솔 기준, 로드밸런서 생성 > Application Load Balancer를 선택한다.
이름을 정하고, 기본 설정은 그대로 둔 채 진행한다.
네트워크 매핑에서, 위에서 설정한 VPC를 고르면 하위에 서브넷 목록에 정한 AZ들이 보인다. 각각 체크박스 선택하면, 각 서브넷이 활성화 된다. ap-northeast-2a, ap-northeast-2c 모두 체크박스 선택하자.
보안 그룹은 기존에 설정한 게 있다면 그것을 사용하거나, 로드 밸런서 용으로 새로 생성할 수도 있다. 리스너는 http:80 포트를 우선 유지한다.
로드 밸런서에 HTTPS 적용
https를 Route 53을 이용해 설정하고, 가비아를 통해 도메인을 구입한 경우, 아래 글을 참고하여 Route 53과 도메인을 연결하고 와야한다.
위의 과정을 통해 ELB 레코드를 생성했다면, 아래와 같이 설정할 수 있다.
HTTP:80을, HTTPS:443 으로 Redirect 시킨다.
HTTPS:443은, 타겟 그룹을 위에서 생성한 로드 밸런서 - 타겟 그룹으로 포워딩한다.
ELBSecurityPolicy는 2016-08 기본을 골라주고, 하단의 SSL 인증서를 Route 53과 ACM 에서 생성한 인증서로 연결해준다. 같은 계정을 사용했다면 선택할 수 있다.
이로써 ELB에 HTTPS 연결까지 완료하였다.
CodeDeploy 배포를 위한 로드 밸런서 설정
앞서 설정했던 CodeDeploy 배포는, 특정 인스턴스만을 대상으로도 할 수 있지만 ELB에 연결된 EC2들 대상으로도 지정할 수 있다.
기존에 설정한 CodeDeploy - 배포 그룹을 선택하고, 편집을 선택한다.
최하단에 로드밸런서를 활성화 하고, Application Load Balancer 라디오 버튼을 선택한 뒤 그룹을 지정하면 된다.
OneAtATime으로 설정했으므로, 로드밸런서가 차례로 특정 인스턴스의 트래픽을 막은 후 하나를 배포한 후, 띄워진걸 확인하면 다음 인스턴스에 배포하게 된다.
설정 끝!
참고 URL
핵심사항 참고
DevOps 안내서 - AWS 배포하기
기본 개념잡기, 이 아키텍처 구성을 왜 하는지 이해하는데 정말 도움 많이됨.
AWS 환경에서 node 앱 https 서비스 하기
기본 뼈대 아키텍처를 많이 참고. 설정법은 다소 단순하게 설명.
Scale-up과 Scale-out에 대해 알아보자!
아키텍처를 위와 같이 구성하게 된 이유.
개념 잡기
만들면서 배우는 아마존 버추얼 프라이빗 클라우드(Amazon VPC)
VPC 에 대한 이해 잡기.
Amazon Web Service Network 쉽게 이해하기
AWS 서비스 전반에 대한 설명.
AWS 아마존 웹서비스 가입부터 활용까지
2022년 4월 이후로 AWS 관리 페이지 UI가 바뀔 예정이라, 다소 안맞을 수 있음.
따라해보기
[Devops] 가비아-Route53 DNS 설정 및 SSL 적용
1~5.1까지 거의 대부분 따라함. 3의 경우, makehabitapi.shop 이므로 하위 도메인 설정은 하지 않음.
AWS ELB(Elastic Load Balancing) 생성 후 EC2 연동 & 외부 도메인 연동
ELB에 EC2 연동, 외부 도메인 연동하는 상세 스텝.
AWS ELB에 https 적용하기
Route 53 에서 ELB https로 연결할 때 상세 스크린샷 참조.
[aws] CodeDeploy 를 이용해 로드밸런서 환경에서 배포하기
오류 참고.
버그 추적
AWS - EC2 인스턴스에 Public DNS 부여하기
Public DNS 안 나올 경우 설정
ELB 관련 에러 코드
502, 503 에러 모두 겪어봄. 인스턴스와 연결 문제가 대부분임.
