Microsoft Azure, 가상 컴퓨터(VM)의 가용성 집합(Availability Set), 그리고 부하 분산(Load Balancing)

Microsoft Azure를 사용하시다보면, 정기적인 유지 보수 작업을 위해서 시스템이 리부팅될 수 있다는 메일을 받을 수 있습니다. 해당 메일 내에는 다운 타임에 대응하기 위해, 가용성 집합(Availability Set)을 사용하라는 내용이 포함되어 있죠. 이를 활용해야, Microsoft Azure에서 보장하는 SLA(Service Level Agreement)를 보장한다는 것입니다. 금일 포스팅은 Microsoft Azure내 가상 머신에 대한 가용성을 높이는 방법을 살펴보려고 합니다.

가용성에 대한 이야기를 살펴보려면, 2가지 용어에 대해서 살펴보아야 합니다. 오류 도메인(Fault Domain, FD)와 업데이트 도메인(Update Domain, UD)입니다. 자세한 기술 페이지는 여기를 살펴보시면 좋습니다.

“FDs define the group of virtual machines that share a common power source and network switch.” 해당 링크내 내용에 FD에 대한 정의가 있습니다. 보통 데이터센터내 서버를 구성할 때, 서버를 단독적으로 구성해놓은 형태가 아니라, 렉이라는 캐비넷 형태로 탑재되게 됩니다. 하나의 렉에는 여러 대의 서버가 들어가는 형태가 되죠. 일반적인 IT 엔지니어라면 이해가 가시는 내용일 것입니다. 렉 단위에서 구성된 전원과 네트워크가 있게 되고, 여기서 문제가 발생하면 렉 전체의 서버들로 문제가 확장될 수 있습니다. 물론 이를 방지하기 위해 장치들에 대한 2중화 및 비상 처리 방안들을 만들게 되죠.

Microsoft Azure에서는 이러한 같은 전원과 네트워크 스위치로 구성된 하나의 렉을 하나의 오류 도메인(FD)으로 보게 됩니다. 장애에 대비하기 위해 2대 이상으로 무언가를 구성하더라도, 하나의 렉에 들어 있는 서버들에 배치되어 있다면, 하나의 오류 도메인이 장애를 발생시키면, 2대란 의미가 없어지죠.

더불어, 이미 예상되셨겠지만, Microsoft Azure내 많은 서비스들(가상 컴퓨터, 클라우드 서비스등)은 모두 Hyper-V 기반의 가상 컴퓨터(VM)에서 동작하게 됩니다. 당연히 하나의 서버에 가상화 기술을 통해 여러 VM들이 구동되고 있겠죠. 2대의 VM을 생성했을 경우, 구성 방법이 2대의 Hyper-V 호스트에 분리해서 1대씩 구성하는 것도 방법이지만, 구성상 1대의 Hyper-V 호스트에 2대의 VM들이 같이 배치될 수도 있습니다. 이 경우, 하나의 호스트가 문제를 일으키면, 2대의 VM이 모두 장애를 일으킬 수 있습니다. 이렇게 가상 컴퓨터들을 구동하는 하나의 호스트를 업데이트 도메인(UD, 예전에는 업그레이드 도메인이라고도 불렀습니다.)라고 봅니다.

사실 업데이트 도메인은 가상 컴퓨터, 네트워크, 스토리지를 구성하는 IaaS(Infrastructure as a Service) 형태보단, PaaS(Platform as a Service)에서 먼저 사용하던 개념입니다.

Microsoft 본사에서 유명한 마크 루시노비치의 블로그 포스팅 중 Windows Azure Host Updates: Why, When, and How에서 발췌해온 그림입니다. 앞서 언급한 바와 같이 Microsoft Azure는 서버 코어를 기반으로 구성이 되어 있고, 그 안에 Hyper-V 아키텍쳐와 동일한 형태로 VM(게스트 파티션)이 구성되게 됩니다. 호스트 파티션에는 호스트 자체와 VM들을 모니터링 및 구성하기 위한 FC(Fabric Controller) 호스트 에이전트가 있으며, 게스트 파티션에는 게스트 자체에 대한 모니터링 및 구성을 위한 게스트 에이전트(GA)가 있습니다.

