데이터 사이언스를 위한 네트워크 Part 2
Part 1에서 다룬 이론을 바탕으로 AWS 화면과 친숙해지자
데이터 사이언스를 위한 네트워크 Part 2
이번 글에서는 AWS를 다루면서 보는 익숙하지만 생소한 용어들에서 다루려고 합니다. 자주봐서 익숙하기는 하지만 어떤 역할을 하는지, 어떤 개념인지는 잘 모르고 넘어가는 경우가 많습니다. 경험 상 이러한 개념적인 부분이 제대로 다져지지 않으면 업무를 할때마다 찾아보게 되서 생산성이 낮아지곤 했습니다. 이번 글을 통해 개념을 제대로 다지는 계기가 되었으면 좋겠습니다.
AWS? GCP는 뭐에요?
AWS란? 이라고 검색했을때 나오는 결과들은 대체로 ‘클라우드 컴퓨팅 플랫폼’이라고 설명하고 있습니다. 클라우드 컴퓨팅 플랫폼 서비스라고 하면 Amazon같은 거대한 회사에 있는 거대한 서버를 비용을 지불하고 내가 쓸 만큼만 사용하는 서비스라고 생각하실 겁니다. 맞습니다. 하지만 한 발자국 더 들어가서 생각해보면, ‘내가 쓸 만큼? 어떻게 내가 쓰는 부분을 따로 나눌 수 있는거지?’라는 의문이 생길 수 있습니다. 실제로 사용하면서도 어떻게 내 것만 잘 분리가 되는지 의문이 드실 수 있습니다.
VPC(Virtual Private Cloud)
AWS는 VPC를 이용해서 다른 사용자와 나를 분리시킵니다. 설명에 들어가기 전에 먼저 VPN에서 다뤄보겠습니다. VPN은 Virtual Private Network으로 실제로는 같은 네트워크 망에 있지만, 논리적으로 다른 네트워크인 것처럼 동작하는 것을 말합니다. VPC역시 같은 클라우드지만, 논리적으로 구역을 나눠놓은 것입니다.
VPC를 사용하게 되면 위 그림에서 아래 그림으로 구조가 변경됩니다. 복잡하던 시스템이 간단하게 바뀌었고 각각의 VPC는 완전히 독립된 네트워크처럼 작동할 수 있게 됩니다.
VPC를 구축하기 위해서는 사설 아이피, Private IP 대역에 맞춰야 합니다. 일반적인 IP는 Public IP로, 외부에서 사용하는, 한 곳에서만 사용할 수 있는 아이피입니다. 어떤 사람이 IP를 점유했다면, 그 IP는 다른 사람이 사용할 수 없습니다. Private IP는 내부 사용자들끼리 사용하는 IP입니다. 따라서 192.168.0.53이라는 IP는 누군가의 집 컴퓨터에서 사용하고 있는 Private IP일 수 있습니다. 결론적으로 클라우드 서비스 시스템은 어떻게 내가 사용할 클라우드를 나누냐면, 이 Private IP 범위를 이용해서 구역을 나누어 관리하는 것입니다.
Public IP와 Private IP가 쉽게 다가오지 않을 수 있을 것 같습니다. 비유를 해보자면, 서울시 강남구 XX아파트 1302동 704호는 Public IP라고 할 수 있고 그 집 내부의 안방은 Private IP라고 할 수 있습니다. 아파트의 주소는 세상에 딱 하나이지만, 안방은 어떤 집에서도 갖고 있는 곳이기 때문입니다.
이렇게 한번 설정된 아이피 대역은 수정이 불가하며 각 VPC는 하나의 리전에 종속됩니다. 각각의 VPC는 완전히 독립적이며, 만약 VPC간 통신을 원한다면 VPC 피어링 서비스를 고려해볼 수 있습니다.
서브넷
이제 서브넷을 구성할 수 있습니다. 처음 AWS EC2를 만들 때 어렵고 난감했던 개념이 서브넷이였습니다. 서브넷은 그림에서 보듯이 VPC를 더 잘게 쪼갠 것입니다. 목적에 따라서 퍼블릭 또는 프라이빗으로 설정할 수 있습니다. 퍼블릭은 누구나 들어올 수 있도록 설정한 것이고, 프라이빗은 특정 대상만 들어오는 것을 허용한다는 것입니다. 누구나 들어올 수 있다는 것은 인터넷 통신이 자유롭다는 말입니다.
보통 회사에서는 보안 때문에 프라이빗 서브넷을 구성해놓고 특정 대역을 열어 서비스하는 경우가 많습니다. 그런데 만약 프라이빗 서브넷의 EC2 인스턴스에서 텐서플로를 사용할 일이 있어 pip install tensorflow 를 한다면 어떻게 될까요? 프라이빗 서브넷은 인터넷 통신이 자유롭지 않기 때문에 별도의 설정이 없다면 설치가 되지 않을 것입니다.
NAT
그래서 NAT 게이트웨이가 필요합니다. NAT 게이트 웨이는 프라이빗 서브넷이 인터넷과 통신하기 위한 아웃바운드 인스턴스입니다. 프라이빗 네트워크가 외부에서 요청되는 인바운드는 필요 없더라도 인스턴스의 펌웨어나 혹은 주기적인 업데이트가 필요하여 아웃바운드 트래픽만 허용되야 할 경우가 있습니다. 이때 퍼블릭 서브넷 상에서 동작하는 NAT 게이트웨이는 프라이빗 서브넷에서 외부로 요청하는 아웃바운드 트래픽을 받아 인터넷 게이트웨이와 연결합니다. 이렇게 되면 프라이빗 서브넷 안에서도 자유롭게 텐서플로를 설치할 수 있습니다.
보안그룹
위에 개념을 숙지하고 호기롭게 AWS 클라우드를 이용하려고 하면 두 번째로 마주치는 벽이 바로 보안그룹입니다. 일종의 방화벽으로 쉽게 말하자면, 허용할 IP대역과 Port를 지정하는 것입니다. 관리하는 부분은 인바운드 트래픽과 아웃바운드 트래픽입니다. 보통 아웃바운드 트래픽은 제한을 걸어두지 않습니다. 네트워크가 나가는 것이기 때문에 크게 신경을 쓰지 않는 경우가 대부분입니다. 중요한 것은 들어오는, 인바운드 트래픽입니다. 회사나 집에 아무나 들어올 수 없는 것처럼, 클라우드에서도 보안그룹을 이용해서 들어올 인터넷 통신을 관리합니다. 방화벽 역할을 하는 것에는 사실 네트워크 ACL도 있지만 생략하도록 하겠습니다. 만약 보안정책인 네트워크 ACL과 보안그룹이 충돌한다면 보안그룹이 더 높은 우선순위를 갖습니다.
Port & Protocol
보안그룹 설정을 실제로 하려고 들어가면 설정할 것이 Port와 Protocol입니다. 프로토콜을 먼저 선택하게 되는데, 실제로 클릭하게 되면 각종 알수없는 영어들의 리스트가 주르륵 흘러나옵니다. 대표적인 몇 가지만 알아보도록 하겠습니다.
프로토콜 유형에서 모든 트래픽을 기준으로 설명을 할 수 있을 것 같습니다. 모든 트래픽의 윗 부분은 TCP/UDP에 관한 내용이고 그 아랫부분은 well-known 포트로 많이 사용하는 포트에 대해서 미리 지정해 놓은 것입니다. 보통 well-known 포트는 0~1023의 범위입니다.
TCP / UDP
TCP와 UDP는 OCI 7 Layer에서 4번째 Layer인 Transport Layer에 해당됩니다. 이 레이어의 역할은 저번 글에서도 다뤘듯이, End to End 서비스 , 커넥션(연결)을 관리하고 서비스와 서비스의 연결을 관리하며 TCP UDP 소켓을 통한 프로세스 별 통신을 하게 됩니다. 이 레이어에서는 port to port로 통신, 데이터는 segment라고 불리우고 있습니다. TCP와 UDP는 성격이 조금 다릅니다. TCP는 통신에서 정확성(신뢰성 있는 전송기능)을 중시한다면 UDP는 속도를 더 중시합니다.
TCP 프로토콜은 언제 사용할까요? 은행 서비스를 생각해 봅시다. 빠른 속도를 위해 신뢰성은 신경쓰지않고 은행 서비스를 구축했고 가족에게 1억원을 송금했습니다. 그런데 처리되는 도중에 에러가 발생해 1만원을 보낸 것이라고 처리가 되었습니다. 재앙이 발생했습니다.
TCP는 이렇듯 신뢰성있는 데이터 전송(RDT, Reliable Data Transfer)이 필요할 때 사용하게 됩니다. 그 외에 연결 제어, 흐름 제어, 혼잡 제어 기능을 수행할 수 있습니다.
UDP는 TCP에 비해 간단합니다. TCP에서 제공하는 기능을 제공하지 않으면 UDP기 때문입니다. 기능이 적어졌으므로 굉장히 가벼워 Overhead가 매우 적습니다. 따라서 많은 요청에 대해서 처리해야 하고, 신뢰성이 필요하지 않은 서비스에서 유용하게 사용됩니다. 혹시 UDP가 익숙하지 않으신가요?
학교 컴퓨터실에서 스타크래프트를 할 때 방을 만들때면 꼭, UDP를 사용했었던 것이 어렴풋이 기억이 나실 수도 있겠습니다. 이렇듯, 온라인 게임이나 DNS, 음성 인터넷 프로토콜, 동영상 서비스 등에서 UDP 프로토콜을 사용하고 있습니다.
Reference
https://medium.com/harrythegreat/aws-가장쉽게-vpc-개념잡기-71eef95a7098
데이터 사이언스를 위한 네트워크 Part 2