[총정리] AWS에 내 웹사이트 올리는 법 (2편)

* 1편 (EC2 호스팅) : [총정리] AWS에 내 웹사이트 올리는 법 (1편)

 

지난 편에서 AWS의 컴퓨터를 빌려 내 웹사이트 파일을 올리고 실제 브라우저에서 접속까지 해봤다.

이번 편에서는 웹사이트에 고정 IP를 할당하고, DB를 달고, 도메인을 연결하고, SSL을 적용해보자!

 

* 이 글은 전문가가 쓴 것이 아니기 때문에 오류가 있을 수 있는 점 양해 부탁드립니다.

1. 고정 IP 할당하기

지금 EC2에는 퍼블릭 IPv4가 자동으로 할당되어 있다.

그런데 만약 어떤 이유로 서버를 중지했다가 재시작하게 되면, 이 주소가 다른 주소로 바뀌게 된다.

빌린 컴퓨터를 반납했다가 한번 더 빌리면, 가지고 있는 것 중 다른 컴퓨터를 빌려주는 것과 같은 이치이다.

그런데 퍼블릭 IP는 웹사이트에 접속할 때 필요한데, 이게 바뀌면 웹사이트 주소가 계속 바뀌는 거나 다름이 없다.

따라서 상용 서비스라면 항상 IP가 동일하도록 고정적인 IP를 사용할 필요가 있다.

 

이렇게 내가 전용으로 쓸 수 있는 고정 IP를 AWS에서는 '탄력적 IP'라고 한다.

탄력적 IP를 만들어서 EC2에 할당해보자.

 

(1) EC2 > 메뉴 중 ‘탄력적 IP’ 클릭 > ‘탄력적 IP주소 할당’ 버튼을 누른다.

(2) 상세 내용은 수정할 것 없이 바로 하단의

‘할당’ 버튼을 눌러 탄력적 IP를 생성한다.

(3) 목록에서 할당된 IP 선택 > ‘작업’ 버튼 클릭 > 탄력적 IP주소 연결을 선택한다.

- 리소스 유형: 인스턴스

- 인스턴스: 선택지 뜨는 거 고르기 (내 EC2 인스턴스)

- 프라이빗 IP 주소: 선택지에 뜨는 거 고르기 (내 EC2 인스턴스의 프라이빗 IP)

 

이렇게 손쉽게 탄력적 IP를 생성하고 EC2에 할당했다.

이제 EC2 인스턴스의 상세 정보를 보면, '퍼블릭 IPv4 주소'가 방금 할당한 탄력적 IP로 바뀌어 있을 것이다.

 

참고로, 원래 AWS에서 모든 IPv4는 과금 대상인데, 프리티어는 EC2에 할당된 것만은 무료로 제공해주므로 여기서는 비용이 청구되지 않는다.

 

이제 웹사이트 IP가 바뀌었으니 아래 부분도 함께 바뀌어야 한다.

• ssh 접속 명령어: EC2에 SSH 연결 시 사용했던 명령어가 바뀐다. AWS Console에서 확인할 수 있다.
• 백엔드 cors 설정: 기존에 썼던 퍼블릭 IPv4 주소를 탄력적IP로 바꿔준다.
• 웹사이트 접속 주소: 'http://탄력적IP' 로 접속해야 접속된다.

 

2. DB 달기

만약 프로젝트에서 DB를 사용한다면 DB도 달아보자.

 

2-1. RDS 인스턴스 생성

 

AWS에서 DB는 RDS라고 불리는 서비스를 이용하면 된다.

(처음에는 그냥 EC2에 DB를 설치하면 되는 줄 알고 EC2 에 DB를 만들고 테이블도 생성했었는데, 나중에 재접속했더니 만든게 다 날라가 있었다. 처음부터 RDS를 쓰자.)

 

AWS Console에서 RDS를 검색하고 데이터베이스 > 데이터베이스 생성을 통해 인스턴스를 만들어준다.

엔진은 원하는 데이터베이스 소프트웨어를 선택하고, 템플릿은 프리티어를 쓰면 된다.

나머지는 별로 건들게 없고 하나만 신경 써주면 되는데, "연결"이라는 탭에서 "퍼블릭 액세스"를 설정하는 부분이다.