일반적인 인프라와 동일하게 Hyper-V로 구성된 호스트는 주기적인 유지 보수를 위해 시스템을 다시 시작해야 할 경우가 있습니다. 대표적인 것이 시스템의 보안 업데이트가 적용되는 시점이죠. 보안 업데이트 뿐만 아니라, 성능, 안정성, 신뢰성, 효율성등을 위한 업데이트가 반영될 수도 있고, 최대한 다시 시작이 일어나지 않는 형태로 시스템의 업데이트를 반영한다고 합니다. 그러나 다시 시작이 필요한 경우가 발생할 수 있다는 것이 중요합니다. 이 경우, 해당 호스트내 VM은 일시적으로 구동을 하지 못하는 형태가 됩니다.

PaaS 형태 프로그램은 VM(인스턴스)과 연계되어 동작하지만, 해당 VM에 종속되는 형태가 아니라, 다른 VM에서 구동될 수 있는 형태로 동작하게 됩니다.(Stateless) 필요시 다른 VM을 생성하고, 해당되는 프로그램 패키지를 구성하게 되면, 필요시 스케일 아웃(Scale-Out)을 할 수 있고, 다시 반대의 경우도 구성할 수 있는 것이죠. 만약 부하 분산이라던가, 장애 대비를 위해 2개 이상의 인스턴스들을 구성했는데, 하나의 호스트에 있다면, 역시나 앞서 언급한 바와 같이 호스트 유지 보수나 장애시 전체 장애로 발전할 수 있습니다. 이러한 이유로 PaaS에서부터 시작된 컨셉이 호스트 하나를 하나의 업데이트 도메인으로 놓고, 2개 이상 인스턴스를 구성하게 되면, 호스트를 분리하는 형태로 구성하는 것입니다. 분리되어 있는 업데이트 도메인은 동시에 호스트 다시 시작이 일어나지 않습니다. 순차적으로 발생하게 되죠.

Microsoft Azure의 클라우드 서비스(PaaS)에 구동되는 응용 프로그램입니다. 10개의 인스턴스를 구성했더니, 업데이트 도메인이 5개, 오류 도메인이 2개가 구성되었습니다. 오류 도메인은 렉이 분리된 형태이며, 업데이트 도메인은 호스트가 분리된 형태입니다. 0번 FD에 UD0, 2, 4번이 배치되어 있고, 1번 FD에 UD1, 3번이 배치되어 있습니다. 기본적으로 구성된 PaaS용 응용 프로그램은 UD의 개수가 5개입니다. 최대 20개까지 구성 가능한 UD는 Microsoft Azure 서비스 정의 스키마 파일인 .csdef 파일내 upgradeDomainCount 값을 이용해서 수정할 수 있습니다. 관련된 정보는 여기를 참고하세요.

다시 IT 엔지니어 분들에게 중요한 VM 이야기로 돌아오겠습니다. 구성된 VM은 오류 도메인이 분리되어 구성되는 것이 우선 중요합니다. 이에 대한 구성이 바로 가용성 집합입니다.

VM을 생성할 때, 가용성 집합을 생성할지에 대해서 옵션이 나타납니다. 더불어 가용성 집합에 대한 부분은 VM 생성 후, 설정할 수도 있습니다.

설정은 매우 쉽습니다. 오류 도메인을 분리하여 운영할 VM들에서 우선 가용성 집합을 하나 생성하고, 다른 VM들을 해당 집합에 포함시키는 형태입니다.

같은 가용성 집합에 배치된 VM들은 오류 도메인을 별도로 생성하는 형태로 만들어지므로, 동시에 장애가 발생하지는 않는다는 것입니다. 2014년 8월 현재 Microsoft Azure는 IaaS/PaaS 모두, 최대 2개까지의 오류 도메인을 생성하고, VM을 배치하는 형태입니다. 또 한가지 중요한 사실은 오류 도메인을 분리해놓았다고, 데이터까지 모두 동일하게 구성된다는 것은 아닙니다. 말 그대로 VM 2대가 구성되어 있는 형태이며, VM내 운영 체제에 대한, 그리고 응용 프로그램, 데이터에 대한 동기화는 내부적으로 구성해야 합니다. 또한 하나의 VM에서 서비스되던 것이 유지 보수로 인한 호스트 다시 시작시, 또는 장애시 세션이 유지된 채로 다른 VM으로 장애 조치되지 않으므로, 이에 대한 추가적인 구성이 필요합니다. Hyper-V 서버를 구축해보신 분들은 실시간 마이그레이션(Live Migration) 형태가 있는지 궁금하실 수 있지만, 현재에는 VM에 대한 이전 후, 호스트가 다시 시작되는 형태로 Microsoft Azure VM이 구성되어 있지는 않습니다.

