시작하기에 앞서

본 글은 넷플릭스 기술 블로그의 Active-Active for Multi-Regional Resiliency Article을 번역한 글입니다.

해당 Article의 저자는 Ruslan Meshenberg, Naresh Gopalani, and Luke Kosewski입니다.

서론

6월에 우리는 지역 전체 ELB 중단에 대한 resiliency(탄력성)를 위한 접근 방식인 Isthmus에 대해 이야기 했었다.

Isthmus 프로젝트를 완료한 뒤, 우리는 더 높은 탄력성과 가용성을 위해 우리의 다음 과제에 착수했다. - 완전한 지역 전체 Active-Active 솔루션

이 프로젝트는 지금 완료하였고, 넷플릭스는 미국 전역에 Active-Active가 가동중이다.

그래서 이 글은 몇 가지 흥미로운 도전 과제와 우리가 걸어간 길에 대한 배움을 강조하는 것을 목표로 한다.

실패 - 규모와 성능의 기능

일반적으로, 실패는 조직이 다루는 실패율은 크게 2가지, 변화의 속도와 운영 배포 규모에 달려있다.

만약 규모와 속도가 작다면, 대부분의 경우 잘 동작한다.

규모가 커지면 속도가 느려도 하드웨어의 실패할 가능성이 높아진다.

반대로, 작은 규모라도 속도가 충분히 빠르다할지라도 소프트웨어의 실패할 가능성이 증가할 것이다.

궁극적으로, 당신이 큰 규모에서 동작하면서 여전히 빠른 속도를 추구한다면 작업은 항상 실패할 것이다.

물론, 모든 실패가 똑같이 생성되지는 않는다.

우리가 본 글에서 집중할 실패의 종류는 다루기 훨씬 더 어렵고 가장 중요한 것들이다.

완벽히 장기간 서비스가 멈춰서 불만을 품은 고객들의 글이 고객센터에 넘쳐나고, 그들의 불만이 트위터에 올라오고, “서비스 X가 다운됐다!”는 기사들이 여러 출판사에 나타나는 것들.

넷플릭스에서, 우리가 추구하는 가용성은 99.99%로 우리의 서비스가 중단될 시간이 많지 않다.

그래서 추가적으로 가용 가능한 지역과 여러 인스턴스들에 우리의 서비스를 배포하는 것에 더해, 우리는 여러 AWS 지역에 걸쳐 서비스를 배포해야하기로 결정했다.

완전한 지역 인프라 중단은 극단적으로 일어나지는 않지만, 우리의 변화는 속도는 때때로 지역에 있는 치명적인 서비스를 중단시키도 해서 우리는 넷플릭스가 어떤 숨은 의존들에도 탄력있는 서비스로 만들고 싶었다.

이 과정에서, 우리는 독립성 원칙과 이중화 활용하고 있다.

그것은 한 지역에서의 어떤 종류의 실패가 다른 동작중인 서비스에 영향을 미치지 않아야하며 networking partitioning event가 또 다른 지역의 서비스 품질에 영향을 미쳐서도 안된다.

Active-Active 개요

쉽게 말해, Active-Active 솔루션이란 여러 AWS 지역에 걸쳐 배포된 유저 호출 경로의 모든 서비스를 가져오는 것이다.

이 경우에서는 버지니아의 US-East-1과 오레곤의 US-West-2이다.

이것을 하기 위해서, 몇 요구사항이 충족되어져야만한다.

• 서비스는 stateless해야만 한다. 모든 데이터와 상태의 복제는 데이터 계층에서 처리되어야한다.

• 그것들은 리전 내 로컬에서 어떤 자원에도 접근할 수 있어야한다. 이것은 S3, SQS 등과 같은 자원들을 포함한다. 이것은 S3 버킷으로 데이터를 발행하는 몇 애플리케이션들을 의미하며 그것들은 여러 지역에 걸친 S3에도 똑같은 데이터를 발행해야만한다.

• 유저의 호출 경로에 지역 간 호출이 되어서는 안된다. 데이터 복제는 비동기적이어야한다.

정상적인 동작에서, 유저는 50대 50으로 러프하게 분리된 가장 가까운 AWS 지역으로 라우팅되어질 것이다.

전 지역의 중대한 중단이 발생할 경우, 우리는 geo-DNS를 재정의하고, 모든 유저의 트래픽을 정상 지역으로 보내는 도구를 갖고 있다.

이러한 환경을 구축하기 위한 몇 가지 기술적 도전들이 있었다.

• 올바른 지역으로 트래픽을 보내기 위한 효과적인 도구들

• 엄청난 양의 이벤트를 다루기 위한 트래픽 조절과 부하 분산

• 상태와 데이터를 비동기적으로 여러 지역에 걸쳐 복제

