애플리케이션의 고 가용성(High Availability)을 달성하기 위해 서로 다른 Data Center, Cloud에 애플리케이션을 배치할 수 있습니다. 이 경우 각각의 환경의 Load Balancer에 대해 로드밸런싱을 할 수 있는 GSLB가 필요합니다.

이 페이지에서는 AWS의 Route 53을 활용하여 GSLB(Global Server Load Balancing)를 구성하는 방법을 알아보겠습니다.

구성하기

AWS의 Route 53 서비스에 접속합니다.

Health Check 생성하기

먼저 Master, Slave 애플리케이션에 대한 health check를 추가하겠습니다. (서로 다른 Data Center, Cloud에 배치된 애플리케이션을 Master와 Slave로 구분하도록 하겠습니다.)

Route 53 서비스 main > Left menu > Health checks > Create health check를 선택합니다.

아래와 같이 Master 애플리케이션에 대한 health check 설정을 입력합니다.

마찬가지로 Slave 애플리케이션에 대한 health check 설정을 입력합니다.

Host Zone 생성하기

Route 53 서비스 main > Left menu > Hosted zones > Create Hosted Zone을 선택합니다.

아래와 같이 Hosted Zone의 정보를 입력합니다.

  • Domain Name : dr.example.com(*.example.com 도메인을 소유하고 있고 하위 도메인 dr.example.com을 GSLB 구성에 사용합니다.)

Record Set 생성하기

Route 53 서비스 main > Left menu > Hosted zones > Create Record Set을 선택합니다.

Master(Primary)에 대한 Record Set을 아래와 같이 설정합니다.

  • Value : Master 애플리케이션 Endpoint가 가르키는 IP Address
  • Health Check to Associate : 앞에서 생성한 Master의 health check name 선택

Slave(Secondary)에 대한 Record Set을 아래와 같이 설정합니다.

  • Value : Slave 애플리케이션 Endpoint가 가르키는 IP Address
  • Health Check to Associate : 앞에서 생성한 Slave의 health check name 선택

아래와 같이 Master(Primary)와 Slave(Secondary)에 대한 Record Set이 설정되었습니다.

도메인 설정하기

도메인 제공자의 관리 페이지에서 아래와 같이 설정합니다.

  • CNAME 설정

    demo.example.com에 대한 canonical name을 demo.dr.example.com로 설정

  • Name Server 설정

    dr.example.com에 대한 Name Server를 위에서 생성한 Host Zone의 Name Server로 설정합니다.

    위에서는 ns-1064.awsdns-05.org와 ns-609.awsdns-12.net을 뜻합니다.

동작 확인

이제 Master 애플리케이션의 접속이 정상인 경우와 비정상일 때 GSLB가 어떻게 동작하는지 확인해보겠습니다.

Master 애플리케이션의 접속이 정상인 경우

Master 애플리케이션의 접속이 정상인 경우 demo.example.com 도메인에 대한 주소를 확인해보면 169.x.x.1 즉, Master 애플리케이션의 IP 주소가 반환됩니다.

$ nslookup demo.example.com
Server:     x.x.x.x
Address:    x.x.x.x

Non-authoritative answer:
demo.example.com canonical name = demo.dr.example.com.
Name:   demo.dr.example.com.
Address: 169.x.x.1

좀 더 상세한 흐름을 그림으로 표현해보면 아래와 같습니다.

Master 애플리케이션의 접속이 비정상인 경우

이제 Master 애플리케이션을 강제로 종료해 접속이 되지 않도록 변경해보겠습니다.

Master 애플리케이션의 접속이 비정상인 경우 demo.example.com 도메인에 대한 주소를 확인해보면 169.x.x.2 즉, Slave 애플리케이션의 IP 주소가 반환됩니다.

$ nslookup demo.example.com
Server:     x.x.x.x
Address:    x.x.x.x

Non-authoritative answer:
demo.example.com canonical name = demo.dr.example.com.
Name:   demo.dr.example.com.
Address: 169.x.x.2

좀 더 상세한 흐름을 그림으로 표현해보면 아래와 같습니다.