포스트 목적
해당 포스트는 나만의 명언집 프로젝트를 AWS EC2 에 배포하는 과정을 정리하는 것을 목적으로 합니다.
다양한 EC2 배포 포스트를 보았지만, 각 과정에서 해당 명령어의 설명이나 이러한 순서를 지키는 목적 등에 대한 언급이 거의 없었습니다.
이로 인해 왜 그 과정을 거치는지에 대한 이해도 없이 따라만 하기에 급급해질 것 같았기에 최대한 이를 공부하며 지니가자는 마음으로 부연 설명을 곳곳에 적으며 정리하였습니다. 따라서 빠르게 EC2 배포를 진행하고자 하시는 분들이라면 다른 분들의 포스트를 참고하시는 것을 권장합니다.
Route 53 으로 도메인 발급받기
| 이미 도메인이 있다면, 이 과정은 건너 뛰어도 됩니다. 만일 새로 발급받아야 한다면, 이 과정을 따라가며 하나 발급받는 것도 좋을 것 같습니다. |
우선 AWS 사이트의 Route 53 으로 접속하고, 대시보드에서 [도메인 등록] 을 클릭한다.
다음 페이지가 나오면 도메인의 가용성 확인 부분에 사용할 도메인을 입력 후 검색하고 그 중에서 선택하고 고 결제진행을 클릭한다.
이 다음 화면에서 결제 정보 등록 및 제출을 진행하고 나서, [도메인] - [요청] 을 확인하면 도메인 등록이 진행되는 상황을 확인할 수 있다.
그리고 요청이 완료되면, [등록된 도메인] 으로 접속하면 아래와 같이 등록된 상태를 확인할 수 있다.
EC2 생성하기
도메인 등록 후에는 EC2 (쉽게 말해 제3자가 임대 해주는 가상의 컴퓨터) 를 대여해야 한다.
AWS 검색창에 ec2 를 검색하면 아래 화면이 뜨는 것을 볼 수 있다. 그리고, 헤더 상단 우측에 거주하고 있는 국가를 선택하고 [인스턴스 시작] 을 클릭한다.
| 여기서 국가의 설정을 매우 매우 중요하다. 거리에 따라서 EC2를 운영하는데 쓰이는 비용이 극단적으로 차이가 날 수 있다. 왜냐 하면, 선택한 지역에 가까운 데이터센터를 ec2 생성 시 연결해주는데, 거리가 멀수록 이에 따른 비용도 차이가 발생하기 때문이다. 또한 먼 거리로 인한 사용자의 네트워크 요청과 응답 사이에 왕복거리도 멀어지므로 사용자 경험에도 좋지 못할 가능성이 매우 높다. 따라서 한국에서 운영할 것이라면 서울을 선택해주자. |
① 인스턴스 이름(컴퓨터 이름) 설정
해당 인스턴스(가상 컴퓨터)를 식별하는 이름을 입력한다(즉, 컴퓨터에 고유한 이름을 붙여주는 것).
② OS 이미지(운영체제) 선택
그 다음에는 가상의 컴퓨터를 구성하는 운영체제를 선택해야 한다(흔히, 가정에서 컴퓨터를 처음 구입할 때 윈도우를 설치하는 것과 같다). 이는 개인의 편의성에 맞게 선택하면 되는 부분이며, 본인의 경우에는 기본 설정인 아마존 리눅스를 선택하였다.
③ 인스턴스 유형(하드웨어 부품들) 선택하기
인스턴스를 가상의 컴퓨터라고 했을 때 인스턴스 유형은 해당 컴퓨터의 본체를 구성하는 기본적인 하드웨어 구성부품(CPU, 흔히 램으로 불리는 메모리)을 선택하는 것이다. 본인의 경우 프리티어 혜택을 볼 수 있는 t2.micro 를 선택하였다.
④ 키 페어 생성하기
키 페어는 퍼블릭 키와 프라이빗 키로 구성된 키 페어는 Amazon EC2 인스턴스에 연결할 때 신원을 증명하는 데 사용하는 보안 자격 증명 세트이다. 즉, 해당 키 페어를 생성 후 잘 보관해야 EC2 에 접속할 수 있다.
| 컴퓨터를 접속하기 전에 실제 사용자인지 검증하는 비밀번호와 같다(흔히 우리가 컴퓨터를 키게 되면 만나게 되는 사용자 비밀번호를 대신한다). |
우선 기존에 키 페어가 없다면 [새 키 페어 생성] 을 클릭한다.
그 후 키 페어 이름을 작명하고, 어떤 방식으로 키 페어를 발급 받을 것인지 입력한다. 윈도우 환경이라면 .ppk 를 사용하는데, 그 외 운영체제에 맞게 둘 중 하나를 선택하면 된다.
[키 페어 생성] 을 클릭하면, .pem 파일을 다운로드 하는데 해당 파일을 꼭 누구도 볼 수 없도록, 탈취 위험이 없는 곳에 두어야 한다( 본인은 PuTTY 를 사용하기 때문에 .ppk 를 선택했어야 했으나, 설명을 위해 .pem 을 선택했다. 나중에 이를 puttygen.exe 를 사용하여 .ppk 로 변환 할 수 있다)
④ 네트워크 설정
이 부분은 현재 EC2 에 접근 가능한 IP 를 무엇으로 한정할 것인지에 설정하는 것이다.
SSH 는 내부에서 ec2에 접근하여 컴퓨터를 관리할 때 사용하므로 내부 IP 에서만 접근이 가능하도록 설정하고,
HTTP 와 HTTPS 는 외부에서 들어오는 네트워크 통신을 처리해야 하므로 모든 IP에서 접근이 가능하도록 설정해둔다.
⑤ 스토로지 설정 (일명, 하드디스크;HD 설정)
이는 ec2 를 생성하면 딸려오는 하드디스크 즉, 파일 저장소를 설정하는 것이다. 범용적으로 사용되는 gp3 를 선택하고, 좌측의 숫자는 저장소의 크기로 1GB 를 기준으로 입력한다. 예시대로 라면 8GB 를 사용할 수 있는 것인데, 이는 본인 프로젝트의 특성에 따라 더 추가하면 된다.
모두 설정이 완료 되었으면 아래 요약본 확인이 가능하다. 그 후 [인스턴스 만들기] 를 클릭한다.
EC2 접속을 위한 사전 환경 셋팅
EC2 에 접속하기 위해서는 SSH 클라이언트를 연결해야 한다. 이 때 클라이언트 연결 도구는 다양하게 존재하는데, 본인의 경우에는 PuTTY 를 사용할 예정이다. 참고로 Putty 는 오픈소스 터미널 프로그램으로 이해하면 된다.
Q. PuTTY 란 무엇인가?
PuTTY는 Windows 운영 체제에서 사용할 수 있는 SSH (Secure Shell) 클라이언트이다.
참고로 SSH는 원격 서버에 안전하게 연결하고 원격으로 명령을 실행하거나 파일을 전송하는 데 사용되는 프로토콜이다.
Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스 또한 원격 서버이므로 PuTTY를 사용하여 EC2 인스턴스에 접속할 수 있다.
① PuTTY 설치하기
우선 putty 공식 사이트에서 아래 PuTTY.exe 파일을 설치한다. 만일 링크가 열리지 않는다면, https://www.chiark.greenend.org.uk/ 여기로 접속해서 다운로드 페이지를 찾아보자(쉽게 찾을 수 있다)
설치 후 .exe 파일을 실행하면 다음 화면을 바로 볼 수 있다.
② .pem 을 .ppk 로 변환해주는 PuTTYgen.exe 설치하기(처음 부터 .ppk 로 받았으면 필요 없음)
그리고 만일 PuTTY 를 사용하는데 .pem 을 선택한 경우에는 PuTTY 에서는 .ppk 만 인식할 수 있으므로 기존 키를 해당 키로 변환시켜주는 putty.exe 파일을 설치해야 한다.
③ .pem 파일을 .ppk 로 변환하기
앞서 발급 받은 키 페어(.pem)을 .ppk 형식으로 바꿔주기 위해 해당 파일을 실행한다. 실행하게 되면 아래 화면이 보이는데 순서대로 [Conversions] 탭을 클릭하고 .pem 파일을 import 해온다.
그 후 save private key 를 선택하여 해당 키를 저장한다. 이 때 경고 메시지가 뜨는데 그냥 넘어가면 된다.
다음에는 SSH 클라이언트에 접속하기 위한 과정을 언급한다.
SSH 클라이언트 접속하기
① putty.exe 파일 실행하고, Host Name(or IP address) 입력하기
앞서 putty.exe 파일을 설치하고 실행하면 다음 화면을 볼 수 있을 것이다.
여기서 Host Name 의 경우 앞서 우리가 생성한 인스턴스의 Public IP 주소를 입력해야 한다.
이 때 해당 Public IP 주소는 EC2 인스턴스 페이지에서 인스턴스를 클릭하면 하단에서 확인할 수 있다.
중요한 사항은 해당 IP주소 앞에 ec2-user@를 꼭 넣어주어야 한다.(ex. ec2-user@123.53.22..)
② SSH -> AUTH -> Credential 탭에서 .ppk 파일 등록하기
앞서 변환한 .ppk 파일을 다음 경로로 접근하여 Private Key file for authentication 에 입력한다.
여기 까지 하면 모든 설정이 끝났다. 만일 이때 까지 설정한 옵션들을 저정해두고 싶다면 , Session 탭에서 Save Sessions 에 식별할 이름을 입력하고 Save 를 클릭하면 저장된다.
그 후 Open 을 클릭하면 다음 화면이 뜨는데, 이는 최초 접속으로 인해 host key 가 캐시되어 있지 않다고, 이를 캐싱처리 할 것인지 묻는 것으로 Accept 를 클릭하고 넘어가면 된다.
[참고] 만일 터미널에 자동 로그인 하고자 한다면?
만일 별도의 username 입력 없이 바로 SSH 터미널에 접속하고자 한다면, data 탭의 auth-login-username 에 작명해두면 된다. 보통 운영체제에 따라서 관습에 따른 유저이름이 다르다고 하는데, 본인의 경우에는 ec2 를 사용하므로 아래와 같이 지정했다.
[참고] 만일 변환 이후 키가 인식이 안 된다면?
EC2 대시보드의 스크롤 메뉴 하단에 [키 페어] 를 클릭하면 새로운 키 페어를 생성할 수 있으므로 거기서 호환되는 키의 확장자를 선택하여 사용하면 된다. (만일 이래도 안 된다면, 과감하게 ec2 를 새로 생성하자. 이미 지나왔던 길이라 얼마 안 걸린다)
③ SSH Root 사용자로 접속 및 운영체제 및 관련 종속성 등 기타 환경설정
앞서 과정을 잘 따라 왔다면, 아래 커맨드 창이 뜰 것이다.
root 권한 사용자 접속 및 ec2 운영체제의 종속성 파일 업데이트
여기서 root 권한을 가진 사용자로 접속하기 위해서 sudo su 를 입력한다.
그 후 접속한 EC2 에 운영체제와 관련한 종속성 파일을 업데이트 하기 위해서 sudo yum update -y 를 입력한다.
서버 타임존 변경
그 다음에는 인스턴스에 설정된 시스템의 시간 포맷을 한국 시간으로 바꾸기 위하여
sudo vi /etc/sysconfig/clock 을 입력한다.
이 때, 편집창으로 변경되면서 ZONE = "UTC" 가 입력된 것을 볼 수 있는데, 해당 편집창에서 키보드 ' i ' 키를 입력하면, 데이터를 편집할 수 있게 된다. 그리고 앞서 UTC 를 서울 기준 "Asia/Seoul" 으로 바꿔주며, 그대로 ESC 키 → 문자로 :wq 입력 하여 나온다. 참고로 :wq 는 저장하고 편집창을 종료한다는 의미이다.
NodeJS 설치 등의 프로젝트 셋팅을 위한 환경 설정 마무리
nvm 설치
현재 프로젝트에 사용되는 nodejs 버전이 차이가 나는 경우 예기치 못한 문제가 발생할 수 있으므로 기존 프로젝트에서 사용하는 특정 노드 버전을 설치해야 한다(물론 필수는 아니지만 권장사항이다).
이를 간편하게 수행할 수 있도록 해주는 nvm 을 설치하도록 한다. nvm 의 버전 유무는 nvm 공식 깃허브에서 확인할 수 있다.
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
여기서 nvm 이 정상적으로 설치되었는지 확인하려면 ls -a 명령어를 입력하면 된다. 그러면 아래와 같이 .nvm 이 있는 것을 확인할 수 있다.
nvm 관리를 위한 쉘 실행
해당 명령어를 실행하면 사용자의 루트 디렉토리에 있는 .nvm 폴더 안에 있는 nvm.sh 을 실행한다는 의미이다. 해당 명령어를 입력할 때 중요한 점은 ' . '(마침표) 와 ~(물결표) 사이에 공백(스페이스바 1칸)이 존재한다는 점이다.
참고로 여기서 . 다음에 공백을 두는 이유는 . (공백) 파일.확장자 형식일 때 현재 경로에 지정한 확장자를 가진 파일을 실행한다는 예약어이기 때문이다.
따라서 아래 명령어를 입력하면 ~ (루트 경로에서) / .nvm 폴더에 들어간 후 . (실행한다) nvm.sh (파일을) 이라는 의미로 해석할 수 있다.
. ~/.nvm/nvm.sh
앞서 설명한 예시와 마찬가지로 아래와 같이 cd 명령어를 사용하더라도 해당 폴더에 접속 후 nvm.sh 파일을 실행할 수도 있다.
참고로 nvm.sh 을 실행해도 커맨드 화면에서는 아무런 변화가 없을 것이다. 하지만 정상적으로 실행되고 있는 것이니 그대로 진행하면 된다.
[쉬어가보자] nvm.sh 를 굳이 실행하는 이유
우선 nvm 은 Node Version Manager 의 줄임말이다. 즉, 노드의 버전을 관리하는 패키지 도구인데, 이 때 해당 패키지의 다양한 기능들을 간단한 명령어로 쉽게사용할 수 있도록 하는 스크립트 파일이 nvm.sh 이다.
예를 들어, 해당 파일을 실행하면 다음과 같이 NodeJS 의 버전을 쉽게 관리할 수 있는 명령어를 제공한다.
#!/bin/bash
# Node Version Manager (NVM) 명령어 스니펫
# 1. 지정된 버전의 Node.js를 설치
nvm install 14.17.0
# 2. 지정된 버전의 Node.js를 사용
nvm use 14.17.0
# 3. 시스템에 설치된 모든 Node.js 버전 목록을 표시
nvm ls
# 4. 원격 저장소에서 사용 가능한 Node.js 버전 목록을 표시
nvm ls-remote
# 5. 지정된 버전의 Node.js를 제거
nvm uninstall 14.17.0
# 6. 지정된 이름으로 지정된 버전을 별칭으로 지정
nvm alias default 14.17.0
# 7. 지정된 버전의 Node.js로 지정된 명령을 실행
nvm run 14.17.0 node app.js
현재 프로젝트에 맞는 nodeJS 설치
현재 프로젝트에 사용되고 있는 node 버전은 20.11.0 이므로 해당 버전으로 설치하였다. 아 부분은 본인의 상황에 맞게 버전을 지정하여 설치하면 된다(참고로 자주 사용될만한 nvm 명령어는 위의 쉬어가보자 숨김글에 적어놓았다.).
nginx 설치하기
향후 포트포워딩 및 리버스 프록시를 적용하기 위해 nginx 를 설치한다. 참고로 설치 후 Is this ok 를 y 로 응답해야 설치가 진행된다.
nginx 를 실행할 때는 다음 명령어를 입력하면 된다.
sudo service nginx start
데이터베이스 설치하기
현재 프로젝트에서 사용하고 있는 데이터베이스를 설치한다. 다음은 postgres 를 아마존 리눅스 환경에서 설치할 때 사용하는 명령어인데, 이 부분은 본인이 사용하고 있는 데이터베이스의 설치 방법을 찾아서 설치하면 된다.
sudo yum install postgresql postgresql-server
만일 특정 버전의 postgres 를 설치하려면 다음과 같이 버전명을 패키지명 뒤에 붙여주면 된다.
sudo yum install postgresql15
sudo yum install postgresql15-server
참고로 현재 설치된 posgresql 의 버전을 확인하고자 한다면 다음과 같이(psql -V) 입력한다.
데이터베이스 셋팅하기(postgres 기준)
앞서 데이터베이스 설치가 끝났으면 ec2 에서 데이터베이스를 사용할 수 있는 환경을 설정해주어야 한다.
| 쉽게 말해, 로컬 환경에서 postgres 아이디로 접속할 때, 비밀번호를 입력하고, 호스트 주소와 프로젝트를 연결했던 그 일련의 과정을 여기서도 똑같이 진행해주는 것이다. 차이가 있다면 리눅스 환경에서 커맨드로만 조작해야 한다는 점 |
데이터베이스 초기화 하기
먼저 데이터베이스를 바로 사용할 수 있게 초기화 해주어야 한다. 이 작업을 진행해야 postgres 를 현재 운영체제 환경에서 정상적으로 실행될 수 있는 기본설정이 자동으로 이루어진다.
sudo /usr/bin/postgresql-setup --initdb
참고로 bin 폴더의 위치로 와서 ls p* 이라고 입력하면 문자 'p' 로 시작하는 모든 파일을 조회한다. 여기서 postgresql-setup 이라는 파일이 보이는데, 해당 파일을 실행할 때 --initdb 라는 유틸리티 옵션을 붙이면 자동으로 postgresql 의 데이터베이스 클러스터를 설정하고 초기화하는 동작을 수행한다.
| 데이터베이스 클러스터는 데이터베이스를 구성하는 여러 개의 데이터베이스 서버 인스턴스로 구성된 그룹을 의미한다. 이는 데이터베이스 관리자가 직접 그 구성을 설정할 수도 있는데, 여기서 데이터베이스 클러스터를 초기화한다는 것은 데이터베이스를 실행하기 위한 기본이 되는 설정으로 지정한다는 의미이다. |
데이터베이스 연결을 위한 기본 설정 변경하기(연결 주소와 포트 주석 제거)
이제는 postgres 서버와 ec2 와 연결하기 위해서 기본으로 설정된 postgres 의 구성 설정을 변경해줘야 한다. 해당 구성에 대한 파일은 /var/lib/pgsql/data/postgresql.conf 로 접근하면 되는데,
vi /var/lib/pgsql/data/postgresql.conf
아마 이 경로로 접근하려고 하면 아래와 같이 Permission denied 라고 뜰지도 모른다. 승인 거부라는 의미처럼 해당 경로에 대한 접근 권한이 없다는 것으로 거부당한 것이다.
따라서 이를 해결하기 위해서는 승인의 주체가 되는 관리자 모드로 변경하고 나서 들어가야 한다. 이러한 리눅스 커맨드 환경에서 관리자 권한으로 들어가려면 sudo su 라고 입력한다.
sudo su # 관리자 권한으로 변경
그러면 아래와 같이 ec2-user 라는 사용자 권한에서 root 라는 관리자 권한으로 변경된 것을 볼 수 있다
이 다음 다시 해당 경로로 접근 해보면, 정상적으로 접근 가능한 것을 볼 수 있다. 해당 경로에 접근했으면 해당 파일에 대한 편집을 위해 vi postgresql.conf 를 입력하여 편집화면으로 넘어간다.
.conf 파일의 편집창으로 넘어가면 다음 화면이 보일 것이다(putty 는 왜 검은 바탕에 파란색인가)
여기서 ~ Connection Settins ~ 아래에 보면 listen_address 와 port 부분이 # 으로 주석 처리가 되어 있을 것이다. 이를 아래와 같이 주석을 풀어주고, 나온다.
| vi 편집창에서 편집을 하려면 [ i ] 키를 클릭하고, 변경 후 나오려면 [ ESC ] 키 를 누른 후 [ :wq ] 를 입력하면 저장 후 vi 모드를 종료할 수 있다. |
데이터베이스 접근 가능 호스트 추가
그 다음에 바로 해주어야 할 것은 동일한 경로에 있는 pg_hba.con 파일에 들어가서 추가적으로 접근 가능한 호스트 주소를 하나 포함시켜야 한다.
sudo vi /var/lib/pgsql/data/pg_hba.con
위 명령어로 접속 한 뒤 IPv4 연결 부분의 테이블이 보이는데 노란색 으로 표시한 텍스트를 추가한다.
그 다음에는 데이터베이스 구성에 대한 변경 사항을 반영하기 위해서 데이터베이스를 재시작한다.
sudo service postgresql restart
# sudo : 관리자 권한으로 명령어를 실행한다.
# service : 시스템 서비스(운영체제의 백그라운드에서 실행되는 서비스)를 관리할 때 사용하는 키워드
# postgresql : 관리할 시스템 서비스(타겟)
# restart : postgresql 서비스를 재시작하는 옵션
# -> 해석 : 관리자 권한으로 postgresql 시스템 서비스를 재실행한다.
일단 데이터베이스 환경 설정은 여기서 마무리하고 우선적으로 Nginx 기본설정 파트로 넘어가서 설명한 뒤 데이터베이스 접속에 대해서 다룰 것이다.
Nginx 기본 설정 변경하기
gzip 최적화 및 보안 옵션 적용
기존에 기본값으로 설정되어 있는 http 파트의 server 속성을 제거하고, 다음 값으로 변경해야 한다. 이 옵션은 nginx 가 가용하는 자원의 크기를 제한하여 성능과 비용을 최적화하기 위한 옵션으로 보이는데 해당 블로그의 내용을 기반으로 작성하였다.
gzip on;
gzip_min_length 10240;
gzip_buffers 32 32k;
gzip_comp_level 9;
gzip_types text/plain application/x-javascript text/xml text/css;
gzip_vary on;
server_tokens off;
❓ 각 옵션의 역할에 대해 궁금하다면?
gzip on;: 이 옵션은 Nginx가 클라이언트로 전송되는 콘텐츠를 압축할지 여부를 설정 한다. 압축을 사용하면 대역폭을 절약할 수 있다.
gzip_min_length 10240;: 이 옵션은 Nginx가 압축을 수행하기 전에 최소한의 파일 크기를 설정한다. 이 값은 여러 요인에 따라 조정될 수 있으며, 작은 파일을 압축하는 것이 비효율적일 수 있기 때문에 최소 크기를 설정한다.
gzip_buffers 32 32k;: 이 옵션은 Nginx가 압축 버퍼를 설정하도록 한다. 여기서 32는 버퍼의 개수이고, 32k는 각 버퍼의 크기이다.
gzip_comp_level 9;: 이 옵션은 압축 수준을 설정한다. 값이 클수록 압축률이 높아지지만 CPU 사용량이 더 많아진다.
gzip_types text/plain application/x-javascript text/xml text/css;: 이 옵션은 Nginx가 어떤 유형의 콘텐츠를 압축할지를 지정한다. 여기서는 텍스트, 자바스크립트, XML 및 CSS 파일을 압축한다.
gzip_vary on;: 이 옵션은 Vary 헤더를 포함시켜 캐시된 압축된 콘텐츠를 올바르게 처리할지 여부를 지정한다.
server_tokens off;: 이 옵션은 Nginx 서버의 버전 정보를 숨기는 역할을 한다. 이렇게 함으로써 보안 취약점을 이용하는 공격을 어렵게 만들 수 있다.
[참고] 압축버퍼란?
압축 버퍼는 Nginx가 클라이언트로 전달되는 파일에 대한 압축 작업을 수행할 때 할 때 임시적으로 압축된 데이터를 저장 해두는 메모리 버퍼(데이터 임시 저장소)를 나타낸다.
| 즉, 버스(메모리 공간)를 타기 전에 잠시 머무는 버스 정류소(임시 버퍼)와 같이, 일시적으로 버퍼에 데이터를 저장하여 불필요한 디스크 I/O를 줄일 수 있도록 해준다(만일 버퍼가 없다면, CPU가 처리한 압축 데이터를 디스크에 보관하거나, 메모리의 가용 공간을 일부 가져와서 사용해야 하는데, 이로 인한 성능 저하가 클 수 밖에 없다). 다른 예로, 데이터를 압축하는 작업의 경우 CPU 의 부하를 높이는 행위이기 때문에, 많은 양의 압축 데이터를 클라이언트로 전송하기 전에 잠시 동안 보관해둘 장소가 필요하다. 이 때 압축된 데이터를 임시적으로 보관해두는 공간이 압축버퍼 이다. |
예를 들어, 클라이언트가 요청한 파일이 서버에서 압축되어 전송되어야 하는 경우, Nginx는 해당 파일을 메모리에 읽어와서 압축 작업을 수행하고, 압축된 데이터를 압축 버퍼에 저장한다.
그런 다음에는 클라이언트에게 압축된 데이터를 전송할 때 이 버퍼에서 데이터를 읽어와 전송한다.
참고로, 압축 버퍼의 크기는 gzip_buffers 디렉티브로 설정되며. 일반적으로 두 개의 매개변수가 사용된다. 첫 번째 매개변수는 버퍼의 개수를, 두 번째 매개변수는 각 버퍼의 크기를 지정한다.
http 및 https 에 대한 도메인 설정 및 포트포워딩 적용하기
이 작업은 사실 SSL 발급 및 로드밸런서 등록 이후에 적을 생각이었으나, 또 다시 Nginx 구성 파일에 접근하는 것은 비효율적이라 판단하여 여기서 모든 처리를 미리 해둔다.
우선 다음 명령어를 실행해서 example.con.conf 파일을 생성해준다. 해당 파일을 해당 도메인에 대한 포트포워딩을 설정하는 구성파일로 지정된다.
# 사이트도메인 예시) naver.com
sudo vi /etc/nginx/conf.d/사이트도메인.conf
아래 코드를 붙여넣기 후 도메인 주소를 본인이 발급 받은 것으로 변경해주면 된다. 각 옵션에 대한 설명은 주석으로 달아두었으니 참고해서 적용하면 좋을 듯 하다.
# HTTP 리다이렉트 설정(80포트로 오는 요청을 443 포트로 리디렉트(포트포워딩)
# example.com 을 대체하여 본인이 발급받은 도메인 주소를 입력해줍니다.
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
# 모든 요청을 HTTPS로 리다이렉트
location / {
return 301 https://$host$request_uri;
}
}
# HTTPS 설정(향후 AWS ACM으로 발급받은 SSL 을 적용하는 로직)
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com www.example.com;
ssl_certificate /path/to/ssl_certificate.crt;
ssl_certificate_key /path/to/ssl_certificate.key;
# 모든 요청을 로컬 서버로 프록시(443 포트가 3000 포트의 앞단에서 요청 처리 후 전달 )
location / {
proxy_pass http://localhost:3000;
}
# 클라이언트 업로드 제한
client_max_body_size 10M;
# 보안 및 접근 제한(해당 파일 및 디렉토리에 대한 접근을 거부)
location ~ /\. {
deny all;
}
location ~* \.(log|binary|pem|enc|crt|conf|cnf|sql|sh|key)$ {
deny all;
}
location ~* (composer\.json|composer\.lock|composer\.phar|contributing\.md|license\.txt|readme\.rst|readme\.md|readme\.txt|copyright|artisan|gulpfile\.js|package\.json|phpunit\.xml)$ {
deny all;
}
# 로깅 처리 배제
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
log_not_found off;
access_log off;
}
location = /sitemap.xml {
log_not_found off;
access_log off;
}
}
위 코드를 참고하여 변경하였으면 [ESC ] - :wq 를 입력하고 나온 뒤 다음 명령어를 입력하여 nginx 를 재시작해준다(변경 사항을 반영하기 위함)
sudo service nginx restart
데이터베이스 접속하기(postgresql 기준)
데이터베이스 관리자(루트) 계정으로 변경하기
앞서 데이터베이스를 설치하고 나면 데이터베이스 계정은 기본설정으로 postgres 가 된다. 따라서 관리자 권한으로 해당 데이터베이스 계정으로 변경한다.
sudo su - postgres
변경 후 커맨드 창을 확인해보면 다음과 같이 데이터베이스 관리자(루트) 계정으로 변경된 것을 볼 수 있다.
그 다음 psql 를 입력하면 postgreSQL 로 접속할 수 있다.
psql
데이터베이스 사용자 계정 생성하기
앞서 관리자 계정(postgres)로 변경하였다면, 이제는 데이터베이스의 특정 권한만을 가지고 사용 가능한 사용자 계정을 생성한다. 이 계정은 앞으로도 계속 사용될 것이므로 작명을 잘해두는 것이 좋다.
CREATE USER [username] NOSUPERUSER; # username 영역에 작명해서 입력 후 엔터
ALTER USER [username] WITH PASSWORD '[password]'; # password 를 안전한 값으로 입력 후 엔터
CREATE DATABASE [dbname] WITH OWNER [username]; # dbname 작명해서 입력 후 엔터
만일 psql 을 종료하려면 exit 명령어를 입력하면 된다.
exit
NextJS 파일 압축과 EC2에 zip 파일 올리기(With PSCP 활용)
이번에는 NextJS 파일을 압축하여 EC2 에 어떻게 해당 파일을 올리는지 그 방법과 과정을 정리한다.
| 사실 ec2 도 가상 컴퓨터 이기 때문에 git clone 을 통해서 파일을 받아올 수 있다. 다만, 보안 문제로 SSH 을 이용해야 하기 때문에 일반적인 방식으로는 안 된다. 즉, 추가적인 설정이 필요하다. 또한 , .zip 으로 일일이 만들어 올리는 방식은 많은 피로도를 요하기 때문에 github actions 을 이용하여 개발자가 배포 시 자동으로 ec2 에서 git clone이 되도록 연결하거나 아니면 zip 파일을 s3 와 같은 서비스를 이용하여 파이프라인을 구축하는 등의 다양한 방법이 존재 하는데 자신의 프로젝트 상황에 맞게 찾아서 적용하면 될 일인 것 같다. |
NextJS 프로젝트 파일을 .zip 으로 압축하기
해당 파일을 압축하는 것은 [프로젝트 파일 전체]를 드래그 하여 [마우스 오른쪽]을 클릭하면, [보내기] 항목이 보일 것이다. 해당 부분의 클릭하면 , [압축(ZIP) 폴더] 가 보이는 데 이를 클릭한다. 참고로, 해당 환경은 윈도우 10 의 경우이다. 운영체제 마다 위치가 다를 수 있으므로 이럴 땐 구글 검색을 통해 찾아보자.
또한, 압축 시에는 개별 파일에 대해 압축을 하기 보다는 프로젝트 폴더 자체를 zip 으로 압축하는 것을 권장한다. 별도의 파일 압축은 향후 ec2 내에서 압축을 풀고, npm install 등의 작업을 수행할 때 제약이 따르기 때문에 불편한 점이 있다.
앞으로, 해당 압축 파일을 ec2로 전송하기 위해 SCP 를 사용한다. scp 를 사용하는 방식은 운영체제 마다 차이가 있을 수 있기 때문에, 이를 참고하여 자신의 상황에 맞게 과정을 이어나가야 한다.
우선 이 글이 작성되고 있는 운영체제 환경은 window10 이므로 window10 의 로컬에서 리눅스 환경의 aws ec2 로 데이터를 전송하는 방법에 대한 언급이 될 것이다.
압축(zip) 파일을 EC2 에 올리기 위한 PSCP(pscp.exe) 설치
여기서 한 가지 알고 가야하는 것이 있다. 윈도우에서 아마존 리눅스 환경의 ec2에 접속하기 위해서 Putty 기반의 .ppk 확장자를 가진 키페어를 사용했다.
그런데, 해당 키를 윈도우 환경에서 제공하는 OpenSSH 기반의 scp 를 사용하려고 하면 .ppk 파일을 유효한 확장자로 인식하지 못한다 즉, 아래와 같은 에러에 직면할 수 있다.
이 문제를 해결하기 위해서는 .ppk 를 위한 scp 인 PSCP 를 사용해야 하며, 이 도구는 PUTTY 공식 사이트에서 제공해주고 있다.
따라서 해당 링크(https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html)로 들어가서 아래와 같이 파일을 다운로드 한다.
PSCP 를 사용할 수 있도록 환경설정
앞서 pscp 를 다운로드 하였다면, 해당 파일이 있는 위치로 CMD 의 경로를 지정해야 한다. 예를 들어, pscp.exe 파일이 C:\Users\Administrator\Downloads 이라는 경로에 있다면, CMD 창이 가리키는 경로 또한 이와 동일해야 pscp.exe 파일의 스크립트가 정상적으로 동작한다.
만일 해당 파일을 전역적으로 사용하고 싶다면, 루트 경로에 해당 .exe 파일을 둬도 상관없다(물론 이 방식이 안 될 수도 있다. 이럴 땐 그냥 경로를 일치시키자).
본인의 경우에는 해당 파일이 다운로드 폴더 경로에 있기 때문에 임시적으로 아래와 같이 CMD 경로를 옮겨 주었다(이러한 불편사항에 거부감이 든다면 다른 방식도 많으니 찾아보자).
PSCP 사용해서 EC2 로 로컬에 있는 .zip 파일 올리기
이 다음 부터는 일반적인 scp 사용법과 동일하다. 앞에 붙은 접두사가 scp 에서 pscp 가 되는 차이 뿐이다.
scp 명령어는 다양하게 존재하지만, ec2 에 파일을 올리는 명령어(쿼리)는 다음이면 충분하다.
pscp -i ec2-key-pair.ppk project.zip ec2-user@35.333.23.5:/home/ec2-user
해당 규칙에 따라 쿼리를 입력해주면, 정상적인 경우 다음과 같이 다운로드 중인 상태 내역이 로드 된다.
압축 파일이 모두 업로드 된 것을 확인한 뒤, SSH 클라언트로 돌아와서 ~(루트 경로) 에서 ls -a 을 입력해보았다.
성공했다면 해당 압축파일이 아래와 같이 ec2 사용자 루트에 업로드 된 것을 볼 수 있다.
❓ 각 옵션에 대한 부연설명이 궁금하다면
-i 는 identity file 의 약자로 -i 다음에 오는 키페어 파일을 인증에 사용하도록 등록하는 옵션이다.
project.zip 은 업로드 할 파일 이름, 이며
ec2-user 는 ec2 에서 사용되는 호스트 이름이다(해당 이름은 앞서 putty 를 통해 ssh 클라이언트 접속 시 지정했었다. 보통 이 이름은 ec2 연결 시 관습적으로 사용되므로 어찌보면 고정된 이름이다).
@35.333.23.5 는 ec2 인스턴스에 접근할 수 있는 Public IPv4 를 의미하며,
: (클론) 을 구분으로 /home/ec2-user 로 지정된 경로는 .zip 파일이 업로드될 ec2 내의 폴더 경로이다.
| 참고로 .ppk 나 .zip 파일명을 명시할 때, 현재 파일들이 어디에 위치하고 있는지 경로를 파악해야 한다. 보통 윈도우 환경에서 CMD 의 기본로는 User/Abministator 로 되어 있을 가능성이 높으므로, 쉽게 파일을 전송하고자 한다면 해당 경로와 파일들을 일치시켜 두고, 파일명만 입력하도록 하는 것이 접근하기 쉬울 수 있다. |
업로드된 프로젝트 ZIP 파일 압축 풀기 및 프로젝트 실행 환경 셋팅
/home/ec2-user 에 .zip 압축 풀기
앞서 zip 파일을 업로드 했다면, 이제는 해당 파일의 압축을 풀어야 한다. 당연히 ec2 라는 컴퓨터를 대여 받았고, 해당 컴퓨터에서 프로젝트를 실행시키려면 zip 파일의 압축을 풀고, 해당 프로젝트 파일에 접근해서 npm install 등의 작업을 해야 하므로 이 과정은 단순하지만 매우 중요하다
현재 ec2 컴퓨터의 루트 디렉토리는 home/ec2-user 이다. 그리고 해당 .zip 파일도 여기에 올려져 있다.
따라서 해당 파일의 압축을 푸는 곳도 해당 경로에서 이루어져야 한다.
/home/ec2-user 가 현재 경로인지 확인하려면 pwd 를 입력하면 되며,
pwd # 현재 경로를 출력하는 명령어
경로를 확인 했다면, 다음 명령어를 실행하여 압축 풀기를 진행한다
unzip 압축폴더명 # 폴더명.zip 확장자 이렇게 붙여도 혹은 안 붙여도 인식한다.
압축 풀기가 완료되면, 아래와 같이 폴더들이 다운로드 된 것을 볼 수 있다.
프로젝트 실행환경 설정하기
이 다음에는 실제 프로젝트를 실행하기 위한 환경을 셋팅한다. 개발 서버와 다르게 실제 서비스 운영을 위한 것이므로 추가적으로 필요한 패키지가 존재한다.
npm install 과 npm run build 하여 종속성 설치 및 빌드 파일 생성하기
우선 npm install 을 통해 package.json 에 명시된 종속성들을 설치한다. 이 때 설치하는 경로는 압축을 풀고 생성한 프로젝트의 루트 경로에서 해야 한다(당연한 말)
그 후 프로덕션 서버를 실행하기 위한 프로덕션 파일을 생성하기 위해 npm run build 을 입력하여 빌드 파일을 생성한다.
💢 npm run build 를 하는 도중에 멈추는 현상이 발생합니다.
한 번 이 포스트를 참고해보세요. 프리티어로 주어지는 t2.micro 를 사용 중이시라면 메모리 공간 부족 문제 및 CPU 과부하로 해당 문제가 발생할 수 있습니다. 저사양 환경에서 이 문제를 해결하는 방법이 스왑파일을 생성하는 것인데, 이와 관련한 트러블 슈팅을 정리해보았습니다. 각 명령어가 어떤 의미인지도 나와 있으니 참고해보시면 좋을 듯합니다.
[나만의 명언집 프로젝트] 트러블 슈팅 ②
포스트 목적 해당 포스트는 프로젝트를 진행하는 중 경험하는 트러블 요소들을 어떻게 해결해 나갔는지 정리하는 용도로 작성됩니다. 해당 포스트는 트러블 슈팅 ① 에 이어서 작성됩니다. [빌
duklook.tistory.com
pm2 설치하여 무중단 서버 설정 및 서버 실행
pm2 는 쉽게 말해 프로덕션 환경에서 서버문제가 발생해도 중단되기 보다는 재시작하거나 지정한 옵션에 따라서 다른 안정된 서버로 리디렉트 하는 등의 로드밸런서 역할의 역할도 수행할 수 있는 도구이다.
이는 NodeJS 기반의 서버 환경에서 사용되는데, 보통 개발에서는 nodeman 을 사용하고, 배포 이후에는 pm2 를 사용한다. 해당 패키지는 전역적으로 사용할 수 있도록 하기 위해 -g 옵션을 붙여서 설치한다.
npm i -g pm2
설치 후 프로젝트를 실행하려면 다음 형식으로 입력해준다. 이렇게 되면 package.json 에 등록되어 있는 script 명령어 중 키가 'start' 인 명령어를 인식하여 실행하고, 지속적으로 관리 한다.
pm2 start npm --name '사용자작명' --start
참고로 pm2 는 프로그램이 정상적으로 실행되고 있는지 유무 등을 로깅하여 문제가 발생하면 자동으로 재시작 하거나 오류 로그를 표시해주는 등의 역할을 수행한다. 또한 백그라운드에서 실행되므로 커맨드 창을 종료하더라도 pm2 는 종료되지 않고 실행이 유지되도록 하여 무중단 상태를 유지하게 해준다.
추가로 위 내역에서 특정 로그를 삭제하려면 pm2 delete 'name' 을 입력하면 된다. 아니면 pm2 delete id 를 입력해도 된다. 여기서 id 는 상단 이미지에 나와 있는 id 컬럼에 표시된 숫자를 의미한다.
ACM 을 통해 SSL 발급 받기(부제 : HTTS 등록하기)
앞서 nginx 파트에서 80 포트와 443 포트에 대하여 포트포워딩 및 리버스 프록시를 등록하였는데, 이를 실제 적용하려면 SSL 과 로드 밸런서가 있어야 한다. 따라서 기존 http 통신을 https 로 바꾸는 작업을 하면서, 마지막에는 로드 밸런서에 이를 적용할 것이다.
참고로, SSL 을 발급 받는 방법은 꼭 ACM 을 사용할 필요는 없다. 직접 nginx 를 관리하여 관리의 주체를 본인이 가져가고자 한다면 이 블로그(https://puterism.com/deploy-next-js-with-ec2/)를 살펴보길 권장한다.
AWS Certificate Manager 접속 및 인증서 요청
해당 링크로 들어가서 [인증서 요청] 을 클릭하면 이후에는 안내에 따라서 인증서 생성 과정을 거치면 된다.
크게 설명할 것이 있는가 싶었지만, 이후 입력하는 단계에 대해서 AWS 자체적으로 한글로 잘 설명이 되어 있어서 별도로 언급하지 않는다(본인의 경우에는 도메인 이름 설정하는 것을 제외하고는 기본값을 선택하였다).
DNS 레코드 생성하기
인증서 요청이 완료되면, 다음 화면을 볼 수 있지도 모른다. 해당 화면에는 각각 등록한 도메인에 대한 검증을 대기하고 있다는 상태표시를 볼 수 있다.
Route 53 을 통해 발급 받아 관리하는 도메인인 경우(혹은 타 도메인 업체에서 이전하여 aws에서 관리하는 경우 등)
해당 화면에서, 만일 Route 53 에서 도메인을 구매하였거나, 타 업체의 도메인이지만, aws 으로 이전한 경우에는 [Route 53에서 레코드 생성]을 클릭하면, 간단한 절차를 통해 알아서 CNAME 이름과 값이 등록되어 손쉽게 인증 과정을 완료할 수 있다.
타 업체에서 발급 받아서 해당 사이트에서 관리하고 있는 도메인인 경우
반면에, 타 업체의 도메인이라면 해당 도메인을 발급 받은 사이트의 DNS 관리 페이지를 방문하여 DNS 및 CNAME 인증 절차를 별도로 거쳐야 한다.
현재 포스트에서는 AWS 에서 발급 받은 도메인을 다루므로 별도로 타 도메인에 대한 처리를 다루지 않는다. 즉, 이 부분은 다른 분들이 올려둔 포스트를 참고하길 추천한다.
로드 밸런서 생성 및 적용
이제 마지막 단계이다. 이 단계를 마무리하면 배포는 끝이 난다.
로드 밸런서 생성 및 유형 선택
EC2 페이지에서 좌측 메뉴의 하단으로 내려가면 [로드밸런서] 가 보이는데 이를 클릭해서 들어가고, [로드 밸런서 생성] 을 클릭한다.
그 다음 화면에서 [애플리케이션 로드 밸런서] 를 선택하여 들어간다.
기본 구성 작성하기
우선 [로드 밸런서 이름]은 고유하게 식별 가능한 이름을 선택하여 작성하면 된다.
[체계]의 경우에는 로드밸런스를 외부 네트워크 요청에 대해서 사용할지, 내부 네트워크에서만 사용할지 결정하는 영역으로 우리가 로드밸런스를 설정하는 이유는 외부의 요청을 처리하여 내부에 전달하기 위한 목적이므로 인터넷 경계를 선택한다.
[IP 주소 유형]은 우리가 사용하는 대부분은 IPv4 이므로 이를 선택한다. 만일 이 둘 모두를 지원하는 서비스의 경우에는 듀얼 스택을 선택하면 되는데, 선택하는 것 자체는 추가 비용이 발생하지는 않지만, AWS 의 다른 서비스를 이용하는 경우에는 추가 구성에 의한 비용이 발생할 수 있다는 점을 고려해야 한다.
네트워크 매핑
이번에는 네트워크 매핑에 대한 옵션을 설정하여야 한다. 각각 VPC 와 매핑으로 나뉘는데 이에 대해 설명하고자 한다.
VPC
우선 VPC 는 가상의 클라우드이다. 즉,사용자가 사용할 수 있는 가상의 클라우드 공간으로서 AWS 의 다양한 서비스를 각각의 사용자가 자기만의 격리된 공간에서 사용할 수 있도록 해주는 네트워크 공급망이라 할 수 있다.
여기서는 기본적으로 AWS 에서 제공하는 VPC 를 설정 하였는데, 특별한 이유가 없다면 기본설정을 사용하고 넘어간다.
매핑
여기서는 2개의 가용영역만 활성화한다. 사실 하나의 인스턴스만 생성하여 관리하는 경우 굳이 여러 개의 가용 영역은 불필요할 수 있다. 타 블로그 사이트에서는 기본적으로 4개를 활성화시키는 것을 보았는데, 여러 자료를 찾아보고 나니 굳이 그럴 필요성이 없어 보였다(물론 앞으로 어떻게 될지는 모른다).
EC2 인스턴스를 하나만 사용하는 입장에서 1개만 있어도 충분하지만, 2개 정도를 설정했다. 이 부분은 나중에 CLI 로 수정이 가능하다고 해도, 커맨드를 조작해야 하므로 임으로 미리 2개를 잡아 두었다.
만일 안정적인 서비스를 운영하고자 한다면 두 개이상의 로드밸런서를 배치하여 각각의 가용영역에 인스턴스를 배치해두는 것이 좋다.
참고로 ec2 인스턴스의 가용 영역에 대한 부분은 ec2 인스턴스 에서 네트워크 탭 부분에서 확인할 수 있다. 만일 해당 가용영역에 포함되지 않는 영역을 로드밸런서 생성 시 매핑에서 선택했을 경우, 해당 가용영역은 활성화 되지 않아서 동작하지 않는다.
매핑에 대한 부연설명
이 부분은 로드밸런서가 네트워크 트래픽을 처리하는 가용 영역의 갯수를 설정하는 부분이다.
만일, 여러 개의 EC2 인스턴스를 구성하여 서비스를 운영하는 경우라면 가용영역 마다 EC2 인스턴스를 구성할 수 있기 때문에 장애발생시 트래픽 전환을 보다 빠르고 효율적으로 이루어지게 할 수 있다.
이러한 가용 영역은 어렵게 생각할 필요 없이 EC2나 RDS와 같이 AWS 서비스를 독립된 공간에서 사용할 수 있도록 해주는 별도의 공간 이라고 이해하면 되는데, 각자가 하나의 영역인 만큼 각자 개별적인 VPC를 구성하며, 부하분산을 처리하는 로드밸런서 또한 별도로 가질 수 있다.
| 물론 매핑에서 설정하는 로드 밸런서는 여러 가용영역을 포함하여 트래픽을 동등하게 분산하는 역할을 수행한다.( 이러한 로드밸런싱 기능을 교차 영역 로드 밸런싱 이라 부른다.) |
아래 이미지는 aws 사용 설명서에 있는 이미지로 로드밸런스의 경우 각 가용 영역에 위치하고 있는 것을 볼수 있다. 또한 가용영역이 어떻게 동작하고 있는지도 시각적으로 확인이 가능하다.
이때, B 라는 가용영역에서 실행중이던 서비스에 문제가 발생하는 경우에는 A 라는 가용영역이 B가 처리하던 것을 대신처리함으로 장애가 발생하더라도 즉각 대처할 수 있다.
현재 선택한 애플리케이션 로드 밸런서의 경우에는 기본적으로 교차 영역 로드 밸런싱 이라는 기술이 적용되어 있다고 한다.
해당 내용을 참고하려면 아래 [더보기]를 눌러보면 된다.
교차 영역 로드 밸런싱(Cross-Zone Load Balancing)은 AWS Elastic Load Balancer (ELB)에서 제공되는 기능이다.
이 기능을 활성화하면 로드 밸런서가 여러 가용 영역에 걸쳐 배치된 EC2 인스턴스로 트래픽을 분산할 때 각 가용 영역의 인스턴스에 공정하게 분배된다.
기본적으로 ELB는 각 가용 영역에서 인스턴스에 트래픽을 분산하는데, 교차 영역 로드 밸런싱 기능은 로드 밸런서가 모든 가용 영역의 인스턴스를 통합하여 하나의 풀(pool)로 간주하고 트래픽을 분산한다. 이렇게 함으로써 각 가용 영역의 인스턴스가 균형있게 사용되어 부하가 골고루 분산되고, 전체적인 가용성과 성능이 향상될 수 있다.
또한, 해당 기술을 적용하면 각 가용 영역에 대해 동일한 수준의 트래픽이 발생할 때 서비스에 대한 응답 시간을 최적화할 수 있다.그리고 특정 가용 영역에서 장애가 발생했을 때 다른 가용 영역으로 트래픽을 자동으로 전환하여 가용성을 높일 수 있다.
요약하자면, 교차 영역 로드 밸런싱은 ELB를 사용하여 여러 가용 영역 간에 인스턴스로 트래픽을 분산하는 방법 중 하나이며, 가용성을 향상시키고 서비스의 응답 시간을 최적화하는 데 도움이 된다는 점이다.
참고로 각 부하분산을 동등하게 처리하는데 사용되는 알고리즘이 라운드 로빈 알고리즘이다.
보안그룹 설정
보안 그룹은 ec2 생성 시에 지정했던 보안그룹으로 지정해도 무방하다. 물론 별도의 처리를 위해 새로운 보안 그룹이 필요하다면 아래 안내와 같이 새로 생성하면 된다.
참고로 보안 그룹은 로드 밸런서가 클라이언트로 부터 오는 요청에 대한 트래픽을 처리할 때 어떻게 처리할지에 대한 규칙 세트로 이해하면 된다.
리스너 및 라우팅 설정(+ 대상그룹 생성 및 인스턴스 등록)
이 다음에는 리스너와 라우팅을 설정한다. 각 포트별로 수신되는 요청을 검사해서, 사용자가 정의하거나 기본으로 설정된 규칙에 따라서 요청을 라우팅하기 위해 설정하는 부분이다.
이 때 로드밸런서는 라우팅 시 지정한 대상 그룹을 기반으로 라우팅 하기 때문에 대상 그룹을 설정해주어야 한다. 원래라면 443 포트와 함께 80 포트도 지정해야 하는데, 이는 로드밸런서를 생성한 뒤에 리스너를 별도로 추가하여 지정할 것이다. 따라서 우선적으로 443 포트에 대한 리스너만 생성한다.
[대상 그룹 생성] 에 들어가보면, 아래 화면을 볼 수 있다. 여기서 대상 유형은 VPC 내의 인스턴스를 대상으로 하는 것이므로 [인스턴스] 를 선택한다. 그리고 트래픽의 라우팅 대상으로 HTTPS 프로토콜/443 포트를 설정하고 넘어간다. 그 외 나머지 옵션은 지정되어 있는 기본값으로 설정하고 그룹 생성을 완료한다.
그 다음 화면으로 넘어가면 [대상등록] 화면이 보인다, 여기서 해당 앞서 생성한 대상그룹과 매칭할 인스턴스(ec2 ; 가상 컴퓨터)를 선택하고, 어떤 포트로 트래픽을 라우팅 할지 입력한다(여기서는 443을 입력해야 한다) 그 후 [아래에 보류 중인 것으로 포함] 클릭 및 [대상 그룹 생성] 을 클릭한다.
보안 리스너 설정
이 부분은 HTTPS 를 적용하기 위한 SSL 인증서를 설정하는 영역이다.
aws 문서에서는 HTTPS 리스너를 생성할 때는 리스너에 하나 이상의 SSL/TLS 서버 인증서를 배포해야 하며, HTTPS 리스너가 SSL 연결을 협상하려면 생성 중에 보안 정책도 선택해야 한다고 나와 있다.
여기서 보안 정책은 사용자가 맘대로 정의할 수 없고, HTTPS 적용 시 권장되는 정책이 기본값으로 설정되어 있으므로 넘어가면 된다. 또한, 인증서의 경우에도 앞서 ACM 을 통해서 발급 받았기 때문에 이를 등록하고 넘어가면 된다.
80 포트에 대한 리스너 추가하기
앞서 443 포트에 대해서만 리스너를 추가하였는데, 나머지 80 포트에 대한 리스너도 추가한다. 우선 ec2 페이지의 좌측 카테고리를 보면 로드밸런싱이 있는데, 거기서 로드밸런서 항목을 클릭한다.
그 다음 아래 화면에 표시된 것 과 같이 [리스너 추가] 를 클릭한다.
그럼 아래 화면을 볼 수 있는데, HTTP 80 포트로 요청이 들어오면 URL 리디렉션을 통해서 HTTPS 443 포트로 포트포워딩 되도록 설정한다. 그 다음 추가를 클릭하여 리스너 추가를 완료한다.
로드 밸런서와 도메인 연결하기
대망의 마지막 파트이다.
Route 53 의 레코드 생성 에서 A 레코드 생성하기
여기서 A 레코드를 생성하는 이유
A 레코드는 해당 로드 밸런서의 IP 주소를 가리키는 레코드이다. A 레코드를 사용하면 도메인 이름을 특정 IP 주소로 매핑하여 클라이언트가 해당 로드 밸런서에 접속할 수 있게 해준다.
예를 들어, "example.com" 도메인을 사용하여 로드 밸런서를 생성했다고 가정해보자. 그러면 "example.com"의 A 레코드는 생성된 로드 밸런서의 IP 주소로 설정된다. 즉, 클라이언트는 이 IP 주소를 사용하여 해당 로드 밸런서에 접속할 수 있다.
로드 밸런서의 A 레코드는 DNS(Domain Name System) 서버에서 관리되며, 클라이언트가 도메인 이름을 이용하여 해당 로드 밸런서에 연결하려고 할 때 DNS 서버는 이 A 레코드를 반환하여 클라이언트가 로드 밸런서의 IP 주소로 연결할 수 있도록 도와준다. 이후 클라이언트는 해당 IP 주소로 요청을 보내고 로드 밸런서는 요청을 적절히 백엔드 서버로 라우팅 해준다.
요약 하자면, A 레코드는 우리가 앞서 생성한 로드 밸런서를 가리키고 있으며, 클라이언트의 요청을 로드밸런서로 연결 시켜주는 주는 역할을 한다.
일단 Route53 으로 접속하여 좌측 탭의 [호스트 영역]을 클릭한 뒤 우측 중단에 [레코드 생성]을 클릭한다.
그럼 다음 화면을 볼 수 있는데 아래와 같이 순서대로 입력 및 선택해준 후 레코드 생성을 클릭해준다. 참고로 노란색으로 칠해진 부분은 우리가 생성한 로드밸런서를 선택하는 항목이다. 즉, 생성하는 A 레코드가 가리키는 대상을 지정하는 것이다.
여기 까지 하고 다시 로드밸렁싱의 로드 밸런서로 돌아와서 [리소스 맵 ] 을 확인해보면 포트포워딩이 이루어지고 있는 것을 시각적으로 확인해볼 수 있다.
여기 까지가 마무리..
드디어 모든 배포가 끝났다. 다만, 추가적으로 처리해야 할 문제가 발생하여서 안심할 수는 없을 것 같다. 이 부분은 해결이 되면 정리해 봐야 겠다.
참고자료
- 로드밸런싱(https://aws-hyoh.tistory.com/133)
- postgres 설치( https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html )
- nvm 설치(https://github.com/nvm-sh/nvm )
- postgres 설치( https://sarc.io/index.php/miscellaneous/2337-ec2-amazon-linux-2023-postgresql )
- pscp 솔루션( https://www.cisco.com/c/ko_kr/support/docs/security/email-security-appliance/118302-qa-cs-00.pdf )
'프로젝트 > 나만의명언집' 카테고리의 다른 글
| [나만의 명언집 프로젝트] AWS RDS Postgres 연결 후 EC2 인스턴스와 연결하기(1) | RDS 생성 (0) | 2024.03.18 |
|---|---|
| aws ec2에서 npm install 이 실패하였습니다.. 알고 보니 권한 문제였다는데,, 혹시 여러분도?? (0) | 2024.03.17 |
| [나만의 명언집] 기능 구현 정리본 ③ (0) | 2024.03.07 |
| [나만의 명언집 배포] NextJS(^14.1) - ② Amplify 배포 | 도메인 설정 (0) | 2024.03.06 |
| [나만의 명언집 배포] NextJS(^14.1) - ① AWS Amplify 배포 (0) | 2024.03.06 |
