블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


구글 클라우드 로드밸런서 소개

조대협 (http://bcho.tistory.com)


클라우드 플랫폼에서 가장 필요한 기능중의 하나가 로드밸런서이다.

그중에서 구글 클라우드의 로드밸런서는 L7 스위치 이상의 기능을 가지면서 로드밸런서와 api gateway의 일부 기능을 수행할 수 있는데, 어떤 특징이 있는지 살펴보자. (개인적인 생각이지만 이게 정말 물건이다..)

HTTP 프로토콜 지원

TCP,UDP 뿐 아니라 HTTP 레이어의 로드밸런싱을 지원한다. HTTPS Termination을 당연히 지원하고 HTTP 모드로 부하분산을 할 경우 HTTP URI에 따라 다양한 라우팅을 할 수 있다.

No warming

다른 클라우드 로드밸런서와는 달리 트래픽이 갑자기 많이 들어오더라도 별도의 워밍업작업 없이 트래픽을 받을 수 있다. 클라우드 로드밸런서의 경우에는 종종 수십분간 워밍(부하를 지속해서 넣어서 로드밸런서의 용량을 늘려주는 행위)을 해주지 않으면 큰 대역폭의 트래픽을 못 받는 경우가 있다.

리전간 부하 분산과 서버 그룹간 부하 분산

여기 부터가 재미있는 기능인데, 들어오는 트래픽에 따라서 특정 리전(국가)로 라우팅을 하도록 설정할 수 있고, 별도의 설정이 없으면 자동으로 클라이언트가 가까운 데이타 센터로 트래픽을 라우팅해줄 수 있다.


아래 그림은 HTTP 요청을 US와 EU 리전에 있는 각각의 서버 그룹으로 분산하고, HTTPS요청도 US와 EU에 있는 각각의 리전으로 분산하는 구조를 설명한 그림이다.


(출처 : https://cloud.google.com/compute/docs/load-balancing/http/cross-region-example#overview)


리전간 부하 분산을 하면 리전 단위의 장애 대응이 가능할 뿐만 아니라, 가장 가까운 데이타 센터로 부터 호출을 할 수 있기 때문에 네트워크 구간 시간을 줄일 수 있다.


위의 그림에서 봐야 할것중 하나가 서버 그룹간의 부하 분산인데, 같은 애플리케이션이라도 “인스턴스 그룹" 이라는 개념으로 서버들을 묶을 수 있다. 위에 HTTP 를 지원하는 애플리케이션은 두개의 그룹으로 정의되어 있는데, 이렇게 서버를 여러개의 그룹으로 묶으면 좋은 점이 롤링 업그레이드가 가능하다는 것이다. 즉 그룹 A,B가 있을때, A를 로드 밸런서에서 떼어서 업데에트 한 후 다시 붙이고, 그 다음은 그룹 B를 로드밸런서에서에서 떼어서 업데이트 한 후 다시 붙여서 서버 배포나 업데이트시에 무장애로 진행이 가능하다.

HTTP URI 기반의 부하 분산

매우 흥미로운 기능중 하나가 HTTP의 URI를 기반으로 특정 서버 그룹으로 요청을 라우팅 할 수 있는 기능이다. 일반적인 네트워크 장비인 L4등에서는 구현이 불가능한 기능인데 원리는 단순하다.

아래 그림처럼 /static URL를 갖는 요청은 “static-resources” 라는 서버 그룹으로 라우팅 하고, /video URL을 갖는 요청은 “video-resources”라는 서버 그룹으로 라우팅 하는 식이다.



출처 : https://cloud.google.com/compute/docs/load-balancing/http/content-based-example#overview


매우 간단한 기능이기는 하지만 그 활용도가 매우 높다.

웹서버, 스트리밍 서버등으로 컨텐츠 타입에 따라 서버를 나눌 수 도 있지만,

마이크로 서비스 아키텍쳐 (MSA)로 되어 있는 경우, 각 서비스 컴포넌트가 다른 URL을 가지기 때문에, 앞단에 API Gateway와 같이 URL에 따라 라우팅을 해주는 프록시 계층이 필요한데, 구글의 로드밸런서는 이 기능을 지원하기 때문에, 백앤드 서비스가 MSA로 구성되어 있을 경우 이 기능을 유용하게 사용할 수 있다.

글로벌 엣지 서버와 통합을 통한 네트워크 가속

다른 글에서도 설명했던 내용인데, 구글 클라우드 로드 밸런서를 사용하게 되면 전세계에 흩어져 있는 약 70여개의 엣지 노드를 통해서 요청 트래픽을 받는다. 가장 가까운 엣지 노드로 트래픽을 받은 후, 엣지노드에서 서버까지 구글의 광케이블을 통해서 트래픽을 전달해줘서, 글로벌 서비스의 경우 네트워크 지연 시간을 절약할 수 있다.



자세한 내용은 http://bcho.tistory.com/1109 를 참고


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 박찬민 2017.01.11 16:17  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 덕분에 좋은 정보 배웠습니다.
    헌데, 질문이 하나 생겼습니다.
    구글 로드밸런서를 사용했을 때, 서버가 구글 VM이 아닐 경우에도 구글의 엣지노드를 통해서 서버 인근의 엣지노드 까지 트래픽이 구글 네트워크를 타고 와서 서버까지는 public 인터넷을 통해서 오게 되는 건가요?

    감사합니다.