[기술포스팅 원문]

1. 넷플릭스의 테스트 및 회복력 공학

- 넷플릭스 팀은 프로덕션 테스트에 큰 관심을 갖고 있으며, 혼돈 공학(Chaos Engineering)과 회복력 공학(Resilience Engineering)을 활용한다.

- 혼돈 공학은 하나의 수단으로, 궁극적인 목표는 서비스의 가용성을 개선하는 것이다.

- 팀의 목표는 프로덕션 시스템에서 실험을 통해 서비스의 취약점을 미리 탐지하는 것이다.

- 실시간 트래픽에서만 발견할 수 있는 특정 유형의 취약점이 존재한다고 믿는다.

- 그러므로, 프로덕션 환경에서 직접 실험하는 것이 중요하다.

2. 프로덕션 테스트의 안전성과 모니터링

- 오늘은 프로덕션 테스트에 대해 이야기하겠습니다. 가장 중요한 초점은 안전성과 모니터링입니다.

- 안전성과 모니터링이 마련되어 있지 않으면 훌륭한 프로덕션 테스트를 진행할 수 없습니다.

- 프로덕션 테스트가 무섭게 느껴진다면, 그 목소리를 듣고 왜 그런 느낌이 드는지 파악해야 합니다.

- 이런 두 가지 측면을 Netflix와 우리의 도구 내에서 중점적으로 다룹니다.

- 혼돈 공학(Chaos Engineering)은 시스템의 취약점을 발견하기 위해 프로덕션에서 실험하는 분야로 정의할 수 있습니다.

- Netflix에서는 ChAP라는 도구를 사용하여 취약점을 포착하고, 서비스에 실패를 주입하여 서비스에 대한 가정을 검증합니다.

3. 서비스 D의 캐시 실패에 대한 복원력 테스트

- 서비스 D가 캐시의 실패에 견디는지 확인하기 위해 사용자가 ChAP 인터페이스에서 서비스 D를 선택하고 실패할 서비스로 캐시를 정의한다.

- ChAP는 실제로 서비스 B를 두 개의 복제본으로 클론하여 '제어 클러스터'와 '실험 클러스터'로 나누며, 이는 느낌이 AB 테스트나 '스티키 카나리'와 유사하다.

- 서비스 B의 크기는 상대적으로 작기 때문에, 고객의 소수의 백분율만 이러한 클러스터로 라우팅하는데, 이는 블래스트 반경을 제한하기 위함이다.

- 현재 스트리밍 중인 사용자 수를 기반으로 해당 퍼센트를 계산하고, 이후 실패 주입 테스트를 통해 요청을 태그하여 우리의 기준에 맞는 요청을 처리한다.

4. 요청 헤더에 정보를 추가하여 실험 클러스터로 라우팅

- 요청의 헤더에 정보를 추가함으로써 두 세트의 태그가 생성된다.

- 하나는 실패하도록 지정되고 카나리로 라우팅되며, 다른 하나는 컨트롤로만 라우팅된다.

- 서비스 A의 RPC 클라이언트가 요청 라우팅 지침을 보고 요청을 컨트롤 또는 실험 클러스터로 보낸다.

- 실험 클러스터에서 RPC 계층의 실패 주입 테스트가 요청을 실패로 태그하면 실패한 응답을 반환한다.

- 실험 클러스터는 이를 캐시에서 실패한 응답으로 간주하며, 이후 실패 처리를 위한 코드를 실행한다.

5. 넷플릭스의 카오스 엔지니어링 모니터링 방법

- 카오스 실험을 시행할 때 서비스 A의 관점에서는 모든 것이 정상적으로 작동하는 것처럼 보이지만, 실제로는 그렇지 않은 경우가 많다.

- 넷플릭스는 초기에는 안전 장치가 부족했지만, 지금은 주요 비즈니스 지표인 SPS(초당 스트림 시작)를 통해 안전성을 강화하고 있다.

- 고객이 '프렌즈' 나 '더 오피스' 등을 원하는 때에 시청할 수 있음을 보장하는 것이 넷플릭스 비즈니스의 가장 중요한 요소다.

- 카오스 실험 중에 SPS가 큰 편차를 보일 경우, 자동 카나리아 분석을 사용하여 실험을 중단하고 고객에게 정상적인 경험을 제공한다.

- 우리는 각 지역에서 영향을 받는 트래픽의 양을 제한하여 카오스 실험을 보다 안전하게 진행하고 있다.

6. 실험 실행의 제한과 문제 해결

실험이 동시에 실행될 수 있는 양을 제한하여 업무 시간 동안만 진행하며, 문제가 발생해도 엔지니어를 깨우지 않는다.

테스트가 실패하면 누군가가 명시적으로 문제를 해결할 때까지 자동으로 재실행 되지 않으며, 실패를 인지하고 수정을 확인해야 한다.

또한 서비스가 여러 클러스터로 나누어져 있는 경우 유용한 사용자 지정 속성을 적용할 수 있다.

특정 기기에서 문제가 발생할 경우, 그 기기에 한정하여 실험을 제한할 수 있는 기능도 있다.

7. ChAP 실험을 통해 발견된 취약점 사례

- ChAP는 많은 취약점을 발견했으며, 그중 하나는 사용자 평가에 따른 서비스의 fallback 경로가 제대로 작동하는지를 검증하는 실험이었다.

- 해당 실험을 통해 fallback 경로의 문제를 포착했으며, 이로 인해 가용성 사고가 발생하기 전에 문제가 해결되었다.

- 다른 사례로는 특정 배포와 밤에 간헐적으로 발생한 사용자의 가입 흐름 fallback 문제를 재현하기 위한 실험이 있었다.

