[B급 프로그래머] 넷플릭스, AWS EC2 장애에서 원숭이 때문에 살아나다

2014년 9월 25일, 대략 10%에 이르는 AWS EC2 인스턴스가 '즉각적인 보안과 운영 업데이트'로 인해 재시동되는 상황이 벌어졌다는 사실을 애독자 여러분들은 이미 알고 계실 것이다. 넷플릭스는 여러 차례 경험을 토대로 비상시 복원 전략이 충분히 갖춰져 있었음에도 불구하고, 이런 환경적인 영향은 서비스에 심각한 영향을 미치기 마련이다. 다행히도 Chaos Monkey를 도입했기 때문에 넷플릭스는 충분한 대응을 할 수 있었던 것으로 보인다. 넷플릭스 기술 블로그에 올라온 A State of Xen - Chaos Monkey & Cassandra에서 핵심을 간추려본다.

데이터베이스는 애플리케이션 세상에서 응석받이 버릇없는 왕자로 자라왔다. 최상의 하드웨어, 풍부한 관리자 지원을 데이터베이스에 쏟아왔으며, 고의로 데이터베이스를 망치는 상황은 꿈도 꾸지 못한다. 하지만 민주화된(주목: 일베 용어 아님! 원문을 참조하시오.) 클라우드 공화국에서는 더 이상 이런 응석이 가능하지 않다. 노드 실패는 충분히 발생할 뿐더러 예상하고 있어야 한다. 따라서 실패를 견디고 계속 수행이 가능한 데이터베이스 기술이 필요하다.

넷플릭스에서 채택한 데이터베이스는 카산드라로 CAP 중에서 AP(Availability, Partition Tolerance)를 강조한다. C(Consistency)를 희생하는 관계상 궁극적으로 일관성을 유지하게 애플리케이션을 작성하는 식으로 설계 방향을 잡았다. 여러 해 동안 카산드라를 운영한 결과 실패에 상당한 내성을 발휘했다. 하지만 사람의 개입을 많이 요구했다.

2013년 실패한 카산드라 노드 복원을 자동화하기 위해 상당히 큰 투자를 결정했다. 그 결과 실패한 노드를 감지하고 파악할 수 있는 수준에 도달했다. AWS가 제공하는 클라우드 API를 사용해, 실패한 노드의 위치를 파악하고 프로그램적으로 대체 노드를 구축하고 새로운 카산드라 노드를 부트스트랩할 수 있게 되었다.

처음에는 완벽하지 않았다. 하지만 계속하다보면? 넷플릭스의 일하는 방식에 따라, 빨리 실패하고 좋은 방향으로 수정했다. 몇 달이 지나자 자동화가 더 나아졌다. 오탐 확률이 낮아졌고, 복구 스크립트는 거의 사람 손을 필요로 하지 않았다.

그리고... 9월 25일이 되었다.

EC2 재시동 소식을 듣자마자 우리는 입이 쩍 벌어졌습니다. 얼마나 많은 카산드라 노드가 영향을 받을지 알게 되자 현기증이 느 껴졌습니다. 그 때 지속적으로 수행한 Chaos Monkey 연습을 떠올렸습니다. 제 반응은 다음과 같았습니다. "한번 해보자!"(크리스토스 칼란치스)

그 주에 비상 대기 중이던 운영 요원들은 바짝 경계했고, 전체 클라우드 데이터베이스 엔지니어링 팀이 초 비상 상태가 되었다. 자동화를 믿었지만 신중한 팀은 최악을 준비하고 최상을 희망했다.

2700대 이상의 상용 카산드라 노드 중에 218개가 재시동 되었고, 22개 노드는 성공적으로 재시동되지 못했다. 따라서 문제가 생긴 노드는 온라인으로 살아나지 않았다. 자동화 시스템이 실패한 노드를 감지해 사람의 개입을 최소화하며 자동으로 교체했다. 넷플릭스의 다운타임은 0이었다.

반복적이고 주기적인 실패에 대한 연습은 모든 회사의 복원 계획의 일부가 되어야 한다. 만일 Chaos Monkey로 카산드라를 테스트하지 않았더라면, 아마 다른 이야기로 끝났을 것이다.

EOB