이건 RDS에 대한 퍼블릭 접속 가능 여부를 정하는 것인데, 예를 들어 로컬 GUI 툴에서 DB에 접속하려면 접속이 가능해야 한다. 만약 접속을 막더라도 EC2에서 접속하는 건 가능하다.

이게 중요한 이유는 만약 퍼블릭 액세스가 가능하게 설정하면 RDS 인스턴스에 퍼블릭 IPv4가 할당되어 과금되기 때문이다. 현재 AWS에서 프리티어 EC2용 IPv4를 제외한 모든 IPv4는 과금되므로, 본인 상황에 맞게 잘 판단해서 설정하자. 참고로 이건 인스턴스 생성 이후에도 바꿀 수 있는 거라, 일단 막았다가 나중에 필요할 때 잠깐 허용하는 식으로 써도 된다.

 

추가로 DB를 생성하면 Elastic Cache를 쓰라고 추천해주는데, 비용절감과 성능에 좋다길래 아무생각 없이 디폴트 값으로 그냥 만들었다가 DB보다 비용이 더 나가길래 삭제했다. 설정을 잘못한 거겠지만 만약 만들거면 신경을 좀 써야 한다.

 

2-2. EC2에서 접속하기

 

이제 EC2에서 RDS에 접속해보자.

먼저 EC2에 접속한 뒤 DB를 설치한다. 나의 경우 postgreSQL을 설치했다.

sudo apt install postgresql

 

잘 설치되었는지 보려면 버전을 출력해본다.

psql --version

 

DB상태 확인도 할 수 있다. active라고 출력된다.

sudo service postgresql status 

 

RDS 인스턴스에 접속하려면 엔드포인트를 알아야 한다.

AWS Console에서 생성한 인스턴스를 클릭하면 상세정보가 나오는데, '엔드포인트'라고 적힌 부분의 값을 복사한다.

이를 이용해 EC2 에서 접속해보자.

psql -U postgres -d postgres -h 엔드포인트(..rds.amazonaws.com) -p 5432

• -U postgres: DB서버에 접속할 때 사용할 사용자 이름. 여기선 postgreSQL의 기본 사용자인 'postgres'라는 사용자로 접속했다. RDS 인스턴스를 생성할 때 '마스터 사용자 이름' 부분에서 설정한 값을 쓰면 되는데, 안 바꿨으면 각 DB의 기본값을 쓰면 된다.
• -d postgres: 접속할 DB의 이름. PostgreSQL은 처음에 postgres라는 DB가 기본값으로 생성되어 있어서 'postgres' 데이터베이스에 접속했다.
• -h 엔드포인트: DB서버가 실행 중인 호스트 주소. 앞서 말한 RDS 엔드포인트를 사용한다.
• -p 5432: DB서버의 포트 번호. 여기선 PostgreSQL 기본 포트인 5432번을 사용했는데, RDS 인스턴스 생성 시 값을 바꿔줬다면 해당 값을 사용하면 된다.

그럼 RDS에 접속될 것이다.

 

2-3. 사용자 암호 설정

 

1) 기본 사용자 그대로 쓰는 경우

postgres 사용자에 암호를 설정해주자.

아래 명령어는 암호를 설정하겠다는 명령어인데 현재 나는 postgres라는 유저로 들어왔으니 postgres라고 썼다.

sudo passwd postgres

 

이후 암호를 입력하라고 뜨면 입력하면 된다. 이 암호는 다음에 DB 접속 시에 사용된다.

 

※ 아래와 같이 사용자가 없거나 문제가 있다고 뜬다면

"user postgres does not exist or the user entry does not contain all the required fields"

아래 명령어로 사용자를 추가해주면 된다.

sudo adduser postgres

 

2) 새로운 사용자를 추가하는 경우

postgres 말고 다른 사용자를 만들어서 쓰려면 아래 명령어로 생성해주면 된다.

create user 사용자이름 with password '암호';

 

사용자에게 필요한 권한을 추가해준다. 아래의 경우 슈퍼유저 권한과 DB생성 권한을 추가하는 명령어이다.

alter role 유저아이디 superuser createdb;

 

 

