코드프레소 백엔드 개발자 양성 과정

AWS로 서비스 배포하기 4

사설 서브넷에 데이터베이스 서버를 구축해본다.

H Lee
10 min readMar 4, 2020

이 글에서는 사설 서브넷 안에 파란색 사각형으로 표시된 가상 컴퓨터에 데이터가 저장될 데이터베이스 서버로 MySQL을 설치한다.

라우팅 테이블 (Route Table)

이제부터는 사설 EC2 인스턴스에 접속하여 작업한다. 하지만 이전 글에서 안방에 비유했듯, 사설 인스턴스는 아무나 들락날락할 수 없도록 공공 IP 주소를 부여하지 않았다. 그렇다면 어떻게 인터넷에서 필요한 자원을 끌어와 데이터베이스 서버를 구축할 수 있을까? 지난 글에서 뚫어준 NAT 게이트웨이를 통해 작업할 수 있다.

그러나 이 NAT 게이트웨이를 타고 들어가려면 또 하나의 설정을 조작해주어야 한다. 바로 라우팅 테이블이라는 것이다. 라우팅 테이블이란 VPC 내에서 네트워크 통신을 특정 목적지로 보내겠다는 규칙을 명시한 표이다. 여기서 목적지는 서브넷이 될 수도 있고 게이트웨이가 될 수도 있다.

한마디로, 라우팅 테이블이라는 이정표를 명시해주지 않으면, NAT 게이트웨이를 뚫어주었더라도 사설 서브넷이 이를 이용할 방도가 없는 것이다.

그럼 사설 서브넷의 라우팅 테이블을 변경해보자.

사실 VPC 대시보드에서 라우팅 테이블 부분을 보면, 이미 라우팅 테이블이 존재함을 볼 수 있다. VPC를 생성할 때 사용한 마법사가 이것까지 자동으로 만들어 주고, 그때 입력한 NAT 게이트웨이 ID를 서브넷에 연결까지 해주기 때문이다. 이름은 본래 빈 칸으로 표시되나, 구분을 쉽게 하기 위해 직접 입력해주었다.

마법사를 사용하여 이렇게 라우팅 테이블이 이미 있다면, 어떤 테이블이 공공 서브넷에 적용되는지, 어떤 테이블이 사설 서브넷에 적용되는지 정도만 파악하고 넘어가도 좋다.

social_media_project_vpc에 속해 있는 테이블은 두 개가 있다. 상세 정보를 보았을 때, 타겟에 외부와 통신할 수 있는 인터넷 게이트웨이(Internet Gateway, IGW)가 보이면 공공 서브넷의 라우팅 테이블이다.

반대로 NAT 게이트웨이와 연결되어 있다면 사설 서브넷의 라우팅 테이블이다.

만약 마법사를 사용하지 않았다면, 라우팅 테이블 생성하기 단추를 눌러 손수 NAT 게이트웨이와 인터넷 게이트웨이를 규칙에 추가해 주어야 한다.

여기서 목적지(Destination)는 통신이 도달해야 하는 사이더 범위를 의미한다. 모든 요청이 NAT 게이트웨이를 타고 인터넷 게이트웨이로 전달되어 인터넷에 접속할 수 있도록 0.0.0.0/0으로 지정한다.

표적(Target)은 그 통신이 목적지에 도달하기 위해 통과해야 하는 관문을 가리킨다. 예로는 NAT 게이트웨이, 인터넷 게이트웨이, 외부 전용 인터넷 게이트웨이 등이 있다. 보기에서 NAT 게이트웨이를 선택하니 내가 만든 social_media_project_nat이 추천된다. 선택하고 라우트 규칙을 저장한다.

이제 NAT 게이트웨이를 통해 사설 EC2 인스턴스에서도 인터넷에 접속할 수 있다.

사설 EC2 인스턴스 로그인

사설 가상 컴퓨터에 SSH 터널링을 통해 접속해 보겠다. 우선 푸티를 사용해 공공 EC2 인스턴스에 로그인한다.

ec2-user

EC2 대시보드에서 사설 EC2 인스턴스를 선택한 후, 연결하기 단추를 눌러 보면 다음과 같은 과정이 표시된다.

  1. 푸티를 사용하여 SSH 클라이언트를 연다.
  2. .pem 형식의 키 파일을 공공 EC2 인스턴스로 전송한다. 공공 EC2 인스턴스에서 문을 따고 사설 인스턴스로 들어가야 하기 때문이다.
  3. 키 파일은 외부에서 보여선 안 된다. 외부에서 .pem 파일을 접근할 수 있다는 경고가 뜨면 chmod 400 (키 파일 이름).pem으로 접근 권한을 조정해 준다.
  4. ssh -i "(키 파일 이름).pem" ec2-user@(사설 EC2 인스턴스의 사설 IP 주소) 명령문으로 사설 인스턴스에 접근할 수 있다.

파일질라로 .pem 파일을 공공 EC2 인스턴스로 전송한다.

먼저 공공 EC2 명령창에서 ssh -i "(키 파일 이름).pem" ec2-user@(사설 EC2 인스턴스의 사설 IP 주소) 명령문을 실행해 본다.

ssh -i "chapter2.pem" ec2-user@10.0.1.15

키 파일이 보호되지 않고 노출되어 진행할 수 없다는 경고가 표시되었다. chmod 400 (키 파일 이름).pem를 적용해 준다.

