[Youtube] 넷플릭스 마이크로 서비스 가이드 3-2

유투브 출처 :  넷플릭스 마이크로 서비스 가이드 - 혼돈의 제왕

강의 순서
1. Introductions 00:00~5:38

2. Microservice Basics 05:39~13:18 

3. Challenges & Solutions 13:19 ~ 43:33
 1) Dependency 13:19 ~ 25: 02
 2) Scale 25:03 ~ 33:33
 3) Varience 33:34 ~ 43:33
 4) Chagne 43:33~ 45:45

4. Organization & Architecture 46:46~53:13

 

---

 

3. Challenges & Solutions

 

지난 7년간 넷플릭스의 해법과 해법 철학으로 4가지 접근방법이 있다. 

.

1) Dependency

2) Scale

3) Variance, 다양한 아키텍쳐의 수용

4) Change, 변화를 어떻게 처리할지

 

 

 

2) Scale

 

사례 1. Stateless Services
사례 2. Stateful Services
사례 3. Hybrid Services ( Stateless Services + Stateful Services조합)

 

사례 1. Stateless Services

Stateless는 캐시나 데이터베이스 이야기가 아니다. 엄청나게 많은 데이터를 저장할 필요가 없는 것이다. 매우 자주 요청되는 메모리에 캐시된 메타데이터이다. 따라서 태생적으로 이건 휘발성이 있는 데이터라고 할 수 있다. 고객이 동일한 서버에 접근하도록 해야 할 필요가 없는 경우도 해당 된다. 가장 중요한 컨셉은 서버의 문제가 서비스의 문제는 아니라는 것이다. 이게 잘못 되었다고 해서 시간을 엄청나게 써야하는 그런 류의 장애가 아니다. 아주 빠르게 복구할 수 있는데 그저 동일한 역할을 하는 서버를 새로 켜기만 하면 해결하는 문제이다.

 

오토 스케일링이 복제를 하며 이런 부분을 담당한다. 오토스케일링은 클라우드기반 서비스에서 굉장히 중요한 요소이다. 확장에 대한 최소 값과 최대 값이 있고, 확장을 언제 할지에 대한 매트릭이 있다. 새로운 서버가 시작될 때 S3로 부터 원본을 가져와서 구동 되는 형태이다. 다양한 장점이 있는데, 먼저 트래픽에 따라 서버를 켜고 끄니까 효율이 있다. 고장난 서버를 쉽게 대체할 수 있으며, 가장 좋은 점은 DDos 나 급격한 요청의 증가로 인해 트래픽이 폭증하는 경우 또는 성능상의 버그가 있는 경우에도 무슨 일이 발생한건지 분석하는 동안, 서비스가 정상적으로 동작할 수 있도록 해준다. 아주 강력하게 사용하는 것을 권고하는 바이다. 

 

 

`카오스`를 만들어내는 방법으로 이런 방법이 동작한다는 것을 확인 한다. '카오스 몽키'는 거의 최초의 카오스 도구 였으며, 이게 하는 일은 어떤 노드가 다운되어도 서비스는 문제가 없다는 것을 확인하는 것이다. 넷플릭스에선 카오스 몽키를 도입한 후에 오토스케일링이 잘 동작하는지 걱정하는 일은 없다. 이런 형태의 장애는 더 이상 문제가 아니었다. stateless로 등장하는 단일노드의 장애는 사실 이제 살펴볼 필요도 없는 것이다. 

 

 

사례 2. Stateful Services

이제 stateless와 정 반대인 stateful 서비스에 대해서 알아보자. 이것은 데이터베이스와 캐시 이다. 넷플릭스가 했던것 처럼 가끔 엄청나게 많은 양의 데이터를 내부 캐시에 가지고 있는 커스텀 앱으로 구현될 수도 있다. 넷플릭스는 이것만을 위한 별도의 서비스 구간이 있다. 멀티 리전 전략을 선택하면서 리전간 데이터를 복제할 필요가 있었는데, 사실 이부분이 가장 큰 골치였다. 그래서 조반 에반스는 비즈니스 로직과 상태 데이터를 하나의 애플리케이션에 모두 저장하는 방법을 피하는걸 권고한다. 아무튼 stateless와 가장 다른점은, 서버(노드)의 장애가 매우 신경 써야하는 이벤트라는 것이다. 이런 서버들은 기존의 서버를 준비하고 대체하는 데 몇 시간이 걸리수도 있다. 그래서 더욱 더 조심해야한다. 이부분에 대해 캐시 접근 방법에 대한 2가지를 제안한다.

 

넷플릭스에슨 야후로부터 이직한 많은 엔지니어가 있는데, 이분들은 HAproxy와 Squid 캐시에 대한 경험이 많았다. 이분들이 사용했던 패턴은 고객을 위한 할당된 노드가 있고, 따라서 데이터는 딱 하나만 해당 노드에 저장된다. 여기서의 문제는 당연히 해당 노드에 장애가 발생하는 경우인데 장애가 난 서버에는 할당된 고객들은 서비스에 접근이 불가능하다. 넷플릭스가 Hystrix 구현하기 이전 시점의 더 큰 문제는 스레드 풀에 대해 격벽과 같은 방법을 사용해서 장애를 격리할 수 있는 방법이 없었다.  그 예로 1개의 노드가 다운 되어 넷플릿즈 전체에 장애가 발생했다는 내용이었다. 캐시에 다시 데이터를 올려서 서비스를 복구하는데 3.5시간이 걸렸다. 이게 바로 하지 말아야할 패턴이다. 피해야한다. 

