AWS는 세계 각지에 데이터센터가 있어서 온프레미스보다 유연하게 재해 대처를 할 수 있다. 하지만 가용성 설계가 부족하다면 자주 다운되는 취약한 시스템이 되어 버린다. 가용성을 높이는 설계는 매우 중요하다.
핵심 설계 사항
1. 데이터 센터 다중화
2. 장애 자동 복구
3. 리전의 다중화
장애 발생을 전제로 설계
AWS는 하드웨어를 이용하며 고급 소프트웨어로 관리하고 있다. 하지만 하드웨어 고장이나 소프트웨어 버그가 발생할 수 있고 관리작업 미스가 발생할 가능성 또한 충분하다. 이러한 장애에도 시스템이 계속 가동되기 위해서는 다중화 구조를 이용하여 시스템 설계를 해야한다.
먼저 단일 리전 내에서의 다중화 작업을 진행한다. AP서버가 되는 가상 서버 EC2의 가용성을 높이기 위하여 ELB를 사용하고 HTTP 요청을 배분하는 EC2 인스턴스를 여러 가용 영역에 배치하여 다중화 한다. 도한 장애가 발생한 EC2 인스턴스의 조기 발견과 자동 복구를 실시하는 장치 클라우드 워치를 사용한다.
DB서버는 RDS 관리 서비스에 있는 멀티 AZ를 사용하여 메인 사이트와 다른 리전에 백업 사이트를 설치한다. 서울 리전 전체에 영향을 주는 대규모 재해에도 대비할 수 있다. DB는 RDS의 크로스 리전 읽기 전용 복제본과 읽기 전용 복제본의 마스터 승격 기능을 사용한다. 이를 통해 백업 사이트에 데이터를 자동으로 동기화하고 메인 DB서버의 장애시 백업 사이트 읽기 전용 복제본이 마스터로 승격된다.
정적 콘텐츠를 저장할 경우 S3 크로스 리전 복제 기능을 통해 백업 사이트에 데이터를 동기화 한다. DNS는 Route 53을 사용하면 메인 사이트의 장애를 감지하여 백업 사이트에 동적으로 라우팅한다.
AZ 다중화
AWS의 가용성을 높이는 가장 기본적이면서 효과가 큰 방법인 AZ 다중화는 하나의 리전에 최소 2개 이상의 AZ를 이용하는 것이다. AZ는 각각 별도의 전원과 복수 백본망을 사용하도록 독립적으로 운영되기 때문에 AZ하나가 장애를 일으켜도 나머지 AZ에 영향을 미치지 않는다. 따라서 복수의 aZ에 걸쳐 다중화 하는 것은 가용성을 높이는 매우 중요한 대비책이다.
AP서버를 EC2로 DB를 RDS로 사용하는 경우 EC2 인스턴스를 여러 AZ에 분산하여 배치한다. 또한 RDS는 멀티 AZ기능을 이용한다. 하나의 AZ가 장애를 일으켜 마스터가 제 기능을 사용하지 못하는 경우 서브가 마스터로 승격되고 마스터가 장애 복구가 되기까지 마스터로서의 역활을 수행한다.
DB 장애발생으로 인한 다운타임을 단축하려면 AP에서 재연결을 자동화 해야한다. 장애복구시 AP 서버에서 DB 서버로의 연결이 끊어진다 재연결을 자동화 하지 않으면 수동으로 재연결을 해야하고 그만큼 다운타임이 길어진다. AP의 프레임워크 기능을 사용하여 자동으로 재연결이 되도록 설정해야한다.
EC2 인스턴스 자동복구
AWS는 EC2 인스턴스의 이상을 감지하여 자동으로 복구 시키는 방법을 제공한다. 클라우드 워치를 이용하여 서비스 상태를 모니터링하고 자동 복구를 하는 방법이다. 구체적으로 하드웨어에 이상이 생기면 StatusCheckFailed_System 감시지표를 이용하여 호스트 하드웨어의 레벨상태(0:정상, 1:이상)를 확인하고 EC2인스턴스를 복구하는 것이다. 이외에도 인스턴스 레벨이나 ELB와 관련된 모니터링 지표등을 이용하여 자동 재기동 시켜 복구한다.
발생 빈도가 적은 대규모 장애
발생 빈도는 적지만 영향이 큰 대규모 장애 즉 복수의 AZ에 장애가 발생한 경우의 대응책을 마련해둘 필요가 있다. 기본적인 방법은 지리적으로 떨어진곳에 마련하는것이다. 다시말해 타 리전에 동일한 시스템이 움직일 수 있도록 리전간 중복성을 갖도록 구성하고 백업사이트로서 활용하는 것이다.
구체적인 이용 방식
-
장애 발생시 자동 전환
짧은 다운타임으로 복구가 가능하지만 비용이 많이든다. -
백업 데이터로부터 복구용 서버를 만들기
저렴하지만 다운타임이 길어진다.
백업 사이트로 자동 전환하기
자동 전환은 Route 53의 DNS장애조치 기능을 사용한다. 이 기능은 Route 53의 기본 사이트 ELB 상태를 감시하는데 ELB에 연결되 EC2 인스턴스와 AP 모두 다운되었다고 판단하면 자동으로 백업 사이트의 ELB로 연결을 재설정한다. 이 방식은 백업 사이트에 메인과 동일한 서버와 데이터가 존재하는 것이 전제이다. 따라서 동기화 시킬 필요가 있다.
EC2
EC2의 스토리지 EBS는 실시간 복제 기능이 없다 이를 해결하는 방안은 두가지이다.
첫번째는 copy-snapshot 명령을 AWS CLI가 설치된 운영 관리 서버에 정기적으로 반복 실행되게끔 하여 스냅샷 백업 사이트로 복사하는 방법이다.
두번째는 EC2에 실행되는 데이터 동기화 도구를 이용하여 디스크의 내용을 실시간을 동기화하는 방법이다.
RDS
RDS는 다른 지역에 읽기 전용 복제본을 만드는 기능을 사용하여 일긱 전용의 DB로서 프라이머리에 대한 복제본으로 작동하게 한다. 이를 읽기 전용 복제본의 마스터 승격기능을 활용하여 장애 조치시에 원본 마스터에서 복제를 중지, 독립된 DB로서 작동을 하게된다.
하지만 마스터 승격시까지 다소 시간이 걸린다. 마스터 승격 작업은 Route 53 DNS 장애조치 기능과 연동되지 않고 자동으로 시스템 다운을 감지하고 마스터 승격 API가 실행되도록 구성할 필요가 있다. 이는 Cloud Watch의 이벤트를 활용하여 람다를 이용해 읽기 전용을 마스터로 승격시키는 API를 호출하도록 구축한다.
S3
리전간 복제 기능을 이용하여 백업 사이트와 데이터를 동기화한다.
자동전환이라는 방법은 다운타임이 짧은 대신 비용이 상당히 추가된다. 평상시에도 백업 사이트의 인스턴스를 가동시켜야 되기 때문이다.
백업 데이터로부터 복구용 서버
장애 시간이 길어도 된다면 더 저렴하게 리전 간 백업을 이용하면 된다. 기본 사이트와 동일한 구성의 시스템을 백업 사이트에 구축하는 방식이다.
방식은 이러하다. EC2 인스턴스의 바탕이 되는 아마존 머신 이미지를 백업 사이트로 복사하고 EBS, RDS, S3의 데이터를 백업 사이트에 보관해야한다. AMI는 EC2 인스턴스의 관리 콘솔이나 명령행을 통해 만들 수 있다. 대상 지역을 지정하고 백업 사이트에 복사한다. 이 기능을 이용하여 최신 EC2 인스턴스의 AMI를 백업 사이트에 복제한다.
EBS, RDS는 스냅샷을 이용하여 통째로 백업한다. 관리 콘솔, 명령행 인터페이스에서 스냅샷을 지시하면 메인 사이트에 스냅샷이 생성된다. 생성된 스탭샷을 다른 지역으로 복사할 수 있고 이 명령이 반복적으로 수행되도록 스크립트를 작성하여 정기적으로 스냅샷을 백업사이트로 복사한다.
S3는 앞에서 다룬 크로스 리전 복제 기능을 사용하여 백업 사이트에 데이터를 동기화 한다.
메인 사이트 전체에 영향을 주는 장애가 발생하면 AMI에서 EC2인스턴스를 생성하고 EBS, RDS는 스냅샷으로부터 데이터를 복원한다. ELB나 클라우드 워치를 메인 사이트와 같은 설정으로 작성하면 메인 사이트와 동일한 구성의 백업 사이트를 작성할 수 있으며 이는 AWS의 특징을 살린 가용성 향상 방법이다.
이 방식은 백업만 만들어 두는 것이므로 비용 절감에 효과적이다. 하지만 자동 전환 방식보다 긴 다운타임이 발생하므로 연결이 계속 되어있어야 하는 서버의 경우 효율적이지 못하다.
여러가지 방법으로 가용성을 높일 수 있다. 이 방법들을 잘 활용하여 재해 대책을 충분히 마련하는 것이 좋다.
