Netflix 서버 API의 GraphQL로의 이관 여정

Netflix의 UI 팀에서 상당량의 Server API를 GraphQL로 이관하였다고 합니다. 이 포스팅에서는 운영중인 Netflix 서비스를 어떻게 안정적으로 이관하였는지 노하우를 설명하는 포스팅입니다.

원문링크: https://netflixtechblog.com/migrating-netflix-to-graphql-safely-8e1e4d4f1e72

Migrating Netflix to GraphQL Safely

 

2022년에는 Netflix의 iOS 및 Android 애플리케이션에 큰 변화가 있었습니다. 다운타임 없이 Netflix의 모바일 앱을 GraphQL로 마이그레이션했으며, 여기에는 클라이언트에서 API 레이어까지 전체적인 점검이 포함되었습니다. 최근까지 내부 API 프레임워크인 Falcor 가 모바일 앱을 구동했습니다. 이제 도메인 팀이 API의 특정 섹션을 독립적으로 관리하고 소유할 수 있는 API에 대한 분산 접근 방식인 Federated GraphQL 의 지원을 받습니다. 수억 명의 고객을 위해 중단 없이 안전하게 이를 수행하는 것은 특히 관련된 변화의 다양한 측면을 고려할 때 매우 어려운 일입니다. 이 블로그 게시물에서는 이 마이그레이션을 수행하는 데 사용된 (GraphQL 외에도) 광범위하게 적용 가능한 기술을 공유합니다. 오늘 논의할 세 가지 전략은 AB 테스트, 재생 테스트 및 Sticky 카나리아 입니다.

---

마이그레이션 이전 어플리케이션 구조
- GraphQL 이전에는 API 팀에서 구현하고 유지 관리하는 Monolithic Falcor API를 사용하였습니다. 

 

마이그레이션 과정
- 1단계
기존 Monolith Falcor API 위에 GraphQL Shim 서비스를 만들었습니다.
※ Shim : Shim 형식은 테스트 중에 앱의 구성 요소를 격리하는 데 중요한 역할을 합니다. 호출을 가로채고 특정 메서드로 전환하여 작동합니다. 그러면 테스트 내에서 사용자 지정 코드로 직접 연결할 수 있습니다. 이 기능을 사용하면 이러한 메서드의 결과를 관리하여 외부 조건에 관계없이 각 호출 중에 결과가 일관되고 예측 가능하도록 할 수 있습니다. 이 수준의 제어는 테스트 프로세스를 간소화하고 보다 안정적이고 정확한 결과를 달성하는 데 도움이 됩니다.

본격적인 마이그레이션을 시작하는 대신 기존 Falcor API 위에 GraphQL Shim을 만들었습니다. GraphQL Shim을 통해 클라이언트 엔지니어는 빠르게 GraphQL로 전환하고, 캐시 정규화와 같은 클라이언트 측 문제를 파악하고, 다양한 GraphQL 클라이언트를 실험하고, 서버 측 마이그레이션으로 인해 차단되지 않고 클라이언트 성능을 조사할 수 있었습니다. 

1단계를 안전하게 시작하기 위해 AB 테스트를 사용했습니다.
※ AB 테스트 : 분할 테스트 또는 버킷 테스트라고도 하는 A/B 테스트는 두 가지 콘텐츠를 비교하여 방문자/뷰어가 더 높은 관심을 보이는 버전을 확인합니다. 주요 측정지표를 기반으로 가장 성공적인 버전을 측정하기 위해 변형(B) 버전과 비교하여 컨트롤(A) 버전을 검증합니다.

- 2 단계
도메인 팀이 소유한 GraphQL 서비스를 위해 GraphQL Shim 서비스 및 레거시 API 모놀리스를 더 이상 사용하지 않습니다.

 

 
레거시 Falcor API가 영원히 지속되는 것을 원하지 않았기 때문에 Federated GraphQL을 활용하여 여러 GraphQL 서버로 단일 GraphQL API를 강화했습니다.

또한 페더레이션 지시문을 사용하여 GraphQL Shim에서 Video API로 필드 구현을 교체할 수도 있습니다. 2단계를 안전하게 시작하기 위해 Replay Testing 과 Sticky Canaries를 사용했습니다.

