AWS 환경에서 Overlay IP 주소를 활용한 고가용성 구성 및 MCCS 솔루션을 통한 자동 장애조치

AWS 클라우드 환경에서의 고가용성 구조에 적용할 수 있는 장애 조치 구현 방법은 다양합니다. 예를 들어 Amazon RDS와 같은 여러 AWS 서비스들은 도메인 이름 시스템(Domain Name System, DNS)을 이용하여 DNS 레코드의 IP 주소를 변경하는 방법으로 장애 조치를 수행합니다. 하지만, DNS를 기반으로 하는 장애 조치 방법은 해당 시스템에 접근하고자 하는 외부 시스템이 레거시 소프트웨어나 하드웨어 장비와 같이 도메인 이름을 IP 주소로 변환하는 과정(DNS resolve)을 지원하지 않거나, SAP HANA의 고가용성 설정과 같이 SLES HAE, RHEL HA 또는 SIOS와 같은 클러스터 솔루션을 사용하는 경우에는 적합하지 않습니다. 이런 경우에는 Active/Standby 인스턴스에 연계된 IP 주소를 직접 변경하는 Floating IP 패턴을 이용할 수 있습니다.

본 게시글에서는 AWS 클라우드 환경에서 Overlay IP 주소를 이용하여 고가용성 구조를 구성하는 방법을 알아봅니다. 그리고 Active/Standby 인스턴스 간 실시간 데이터 복제를 수행하고 호스트 간에 수행하는 상태 확인을 기반으로 Overlay IP 주소를 기반으로 장애 조치를 자동으로 수행해 주는 MCCS(Mantech Continuous Cluster Server) 솔루션에 대해 알아봅니다.

Overlay IP 주소의 필요성

온프레미스 환경에서 고가용성(HA)을 위해 자주 사용되는 Virtual IP(VIP) 주소는, 두 대 이상의 장비가 각자 실제 IP 주소를 가지고 있으면서, Active/Standby 상태에 따라 Active 상태의 장비에만 별도의 IP 주소를 부여하는 개념입니다. 장애 발생 시, VIP는 기존의 Active 서버에서 Standby 서버로 자동 이전되어 장애 조치가 이루어집니다. 반면에, AWS의 Virtual Private Cloud(VPC)는 서브넷을 기반으로 관리되며, 각 서브넷은 하나의 가용 영역(Availability Zone, AZ)에만 할당됩니다. 서버를 이중화하기 위해 Multi-AZ 구성을 사용할 경우, 각 서버는 다른 서브넷에 위치하게 되므로 같은 IP 주소를 두 서버에 할당하는 것은 기본적으로 불가능합니다. 이런 제한을 극복하기 위해 VPC 외부에서 관리되는 별도의 IP 주소 대역을 Overlay IP 형태로 사용하는 방법이 필요합니다. 이 접근 방식을 통해 서버 간 IP 충돌 없이 안정적인 Multi-AZ 아키텍처를 구축할 수 있습니다.

그림1. IP 주소 기반 HA구성

AWS 클라우드 환경에서 Overlay IP 주소 구성

Overlay IP 주소는 서로 다른 네트워크나 서브넷 간의 IP 충돌을 방지하기 위해 별도로 관리됩니다. 아쉽게도 AWS 클라우드 환경은 기본적으로 Overlay IP 구성 기능을 제공하지 않습니다. 그러나 EC2 인스턴스의 특정 ENI를 라우트 경로를 설정하는 방법으로 Overlay IP를 구성할 수 있습니다. 이러한 설정을 위해, VPC의 서브넷에 있는 라우트 테이블을 활용할 수 있습니다. 이는 서브넷의 라우트 테이블에 Overlay IP 주소 대역에 대한 목적지를 VIP를 부여하고자 하는 EC2 인스턴스 또는 해당 인스턴스에 부착돼 있는 특정 ENI로 지정하는 방법으로, 이를 통해 AWS 클라우드에서도 Overlay IP 주소를 효과적으로 구현할 수 있습니다.

그림2. EC2 인스턴스 ID의 라우트 테이블 등록

그림3. ENI ID의 라우트 테이블 등록