DNS - Denominator를 사용해 유저 트래픽 컨트롤

우리는 UltraDNS와 Route 53의 조합을 통해 유저의 트래픽을 우리의 서비스로 보낸다.

우리의 Denominator 프로젝트는 다양한 DNS 제공자를 다루는 커맨드라인과 단일 클라이언트 라이브러리를 제공한다.

넷플릭스에서 만든 데노미네이터

왜 우리가 두개의 조합을 사용하게 된 몇 가지 이유가 있다.

• UltraDNS는 북미의 다른 지역에서 다른 지역 엔드포인트로부터 직접적으로 고객들을 라우팅하는 기능을 우리에게 제공한다. 이 기능은 Dyn을 포함한 다른 벤더에 의해 지원되지만 Route 53에서는 지원하지 않는다. 우리는 대기 시간 기반 라우팅 메커니즘을 사용하고 싶지 않았다. 왜냐하면 그것은 예측할 수 없는 traffic migration effects를 야기시키기 때문이다.

• UtlraDNS와 ELB 사이에 Route 53 레이러를 사용함으로써, 우리는 유저 트래픽을 전환하는 기능과 Route 53 API가 다른 DNS 벤더 API들에서는 장점이 아닌 신뢰할 수 있고 빠른 구성 변경 기능을 제공한다.

• 구분된 Route 53 레이어를 사용해 트래픽을 스위칭하는 것이 조금 더 간단하다. 직접적인 그룹으로 지역을 옮기는 것 대신에, Route 53의 CNAME들만 옮기면 된다.

Zuul - 트래픽 셰이핑 ( Traffic Shaping )

우리는 최근 Zuul에 대해 이야기했었다. ( 줄은 2013년도에 커뮤니티에 공개되었다. )

모든 넷플릭스의 엣지 서비스들은 줄 레이어 계층에 있다.

Zuul은 우리에게 다운 스트림 서비스가 과도하게 실행되지 않도록 보호하기 위해 트래픽을 줄일지 말지를 결정하기 위한 능력, 런타임에 라우팅을 변화하기 위한 능력, 적절한 서비스 클러스터로 트래픽을 보내기 위한 탄력적이고 강력한 방법을 제공한다.

우리는 Active-Active 사용을 가능하게 하기 위해, 운영 요구사항을 위해 원래 기능의 집합 이상으로 Zuul을 강화시켜야했다.

기능 강화는 몇 가지 영역에서 이루어졌다.

• 잘못 라우팅된 리퀘스트에 대한 처리와 식별 기능.
  • 유저의 요청은 우리의 geo directional records에 허락되지 않는다면 잘못 라우팅되어지는 것으로 정의한다.
  • 이러한 보장은 단일 유저 장비의 세션이 여러 지역에 걸쳐있지 않다는 것을 의미한다.
  • 우리는 또한 잘못 라우팅된 요청들이 올바른 AWS Region으로 보내지기 위한 isthmus 모드를 사용할지, 클라이언트가 올바른 Region으로 보내질지에 대한 응답을 반환할지에 대한 제어를 갖는다.

• FailOver 모드에서 지역을 정하는 능력. 이것은 잘못 라우팅된 리퀘스트를 다른 지역으로 라우팅하기 위한 시도를 더 이상하지 않고 로컬에서 처리한다.

• 특정 시점에서 최대 트래픽 레벨을 정의하기 위한 능력.
  • 엄청난 양의 요청으로부터 다운스트림 서비스를 보호하기위해 추가적인 요청들이 자동으로 삭제된다. (Response == Error)
  • 이같은 능력은 또는 지역 캐시가 Cold일 때 persistence layer가 요청으로 과부화되지 않게 하기 위해, 증가하는 수요를 충족하기 위해 계속해서 Scailing Up하는 서비스를 보호하기 위해서 반드시 필요하다.

이같은 모든 능력들은 우리에게 둘 모두 안정된 상태와 장애 극복 상황에서 유저의 트래픽을 관리할 수 있는 강력하고 유연한 도구를 제공한다.

데이터 복제 ( Replicating the data ) - 카산드라(Cassandra)와 EvCache

Active-Active를 구현하기 위한 더 흥미로운 도전 중의 하나는 유저의 데이터와 상태의 복제였다.

넷플릭스는 우리의 확장가능하고 탄력적인 NoSQL 저장 솔루션으로 카산드라를 사용해오고 있다.

카산드라의 타고난 능력 중 하나는 다방향(multi-directional), 다중 데이터 센터 비동기 복제이다.

이러한 이유로 사용자의 요청을 수행하기 위한 읽기/쓰기 모든 데이터는 카산드라에 저장된다.

넷플릭스는 Active-Active 이전, US-EAST-1과 EU-WEST-1에 Multi Region 카산드라 클러스터를 운영해왔다.

