[발 번역] 클라우드에서 고가용성을 가지기 위한 4가지 단계

해당 블로그는 KT UCloud 의 지원을 받고 있습니다.

해당 글은 RightScale 의 http://blog.rightscale.com/2012/05/09/four-steps-to-achieving-high-availability-in-the-cloud/ 글을 발 번역 한 것입니다. 오역에 주의하세요. 읽고 나면 약간 약장수 같은 부분이 있지만, 클라우드를 생각하시는 분이 시작하기 전에 어떤 부분에 주의해야 할지에 도움이 되는 글입니다. 읽기에 적합한 대상은 이제 막 클라우드를 생각하시는 분들이 보시면 좋을 듯 합니다.

 

클라우드에서 고 가용성 어플리케이션을 구축하는 것은 매우 겁나는 작업 처럼 보입니다. 시스템의 모든 컴포넌트에 갑자기 장애가 날 수 있다고 가정해야하고, 이에 대비해야 하기 때문입니다. 그래서 장애와 해당 장애에 대한 자동적인 대응 방법을 준비해야합니다. 클라우드에서 고 가용성을 달성하기 위해서는 장애에 강한 시스템을 디자인해야합니다.

 

6월에 열릴 RightScale Conference 에서, 많은 업체들이 고가용성(HA), 장애복구(DR) 에 대한 전략을 다루려고 할 것이고, 중요하게 논의될 것입니다. 우리의 고객에서 클라우드에서의 HA를 위한 아키텍처 디자인에 대해서 조언을 할 때면, 일반적으로 다음 4가지 단계를 추천합니다.

 

1. 서버 장애에 준비하라.

클라우드에서의 장비는 임시적입니다.(일반적으로 데이터 센터에 있지만), 서버 장애에 대해서 미리 준비해야 합니다. 서버 장에 대비하는 것은 먼저 서비스의 리부팅이나 재시작에도 강인한 stateless 한 애플리케이션을 디자인 하는 것으로 시작합니다. (역자 주: stateless 한 애플리케이션이 왜 장애에 강할까요? 해당 서버에 저장하는 데이터가 없기 때문에, 해당 로직만 있는 서버라면 어디에 가서든 해당 리퀘스트를 처리할 수 있기 때문입니다. 그런데, 문제는 이럴 경우 필연적으로 stateful 한 데이터스토어가 필요해집니다. 그래서 분산 데이터스토어에서 데이터를 분산해서 저장해두는 형태로 장애에 대비하는 것입니다. )

  • 애플리케이션이 동적으로 변하는 트래픽 패턴에 대응하기 위해서 성능 지표에 따른 매트릭스를 이용해서  auto-scaling을 설정합니다.
  • database mirroring을 설정합니다.(역자 주: Replication 하라는 얘깁니다.) master/slave 설정을 해서, 최소한의 다운시간과, 데이터 무결성을 보장합니다.
  • 어플리케이션 인프라스트럭처의 구성 컴포넌트들이 언제나 올바른 내용을 가지도록 Dynamic DNS 와 정적 Ip를 사용합니다.( 역자 주: 클라우드 환경의 장비가 임시적이므로, 모든 서버 접근은 static IPs가 아닌 DNS를 통해서 접근해야합니다. 구글 등에서는 IPs가 실제 물리적인 거리를 설명하기 위해서도 사용한다고 합니다. 규칙이 명확하다면, 여러가지 오해의 소지가 줄어들겠죠 ^^, 전체 시스템을 구성하다보면, 최초에는 이런 설정이 맞다가, 뒤로 갈수록 다른 네트워크의 장비가 추가되는 경험도 있었습니다.)

2. Zone 장애에 대비하라. 

종종, 단일 장비들이 고장나는 것보다 많이 발생할 수 있습니다. 파워의 고장, 네트워크의 과다 전송, 낙뢰로 인한 장애가 발생합니다. 꼭 zone 장애에 대해서 준비를 해두어야 합니다.( AWS에서는 “availability zones” 이라고 부르는  Zone들이 있습니다.)(역자 주: 크게 AWS에서는 Region 과 zone이 있는데 Region은 큰 지역별 기점을 얘기하고 zone 은, 그 안에 있는 실제 데이터 센터들을 의미합니다. 예를 들면, E마트 서울 지역이 큰 Region으로 분리되는 것이고, 그 안에 있는 E마트 지점들이 zone이 되는것입니다.)   Zone은 다른 Zone 들과 지역적으로 분리되어 다른 Zone에 장애가 나더라도 영향을 받지 않는 별도의 장소입니다. (역자 주: 이마트 성동점이 불나도, 왕십리점은 이용할 수 있는 것입니다.)

  • 어플리케이션을 위한 서버를 최소한 두 군데 이상의 Zone으로 분리해서 배치해야 합니다.
  • Zone 끼리 상호 데이터를 복제합니다. 다만, 무료는 아니지만 쌉니다.( 역자 주: 실제로 zone을 두 개 이상 사용하는 것은 비용과 직결되는 문제입니다. 그래서 장애 복구냐, 비용이냐 측면에서 잘 판단하셔야 합니다. DR쪽 이론을 봐도, 만약 유지비용이 실제 장애 났을 때의 전체 피해액보다 크면, 그냥 장애를 맞이하라고 나옵니다. 최근에 있었던 AWS Region 장애 사건을 보면 그냥 zone을 분리하는 것보다는 차라리 Region을 분리하는 것이 더 나아보입니다.)

 Cloud Regions and Zones