이때 EC2 인스턴스는 Elastic Network Interface(ENI)에 할당된 IP 주소 외에 VIP를 대상으로 하는 패킷도 수신해야 하므로 Source/Destination check 기능의 비활성화는 필수입니다. 마지막으로 ENI를 통해 VIP를 이용한 트래픽이 EC2 인스턴스로 도착했다 하더라도, OS에서 이를 수신받아 처리할 수 있어야 하므로, VIP 주소를 OS에 추가시켜 줍니다.

그림4. Source/Destination check 비활성화

다음은 Amazon Linux 2023에서 OS의 Secondary IP주소 등록을 통해 VIP를 이용하는 방법의 예시 입니다.

# ip addr show enX0
2: enX0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/ether 0a:aa:6e:33:3a:73 brd ff:ff:ff:ff:ff:ff
    altname eni-0ad523e7e3561c2c4
    altname device-number-0
    inet 10.0.2.10/24 metric 512 brd 10.0.2.255 metric 512 brd 10.0.159.255 scope global dynamic enX0
       valid_lft 1846sec preferred_lft 1846sec
    inet6 fe80::8aa:6eff:fe33:3a73/64 scope link
       valid_lft forever preferred_lft forever

# sudo ip addr add 192.168.0.10/32 dev enX0

# ip addr show enX0
2: enX0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP group default qlen 1000
    link/ether 0a:aa:6e:33:3a:73 brd ff:ff:ff:ff:ff:ff
    altname eni-0ad523e7e3561c2c4
    altname device-number-0
    inet 10.0.2.10/24 metric 512 brd 10.0.2.255 scope global dynamic enX0
       valid_lft 1813sec preferred_lft 1813sec
    inet 192.168.0.10/32 scope global enX0
       valid_lft forever preferred_lft forever
    inet6 fe80::8aa:6eff:fe33:3a73/64 scope link
       valid_lft forever preferred_lft forever

Amazon VPC 외부에서 Overlay IP 주소 접근 방안

위와 같이 VPC 내 서브넷의 라우트 테이블을 이용하여 VIP를 구성하면 해당 서브넷 내에서는 VIP를 통한 통신이 가능합니다. 하지만 서브넷에 구성된 라우트 테이블은 VPC 외부까지 적용되지 않습니다. 따라서 온프레미스나 다른 VPC에 위치한 호스트에서 VIP가 적용된 EC2 인스턴스에 접근하려면 추가적인 구성이 필요합니다. 이에 대한 대표적인 방법으로는 AWS Transit Gateway를 이용한 방법과 AWS Network Load Balancer를 이용한 방법이 있습니다.

AWS Transit Gateway(TGW)를 이용한 방안

AWS Transit Gateway를 사용하면 VPC 외부에서도 VIP가 구성된 EC2 인스턴스와 통신할 수 있습니다. 이는 TGW에 연결된 라우트 테이블을 이용하는 방법으로, 이러한 구성을 통해 VPN이나 AWS Direct Connect를 통해 연결된 온프레미스 환경이나, 다른 VPC에서도 해당 Overlay IP 주소에 접근할 수 있습니다.

그림5. AWS Transit Gateway 구성도

AWS Network Load Balancer(NLB)를 이용한 방안

AWS Transit Gateway를 사용하지 않는 경우에도 AWS Network Load Balancer를 이용하면 VPC 외부에서 Overlay IP 주소에 접근할 수 있습니다. NLB는 OSI 모델의 전송 계층(4계층)에서 작동하며, 초당 수백만 건의 요청을 처리할 수 있는 높은 성능을 제공합니다. NLB가 외부에서 들어오는 연결 요청을 받으면, NLB의 대상 그룹에 등록된 Overlay IP 주소로 요청을 전달하게 됩니다. 이를 통해 VPC 외부에서도 Overlay IP를 사용하는 인스턴스에 접근이 가능해집니다.

그림6. AWS Network Load Balancer 구성도

MCCS 소개

MCCS(Mantech Continuous Cluster Server)는 맨텍솔루션의 제품으로, 애플리케이션 서비스, 네트워크, 스토리지 뿐만 아니라 시스템 리소스와 애플리케이션 리소스 문제로 인한 장애에 대해서 서비스 연속성을 보장하고 높은 가용성을 제공하는 솔루션입니다. MCCS는 자연재해, 시스템 오류, 휴먼 에러 등의 예상하지 못한 상황으로 인해 서비스가 중단되는 경우 이를 자동으로 인지하고 복구를 수행하여 MCCS가 적용된 시스템의 가용성을 향상시켜 주는 솔루션입니다.

