데이터베이스 서버와 애플리케이션 서버를 분리해보자 : 개념

저는 항상 의문점이 있었던 것이 애플리케이션 서버와 데이터베이스 서버를 나누게 되면 이 둘은 어떻게 통신을 하는가? 였습니다. 

 

제가 기존에 배포하던 방식인 EC2 인스턴스에 애플리케이션과 데이터베이스를 동시에 두게 되면 보안상 좋지 않다는 말을 들었습니다. 

 

그래서 이 부분에 대해서 GPT에게 물어봤더니 VPC를 사용하면 된다는 말만 끊임없이 하더군요. 그 당시에는 VPC가 뭔지 도 몰랐고 그냥 VPC를 쓰면 되는구나 하고 넘어갔습니다. 

 

이번 포스팅에선 본격적으로 VPC를 이용해 애플리케이션 서버와 데이터베이스 서버를 분리시켜보도록 하겠습니다. 시작해보죠.

 

VPC가 뭐야?

VPC는 Virtual Private Cloud의 약자로 직역하면 가상의 클라우드 환경이라는 말입니다. 

 

만약 VPC가 없다면 각각의 인스턴스들이 거미줄처럼 서로 복잡하게 엮여있을 것입니다. 

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

이러한 구조는 시스템의 복잡도를 높일 뿐만 아니라 하나의 인스턴스만 추가되어도 모든 인스턴스를 수정해야하는 불편함이 생깁니다. 

 

이런 구조에서 VPC는 인스턴스를 정리해주고 객체지향스럽게 서버를 구성할 수 있게 됩니다. 

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

 

서브넷

VPC를 알았다면 이제 서브넷 차례입니다. 서브넷은 VPC안에서 EC2 인스턴스들을 더 잘게 세분화할 수 있도록 도와주는 개념입니다. 

 

서브넷을 통해 EC2 인스턴스를 조금 더 유연하게 관리할 수 있고, VPC만 사용할 때보다 더 객체지향스럽게 설계할 수 있다는 부분에서 저도 애용하는 시스템입니다. 

 

서브넷에는 private subnet과 public subnet이 있어서 이 둘을 이용하면 어떤 서브넷을 격리시키고 어떤 서브넷을 노출시킬지 결정할 수 있습니다. 

 

눈치 빠르신 분들은 여기서 대충 감이 오셨겠지만 private subnet에 데이터베이스 서버를, public subnet에 애플리케이션 서버를 두어 데이터베이스 서버의 보안을 한층 더 끌어올릴 수 있게 됩니다. 

 

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

서브넷은 VPC안에 포함되는 개념이기 때문에 이 둘을 상속관계라고 나타내기위해 우리는 CIDR ("사이더" 라고 부릅니다.) 설정을 해줘야합니다. 

 

위 그림에서 VPC에 붙어있는 172.31.0.0/16 과 서브넷에 붙어있는 172.31.0.0/20 이 바로 그것입니다. 

 

CIDR에 대해서는 제가 아직 공부가 부족해서 더 공부한 후에 포스팅에 추가하도록 하겠습니다. 

 

대충 VPC와 서브넷의 상속관계를 표한하기 위한 수단이라고 생각해주시면 됩니다. 

 

 

라우터와 라우팅 테이블

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

서브넷끼리 서로 통신할 수 있도록 라우터를 중간에 두면 서브넷끼리 유동적인 네트워크 통신이 가능해집니다. 

 

중간에 라우터를 두면서 동시에 우리는 서브넷의 라우팅 테이블을 설정해줘야합니다. 라우팅 테이블은 해당 서브넷이 어떤 규칙에 의해 외부에서 요청을 받을 수 있게 될것인지를 설정합니다. 

 

위 그림에서 서브넷A의 라우팅 테이블에서 172.31.0.0/16 이 범위이고 타겟은 Local인 것은 서브넷A는 외부와 연결되지 않고 내부적으로만 통신하겠다는 의미로서 그림에선 나와있지 않지만 서브넷A는 private subnet으로 추측할 수 있습니다. 

 

 

인터넷 게이트웨이

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

인터넷 게이트웨이는 외부 네트워크망과 VPC를 연결해주는 개념으로 무슨 요청이 어떤 VPC로 향하게 할 것인지 나타냅니다. 

 

따라서 VPC가 여러개인 경우에는 인터넷 게이트웨이도 여러개를 설정해줘야 합니다. 

 

 

NAT 게이트웨이

NAT 게이트웨이는 인터넷 게이트웨이와 다르게 private subnet이 외부와 통신할 수 있도록 해주는 개념입니다. 

 

private subnet은 인터넷 게이트웨이와 연결되지 않아 외부와 네트워크 통신을 할 수 없습니다. 그렇다는 말은 우리가 흔히 패키지를 다운 받을 때 사용하는 apt-get 같은 명령어도 사용할 수 없다는 의미가 됩니다. 

 

이건 좀 곤란하긴 하죠. 우리는 필요에 의해서 도커도 다운받아야할 수도 있고, 무엇보다도 데이터베이스를 다운받아야 하기 때문이죠. 

 

따라서 우리는 NAT 게이트웨이를 설정해줌으로써 private subnet이 외부와 통신할 수 있도록 설정해줍니다. 

 

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

그림이 잘렸지만 NAT 게이트웨이는 public subnet에 위치해있게 됩니다. 

 

어? private subnet이 외부와 네트워크 통신할 수 있도록 해주는 것인데 왜 public subnet에 위치해있나요?

 

NAT 게이트웨이는 인터넷 게이트웨이와 통신해야 하기 때문에 public subnet에 위치하게 됩니다. 때문에 NAT 게이트웨이는 public subnet에 위치해있습니다. 

 

 

마치며

이렇게 VPC와 서브넷, 라우터와 라우팅 테이블, 인터넷 게이트웨이, NAT 게이트웨이까지 개념적인 부분에 대해서 알아봤습니다. 

 

이제 우리는 다음 포스팅에서 실전에 들어갑니다. VPC를 설정하고 서브넷, 라우터, 라우팅 테이블, 인터넷 게이트웨이, NAT 게이트웨이까지 설정하면서 궁극적으로 데이터베이스 서버와 애플리케이션 서버를 분리해보도록 하겠습니다. 

다음 포스팅

https://coding-review.tistory.com/452

데이터베이스 서버와 애플리케이션 서버를 분리해보자 : 실전1 (VPC와 서브넷)

 

이미지 출처

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

[AWS] 가장쉽게 VPC 개념잡기