3. 클라우드 장애에 대비하라

드물긴 하지만, 한 Region의 여러개의 zone들이 처리 용량을 넘어서 장애를 경험할 수 있습니다.  “April 2011 Amazon Web Services (AWS) outage” 이 주목할만한 사건입니다. 각 Region 은 서로 독립적인 API endpoint를 가지고 있습니다. 이것이 클라우드라고 부르는 이유입니다.

 

95% 이상의 가용성을 가지기 위해서, 클라우드 장애에 대한 대응책을 가져야 합니다. 클라우드 간에 시스템을 구축하는 것은 쉽지 않습니다. APIs, 서비스, 설정도 다르며, 해당 클라우드에만 존재하는 기능(예: EBS Volumes) 이 아닌 일반적인 개념으로만(예, 스토리지) 시스템을 디자인해야 합니다.( 역자 주:  어떤 분들은 AWS를 7개의 Region을 각각 다른 클라우드라고 부르는 분들도 있습니다. 랙스페이스, 아마존, 이런 형태의 멀티 Cloud 냐, 아니면 AWS에서 두 가지 이상의 다른 Region에 분산 시킬 것이냐는 전략적, 기술적 판단에 따라서 스스로 내리셔야 할 것 같습니다. 해당 글을 쓴 RightScale의 경우, 이런 작업을 공통 인터페이스를 통해서 처리하게 해주는 사업으로 잘 먹고 살고 있는 회사입니다.)

 

Cloud management 시스템은 이런 다른 차이점들을 추상화 시키고 재사용 가능한 building block을 제공해서 , fault-tolerant 전략을 구현하는 것을 쉽게 만들어 줍니다. 이 building block들은 같은 서비스 제공자 안에서 다른 Region으로 옮기는 것 뿐만 아니라, 다른 서비스 제공자끼리 옮기는 것에도 사용 할 수 있습니다.

  • 데이터를 다른 Region이나 서비스 제공자 간에 백업하거나 복제합니다. 패킷들은 안전하게  보호되고 인증받은 채널을 통해서 전달됩니다.
  • 클라우드 장애가 났을 때, 이를 받아줄 zone에서도 충분한 여유 능력을 유지해야 합니다. 필요하면 Reserved Instance를 이용하면 됩니다.
  • 일단 기고 나서 걸어야 합니다. 먼저 zone 단위의 고 가용성 시스템을 구축한 다음 여러 Cloud가 가능하도록 확장해야합니다.

4. 자동화하고 모든 것을 테스트하라.

서버, 존, 클라우드 장애에 대해서 전부 대응할 수 있도록 설정을 했다면, 꼭, 해당 장애가 일어났을 때, 자동적으로 동작할 수 있도록 해야합니다. 클라우드 매니지먼트 시스템은 미리 준비된 장애 대응책을 서버, 존, 클라욷 사이에서 실행할 수 있도록 해줍니다. 긴급 상황에는, 시간이 중요합니다. 그래서 모든 것을 자동화 해야합니다.(역자 주: 일을 하다보면 100% 자동화가 안되고 사람의 판단이 들어가야 하는 경우가 있습니다만, 이 경우에도 판단은 사람이 하더라도, 모든 작업은 자동화가 되어야 합니다. 다만, 자동화 하는 경우에는 이 자동화 시스템 역시 예외에 대한 대비가 잘 되어있어야 더 큰 장애를 막을 수 있습니다.)

  • 장애가 나더라도 대응할 수 있도록 자동적으로 백업을 해야 합니다.
  • 클라우드 서비스 제공자로 부터, 긴급히 관련 정보를 받지 못해서 문제가 발생하는 중요한 문제를 판단하고, 알기 위해서 모니터링 시스템과 알람시스템을 설정해야합니다.(역자 주: 클라우드나 분산 시스템은 결국 monitoring is everything 입니다. )
  • 장애 대응 계획은 그것의 동작을 확신할 수 있을때에만 훌륭합니다. 높은 부하를 서버에 주거나, 여러 zone과 서비스의 서버들을 정지시켜서, 장애에 견디는 인프라스트럭처의 능력을 테스트 할 수 있습니다.

클라우드 인프라스트러처는 다른 옵션에 비해서 DR 과 HA를 특별히 저렴하게 만들었습니다. 최근 발생한 큰 장애에도 불구하고, 올바른 관리툴을 제대로 이용하고, 설계를 제대로 하면, 많은 조직들이 성공적으로 중요한 서비스를 클라우드에서 운영하고 있습니다. 설계나 추가적인 Best Practice를 원한다면 다음 문서를 보면 됩니다. white paper on HA and DR scenarios.