가용성 집합 형태로 구성된 VM들은 대부분 같은 형태의 서비스를 제공하는 VM들일 것입니다. 가용성 집합으로 가용성을 높혔다면, 서비스에 대한 부하 분산을 고려하는 형태까지 이야기는 이어지게 됩니다.

Microsoft Azure에 구성된 VM들은 2가지 형태의 IP 주소를 가지게 됩니다. 외부 주소를 의미하는 공용 VIP(가상 IP) 주소, 그리고 VM이 가지는 내부 IP 주소입니다.

Microsoft Azure, 가상 컴퓨터의 외부/내부 IP 주소에 대한 고정 주소 설정 및 가상 네트워크내 서브넷간 이동 포스팅에서 살펴본 구성이 되어 있지 않다면, 공용 VIP 주소는 변경될 수 있고, 이에 대한 접속을 위해서는 Microsoft Azure에서 제공되는 DNS를 통해 접속을 해야 합니다. 공용 VIP 주소가 변경되면, 연결된 DNS 이름에 업데이트가 되고, 외부 조회를 통해서 접근을 하게 되는 동적 DNS 형태입니다. 접속을 VM에서 직접 받는 것이 아니라, Microsoft Azure의 로드 밸런서에서 접속을 받고, 이를 VM으로 전달하는 형태이죠.

그렇다면, 이런 궁금증이 생길 수 있습니다. 외부 IP 주소와 DNS 이름은 어떻게 VM과 연결되는가?

VM을 생성할 때, 클라우드 서비스라는 이름이 나타납니다. Microsoft Azure에서 클라우드 서비스는 PaaS 형태의 서비스를 의미하는 단어입니다. VM을 만드는데, 왠 PaaS라고 할 수 있습니다만, Microsoft Azure의 DNS 이름과 외부 IP 주소에 대한 구성(가장 앞단의 네트워크 연결에 대한 구성이죠)은 클라우드 서비스의 자원을 이용하는 형태로 되어 있습니다. 만약 2대 이상의 VM들이 외부에 로드 밸런싱 형태로 서비스되려면, 같은 이름과 같은 외부 IP 주소를 가져야 합니다. 이를 위해서는 같은 클라우드 서비스에 들어가 있어야 합니다. 이러한 이유로 기존 클라우드 서비스에 들어갈 수 있다는 메뉴가 존재하는 것이죠.

VM을 만들면, 기본적으로 클라우드 서비스도 같이 생성되는 이유가 이제는 이해될 것입니다. VM이 생성되고, VM에 대한 외부 접속을 위한 연결 고리를 클라우드 서비스에 자원을 이용한다는 것이죠. Microsoft Azure와 같은 형태의 클라우드는 많은 서비스들을 자원 형태로 분리해놓고, 필요시 꺼내서 사용할 수 있는 형태로 설계되어 있어 있습니다. 이왕 이야기를 하고 있기 때문에, PaaS 영역에 대해서 생각을 해보면, IaaS와는 달리 운영 체제에 대한 설정은 필요하지 않고, 개발자가 프로그래밍을 진행한 후, 클라우드 서비스에 배포하여, 서비스를 하는 형태입니다. IaaS의 경우에는 운영 체제의 설정이 필요하지만, PaaS는 운영 체제에 대한 부분을 별도로 신경쓰지 않아도 되는 컨셉이죠.

앞서 언급한 바와 같이 PaaS나 IaaS나 모두 VM 기반이라고 이야기를 했습니다. 운영 체제도 있는 형태이고, 운영 체제를 볼 수 없는 상태에서 개발된 응용 프로그램을 서비스해주는 형태를 PaaS라고 생각할 수 있으며, 하위를 볼 수 있게 열어놓은 구조를 IaaS라고 생각할 수 있습니다. PaaS 형태의 구조도 응용 프로그램 패키지를 업로드하면, VM이 구성되고, 운영 체제가 설정된 후, 응용 프로그램이 업로드되어 구성되는 형태입니다. 이 응용 프로그램과 운영 체제와의 연결 고리가 떨어질 수 없는 상태로 종속되지 않았기 때문에, 손쉽게 다른 운영 체제로 응용 프로그램 패키지를 구성하여, 확장할 수 있는 것입니다. 결론적으론 IaaS나 PaaS나 비슷한 형태의 VM을 사용하고 있다는 것이죠. 이에 VM만 사용하는 IaaS 시나리오에서도 PaaS에서 사용하는 클라우드 서비스라는 부분을 사용하는 것입니다.(연결 설정에 대해서)