그림7. MCCS 일반 구성

MCCS 데이터 복제 방식

MCCS는 애플리케이션의 요구사항에 따라 동기 및 비동기의 두 가지 동작 방식으로 서버 간 실시간 데이터 복제를 제공합니다.
동기 방식은 아래와 같이 동작합니다.

그림8. 동기방식의 MCCS 데이터 복제 동작

애플리케이션이 운영 서버에 데이터 쓰기 요청
MCCS가 쓰기 요청(변경된 블록)을 캡처해 운영 서버의 비트맵에 기록
쓰기 요청(변경된 블록)을 대기 서버로 전송하여 쓰기 수행
대기 서버에서 쓰기가 정상적으로 완료됐다는 응답을 운영 서버로 전송
쓰기 요청(변경된 블록)을 운영 서버에 쓰기 수행

이때, 대기 서버의 장애로 쓰기가 불가능한 상황에서는 운영 서버에만 쓰기를 수행하고, 이후 대기 서버가 정상 상태로 돌아오면 비트맵을 이용해 변경된 블록만을 대기 서버로 복제합니다.
비동기 방식은 다음과 같이 동작합니다.

그림9. 비동기 방식의 MCCS 데이터 복제 동작

애플리케이션이 운영 서버에 데이터 쓰기 요청
MCCS가 쓰기 요청(변경된 블록)을 캡처해 운영 서버의 비트맵에 기록
쓰기 요청(변경된 블록)을 운영 서버에 쓰기 수행
쓰기 요청(변경된 블록)을 대기 서버로 전송하여 쓰기 수행
대기 서버에서 쓰기가 정상적으로 완료됐다는 응답을 운영 서버로 전송

비동기 방식은 동기 방식과 다르게 쓰기 요청이 발생하면 즉시 운영 서버에 쓰기가 수행됩니다. 이후 쓰기 요청의 발생 순서에 맞춰 차례로 대기 서버로 데이터가 전송됩니다.

동기 방식은 데이터의 정합성은 유지되지만 정합성의 유지를 위해 서버의 자원(I/O 등)을 비동기 방식보다 많이 사용하고, 비동기 방식은 서버의 자원을 동기 방식보다 적게 사용하지만 장애 발생 시 데이터의 손실이 일부 발생할 수 있습니다.

MCCS를 활용한 고가용성 구성

아래는 일반적으로 AWS 클라우드 환경에서 서로 다른 두개의 가용영역을 기반으로 MCCS를 기반으로 Active-Standby 형태의 이중화를 구성해서 고가용성을 확보하는 아키텍처의 예시 입니다.

그림10. AWS 클라우드 환경에서 MCCS를 이용한 고가용성 구성

이때, 이중화 구성을 이루는 두개의 EC2 인스턴스가 서로 다른 가용영역에 위치하여, 서로 다른 네트워크 대역을 가지기 때문에 VIP가 필요한 경우 Overlay IP 주소가 필요하게 됩니다. 이러한 Overlay IP 주소에 대한 구성 작업은 MCCS의 설치 및 구성 전에 VPC 서브넷의 라우트 테이블에 선행되어야 합니다.

다음 라우트 구성은 VIP인 192.168.0.10을 EC2 인스턴스의 ENI로 라우트 테이블로 매핑하는 구성입니다. 이때 ENI에 할당된 실제 IP는 192.168.0.10이 아니므로, Source/Destination check의 비활성화가 필요합니다.

그림11. 라우트 테이블 구성 예시

다만, MCCS를 이용할 때에는 OS내부의 VIP설정은 MCCS가 자동으로 제어 하므로, 추가적인 OS의 네트워크 설정 작업은 필요하지 않습니다.

그림12. Windows 환경에서 IP주소 설정 예시

Overlay IP 주소 기반의 VIP를 활용하면, 라우트 테이블을 업데이트하여 두 서버 간에 VIP를 원활하게 이동시킬 수 있습니다. 이러한 VIP 이동 과정을 자동화하려면 MCCS에 라우트 테이블 업데이트 스크립트를 미리 등록해야 합니다. 이렇게 하면 Standby 서버로의 페일오버가 필요한 상황에서 MCCS가 해당 스크립트를 실행하여 라우트 테이블을 자동으로 업데이트하고, 서버 간 VIP 전환을 수행할 수 있습니다.

