해당 블로그는 KT UCloud의 지원을 받습니다.
해당 내용은 http://techblog.netflix.com/2012/07/lessons-netflix-learned-from-aws-storm.html 의 글을 발 번역한 것입니다. 올해에만 AWS에 두 번 정도 큰 장애가 있었습니다. US-East 버지니아 지역 데이터 센터에 정전등의 이슈로 장애가 있었고, 이에 영향을 받은 유명한 업체들도 꽤 있습니다. 대표적인 케이스가 이 기사를 쓴 Netflix 입니다. 과연 Netflix 는 이번 사태에서 어떤 교훈을 배운것일까요? 개인적으로 매번 이러한 post-mortem 을 제공하는 것은 참 대단한 것 같습니다.
Overview
6월 29일 금요일, 일년을 통들어 가장 큰 장애 중의 하나가 발생했습니다. 장애는 미국 지역 Netflix 회원들에게 태평양 시각(역자 주: 미국・캐나다 서부 연안에서 사용하는 시간제) 으로 오후 8시 경부터 시작하고 대략 3시간 정도 지속되었습니다. 우리는 아마존 클라우드에서의 경험과 많은 장애 대응 노력에 대해서 공유를 했었습니다. 과거 AWS 의 Availability zone 장애에서도 최소한의 영향으로 장애를 넘겼습니다. 이번 특정 존의 장애가 특별히 영향이 컸는지 우리가 발견한 점들을 공유하려고 합니다.
배경지식을 위해서, 다음 웹사이트 http://aws.amazon.com/message/67457/ 에서 아마존의 해당 장애의 원인에 대한 분석을 볼 수 있습니다. 간단하게 요약하면, 아마존 Availability Zone(AZ) 중에 하나가 금요일에 태풍에 의한 전력 부족으로 장애가 났고, 전력 문제는 20분 뒤에 복구가 되었다입니다. 하지만, Elastic Load Balancing(ELB) 서비스는 처리에 있어서 문제가 있었고, API backlog는 천천히 복구되었습니다.
자체 장애 원인 분석에서 우리의 내부 로드밸런싱 서비스의 이상한 점을 포함해서. 재미난 점 몇 가지를 발견했습니다. 이것이 많은 트래픽을 이용할 수 없는 zone으로 보내는 로드밸런서로 부터 비정상 노드를 제외하는데 실패하도록 만들었습니다. 게다가, 네트웍은 서버를 찾을 수 없다는 에러 대신에, 이용할 수 없는 zone의 노드를 호출하여 멈춰버렸습니다.
이번 장애의 일부로, 우리와 아마존에서 개선할 수 있는 부분을 발견해냈고, 개선을 위해 함께 작업중입니다.
Middle-tier Load Balancing
중간 단계의 로드 밸런싱에서, 다른 장애 타입을 구별하기 위해서 구현해놓은 기능이 지속적인 장애를 발생시켰습니다. 시스템을 모니터링 하는 서비스는 장애가 동시에 발생하는 것을 표시실패하는 것을 알려주기 위한 중요한 부분으로써 비정상 모드를 제거하지 않는 fail-safe 모드를 가지고 있습니다. 이것은 네트웍 파티션 이벤트들을 처리했고, 누군가 큰 문제가 있는지 조사하기 위해서 짧은 시간의 프리징을 가지도록 되어있습니다. 불행히도, 이 상태를 알아내는 것은 시간을 많이 소모하고, 전력 장애로 인해서 더 이상 동작하지 않는 서버들을 계속 사용하려고 하거나 이용하려고 해서 서비스 장애를 일으키는 크고 무거운 문제로 밝혀졌습니다.
Gridlock
클라이언트가 더 이상 이용할 수 없는 서버로 접근하려고 시동하는 것은 2차적인 문제를 일으켰습니다. 모든 클라이언트 스레드가 컨넥션을 시도하기 위해서 사용되는 바람에, 겨우 몇 개의 서비스만 서비스가 가능했습니다.(역자 주: 일종의 DOS 공격이 되어버렸습니다.) 이것은 필연적으로 미들 티어를 계속 사용하려고 함으로써, 서비스 대부분에 gridlock을 발생시켰습니다. 현재 이런 특별한 케이스에 시스템이 빨리 회복되도록 만드는 작업을 하고 있습니다. 현재 이용 불가능한 호스트로의 라우팅이 되지 않는 다는 것과, 실패에 대해서 빨리 판단을 내리지 않고, 왜 컨넥션들이 타임 아웃이 될 때 까지 연결되어 있었는지 계속 확인중입니다.
Summary
Netflix는 몇년 전에 데이터 센터를 쓰지 않고, 클라우드를 사용하기로 결정했습니다.[1] 우리가 손댈 수 있는 범위를 넘었다는 이유로, 클라우드 장애를 비난하는 것은 쉬운 방법이지만, 과거부터 몇년 동안 천천히 우리의 전체 가용성이 증가했다는 사실을 발견했습니다. 큰 장애의 근본 원인을 파헤치면서, 서비스 중단을 완화시킬 수 있는 장애 회복 패턴을 추가할 수 있다는 것을 발견했습니다.
장애시 원활하게 동작하게 했던 장애 회복 아키텍처의 요소들은 다음과 같습니다.
- 지역별 분리는 US-East 외부 지역에서 사용자들이 서비스를 받아야 한다는 문제가 있습니다. 유럽 지역 회원은 장애에 영향을 받지 않았습니다.
- 우리의 분산 클라우드 데이터 스토어 카산드라는 모든 Zone들과 Region들에 걸쳐서 분산되어 있어서, Region 노드의 1/3 이 사라지더라도, 어떠한 데이터 로스나 가용성의 저하가 없습니다.
- Simian Army의 하나로 하나의 전체 Availability zone 의 유실을 시물레이팅하는 Chaos Gorilla 는 정확히 그 목적으로 만들어졌습니다. ( 역자 주: Simian Army는 Netflix에서 사용하는 장애 시물레이션 도구들의 모음입니다. 그 중에 하나가 Chaos Gorilla 입니다. 나머지는 다 Monkey 종류입니다. 자세한 내용은 다음 두 블로그에 확인할 수 있습니다. http://techblog.netflix.com/2011/07/netflix-simian-army.html, http://techblog.netflix.com/2011_04_01_archive.html), 해당 장애는 Chaos Gorilla 와 Simian Army의 다른 부분들에 대한 유저케이스와 추가 툴이 필요하다는 것을 보여주었습니다.
클라우드의 상태는 시간이 지남에 따라서 더 성숙되고 더 향상 될 것입니다. 현재 아마존은 자신의 시스템을 발전시키는 방향으로 노력중이고, 우리는 개별 존의 장애를 분리시켜서, 광범위한 장애를 발생시킬 수 있는 SPOF를 제거하는데 노력을 집중하고 있습니다.
전체 회원들이 중단 없는 서비스를 제공받도록 가용성을 매우 중요하게 생각하고 노력하고 있습니다. 우리는 여전히 클라우드에 대해 낙관적이며, 우리의 인프라스트럭처 안에서, 서비스 장애로 부터 회원들을 보호하기 위해서 열심히 일하고 있습니다.
우리는 지속적으로 위에서 파악한 문제들 뿐만 아니라 , 각각의 서비스팀이 장애 대응을 다루는 것 처럼, 일할 수 있는 Cloud Operations and Reliability Engineering team 팀을 구성하고 있습니다. 관심이 있다면 jobs.netflix.com 을 살펴보시고, 추가 정보가 필요하거나 바로 지원하거나 @atseitlin 에게 연락을 주시기 바랍니다.
[1] http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html
Charsyam's Blog 