* 사용자가 잘 생성됐는지 확인하려면 아래 명령어로 사용자 목록과 역할을 조회할 수있다.

\du 

 

참고로 창을 나가려면 q 키를 누르면 된다.

 

2-4. DB와 테이블 만들기

지금 postgres라는 DB가 있지만, 다른 이름으로 DB를 새로 만들어서 써도 된다.

create database DB이름

 

참고로 DB를 만들어서 쓸거면 RDS 접속할 때 위에서 본 psql -U.. 명령어에서 DB이름을 그걸로 바꾸어서 명령해야 하는 것을 잊지 말자!

 

이제 DB 안에 사용할 테이블을 만들어줘야 한다.

서비스를 개발할 때 로컬에서 쓰던 테이블들이 있을 텐데, 생성문을 따로 저장해두었으면 그걸 실행해주면 되고, 만약 생성문이 없다면 DDL 추출해서 쓰면 된다.

 

*아래는 어떤 분이 친절하게 설명해주신 PostreSQL DDL 추출 방법이다.

https://dev-h2.tistory.com/8

 

2-5. 연결정보 수정하기

개발 프로젝트 파일에서 현재는 로컬 DB의 접속 정보를 사용하고 있을 것이다.

이제 DB 주소, 사용자 정보 등을 새로 설정한 값으로 수정해주면 된다.

 

[오류 해결]

만약 postgreSQL 버전이 16 이상이면, 웹사이트에서 DB 관련 동작이 안되거나 pg_hba.conf 어쩌고 하는 오류가 날 수 있다.

이는 postgreSQL 버전 16 이상부터는 기본적으로 웹사이트에 SSL 인증서 적용이 되어 있어야만 정상 작동하도록 설정되어 있기 때문이다.

아래에서 SSL 인증 적용 방법을 설명하고 있지만, 만약 SSL 없이 이 문제를 해결해야 한다면 DB를 하위 버전으로 다시 깔거나 이 기본 설정값을 바꿔주면 된다.

아래는 설정값을 바꾸는 방법이다.

1. AWS Console > RDS > 파라미터 그룹 > 파라미터 그룹 생성을 통해 그룹을 생성해준다.
2. 이후 생성된 그룹에 대해 파라미터 그룹 작업 > 편집을 누른 뒤 'rds.force_ssl' 값을 찾아 0으로 바꾸고 저장한다.
3. RDS > 수정 > 추가구성 > DB 파라미터그룹에서 방금 만든 파라미터 그룹을 선택하고 저장한다.
4. RDS를 재부팅한다.

 

2-6. GUI 툴 연결하기

터미널에서 SQL로 DB를 조회할 수도 있지만 시각적인 툴을 쓰고 싶을 수 있다.

여기선PostgreSQL의 GUI 도구인 pgadmin 접속 방법을 정리해보겠다.

 

(1) 퍼블릭 액세스 허용하기

위에서도 언급했지만 RDS 인스턴스의 설정 중 '퍼블릭 액세스' 항목에 '예'를 선택해줘야 접속이 된다.

 

(2) 보안그룹 설정하기

aws 보안그룹 규칙 > 인바운드 규칙 편집 > postgresql 유형 추가해주기 (anywhere ip4)

 

(3) pgadmin에서 연결하기

로컬 PC에 pgadmin를 설치한 뒤 실행한다.

왼쪽의 Servers에 마우스 오른쪽 클릭 > Register를 눌러 DB를 등록한다.

팝업 창의 첫번째 탭인 general에서는 Name에 원하는 DB 이름을 설정한다.

두번째 탭인 connection에서는 DB 연결 정보를 입력해준다.

• host name/address: AWS RDS의 엔드포인트
• port: 5432 (혹은 설정한 다른 포트 번호)
• maintenance: 연결하려는 DB의 이름 (postgres 등)
• username: 사용자 이름 (postgres 등)
• password: 사용자 암호 (위에서 설정해준 것)

[오류 해결]

pgadmin에서 pg_hba.conf에 등록이 안 되었다거나 하는 오류가 난다면 아래 방법으로 해결해본다.

 