- 500 밀리초의 지연을 주입하여 문제를 재현했고, Big Data 포털에 업로드된 로그 파일에서 문제의 원인을 찾을 수 있었다.

- ChAP 실험 설정을 위해 사용자는 여러 가지 사항을 고려해야 하며, 실패 또는 지연을 선택하는 등의 주입 지점을 결정해야 한다.

8. 실험 자동화 통한 서비스의 효율성 증대

- 우리는 다양한 실험을 설계하기 위해 서비스 팀과 만나 여러 가지 조합을 고민했으며, 이 과정은 매우 시간이 오래 걸리는 일이었다.

- 실험을 설정할 때는 자동 카나리 구성(ACA)과 기존 ACAS를 활용했으며, 시스템 메트릭, RPS 성공 및 실패 등을 논의했다.

- 그러나 실험 생성이 번거롭고 효율적이지 않았기에 자동화를 시도하기로 했다.

- 우리는 호출 관계, 타임아웃 파일, 재시도 등을 고려하여 정보를 집계하고, 이를 통해 서비스에 대한 중요한 시각을 제공하는 Monocle을 개발했다.

9. 서비스 종속성 정보와 카오스 실험의 관계

- 사용자가 자신의 앱 및 클러스터 정보를 한 곳에서 쉽게 조회할 수 있도록 설계되어 있으며, 각 행은 종속성을 나타낸다.

- 이 종속성 정보는 카오스 실험에 활용되며, 이런 정보가 한곳에 모여 있다는 사실이 흥미로운 부수적 효과를 만들어냈다.

- 사용자들은 자신의 서비스와 관련된 안티 패턴을 확인할 수 있고, 예를 들어 중요하지 않아야 할 종속성이 실제로는 중요하다는 사실을 알 수 있다.

- 또한, 사용자는 타임아웃 및 재시도 불일치를 통해 실험의 중요도를 평가할 수 있도록 정보를 제공받고, 이를 바탕으로 우선순위를 결정하는 알고리즘에 활용된다.

- 이런 수준의 세부 정보를 제공함으로써 카오스 실험 실행 전에 사용자가 이상한 점을 인지하고 조치를 취할 기회를 마련하고자 한다.

10. 넷플릭스 서비스의 취약점 발견하기

- 넷플릭스 생태계에 대한 맥락이 부족하지만, 이 서비스에는 취약점이 존재한다.

- Hystrix 명령어가 샘플 REST 클라이언트와 그 메소드들을 감싸고 있으며, Hystrix의 타임아웃이 500밀리초로 설정되어 있어 샘플 REST 클라이언트의 요청이 완료되기 전에 Hystrix가 요청을 포기하게 되는 상황이 발생한다.

- 샘플 재시도 클라이언트의 경우, 100 밀리초와 600 밀리초의 타임아웃을 가지고 있으며 이로 인해 Hystrix 래퍼 타임아웃으로 인해 재시도가 완료될 가능성이 줄어든다.

- 이러한 문제는 여러 곳에 분산된 로직으로 인해 이전에는 불가능했던 수준의 통찰력을 제공하게 되니, 이제는 왜 이러한 일이 발생했는지 알아봐야 한다.

- 엔지니어들이 잘못된 선택을 한 것이 아니라 동시에 업데이트할 사항이 너무 많아 발생한 문제임을 이해하는 것이 중요하다.

11. 자동화된 실험 생성 및 우선순위 설정

- 우리는 자동화된 실험 생성을 위해 Monocle을 사용하며, 사용자가 인자 기반 입력을 통해 실험을 생성할 수 있도록 합니다.

- 이러한 모든 요소를 활용하여, 사용자가 직접 실행하지 않도록 실험의 생성과 실행을 자동화하고 있습니다.

- 실험에서는 레이턴시 실패 및 이를 유발하는 요인, RPC, Hystrix 실험을 자동으로 우선순위에 따라 생성하고 있습니다.

- 우리는 RPS 통계 범위, 재시도 수 및 관련 Hystrix 명령 수를 적절히 조정하여 알고리즘을 구성하고 있으며, 고객이 추가하는 맞춤형 영향도 고려하고 있습니다.

- 특히, 로그인 및 가입에 미치는 것으로 알려진 영향을 포함합니다.

12. 실험과 안전성을 위한 모니클의 중요성

- SPS에 미치는 알려진 영향이 있어 부정적인 가중치를 두어 실험을 실행하지 않으며, 테스트 케이스는 중요도 점수에 따라 순위가 매겨진다.

- 모니클은 프로덕션에서 실험을 덜 실행할 수 있도록 피드백을 제공하며, 이러한 피드백 루프를 통해 패턴을 발견하고 특정 구성 파일에서 문제를 파악할 수 있게 되었다.

- 실험이 실패하면 이전에는 해결되어야 했지만, 현재는 다시 실행되기 전에 해결로 표시해야 하며, 사용자들은 알려진 영향을 추가할 수 있다.

- 결론적으로 ChAP의 모니클은 자동 생성된 실험, 자동 우선 순위 지정된 실험 및 장애 발생 전 잠재적 취약점을 찾는 데 매우 중요한 역할을 한다.

- 혼돈 실험을 하는 이유는 고객의 서비스 사용 방식을 이해하고 최고의 경험을 제공하기 위해서라는 점을 잊지 말아야 한다.

요약(한국어) : https://lilys.ai/digest/1095297?s=1&nid=-1
이 게시글은 [lilys.ai]를 통해 요약되었으며, 정보 공유 목적으로 게시되었습니다. 원문 게시물에 대한 책임이나 이해 관계가 없습니다. - 소프트웨어QA 포럼