※ Replay Testing : 사용자의 이벤트를 중심으로 화면 내 Object 정보 및 데이터등을 Recording 하고 Script 화 하여 이를 그대로 재현(Replay)할 수 있는 테스트 자동화 기법

※ Sticky Canary : 기존 Canary에서 일부 개선된 테스트 방식으로 일부 고정된 사용자 풀을 유지하여 Canary 테스트를 수행하는것

---

테스트 전략

테스트 전략을 결정하는 두 가지 주요 요소는 다음과 같습니다.

• 기능적 요구사항과 비기능적 요구사항
• 멱등성

데이터 정확성과 같은 기능적 요구 사항을 테스트 하고 요청이 멱등성인 경우 Replay Testing을 사용했습니다 . 동일한 입력으로 동일한 쿼리를 테스트하고 지속적으로 동일한 결과를 기대할 수 있다는 것을 알고 있었습니다.

멱등성이 아닌 필드를 요청한 GraphQL 쿼리 또는 변형 테스트를 재생할 수 없었습니다.

그리고 사용자 상호 작용 캐싱 및 로깅과 같은 비기능적 요구 사항을 테스트할 수 없었습니다 . 이러한 경우에는 응답 데이터가 아닌 전반적인 동작을 테스트했습니다. 그래서 더 높은 수준의 측정 기준 기반 테스트인 AB 테스트 및 Sticky 카나리아 에 의존했습니다.

세 가지 테스트 전략에 대해 더 자세히 논의해 보겠습니다.

테스트 도구: 

AB 테스트 (AB Testing)
Netflix는 전통적으로 AB 테스트를 사용하여 신제품 기능이 고객의 공감을 불러일으키는지 여부를 평가합니다. 1단계에서는 AB 테스트 프레임워크를 활용하여 사용자 세그먼트를 총 100만 명의 사용자로 구성된 두 그룹으로 분리했습니다. 통제 그룹의 트래픽은 레거시 Falcor 스택을 활용한 반면, 실험 집단은 새로운 GraphQL 클라이언트를 활용하고 GraphQL Shim으로 전달되었습니다. 고객에게 미치는 영향을 확인하기 위해 오류율, 지연 시간, 렌더링 시간 등 다양한 지표를 비교할 수 있었습니다.

Falcor와 GraphQL을 테스트하고 대략적인 QoE (경험 품질 측정항목)를 보고하는 클라이언트 측 AB 실험을 설정했습니다 . AB 실험 결과는 GraphQL의 정확성이 레거시 시스템과 동등하지 않다는 것을 암시했습니다. 다음 몇 달 동안 이러한 높은 수준의 측정 항목을 조사하고 캐시 TTL, 결함이 있는 클라이언트 가정 등과 같은 문제를 해결하는 데 보냈습니다.

성과
높은 수준의 건강 지표: AB 테스트는 전반적인 클라이언트 측 GraphQL 구현에 필요한 보증을 제공했습니다. 이를 통해 6개월 만에 모바일 홈페이지 캔버스의 트래픽을 100% GraphQL로 성공적으로 마이그레이션할 수 있었습니다.

문제
오류 진단: AB 테스트를 통해 잠재적인 문제를 가리키는 대략적인 지표를 확인할 수 있었지만 정확한 문제를 진단하는 것은 어려웠습니다.

재생 테스트(Replay Testing) — 규모에 따른 검증!
마이그레이션의 다음 단계는 GraphQL 우선 서버(비디오 API 서비스)에서 기존 Falcor API를 다시 구현하는 것이었습니다. Falcor API는 10년이 넘는 기술 부채로 인해 로직이 많은 단일체가 되었습니다. 그래서 다시 구현된 Video API 서버가 버그가 없고 이미 제품화된 Shim 서비스와 동일한지 확인해야 했습니다.

멱등성 API가 GraphQL Shim에서 Video API 서비스로 올바르게 마이그레이션되었는지 확인하기 위해 재생 테스트 도구를 개발했습니다 .

