31. 로드밸런서 & DNS

ip주소를 통해 배포를 하게되면 모든 Ip주소를 외우고 다닐수 없기때문에 도메인을 구입해서 쉽게 사이트에 접속 가능하도록 만들 수 있다. 또한 클라우드서비스를 이용하여서 배포하는 방법도 함께 공부해봤다!

---

DNS

 우리의 사이트를 좀더 쉽게, 직관적으로 알아보고 접속할 수 있도록 도메인을 우리의 IP로 연결된 사이트와 결합해주어야하는데 이를 DNS 설정이라고 한다. 나는 내 프로젝트에 도메인을 연결해 주기 위해서 '가비아'라는 사이트에서 원하는 도메인주소를 구매했다!

웹을 넘어 클라우드로. 가비아

이곳에 원하는 도메인주소를 검색해본다.

여기서 구매한 도메인 이름을 실제 네트워크상에서 사용하는 IP 주소로 바꾸고 해당 IP 주소로 접속하는 과정이 필요한데 이런 전체 시스템을 DNS(Domain Name System)이라고 하고 이를통해 이제 내 프로젝트 사이트에 접속할 때 외우기 어려운 IP 주소 대신 해당 도메인 이름을 사용해서 검색하고 들어올 수 있다.

DNS 설정된 사이트 접속 과정 (www.google.com)

www.google.com를 주소창에 입력하면 입력한 URL 주소 중, 도메인 이름에 해당하는 google.com를 DNS 서버에서 검색을 한다. 이 때, 웹 브라우저는 DNS 서버에 검색하기 전에 캐싱된 DNS 기록들을 먼저 확인한다.

해당 도메인 이름에 맞는 IP 주소가 존재하면 DNS 서버에 해당 도메인 이름에 해당하는 IP주소를 요청하지 않고 캐싱된 IP주소를 바로 반환한다. 일치하는 IP주소가 존재하지 않는다면 다음 과정인 DNS 서버 요청으로 넘어간다.

DNS 서버가 호스팅하고 있는 서버의 IP 주소를 찾기 위해서 DNS query를 전달하게 되며 이 DNS query는 현재 DNS 서버에 원하는 IP 주소가 존재하지 않으면 다른 DNS서버를 방문하는 과정을 원하는 IP주소를 찾을 때 까지 반복한다. 해당 도메인 이름에 맞는 IP주소로 변환하는 과정은 점( . )을 기준으로 구분하여 구성된다.

IP 주소를 전달받게 되면 해당 IP주소의 웹 브라우저의 서버에 웹사이트에 맞는 html 문서를 요청한다. 이때 해당 HTTP 요청은 TCP/IP 프로토콜을 사용하여 서버로 전송된다.

출처 - https://velog.io/@tnehd1998/%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-www.google.com%EC%9D%84-%EC%9E%85%EB%A0%A5%ED%96%88%EC%9D%84-%EB%95%8C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95

 