SSH 명령문을 다시 실행하면 새로운 EC2 인스턴스가 불려오면서, 커서 옆 사용자 사설 IP 주소가 변경된 것을 볼 수 있다. 상단의 공공 EC2 인스턴스의 사설 IP 주소인 10.0.0.86에서 사설 EC2 인스턴스의 사설 IP 주소인 10.0.1.15로 바뀌었다. 사설 인스턴스에 접속한 것이다.

핑 테스트 (Ping Test)

로그인이 되었으니 이전에 만들어준 NAT 게이트웨이를 통해 인터넷 통신이 원활한지 확인하기 위해 핑 테스트를 해 보겠다. 핑 테스트란 네트워크 연결 상태를 진단하기 위해 신호를 보내보는 시험이다. 성능뿐만 아니라 지연 시간까지 측정할 수 있다.

ping 8.8.8.8

IP 주소 8.8.8.8은 구글의 주소이다. 한 줄 한 줄 기록이 남으며 연결이 잘 된다.

데이터베이스 서버

이제 사설 EC2 인스턴스에서 인터넷에 접속하여 MySQL을 설치해 보겠다.

사설 인스턴스 명령창에서 우선 sudo yum update로 패키지를 최신 버전으로 갱신한다.

sudo yum install mysql56-server

나는 MySQL 5.6 버전을 깔아보겠다. sudo yum install mysql56-server 명령문으로 설치를 진행한다.

설치가 완료되면 우선 my.cnf 설정 파일에 접근하여 데이터베이스에서 한글이 깨지지 않도록 인코딩을 UTF-8로 변경해 주어야 한다.

sudo vi /etc/my.cnf

sudo vi /etc/my.cnfmy.cnf 파일을 편집기로 열어 아래 내용을 추가해 준다.

sudo vi /etc/my.cnf

그리고는 sudo su root를 이용해 관리자 권한으로 MySQL을 가동해 본다. 시동 명령은 service mysqld start이다.

service mysqld start

[ OK ]로 MySQL 서버가 돌아감을 확인할 수 있다. 이어서 mysqladmin -u root password 명령어로 MySQL 내에서 관리자 계정의 비밀 번호를 지정해 준다.

mysqladmin -u root password

mysql -u root -p을 입력하고 비밀 번호를 제공하면 왼쪽 커서가 mysql>로 변하며 DBMS 내에 성공적으로 들어왔음을 알 수 있다.

로컬 컴퓨터의 MySQL에서 개발할 때 사용했던 데이터베이스 테이블을 모두 이 클라우드의 사설 인스턴스로 옮겨준다.

SHOW TABLES;

이제 이 데이터베이스를 공공 EC2 인스턴스에서도 접근해 자료를 열람할 수 있도록 일반 사용자 권한을 생성한다.

일반 사용자 권한 생성

그리고 사설 EC2 인스턴스를 감싸는 보안 그룹에 가서 MySQL이 기본으로 사용하는 3306번 포트를 열어주겠다고 설정한다. 보안을 위해서는 이러면 안 되지만 일단은 시험해보기 위해 출처를 모든 IP 주소에 해당하는 0.0.0.0/0으로 받았다.

그리고 마지막으로 공공 EC2 인스턴스에 있는 WAR 파일에서 jdbc.properties를 수정해 주어야 한다.

sudo vi /var/lib/tomcat8/webapps/socialMedia/WEB-INF/config/jdbc/jdbc.properties

아래 빨간 상자 부분을 localhost에서 사설 EC2 인스턴스의 사설 IP 주소로 변경하고 저장해줘야 데이터베이스와 연동이 가능하다.

jdbc.properties

그리고 톰캣 서버와 MySQL을 한 번 더 재가동해주었다.

브라우저에서 호출한 결과 회원 가입, 로그인, 팔로우, 피드 기능 등이 정상적으로 구현되는 것을 확인할 수 있었다.

느낀 점

코드프레소 과정 덕에 난생 처음으로 웹 개발이라는 것을 해봤고, 말로만 듣던 아마존 웹 서비스까지 빠른 기간 내에 경험해 볼 수 있어 좋았다. 코딩도 코딩이지만 개발자라면 여러 방면에서 끈기, 검색 능력, 문제 해결 능력을 발휘해야 한다는 점을 또 한 번 느꼈다.

이번 클라우드 배포 과정에서 유독 까다롭다고 느낀 점은 아래와 같다.

  1. 다양한 인터페이스와 환경을 거치는데 흐름을 파악하기가 쉽지 않았다. 아마존 콘솔과 푸티를 오가며 VPC와 서브넷과 EC2 인스턴스의 관계는 어떻게 되고, NAT 게이트웨이와 라우팅 테이블은 왜 쓰는 것인지 처음에는 흐름이 생소했다.
  2. 인터넷과 통신 기술, 규약 등에 대해 전반적인 지식을 더 쌓을 필요성을 느꼈다. IoT 수업을 들을 때에도 그랬지만, IP 주소를 다루고, SSH에 접속하고, 각종 포트를 열고 닫으며 통신하는 대목이 아직도 조금 낯설다.
  3. 버전 문제에 발목을 잡혔다. 클라우드 구조를 다 구축하고 서버를 가동했을 때는 브라우저에 오류만 반환됐다. 개발과는 달라서 디버깅이 오래도 걸리고 막막했지만, 자바 버전을 바꿔 문제를 해결할 수 있었다. 도와주신 동기 교육생 형들께 감사하다.

이렇게 지난 몇 주간 코딩해왔던 개발 프로젝트를 아마존 클라우드로 배포하는 실습을 마친다.

참고 : AllenChoiPage, 고마운 마음, 코린이의 개발 노트, beygee.log

--

--

No responses yet