1년 전 서울시립대학교 컴퓨터 학술 중앙 동아리 퀴푸(QUIPU)에서 동아리를 소개하는 메인 웹(quipu.uos.ac.kr)을 만들어 배포하였다.
비용적인 문제로 클라우드에서 온프레미스로 배포 환경을 바꿀 예정인데, 현재와 앞으로의 배포 구조를 알아보며 필요한 네트워크 개념을 정리하려 한다.
키워드 정리
클라이언트와 서버
간단하게는 클라이언트는 서비스를 요청하는 쪽, 서버는 요청을 처리하고 응답하는 쪽이다.
조금 의문이 생겼다.
데이터를 주고받는 방식에 대한 규칙을 정해놓은 것을 '프로토콜'이라고 하는데, 프로토콜 중 HTTP와 WebSocket에서 클라이언트와 서버의 역할이 헷갈렸다.
HTTP는 클라이언트에서 서버로 먼저 데이터를 주고 응답을 하는 '단방향 통신'을 지원한다.
하지만 WebSocket는 '양방향 통신'을 지원하는데, 클라이언트와 서버가 서로 먼저 데이터를 주고 받을 수 있다. 그럼 정의에 따라 클라이언트와 서버가 어떻게 구분될 수 있는지 의문이 생겼다.
찾아보고 내린 결론은 '요청'의 의미가 HTTP와 WebSocket에서 조금 다르다.
HTTP에서는 클라이언트가 서버에 데이터를 먼저 보내며 '요청'을 한다. 이 요청이 없으면 서버는 클라이언트에게 아무것도 보낼 수 없다. HTTP에서의 '요청'은 클라이언트가 서버에 데이터를 먼저 보내는 행위이다.
WebSocket에서도 '요청'은 클라이언트가 서버에 데이터를 보내는 행위이다. 다만, 서버도 클라이언트에 데이터를 먼저 능동적으로 보낼 수 있는데 이를 '요청'이라고 부르지는 않는다. 요청이 아닌 능동적 데이터 전달이다. 여전히 사용자의 상호작용을 기반으로 서버에 요청을 하고 서버는 응답을 한다. 또한 요청 없이도 서버는 데이터를 클라이언트로 보낼 수 있는 것이다.
WebSocket에서 서버는 연결된 클라이언트들에게 데이터를 보내며 관리하거나 클라이언트끼리 소통을 할 수 있도록 중계 역할을 한다.
클라우드와 온프레미스
서버의 로직을 처리하는 위치에 따라 클라우드와 온프레미스로 구분한다.
온프레미스는 서버를 직접 회사나 개인의 PC에서 실행하는 방식이다. 네트워크 설정, 트래픽 관리, 하드웨어 유지보수 등을 직접 해야한다.
클라우드는 서버를 다른 업체의 마련된 인프라의 PC를 빌려서 실행하는 방식이다. 위의 작업들을 클라우드 업체에서 대신 해준다.
도메인, IP 그리고 DNS
클라이언트에서 서버에 요청을 보내려면 서버의 주소를 알아야 한다.
192.168.0.1과 같이 고유한 숫자로 이루어진 서버의 주소를 IP라고 한다.
기억하기 어려운 이 IP를 www.google.com 처럼 쉽게 기억할 수 있도록 만들어진 주소를 도메인이라고 한다.
클라이언트에서 입력한 도메인을 IP로 바꿔서 요청을 해야한다. 이때 바꿔주는 게 DNS이다.
Private IP, Public IP 그리고 NAT
IP(IPv4)는 32bit로 이루어져 있어 할당할 수 잇는 개수가 한정적이다. 이를 해결하기 위해 특정 IP를 재사용되도록 했는데 이때 나오는 개념이 Private IP, Public IP 이다.
Private IP는 한 네트워크 안에서만 사용되는 IP로 외부 네트워크에서는 접근할 수 없다.
Public IP는 외부 네트워크에서 접근할 수 있도록 전세계적으로 고유한 IP이다.
한 네트워크 내의 Private IP는 서로 중복될 수 없지만, 다른 네트워크에서 재사용할 수 있다.
Public IP와 Private IP을 맵핑하여 네트워크 내부에서 외부 또는 외부에서 내부로 이동할 수 있도록 하는게 NAT이다. 네트워크 당 하나의 Public IP를 할당하여 하나의 Public IP가 NAT에 의해 해당되는 Private IP로 맵핑을 해주어 IP 개수를 아낄 수 있다.
키워드 정리
클라이언트는 사용자와의 상호작용에 따라 서버에 요청하고, 서버는 요청을 처리하고 응답한다. 이때 온프레미스로 서버를 직접 배포하거나 클라우드 업체에서 자원을 빌려 배포할 수 있다.
클라이언트에서 도메인을 입력하면 DNS가 Public IP로 바꾸어 주고 NAT에 의해 서버가 배포되어 있는 네트워크 내의 Private IP로 맵핑되어 서버의 주소를 알 수 있다.
현재 동아리 웹 배포 구조
현재 동아리 메인 웹(https://quipu.uos.ac.kr/)의 배포 구조에 대해 알아보려 한다.
클라이언트에서 실행될 코드를 제공하고 백엔드로의 요청을 중계할 프론트엔드 서버와,
요청을 처리할 로직이 돌아가는 백엔드 서버가 필요하다.
현재 프론트엔드 서버는 깃허브에 배포되어 있고 도메인은 학교 도메인(uos.ac.kr)의 서버 도메인(quipu.uos.ac.kr)을 발급받았다.
백엔드 서버는 AWS에 배포하였고 도메인은 가비아에서 발급받았다.
즉 둘 다 클라우드로 배포를 하였다.
먼저 quipu.uos.ac.kr을 입력하면,
DNS 서버에서 프론트엔드 서버 도메인에 해당하는 Public IP를 반환해준다. 클라이언트는 이 IP로 GET 요청을 하고, 프론트엔드 서버는 HTML, CSS, JS를 반환해준다.
백엔드 서버 도메인으로 API 요청을 하면,
DNS 서버에서 백엔드 서버 도메인에 해당하는 Public IP를 반환해준다. 클라이언트는 이 IP로 API 요청을 하고 백엔드 서버는 요청을 처리하고 응답을 보낸다.
지금 내가 속해있는 네트워크 내 할당된 Private IP에서 NAT를 통해 Public IP로 빠져나가고 quipu.uos.ac.kr에 연결된 GitHub IP로 도달한다.
현재 배포 구조에 대한 문제점
클라우드를 선택한 이유는,
1. 초기 설정이 간단하다. 도메인과 Public IP 만 설정하고, NAT 설정 등 세부적인 네트워크 관리를 하지 않아도 돼서 빠르게 배포해서 서비스에 대한 반응을 보기 위한 목적에 적합했다.
2. 보다 쉽게 확장할 수 있다. 처음으로 경험하는 프로젝트라 트래픽과 서버 자원이 얼마나 필요한지 알기 힘들었다. 그래서 필요할 때 비용만 지불하면 서버를 쉽게 확장할 수 있기 때문에 클라우드를 선택했다.
하지만 1년을 사용해보니 느낀 점은,
클라우드 업체에게 지불해야하는 비용이 꽤나 컸다. 비용을 아끼기 위해 모집, 축제 등 서비스를 사용할 때만 서버를 켰다. 깃허브 서버(프론트엔드 서버)는 비용이 나가지 않아서 항상 도메인을 통해 들어갈 수는 있었지만, AWS 서버(백엔드 서버)는 꺼놔서 백오피스 웹이나 게임 웹들은 평상시에는 사용할 수가 없었다.
온프레미스로 바꾸게 되면,
비용을 크게 줄일 수 있다. 부품 값으로 인한 초기 비용만 투자하면 동아리방에서 부과되는 전기세는 직접 부담하지 않으니 장기적으로 비용 부담을 줄일 수 있을 것이다.
앞으로의 배포 계획
동아리방에 PC를 구비하고, 프론트엔드와 백엔드 서버 모두 학교 네트워크에 접속된 동방의 PC에 배포하려 한다.
학교 도메인(uos.ac.kr)을 사용하기 위해 3개의 신청서를 학교 측에 제출해야 한다.
1. 고정 IP 신청서
2. 도메인 신청서
3. 네트워크 포트 신청서
고정 IP 신청서
네트워크에 재접속할 때마다 다른 IP가 할당된다. 그때마다 설정을 바꿔야 하는 번거로움이 있기 때문에 이를 위해 고정 IP를 발급해야 한다.
현재 서버에 설정된 임시 Private IP와 MAC 주소를 적어야 한다. 이때 임시 Private IP를 적는 이유는 고정 Private IP와 중복되지 않도록 하기 위함이고, MAC 주소는 데이터를 전달하는 하드웨어 주소이다. (IP는 네트워크 상의 주소)
도메인 신청서
도메인명(quipu.uos.ac.kr)과 IP 주소는 학교 네트워크 내 발급받은 고정 Private IP을 적어야 한다. 이 고정 IP가 발급받을 Public IP와 맵핑이 된다.
네트워크 포트 신청서
포트는 하나의 IP 주소에서 실행되는 서버스를 구분하는 역할을 한다.
172.16.133.153 IP가 할당된 서버에서 여러 개의 서비스를 배포할 때 이 서비스는 포트번호로 구별된다. 예를 들어 quipu.uos.ac.kr은 80포트에, game.quipu.uos.ac.kr은 8080포트에 배포될 수 있다는 것이다.
이 고정 IP가 할당된 서버가 사용할 포트를 신청하여 열어달라고 요청을 해야한다.
이 경우에는 Source에 any를 적어 모든 클라이언트가 접근 가능하도록 설정하고, Destination에 서버의 고정 Private IP를 적었다.
신청 결과는?
학교 네트워크 내 할당된 고정 IP(IP 주소)와 외부 네트워크에서 접속할 수 있는 Public IP(NAT IP)를 맵핑해서 준다. 그리고 네트워크를 구분하는 기준이 되는 서브넷마스크와 내부 네트워크와 외부 네트워크를 연결하는 라우터인 게이트웨이의 IP를 제공한다. 또 도메인을 IP로 바꿔주는 메인 DNS와 보조 DNS 서버의 IP를 제공한다.
이 내용을 도식화하면,
quipu.uos.ac.kr을 입력하면,
1. 메인 DNS 서버에서 NAT IP(Public IP)를 반환한다.
2. NAT IP에서 게이트웨이를 통해 학교 네트워크 내 고정 Prvate IP로 변환이 되며 요청을 한다.
정리
현재는 클라우드로 배포되어 있지만, 방학 기간에 동방에 직접 서버 컴퓨터를 구비해서 온프레미스로 배포할 예정이다.
클라우드와 온프레미스는 서버의 위치와 책임의 차이일 뿐 동작 원리는 동일하다.
핵심은
1. 클라이언트에서 도메인(quipu.uos.ac.kr)을 입력하면
2. DNS가 도메인을 Public IP로 변환하고
3. Public IP는 NAT를 통해 Private IP로 변환되어 서버로 요청한다.
4. 서버는 요청을 처리하고 클라이언트로 응답한다.