터미널에서 RDS에 접속한 상태에서, 만약 다른 사용자로 접속해 있으면 루트 사용자인 postgres로 전환한다.

sudo su postgres

 

postgresql 설정 파일을 열어 내용을 수정해줄 것이다. 설정 파일의 경로는 버전마다 다를 수 있다.

아래는 ~postgresql.conf 파일을 vi 에디터로 열겠다는 명령이다.

vi /etc/postgresql/14/main/postgresql.conf

 

설정 파일이 vi 에디터에서 열릴 것이다.

아래 방향키로 화면을 쭉 내려가다 보면

" #listen_addresses='localhost' "라고 적힌 행이 있다.

 

i를 눌러 수정 모드로 들어간다.

i

 

'#'를 지워서 주석을 해제한다.

현재는 로컬 호스트에서만 접속이 가능하게 되어 있으니,

localhost 대신 '*' (또는 0.0.0.0)를 적어줘서 다른 IP의 접속도 가능하게 해준다.

 

esc 키를 누른 뒤, 아래 명령어로 파일을 저장하고 닫는다.

:wq

 

다음으로 pg_hba 설정 파일을 열어 내용을 수정해 줄 것이다. 파일 경로는 버전마다 다를 수 있다.

vi /etc/postgresql/14/main/pg_hba.conf

 

여기서도 아래 방향키로 파일을 쭉 내려가다보면

"#type db user ...: " 라고 적힌 라인이 있을 것이다.

이 라인 아래에 아래 라인을 추가해준다.

* host     all     all     0.0.0.0/0     md5 

 

이제 설정이 적용되도록 PostgreSQL을 재시작해야 한다.

exit 하여 EC2로 돌아간다 (whoami를 쳤을 때 ubuntu가 나올 때까지 exit)

아래 명령어로 인스턴스를 재시작한다.

sudo service postgresql restart

 

 

3. 도메인 연결하기 

 

현재 웹사이트에 접속하려면 브라우저 주소창에 IP주소를 입력해야만 한다.

하지만 일반 사용자 입장에서 IP는 기억하기 어렵기 때문에 naver.com과 같이 도메인 이름을 사용하는게 좋다.

도메인 이름을 쓰려면 도메인을 사서 웹사이트 IP에 도메인을 연결해주면 된다.

 

1) 도메인 구매

도메인은 여러 사이트에서 구매할 수 있다.

필자는 보통 가비아를 이용한다. 회원가입 후, 원하는 이름과 가격의 도메인을 검색해서 구매한다.

 

2) 도메인과 IP주소 연결

가비아 > MY가비아 > 서비스 관리 > 관리 > DNS 정보 > DNS 관리 > (도메인 체크 후) DNS 설정 > 레코드 추가 버튼을 누른다.

아래처럼 적어준 뒤 저장한다.

• 타입: A (A 타입은 도메인 주소와 서버 IP주소를 매핑시키는 유형이다)
• 호스트:  @ (모든 서브도메인이라는 뜻이다)
• 값/위치: EC2의 IP주소를 적어준다.

 

저장한 뒤에 바로 도메인 접속이 되지는 않고, 이론적으로는 48시간 이내에 반영된다고 한다.

그런데 실제로는 10분 정도, 길어도 1시간 이내에는 접속되는 것 같다.

만약 본인 사이트가 1시간 이후에도 접속이 안되면 뭔가 잘못 설정한 것이 있을 수 있으니 확인해보자.

 

* 참고로, 이 방법 대신 AWS의 Route53을 사용하는 방법을 설명하는 경우도 있는데

Route53 호스팅 영역은 월 550원이 청구되므로 굳이 쓸 이유가 없다.

만약 Route53으로 설정했던 사이트가 있다면 아래 방법으로 가비아로 바꿀 수 있다.

1. AWS Console > Route53에서 호스팅 영역을 삭제한다. (해당 영역에 속한 레코드 중 삭제되는 레코드를 먼저 삭제한 후에 가능)
2. 가비아에서 DNS 레코드를 추가한다.
3. 가비아에서 네임서버를 초기화해준다. 가비아 > MY가비아 > 서비스 관리 > 관리 > 도메인 정보 변경 > (도메인 체크후) 네임서버 에 가면 AWS에서 만든 네임서버를 기입했을 텐데, 이를 지우고 상단의 '전체 가비아 네임서버 사용'을 선택하면 된다. 소유자 인증 후 적용한다.

 

 