아래는 라우트 테이블 업데이트를 위한 윈도우즈 스크립트의 예제 입니다.

@echo off

set ROUTE1=rtb-06d9c55f787d62d1b	&rem RouteTable ID (Service Network RouteTable ID)
set HOSTNAME1=Test1			&rem 1번 Server Hostname
set HOSTNAME2=Test2			&rem 2번 Server Hostname
set HOST1ENI=eni-02d7eb25b87f1bc5d	&rem 1번 Server Network ID (Service Network Network ID)
set HOST2ENI=eni-02c83b229e8445329	&rem 2번 Server Network ID (Service Network Network ID)
set VIP=192.168.220.200/32		&VIP

for /f "usebackq" %%f in (`hostname`) do (set HOSTNAME=%%f)

for %%a in (%ROUTE1%) do (
if %HOSTNAME% == %HOSTNAME1% (
aws ec2 replace-route --route-table-id %%a --destination-cidr-block %VIP% --network-interface-id %HOST1ENI%
) else (
aws ec2 replace-route --route-table-id %%a --destination-cidr-block %VIP% --network-interface-id %HOST2ENI%
)
)

exit 0

리눅스 OS를 사용하는 경우에는 다음과 같은 스크립트 형태로 라우트 테이블을 업데이트 할 수 있습니다.

#!/bin/bashhost=$HOSTNAME
TABLE1=rtb-    ## route table id (서비스 네트워크가 속한 route table id1)
TABLE2=rtb-    ## route table id (서비스 네트워크가 속한 route table id2)
ENI1=eni-    ## 1번 서버 서비스 네트워크 인터페이스 id
ENI2=eni-    ## 2번 서버 서비스 네트워크 인터페이스 id
VIP="vip/32"  ## vip로 설정할 ip 입력

if [ `hostname` == "test1" ]    ##1번 서버 호스트 네임 입력
then
for $TABLE in $TABLE1 $TABLE2
do
   aws ec2 replace-route --route-table-id $TABLE --destination-cidr-block $VIP --network-interface-id $ENI1
done
elif [ `hostname` == "test2" ]    ##2번 서버 호스트 네임 입력
then
for $TABLE in $TABLE1 $TABLE2
do
   aws ec2 replace-route --route-table-id $TABLE --destination-cidr-block $VIP --network-interface-id $ENI2
done
fi
exit 0

Overlay IP 주소 작업 외에도, 두 EC2 인스턴스간에 Service, Heartbeat, Mirror 를 위한 3개의 네트워크의 구성이 필요합니다. 여기서 Heartbeat 네트워크는 두 EC2 인스턴스간에 서로의 상태를 확인하는데 사용하는 네트워크이며, Mirror 네트워크는 두 EC2 인스턴스간에 로컬 디스크의 데이터를 동기화하고 복제하는데에 사용하는 네트워크입니다. 이러한 네트워크들은 안정적인 이중화 구성을 위해 서로 분리해야 합니다. 네트워크의 분리는 해당 네트워크를 위한 ENI를 서로 다른 서브넷에 위치시키는 방법으로 이루어집니다. 다만, 부득이한 경우에는 Heartbeat와 Mirror 네트워크는 하나의 네트워크로 사용해서 Service 네트워크만 분리 운영 하는 것도 가능합니다.

그림13. MCCS 네트워크 별 서브넷 구성

결론

본 게시글에서는 AWS 클라우드의 Multi-AZ 환경에서 Overlay IP 주소 기반의 VIP를 구성하는 방법을 알아보고, 이렇게 구성된 VIP와 MCCS를 활용하여 고가용성 시스템을 구성하는 방법을 알아보았습니다. 이러한 구성을 통해 DNS 기반의 장애 조치를 지원하지 않는 애플리케이션에 대해서도 고가용성을 제공할 수 있습니다. MCCS에 대한 더 자세한 내용은 맨텍솔루션의 홈페이지를 참고하시기 바랍니다. 특히 멘택솔루션에서는 MCCS에 대한 e-Learning 컨텐츠를 무료로 제공하고 있어서 이를 이용하면 MCCS 설치에 대한 자세한 정보를 얻으실 수 있습니다.

AWS 기술 블로그