하지만 이러한 클러스터들에 저장되는 데이터의 대다수가, 비록 결과적으로는 다른 지역에 복제가 되어진다고 하더라도, CL_LOCAL_QUORUM과 CL_ONE의 영속성 레벨을 사용하여 작성된 지역에서 대부분 소모되어졌다.

이러한 사용 사례에서 경우에서 지연은 큰 문제가 아니다.

Active-Active는 그 패러다임을 바꾼다.

미국 지역 중 한 곳에서 들어올 가능성이 있는 요청의 경우 우리는 데이터 복제가 허용 가능한 시간 임계값 내에 있는지 확실하게할 필요가 있다.

이것은 우리가 다중 지역의 클러스터 중 하나의 지역에서 100만 레코드 쓰기 실험을 우리에게 수행하도록 만들었다.

우리는 클러스터에서 프로덕션 수준의 로드를 유지하면서 다른 지역에서 최초 시작 지점에서 작성된 레코드를 500ms 후에 읽기를 시작했다.

모든 레코드는 성공적으로 읽혔다.

비록 그 테스트가 철저하지는 않았지만, negative tests와 comprehensive corner case failure scenarios ( 포괄적인 코너 케이스 실패 시나리오? ), 그것은 우리의 사용 사례에서 아파치 카산드라의 일관성과 적시성(timeliness) 수준에 대해 우리에게 충분한 자신감을 심어주었다.

유저 요청을 처리하는 대다수의 애플리케이션은 적시에 이를 수행해야하기 때문에, 우리는 데이터 단계 읽기가 일반적으로 단일 밀리초 범위에서 빠르다는 것을 보장해야만한다.

어떤 경우에서, 카산드라 클러스터를 메모리 케시 레이어로 사용하기도 하고, 다른 경우에서는 Memcached에만 존재하는 일시적인 계산된 데이터를 갖기도 한다.

다중 지역 Active-Active 구성에서 memcached를 관리하면, 캐시를 원본과 동일하게 유지해야하는 문제가 발생한다.

Memcached를 위한 다중 마스터 복제를 재구현하기 보다는, 우리는 우리의 EVCache 클라이언트에 원격 캐시 무효화 기능을 추가했다. ( 2013년 초에 공개한 memcached 오픈소스 )

한 지역에서 쓰기가 발생하면 EvCache 클라이언트는 다른 지역에 해당 항목을 무효화하기 위한 메세지를 보낸다. ( SQS와 같은 곳에 )

따라서 다른 지역에서 이후의 읽기는 재계산하거나, 카산드라로 넘어가 로컬 캐시를 업데이트 시킨다.

여러 환경 및 지역에서 배포 자동화

우리가 2012년에 유럽에서 우리의 서비스를 런칭했을 때, 배포 환경을 2개에서 4개로 늘렸다. 테스트와 프로덕션, 그리고 미국 동부(왜 유럽에 서비스를 오픈했는데 미국 동부쪽을 늘린거지, 오타인가…)와 유럽 서부.

비슷하게 북미 서비스를 Active-Active 모드로 배포하기로 결정으로 배포 환경이 6개로 늘어났다. - 미국 서부 지역에 테스트와 프로덕션을 추가.

모든 개별적인 배포에 우리는 Asgard를 사용했다. (매우 강력하고 유연한 배포와 환경 설정 콘솔)

우리는 우리의 개발자들이 모든 지역에서의 일관성을 위해 최소 6개의 수동 배포를 거칠 필요가 없다는 사실을 빠르게 깨달았다.

다중 지역의 배포 프로세스를 좀 더 자동화하기 위해, 우리의 Tools 팀은 워크플로우 툴을 개발했다. 이름하여 Mimir. 오픈소스 Glisten 워크플로우 언어에 기반한.

그것은 개발자들이 다중 지역 배포 타겟과 배포 방법 및 시기에 대한 특정한 규칙을 지정할 수 있다.

이것은 자동화된 카나리아 분석과 자동화된 롤백과 결합되어 단계별 작업 시퀀스로 여러 위치에 애플리케이션을 자동으로 배포할 수 있다.

일반적으로 지역 업데이트 사이에 많은 시간을 기다린다. 그래서 우리는 우리가 전세계로 배포되기 전에 문제를 알아낼 수 있다.

Monkeys — Gorilla, Kong, Split-brain (번역 불가…)

우리는 Simian Army에 대해서 많은 이야기를 해왔다. SimianArmy는 이제 더 이상 개발되지 않는 프로젝트

( 참고로 Simian Army 프로젝트는 현재 RETIRED 상태이다. 카오스 몽키는 독립적인 프로젝트가 되었고, swabbie와 Conformity Monkey는 CD 오픈소스인 Spinnaker로 합병되었다.)