다시 이야기를 돌아와서, 현재 Microsoft Azure의 로드 밸런서는 L4까지 지원하는 형태입니다. (포트) 외부에서 접속을 시도하는 포트에 대해서, 내부로 접속하는 포트를 연결해주는 형태로 구성할 수 있다는 의미입니다.

이와 같은 외부에 대한 연결 고리를 구성하는 항목이 VM 구성 페이지에 존재합니다. 이를 끝점(EndPoint)라고 부릅니다.

기본적으로 VM을 생성하면 2개의 끝점이 생성됩니다. Windows PowerShell을 이용하여 원격 관리를 하기 위한 PowerShell 포트와, 원격 데스크톱 접속을 위한 RDP 포트가 이에 해당됩니다. 추가적인 포트에 대한 구성이 필요하면 이를 추가해주면 되고, 여기서 로드 밸런싱 구성이 가능합니다.

끝점 추가시 “부하 분산 집합 만들기” 체크 박스가 로드 밸런싱에 대한 옵션입니다. 이를 체크하면, 추가적인 옵션을 구성할 수 있습니다. Microsoft Azure의 로드 밸런서는 로드 밸런서가 외부 연결을 맺고, 로드 밸런서가 내부 서버와 연결을 맺는 프록시 형태의 구성입니다.

이에 직접 서버에 접속하여 기술을 필요로 하는 대표적으로 SQL Server의 AlwaysOn과 같은 기술은 “Direct Server Return 사용”이라는 옵션을 이용해야 합니다.

부하 분산 집합 구성시, 상태 확인을 위한 프로브(Probe) 포트와 간격, 몇번 실패시 문제로 간주할 것인지에 대한 숫자를 지정할 수 있습니다. L4 형태이므로, 포트 형태로 지정함을 알 수 있습니다. Microsoft Azure 로드 밸런서는 5가지의 튜플(Tuple, 원본 IP, 원본 포트, 목적지 IP, 목적지 포트, 프로토콜 유형)을 통해, 해쉬(Hash)를 생성하고, 부하를 분산하는 형태입니다. 해쉬 펑션은 동일 서버에서 진행중인 연결에 대해서는 동일한 서버에서 처리할 수 있도록 계산합니다.

이렇게 부하 분산 집합으로 만들어진 끝점을 다른 VM에서 끝점 추가시 부하 분산 집합에 들어가는 형태로 구성하게 됩니다.

이와 같은 형태로 외부에 대한 로드 밸런싱을 구성할 수 있습니다. 더불어 최근에 업데이트된 내부 IP에 대한 로드 밸런싱도 구성이 가능합니다.

내부 로드 밸런싱(ILB)은 Azure PowerShell을 이용해야 합니다. 이에 대한 구성 방법은 여기에 잘 나와 있습니다.

마지막으로 VM 생성시, 계층 구성이 있습니다. 기본(Basic), 표준(Standard)가 이에 해당됩니다. 초기 IaaS 시나리오에는 없었던 계층 구조는 용도에 적절하고, 가격 효율적인 VM을 이용할 수 있는 형태입니다. 표준보다 낮은 비용으로 제공되는 기본의 경우에는 표준보다 성능(대표적으로 기본은 디스크 1개당 IOPS가 최대 300, 표준은 최대 500) 및 이용 범위(기본은 A0~A4, 표준은 A0~A9)가 낮습니다. 이 둘에 대한 자세한 비교는 여기를 참고하세요.

기본의 제한 사항 중에 한가지는 로드 밸런싱 기술을 제공하지 않는다는 것입니다. 기본으로 만들어진 VM에서 끝점을 추가할 경우, 부하 분산 집합 만들기 옵션이 비활성화되어 있습니다.

역시나 관련 그림 및 설명으로 길었던 포스팅이었습니다. Microsoft Azure도 가용성에 대한 고민이 잘 반영되어 있는 공용 클라우드입니다. Microsoft Azure를 이용하여, VM을 서비스할 경우, 가용성에 대한 부분, 그리고 이에 대한 부하 분산에 대한 부분은 IT 엔지니어분들에게는 잘 숙지하고 있어야 하는 내용이지 않을까 싶습니다.