어제는 지원서를 작성하느라 .. TIL 작성을 못했는데.. 오늘은 절대로 TIL을 미룰 수 없다!
오늘 TIL은 AWS의 VPC, Subnet, AZ, NAT 에 대한 개념, VPN과 Direct Connect의 차이, AWS VPN과 일반 VPN 서비스는 무슨 차이이며 왜 동일하게 VPN이라는 이름을 사용하는지, 프록시와 리버스 프록시의 개념과 적용 사례를 알아보려고 한다.
AWS에서 VPC는 Virtual Public Cloud의 약자이다. 뭔가 이름만 들어도 무슨 느낌인지 이해가 된다.
AWS 클라우드 내에서 가상으로 구성된 퍼블릭한 클라우드 공간이라고 보면된다. EC2나 S3와 같은 인스턴스들이 이 VPC 안에 배치된다고 보면 된다.
서브넷은 VPC 안에 있는 로컬 네트워크들이라고 할 수 있다. 즉 A라는 VPC 안에 a, b, c라는 서브넷이 존재할 수 있다. 이
이렇게 서브넷을 나눴을 때 장점 중 하나는 Private Subnet과 Public Subnet을 나눌 수 있다는 것이다.
Private Subnet은 인터넷이 연결되지 않은 서브넷이고 Public Subnet은 인터넷이 연결된 서브넷이라고 볼 수 있다.
따라서 직접 노출시키고 싶지 않은 서버 인스턴스는 Private Subnet에 넣고 Reverse Proxy와 같은 인스턴스는 Public Subnet에 두어 인터넷과 연결하는 등의 방법을 이용할 수 있다.
이 때 각 서브넷은 CIDR 표기법을 이용해 ip 주소를 표기한다. Classless Inter Domain Routing이라는 것인데 어려울 것 없다.
일단 이게 뭔지 알아보면 한 서브넷에 속한 인스턴스의 ip주소를 어떤 범위에서 할당할 것인지 정해주는 것이다.
예를 들어 127.01.0.0/24 이렇게 하면 127이 8비트, 01이 8비트, 0이 8비트, 0이 8비트인데 앞에 24비트는 고정값이고 뒤에 8비트만 바꾸어서 ip주소를 할당하겠다 라는 뜻이다
즉 예를 들어 127.01.0.0/24 서브넷 내부에 있는 인스턴스들은
127.01.0.0 ~ 127.01.0.255 사이의 ip 주소를 할당 받는다.
그래서 Inter Domain Routing이다.
그러면 Classless는 뭘까?
ip 주소에는 Class 라는 개념이 있는데 아래 그림을 보자.
<ip주소 클래스 그림>
이렇게 ip 주소의 범위를 정하고 이 부분은 A Class이고 A Class에 할당되는 ip 주소의 개체들은 어떤 기능을 수행해야한다. 와 같은 규칙이다. (이런 것을 Classful 하다고 한다.)
그런데 CIDR은 Classless, 즉 이런 클래스의 개념을 두지 않는다는 뜻을 가진다.
그래서 자유롭게 ip를 할당할 수 있다.
단, 127.01.0.0 ~ 127.01.0.3 / 127.01.0.255 이렇게 5개의 ip는 우리가 이용할 수 없다. (서브넷을 할당할 때마다, 이렇게 ip가 5개씩 할당되므로 이에 주의해야 한다.)
127.01.0.0은 이 서브넷의 식별 주소로 사용된다. 127.01.0.1은 게이트웨이의 ip 주소이다. 127.01.0.2은 DNS의 ip 주소이다. 인스턴스에 도메인이 할당되어 있다면 최종적으로 VPC에 도착한 요청이 도메인으로 되어있다면 DNS 쿼리를 127.01.0.2에 날려서 얻은 ip로 게이트웨이가 요청을 전달하게 된다. 127.01.0.3은 미래에 AWS가 새로운 서비스 등을 런칭할 때를 대비하기 위해 예비용으로 예약한 ip 주소이다. 127.01.0.255는 네트워크 브로드캐스트용 주소이다. 사실 AWS VPC는 브로드캐스트를 지원하지는 않으나, 네트워크 표준을 지키기 위해 예약한다.
AZ는 Availabity Zone 의 약칭인데 VPC를 2개 AZ에 복사해서 저장하게 된다. (물론 상황에 따라 2개의 AZ가 완전히 같은 VPC 구조를 가지지 않을 수도 있다.)
쉽게 생각하면 AZ를 2개 두면 한 개의 AZ가 고장나도 다른 AZ를 통해 작동할 수 있게 하기 위함이다.
인터넷 연결을 전담해주는 인스턴스라고 이해할 수 있다.
VPN은 Virtual Private Network의 약자인데
핵심은 사설 네트워크를 가상적으로 확장한다는 의미이다. 이 의미에 대해 알아보자.
AWS에서 VPN이란, 클라우드에 구성된 인스턴스 뿐 아니라, 온프레미스 서버도 AWS의 클라우드 사설 네트워크에 가상적으로 확장시키는 것을 말한다.
여기서 온프레미스란 부지의 즉 기업 부지 내에 있는 서버
말 그대로 기업 자체의 서버를 말한다.
이 기업 서버가 마치 AWS 클라우드의 네트워크에 합쳐진 것처럼 연결할 때 사용한다.
단, 이 방식은 인터넷을 통해 구현되기 때문에 보안 문제나 레이턴시 문제가 있을 수 있다.
그래서 실제 물리적으로 통신 가선을 AWS 클라우드와 직접 연결하는 방식이 Direct Connect 이다.
보통 VPN 서비스는 내 컴퓨터로 A라는 서버에 접속할 때 이를 내 컴퓨터에서 직접 서버에 요청을 보내는게 아니라, 우선 VPN 서비스를 제공하는 곳에 요청을 보낸 뒤 VPN 서비스를 제공하는 곳에서 A 서버에 요청을 보내어 마치 다른 ip에서 A 서버에 요청을 보내는 것처럼 만드는 것이다.
이것은 내 컴퓨터 Private Network를 가상적으로 확대해서 VPN 서비스 컴퓨터가 내 Private Network에 속한 것처럼 만들게 되고 그래서 VPN 컴퓨터의 ip 주소가 A 서버에 찍히게 되는 것이다. 이것이 일반적으로 사용하는 VPN 서비스이다.
여기에 추가적으로 내 요청에 대한 여러가지 보안 관련된 기능을 제시한다. 요청을 하는 데이터를 암호화 하는 등의 기술들이 추가된다.
프록시는 대리인이라는 뜻이다. 즉 무언가를 대신하는 존재라는 것이다.
네트워크에 있어서 무언가를 대신한다는 것은 무엇이고 그것으로 얻는 이점이 무엇일까?
프록시는 아까 VPN의 대리 서버랑 거의 비슷하다.
즉 내가 직접 요청을 보내는 것이 아니라, 프록시 서버에 요청을 한 뒤, 프록시 서버가 서버에 요청을 보내게 된다.
이렇게 되면 프록시 서버의 ip가 로그에 찍히면서 클라이언트의 ip를 보호한다.
VPN은 사실 프록시 기능을 포함하고 있다고 볼 수 있다. 물론 VPN은 추가적인 보안 기능을 제공하지만
이건 반대로 서버의 정보를 숨기기 위해 서버가 대리인을 두는 것이다.
즉 A 서버에 요청을 보내면 먼저 A 서버의 리버스 프록시 서버가 요청을 받는다.
그러면 리버스 프록시 서버가 실제 서버에 요청을 보내 정보를 얻은 뒤 이를 클라이언트에 보내서 서버의 ip를 보호한다.
웹 개발 도메인에서는 Apache나 Nginx와 같은 웹서버가 리버스 프록시의 역할도 수행한다.
물론 이러한 웹 서버는 리버스 프록시 뿐 아니라 로드 밸런싱 등 다양한 기능을 추가로 제공한다.
그래서 실제 WAS의 ip를 감출 수 있게 된다.
AWS 에서는 이러한 리버스 프록시를 Public Subnet에 두고, Private Subnet에 WAS를 두는 역할을 수행하는 구성으로 많이 아키텍쳐를 구성한다.
물론 AWS에서 제공하는 로드 밸런서를 이용해서 구현할 수도 있고 로드밸런서로 여러 Nginx로 보내서, 그걸 또 로드밸런싱을 할 수도 있다.