서버리스 서비스

 나온지는 좀 됐는데 요즘 많이 사용하는 추세라고 해서 배워봤다. 말그대로 백엔드 서버가 존재하지 않는 서비스를 의미하는데 클라우드 서비스에서 cloud function 만 만들어서 올려놓는 것을 의미한다. 이렇게 만든 funtion들은 db에 올라가게 되고 기능을 수행하려할 때에는 이 클라우드 위에 있는 FUNTION을 호출하게된다. 이게 실제 백엔드 서버에서 api가 동작하는 것과 무슨 차이가 있냐면 서버가 항상 가동중이여야 하는지 아닌지의 차이가 있다. 따라서 백엔드 서버를 scale out, scale up 해야하고 모니터링을 해야한다. 또한 접속하는 이용자가 없음에도 불구하고 컴퓨터가 계속해서 24시간 켜져있어야한다. 즉, 서버비용의 부담이 증가하게된다. 하지만 클라우드 서비스에 존재하는 funtion을 이용하게되면 요청이 들어올때만 잠깐잠깐 서버를 키고 때문에 상대적으로 서버 비용이 상당히 줄어들게되고 효율적인 서버 운영이 가능해진다. 또한 모니터링에 대한 부담도 줄어들고 때문에 scale up에 대한 부분도 고려하지 않아도 된다. 하지만 이렇게 좋은 방식을 모두가 이용하지 못하는 가장 큰단점이 있다. 그것은 매우 느리다는 점이다. 매 요청이 들어올때마다 서버를 켯다껏다해야하니까 첫번째 요청에 대해서는 응답이 느릴 수 밖에 없다. 이를 cold start라고 한다. 이를 해결하고자 서버가 꺼지기 전에 의미없는 요청을 계속 보내서 서버가 꺼지지 않도록 하는 warm start 방식도 대두됐지만 이는 클라우드 funtion의 이점을 죽이는 일이기에 무의미하다. 그렇다면 이런 서버리스방식이 가장 유용하게 쓰이는 곳이 어딜까? 바로 관리자 서비스이다. 어차피 직원들이 보는거니까 좀 기다리면서 쓰면 비용을 줄일 수 있으니 딱 접합할 것이다. 하지만 이 점만 해결이된다면 대부분의 서비스들은 궁극적으로 서버리스 방식으로 운영하고 싶어할 것이다.

 

로드밸런서

유저의 접속량의 늘어날수록 백엔드 서버 컴퓨터가 늘어날 것이기 때문에 이러한 백엔드 서버 컴퓨터를 관리하기 쉽게 하나로 묶어 줄 인스턴스 그룹을 만들어주게 된다. 이때 그룹으로 묶인 각각의 서버 컴퓨터중 하나의 컴퓨터로만 부하가 집중되면 이를 분산해준 의미가 없어진다. 따라서 입력 부하를 각각의 인스턴스그룹의 서버들로 나누어서 할당해주는 기능을 하는 장치를 가운데 두게 되는데 이를 로드밸런서 또는 부하분산기라고 한다.

https://velog.io/@dhnjun9/TIL-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%8B%B1

로드밸런서에서 트래픽을 백엔드 서버로 넘겨주는 것을 proxy라고 한다. 이 과정에서 포트포워딩 개념도 포함되어있는데 예를들어 80번포트를 3000번 포트로 넘겨주거나 http로 들어온 요청을 https로 바꿔주는 등의 역할을 한다. 이는 Nginx의 역할과 비슷하다. 그렇다면 이 둘의 차이는 무엇일까? Nginx에도 Https를 사용하기위한 SSL 인증서를 다운받아 설치할 수 있다. 하지만 Nginx 와 로드밸런서의 차이는 Nginx에는 proxy기능뿐아니라 보안적인 기능도 포함되어있다. 따라서 자체적으로 위험적인 요소는 백엔드 서버로 넘겨주지 않거나 할 수 있다. 로드밸런서의 입력포트는 80과 443만 받게 하여 http , https 에 해당하는 입력에서 포트번호를 생략해도 되도록 만들 수 있다.

 

로드밸런서의 기능

• Health Check

서버들에 대한 주기적인 health check를 통해 서버들의 장애 여부를 판단하고 이상이 있는 경우 정상 동작 중인 서버로 트래픽을 보내주는 Fail-over 동작을 한다.

• Tunneling

클라이언트와 서버 중간에서 터널링을 제공, 터널링이란? 데이터 스트림을 인터넷 상에서 가상의 파이프를 통해 전달시키는 기술

• NAT(Network Address Translation)

목적지와 수신지의 IP 주소와 TCP/UDP 포트를 재기록하여 변환해주는 기능, 여러개의 호스트가 하나의 공인 IP 주소를 통해 접속하게 한다.

• DSR(Direct Server Routing)

서버에서 클라이언트로 되돌아가는 경우, 네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트로 찾아가는 방식으로, 로드밸런서의 부하를 줄여준다.

 

Reference

https://velog.io/@dhnjun9/TIL-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%8B%B1