4.SSL 적용하기

주소를 http가 아닌 https로 접속할 수 있게 하는 것이 바로 SSL 인증서이다.

AWS에서 SSL 인증서를 발급받고 SSL 설정을 해보자.

* 여기서는 AWS 로드밸런서를 이용해 SSL 적용하는 방법을 설명하고 있습니다. 그런데 이 방법은 불필요하게 무겁고 IPv4도 최소 2개가 적용되어 비용이 꽤 청구됩니다. 이 외에 Let's encrypt 등 다른 더 가볍고 무료인 방법이 있으니 본인 상황에 맞게 적용하시기 바랍니다. 그냥 SSL을 안 쓰는 것도 방법입니다.

 

(1) 인증서 발급하기

AWS Console > AWS Certificate Manager > 인증서 요청을 통해 인증서를 요청한다.

'인증서 유형'은 퍼블릭 인증서를 선택하고,

'완전히 정규화된 도메인 이름'에는 구매한 도메인을 입력한다.

이때 주소에 www는 넣으면 안 된다. 예를 들어 구매한 도메인이 mysite.com이면, mysite.com만 적어준다.

그리고 서브도메인도 접속되도록 '이 인증서에 다른 이름 추가' 버튼을 눌러 입력란을 추가한 뒤, *.mysite.com과 같이 *.을 포함한 버전도 적어준다.

그 외 나머지 값은 기본값으로 두고 요청을 생성한다.

 

(2) 인증서 검증하기

발급된 인증서 상세화면에서 'Route 53에서 레코드 생성' 버튼 > '레코드 생성' 버튼을 누른다.

그럼 Route 53에서 호스팅 영역의 레코드에 '유형' 칼럼 값이 NS 외에도 CNAME인 행이 생겼을 것이다.이제 조금 기다리면 AWS Certificate Manager > 인증서에서 인증서 상태가 '발급됨'으로 바뀐다.

 

(3) 로드밸런서 생성하기

발급된 인증서는 부적격이라고 뜰 텐데, 로드밸런서 등에 연결되어 있어야 적격으로 바뀐다.

 

먼저 대상그룹을 만들 것이다.

1. AWS Console > EC2 > 메뉴 하단의 '로드밸런싱'의 '대상그룹' > '대상 그룹 생성' 버튼을 누른다.
2. 유형은 '인스턴스'를 고른다. 대상 그룹 이름도 지어준다.
3. 나머지 값은 기본 값을 쓰고 다음으로 넘긴다.
4. 대상 그룹을 등록하는 화면이 나오는데, 사용 가능한 인스턴스 목록의 EC2 인스턴스를 체크해준다.
5. 하단의 '아래에 보류 중인 것으로 포함' 버튼을 누른다.
6. '대상 그룹 생성' 버튼을 눌러 그룹을 생성한다. 

 

다음으로 로드밸런서를 만들 것이다.

AWS Console > EC2 > 메뉴 하단 '로드밸런싱'의 '로드밸런서' > '로드 밸런서 생성' 버튼을 누른다.

• 로드밸런서 유형: 우린 HTTPS 연결을 하려고 하니 Application Load Balancer를 선택한다.
• 기본 구성 섹션: 로드밸런서 이름을 지정해주고 다른 값은 기본값 그대로 둔다.
• 네트워크 매핑 섹션: 가용영역(Availability Zone)을 선택해야 한다. 가용성을 높이기 위해 여러 데이터센터에 인스턴스를 위치시키는 것인데, 최소 2개를 선택해야 한다. 4개가 뜰 텐데 어느 영역을 선택하든 성능과 가격은 똑같지만, 각 가용영역은 IPv4가 할당되어서 과금되니 우선 2개만 선택해도 될 것 같다. 이때 EC2가 위치한 가용영역은 꼭 선택을 해줘야 웹사이트 접속이 된다. EC2가 위치한 가용영역은 EC2 인스턴스 목록 중 '가용영역' 칼럼을 확인하면 알 수 있다.
• 보안 그룹 섹션: EC2에 적용한 보안그룹을 지정해주면 된다.http, https가 접속되도록 인바운드 규칙에 80, 443번 포트가 열려 있어야 한다.
• 리스너 및 라우팅 섹션: 첫 번째에는 HTTP / 80 / 위에서 만든 대상 그룹을 선택한다. 아래 '리스터 추가'를 눌러 두 번째에는 HTTPS / 443 / 위에서 만든 대상 그룹을 선택한다. HTTPS 를 선택하면 하단에 '보안 리스너 설정' 섹션이 뜰 것이다. '기본 SSL/TLS 서버 인증서' > '인증서(ACM에서)' 부분에 위에서 만든 인증서를 골라준다.