어떻게 작동하나요?

 

 
재생 테스트 프레임워크는 GraphQL 페더레이션에서 사용할 수 있는 @override 지시문을 활용합니다. 이 지시문은 GraphQL 게이트웨이에 다른 GraphQL 서버를 통해 하나의 GraphQL 서버로 라우팅하도록 지시합니다. 예를 들어 Shim 서비스와 비디오 서비스에서 정의한 다음 두 가지 GraphQL 스키마를 살펴보겠습니다.

GraphQL Shim은 먼저 1단계에서 CertificationRating 필드(Rated R 또는 PG-13과 같은 것)를 정의했습니다. 2단계에서는 VideoService를 시작하고 @override 지시문 으로 표시된 동일한 인증Rating 필드를 정의했습니다. @override 지시문 과 동일한 필드가 있으면 GraphQL 게이트웨이에 이 필드의 해상도를 이전 Shim 서비스가 아닌 새로운 비디오 서비스로 라우팅하도록 알립니다.

Replay Tester 도구는 Mantis 의 원시 트래픽 스트림을 샘플링합니다 . 이러한 샘플링된 이벤트를 통해 도구는 프로덕션에서 실시간 요청을 캡처하고 GraphQL Shim 및 새로운 Video API 서비스에 대해 동일한 GraphQL 쿼리를 실행할 수 있습니다. 그런 다음 도구는 결과를 비교하고 응답 페이로드의 차이를 출력합니다.

테스트가 완료되면 엔지니어는 평면화된 JSON 노드 로 표시되는 차이점을 볼 수 있습니다 . 괄호 안의 쉼표 왼쪽에는 대조값이, 오른쪽에는 실험값이 표시됩니다.

/data/videos/ 0 /tags/ 3 / id : ( 81496962 , null )
/data/videos/ 0 /tags/ 5 / displayName : (Serie,  value: “S\ 303 \251rie”)

위에서 두 가지 차이점을 포착했습니다. 첫 번째 차이점은 실험에서 ID 필드에 대한 데이터가 누락되었고 두 번째 차이점은 인코딩 차이가 있었습니다. 또한 현지화, 날짜 정밀도 및 부동 소수점 정확도의 차이도 확인했습니다. 이를 통해 가입자 계획과 사용자 지리적 위치에 따라 고객의 카탈로그 가용성이 결정되는 복제된 비즈니스 논리에 대한 확신을 갖게 되었습니다.

성과

• 두 GraphQL 구현 간의 패리티에 대한 신뢰도
• 과도한 시간 초과로 인해 데이터가 누락된 경우 튜닝 구성을 활성화했습니다.
• 많은(알 수 없는) 입력이 필요하고 정확성을 확인하기 어려울 수 있는 테스트된 비즈니스 논리

 

문제

• PII 및 비멱등성 API는 재생 테스트를 사용하여 테스트해서는 안 되며 이를 방지하는 메커니즘을 갖는 것이 중요합니다 .
• 수동으로 구성된 쿼리는 개발자가 테스트하기 위해 기억하는 기능만큼만 우수합니다. 단지 잊어버렸기 때문에 테스트되지 않은 필드로 끝났습니다.
• 정확성이라는 개념도 혼란스러울 수 있습니다. 예를 들어, 배열이 비어 있거나 null인 것이 더 정확합니까, 아니면 단지 노이즈입니까? 궁극적으로 클라이언트 오류 처리의 견고성을 검증하는 것이 어려웠기 때문에 기존 동작을 최대한 일치시켰습니다.

이러한 단점에도 불구하고 Replay Testing은 대부분의 멱등성 쿼리 에 대해 기능적 정확성을 달성했음을 나타내는 핵심 지표였습니다 .

Stikcy Canary
재생 테스트는 새로운 GraphQL API의 기능적 정확성을 검증하지만 사용자 상호 작용의 전반적인 인식 상태 와 같은 성능이나 비즈니스 지표 통찰력을 제공하지 않습니다 . 사용자가 동일한 속도로 재생을 클릭하고 있나요? 사용자가 흥미를 잃기 전에 콘텐츠가 제 시간에 로드되고 있나요? 또한 비멱등성 API 검증에는 재생 테스트를 사용할 수 없습니다. 확신하기 위해 Sticky Canary라는 Netflix 도구를 사용했습니다.