넷플릭스에서는 EVCache 라는 기술을 도입했다. EVCache는 기본적으로 memcached를 랩핑한 것이다. Squid 캐시처럼 샤딩으로 구성되어 있다. 다만 다른 것은 데이터가 여러개의 노드에 중복해서 저장된다는 것이다. 따라서 쓰기가 발생할 때마다 여러개의 노드에 데이터가 저장되고 이 저장되는 데이터는 여러개의 AZ로 복제되어 결과적으로 다수의 네트워크에 데이터가 존재하게 된다. 

 

 

읽기를 할때도 읽기는 효율을 위해 기본적으로 로컬 AZ에서 수행 되지만 그렇지만 접근해야 할 노드가 로컬 AZ에 없는 경우엔 다른 AZ의 노드에서 데이터를 가져올 수 있다. EVCache는 매우 성공적인 도구이고, 현재 캐시가 필요한 모든 서비스에서 사용하고 있다. 넷플릭스에서 이 캐시는 아주 유용한 도구였다. 

 

3. Hybrid Services ( Stateless Services + Stateful Services조합)

 

 

이제 두가지 방법을 조합하는 것에대해 생각해보자. Stateless Services + Stateful Services조합으로 하이브리드 서비스라 불리는 구조이다. EVCache는 좋은 도구인 만큼, 잘못 사용하기 매우 쉽다. EVCache는글로벌에서 초당 3천만 요청을 처리하고, 이건 하루에 2조개의 요청에 해당하는 분량이다. 수천억개의 오브젝트를 저장하고 있다. 수만개의 멤케시 인스턴스를 사용한다. 이것의 가장 큰 장점은 요청의 숫자가 아무리 늘어나도 밀리세컨 단위의 응답 속도가 유지 된다는 것이다. 적절한 수량의 노드가 동작한다면, 트래픽이 아무리 많아도 처리가 가능한 구조이다.

 

 

 몇년전에 한가지 시나리가 있었는데, 사용자 정보를 저장하는 서브스크라이버 서비스가 EVCache에 조금 많이 의존하고 있었다. 이것 역시 또 하나의 하면 안되는 패턴이다. 어쨋든 이 사용자 정보를 필요로 하는 서비스가 많이 있었다. 이를테면 사용자 id, 사용자 정보에 필요한 것들이 있다. 온라인 오프라인, 즉 실시간과 비실시간을 구분하지 않고 모두 동일한 EVCache 클러스터를 통해 데이터를 제공했었다. 추천을 위한 배치 프로세스에서 사용자 정보를 가져가기 위해 호출하기도 하고 사용자 요청 처리를 위한 실시간 데이터 호출도 있었다. 어떤 경우엔 하나의 요청 주기 안에서 동일한 애플리케이션에서 동일한 데이터에 대한 중복 요청까지도 EVCache로 유입 되었는데, 이건 사람들이 데이터가 필요할 때 그저 캐시를 호출했기 때문이다. 이로 인해 피크 상태에서는 서비스에 대한 요청이 초당 80만에서 백만건 정도로 폭증하게 되었다.

 일반적으로 fallback의 방법은 한개만 문제가 되었을때는 잘 동작하지만 예를들어 캐시요청 하나가 미스가 나면 데이터베이스 서비스로 요청을 하는 형태로 동작하지만, EVCache 계층 전체가 완전히 다운되면 다른 이야기가되는데 이때 역시 데이터 베이스 서비스로 호출을 수행하는 안티 패턴이 나타납니다. 어쨋든 기본적으로 데이터 베이스 서비스는 EVCache가 처리하던 막대한 요청을 처리할 능력이 되지 않는다. 따라서 전체 서비스는 빠르게 다운 되었다. 엄청난 요청을 처리하던 EVCache 가 다운되면 전체 서브스크라이버 서비스의 다운으로 이어진다는 것이다. 

 

 몇가지 해법이 있는데 첫번째는 배치 작업을 캐시 요청과 실시간 요청을 분리하는 것이었다. 그리고 하나의 요청 안에서 발생하는 캐시 참조는 한번만 발생 하도록 함으로써 보다 효율적으로 EVCache 리소스를 사용할 수 있었다. 그리고 아직 적용하진 않았지만, 이제 곧 적용할 것중 하나는 클라이언트 장치에 서비스 접근에 필요한 보안 토큰을 저장함으로써 서브스크라이버 서비스가 다운된 경우에도 암호화된 토큰을 이 장치에 저장된 것으로 사용하는 방법이다. 따라서 이 토큰에는 사용자를 인증을 위한 데이터가 올바르게 저장되어 있어야 하며 이 방법을 통해 서브스크라이버가 다운된 경우에도 사용자가 서비스를 지속적으로 사용할 수 있도록 할수 있다. 여기에 카오스 도구들을 사용해서 부하를 시뮬레이션 한다.