우리는 우리의 많은 서비스가 다양한 종류의 실패에도 탄련적이라는 것을 검증할 수 있고, 우리가 우리의 시스템이 취약하지 않게 만드는 방법을 배웠다.

Simian Army의 멤버로 잘 알려진 Chaos Monkey는 테스트와 프로덕션 환경 모두에서 동작한다. 그리고 가장 최근에는 그것의 hit list에 카산드라 클러스터가 포함되었다.

우리의 아키텍처가 더 큰 중단에 탄력적이라는 것을 보장하기 위해서, 우리는 더 큰 Simian을 출시했다.

• Chaos Gorilla
  • 가용영역을 죽이는 서비스이다. 넷플릭스 내부에서 운영되는 서비스. ( 오픈소스 아님 )
• Split-brain
  • 지역간의 연결을 끊는 서비스. 역
• Chaos Kong
  • 리전을 죽이는 서비스이다. 넷플릭스 내부에서 운영되는 서비스. ( 오픈소스 아님 )

실제 장애극복 (Real-life failover)

비록 우리가 다중 지역 격리 및 중복성을 검증하기 전에도 우리는 현실에서 지역적인 장애 극복을 실행할 기회가 있었다.

우리의 지역 중 하나에 있는 Middle Tier 시스템 중 하나는 결국 대부분의 클러스터가 응답하지 않는 심각한 저하를 경험했다.

정상적인 상황에서, 이것은 한동안 많은 사용자가 영향을 받는 심각한 중단의 결과를 초래했을 것이다.

이번에는 추가 도구를 사용할 수 있었다.

우리가 장애 극복과 유저의 요청을 정상으로 동작하는 리전으로 라우팅하는 것을 수행하기로 결정했다.

짧은 시간 안에, 서비스의 품질은 모든 유저에게 복원되어졌다.

우리는 그러고 나서 문제의 요인을 분류하고, 수정 사항을 배포한 다음, 그후에 현재 정상적인 지역으로 트래픽을 다시 라우팅하는데 시간을 할애할 수 있었다.

여기 장애복구의 타임라인이 있다. 검은 선은 일주일 전 기준이다.

가용성의 다음 단계 ( Next steps in availability )

Active-Active 프로젝트를 위한 묘사된 모든 작업들은 이제 막 진행중이다.

프로젝트는 이제 막 Phase2로 접어들었다.

여기서 우리는 모든 다중 지역 도구의 운영에 초점을 맞출것이고, 우리가 할 수 있는 한 많은 수동 작업들을 자동화할 것이다.

우리는 우리가 장애극복을 실행하기 위한 결정하는데 필요한 시간과 트래픽의 모든 실패를 극복하기 위한 시간을 최소화하는데에 집중할 것이다.

우리는 좀 더 어려운 몇 가지 문제들을 계속 해결하고 있다.

예를들어, 일부 종속성이 느리게 응답하거나 에러를 반환하지만 일부만 처리하는 방법이 있을까?

틀림없이 이것은 카오스 타입의 시나리오를 다루는 것보다 더 어렵다. 서비스가 내려가있거나, 지속적으로 실패할 때 무엇을 해야할지 결정하는 것이 더 쉽다.

시스템이 이러한 시나리오를 처리하는 방법을 배우는데 도움이 되도록, 우리는 Latency Monkey를 가지고 있다. (무슨 원숭이가 이렇게 많아…?)

(Latency Monkey는 주어진 빈도/분포에서 대기 시간과 오류를 주입할 수 있는 서비스인 듯)

요약

규모가 크고 속도가 빠르르면 실패의 빈도가 잦아진다.

우리는 고립성과 중복성의 원칙을 활용하여 전지역적 중단에 더 탄력적으로 아키텍처를 만들었다.

우리가 우리의 서비스를 탄력적으로 구성하기 위해 사용한 기본 빌딩 블록은 여기에서 활용가능하다.

Active-Active에 대한 변화의 대부분은 이미 활용가능하며, 일부는 소스 코드를 업데이트하기 전에 코드 리뷰를 거친다.

이 글은 기술적인 도전과 Active-Active 솔루션에 대해 묘사하고있다.

비기술적 복잡성 수준은 심지어 더 어렵다.

특히, 많은 다른 중요한 프로젝트들이 동시에 진행되고 있다는 점을 감안하면.

성공의 비결은 넷플릭스에서 일하는 놀라운 팀과 엄청난 엔지니어들이었다.

그리고 US-WEST2에서 추가 용량을 신속하게 프로비저닝할 수 있는 AWS의 능력이다.

그것은 처음부터 끝까지 고작 몇 달 안에 모든 팀이 협력하여 만들어냈다.