Sticky Canary는 전체 실험 기간 동안 고객이 카나리아 또는 기준 호스트에 할당되는 인프라 실험입니다. 모든 수신 트래픽은 버킷 해시와 유사하게 장치 및 프로필을 기반으로 실험적 또는 기준 호스트에 할당됩니다. 실험적 호스트 배포는 실험에 할당된 모든 고객에게 서비스를 제공합니다. Sticky Canaries에 대해 자세히 알아보려면 AWS Reinvent의 Chaos Engineering 강연을 시청하세요 .

GraphQL API의 경우 Sticky Canary 실험을 사용하여 GraphQL 게이트웨이의 두 인스턴스를 실행했습니다 . 기본 게이트웨이 는 모든 트래픽을 GraphQL Shim으로 라우팅하는 기존 스키마를 사용했습니다. 실험용 게이트웨이 는 트래픽을 최신 Video API 서비스로 라우팅하는 새로 제안된 스키마를 사용했습니다. 기본 에지 게이트웨이인 Zuul은 실험 매개변수를 기반으로 두 클러스터 중 하나에 트래픽을 할당합니다.

그런 다음 두 클러스터의 성능을 수집하고 분석합니다. 우리가 면밀히 모니터링하는 일부 KPI에는 다음이 포함됩니다.

• Median and tail latencies
• Error rates
• Logs
• Resource utilization–CPU, network traffic, memory, disk
• Device QoE (Quality of Experience) metrics
• Streaming health metrics

한 시간 동안의 실험을 위해 작은 고객 할당으로 소규모로 시작했습니다. 성능을 검증한 후 천천히 범위를 구축했습니다. 고객 할당 비율을 높이고 다중 지역 테스트를 도입했으며 결국 12시간 또는 하루 동안의 실험을 진행했습니다. Sticky Canaries는 실시간 프로덕션 트래픽에 영향을 미치고 고객에게 지속적으로 할당되므로 진행 과정에서 검증이 필수적입니다.

몇 차례의 끈질긴 카나리아 실험을 통해 마이그레이션 2단계에서 모든 핵심 지표가 개선되었다는 확신을 얻었으며, 자신 있게 GraphQL을 전 세계적으로 활용할 수 있었습니다.

성과
Sticky Canaries는 새로운 GraphQL 서비스에 대한 확신하는 데 필수적이었습니다.

 

• 비멱등성 API: 이 테스트는 돌연변이 또는 비멱등성 API와 호환됩니다.
• 비즈니스 지표: Sticky Canaries는 마이그레이션 후 핵심 Netflix 비즈니스 지표가 개선되었음을 검증했습니다.
• 시스템 성능: 지연 시간 및 리소스 사용량에 대한 통찰력은 마이그레이션 후 조정 프로필이 어떻게 변경되는지 이해하는 데 도움이 됩니다.

문제

• 부정적인 고객 영향: Sticky Canary는 실제 사용자에게 영향을 미칠 수 있습니다. 일부 고객을 지속적으로 해당 서비스로 라우팅하기 전에 새로운 서비스에 대한 확신이 필요했습니다. 이는 실험을 자동으로 취소하는 실시간 영향 감지를 통해 부분적으로 완화됩니다.
• 단기: Sticky Canary는 단기 실험을 위한 것입니다. 수명이 긴 테스트의 경우 본격적인 AB 테스트를 사용해야 합니다.

---

요약하자면
기술은 끊임없이 변화하고 있으며 엔지니어로서 경력의 대부분을 마이그레이션을 수행하는 데 소비합니다. 문제는 우리가 이주하고 있는지가 아니라 이주하고 있는지 여부입니다.안전하게, 다운타임 없이 적시에.

Netflix에서는 테스트 중인 각 특정 사용 사례를 대상으로 이러한 마이그레이션에 대한 확신을 보장하는 도구를 개발했습니다. GraphQL 마이그레이션에 사용한 세 가지 도구인 AB 테스트 , 재생 테스트 , Sticky Canary를 다루었습니다 .