(4) 로드밸런서 적용하기

AWS Console > Route 53 > 호스팅 영역에서 영역을 선택해 상세화면에 들어간다.

1. 레코드 중 유형이 'A'인 것을 선택하고 오른쪽 패널의 '레코드 편집'을 누른다.
2. 별칭을 ON으로 바꾼다.
3. '트래픽 라우팅 대상'은 'Application/Classic Load Balancer에 대한 별칭'을 선택한다.
4. 저장한다.

(5) HTTP를 HTTPS로 리디렉트하기

AWS Console > EC2 > 로드밸런서에서 생성했던 로드밸런서 상세화면에 들어간다.

1. 하단의 '리스너 및 규칙'에서 HTTP:80 선택 > '기본값' 행에 체크 > '규칙 편집'을 누른다.
2. '라우팅 액션'을 'URL로 리디렉션'으로 선택한다
3. 프로토콜은 HTTPS, 포트는 443을 입력한다.

 

5. 24시간 실행하기

지금은 EC2에서 앱을 실행해도, 터미널을 끄면 서버가 종료되어서 웹사이트 접속이 안 된다.

웹사이트에 언제든지 접속할 수 있도록 앱을 24시간 실행시켜보자.

 

노드 기준으로, 이를 가능하게 해주는 패키지는 pm2가 있다.

EC2 터미널 접속 후 아래 명령어로 pm2를 설치해준다. 권한 문제가 뜨면 앞에 sudo를 붙여 명령하면 된다.

npm install -g pm2

 

이제 프로젝트가 있는 폴더로 이동해서 pm2로 앱을 실행시킬 것이다.

만약 실행하려는 앱 이름이 app.js이면 app.js가 있는 폴더로 이동한 뒤 아래 명령어를 입력해준다.

// 프로세스 시작하기
pm2 start app.js

// 소스에 변경사항이 생기면 재시작하게 설정하고 시작하기
pm2 start app.js --watch

 

두 번째 명령어를 쓰면 깃허브 변경사항을 pull 했을 때 알아서 프로세스를 재시작하므로 편리하다.

 

아래는 pm2 관련 유용한 명령어들이다.

(참고로 나는 sudo를 붙여야 제대로 동작하길래 sudo를 붙였었다)

// 현재 실행중인 프로세스의 목록 확인하기
pm2 list

// 프로세스의 상태 확인하기 (아래는 app.js의 상태)
pm2 show app

// 실행 중인 프로세스 삭제하기
pm2 delete app

 

실행 후 상태를 확인했을 때 status가 online이면, 터미널을 닫아도 서버가 계속 실행되어 24시간 웹사이트에 접속이 가능하다.

 

 

6. 그 외

이제 웹사이트에 잘 접속되고 동작도 잘 할 것이다.

 

추가로 도중에 겪은 문제 중, 모든 게 정상인데 접속이 거부되는 현상이 있었다.

알고보니 중간에 추가한 패키지가 반영이 안 되었던 것으로 npm i를 해주니 해결됐다.

 

그리고 본인 웹사이트를 구글 등에서 검색해보면 검색이 잘 안 될 것이다.

여기부터는 검색엔진 최적화(SEO)의 영역이다.

메타태그 작성, 사이트맵 제출 등 검색엔진 최적화를 통해 웹사이트를 검색엔진 상단에 띄우기까지 하면

모든 배포 과정이 마무리된다.

 

 

끝!