본 글은 Netflix Tech 블로그의 글을 의역하여 작성한 글입니다.
배경
Netflix는 지난 10년 간 주문형 스트리밍 비디오 서비스를 제공하고 있습니다. 서비스를 제공하는 기간동아 Netflix는 전 세계 고객 확보를 위해 30일간 무료 평가판과 결합된 3가지 요금제(기본, 표준, 프리미엄)에 의존했습니다. 하지만 지금 세상은 과거에 비해 많이 변했습니다. 사람들의 여가 시간을 채울 경쟁이 증가하고 있고 디바이스 생태계가 경이적으로 성장했으며 소비자는 언제 어디서나 원하는 디바이스로 콘텐츠를 시청하기를 원하고 있습니다.
Netflix의 Growth 엔지니어링 팀은 이런 변화를 예상하고 적응하는데 도움이 되는 Growth Initiatives를 실행하는 역할을 담당합니다. 전 세계 고객에게 가장 적합한 요금제 플랜과 인센티브로 Netflix에 가입 할 수 있도록 하는 시스템과 프로토콜을 설계하고 구축하는 것이 Growth 엔지니어링 팀의 역할입니다.
사용자 가입 경로
Netflix의 가입 경로는 3단계가 있습니다. Netflix에서는 “Signup Flow”라고 부릅니다.
1. 소개 및 계정 생성
Netflix의 가치를 소개하고, 고객이 가입을 할 수 있도록 유도합니다.
2. Plans & offers
다양한 유형의 Netflix 요금제를 offering 합니다.
3. Payment
고객이 자신의 요구에 가장 잘 맞는 것을 선택할 수 있도록 다양한 결제 옵션을 제공합니다.
서비스 소개 및 계정 생성 부분은 어느 서비스나 비슷하기에 2,3번에 대해 Netflix가 시장에 어떻게 대응하고 있는지 설명을 하려 합니다.
Plans & offers
Definitions
Netflix에서 Plan과 Offer가 무엇인지 정의 해 보겠습니다. Plan은 기본적으로 가격이 있는 기능 세트입니다.
Offer는 제한된 시간 동안 요금 할인 또는 우수한 기능을 포함하는 Incentive입니다. 일반적으로 Offer는 하나 이상의 Incentive와 속성 세트로 구성됩니다.
제안은 일반적으로 제한된 시간 동안 금전적 할인 또는 우수한 제품 기능을 포함하는 인센티브입니다. 일반적으로 오퍼는 하나 이상의 인센티브와 속성 세트로 구성됩니다.
Plan과 Offer를 병합하여 고객에게 제시하면 Plan 선택 페이지에 표시됩니다. 여기서는 선택한 Plan에 관계없이 3개의 Plan과 30일 무료 평가판이 있음을 확인할 수 있습니다.
지금까지 Netflix의 요금제 관련한 비즈니스적인 설명을 하였고, 이제 연관된 아키텍처, 프로토콜 및 시스템에 대해서 살펴 보도록 하겠습니다. 일반적으로 사람들은 비즈니스와 기술을 분리하는 경향이 있는데., 모든 기술은 비즈니스를 위해 고려되어야 하며, 이를 근간으로 아키텍처가 확립 됩니다.
Legacy 아키텍처
위에서 설명했듯이 Netflix는 스트리밍 서비스를 시작한 후 정적인 Plan과 Offer를 가지고 있었습니다. 따라서 아키텍처 또한 매우 간단했습니다. 기술적으로는 런타임에 로드되고 로컬 메모리에 저장된 작은 XML 파일 세트로 구성했습니다. 수년 동안에는 완벽하게 최적화된 디자인이었습니다. 그러나 Netflix가 계속 성장하고 서비스가 발전함에 따라 몇 가지 문제점이 생겼습니다.
- XML 파일 업데이트는 본질적으로 오류가 발생하기 쉽고 수동적이다.
- XML 파일이 업데이트 될 때마다 서비스 전체 배포가 필요하다.
- XML 파일을 업데이트하려면 이 파일을 소유한 Backend 엔지니어팀의 참여가 필요하다. 타 팀의 지원을 받아야 하기에 독립적으로 업무를 수행하기가 어렵다.
- UI를 렌더링하기 위한 클라이언트 로직이 필요하다. (아래는 30일 무료 평가판에 대한 데이터 구조입니다.)
{
“offerId”: 123,
“planId”: 111,
“price”: “$ 8.99”,
“hasSD”: true,
“hasHD”: false,
“hasFreeTrial”: true
…
}
- 전 세계 고객에게 서비스가 제공됨에 따라 위의 모든 문제가 더욱 악화된다.
다음은 Plan & Offer 데이터 검색과 관련된 다양한 시스템을 표현한 그림입니다.
새로운 아키텍처
Growth 엔지니어링팀은 거의 모든 플랫폼에 대해 가볍고 유연한 애플리케이션을 구축 할 수 있는 비즈니스 로직과 프로토콜을 담당하고 있습니다. 이는 Presentation Layer에 비즈니스 로직이 없어야 하며 전달되는 데이터를 렌더링하는 책임을 지니고 있음을 의미합니다. 이를 달성하기 위해 Netflix는 우려 사항 및 분리 설계 원칙을 강조하는 마이크로 서비스 아키텍처를 채택하고 설계했습니다. 아래는 Legacy 아키텍처에서 업데이트된 신규 아키텍처입니다.
위 아키텍처를 보면 두 가지 변경 사항이 있습니다.
첫째, SKU Domain Services입니다. 이 서비스에는 오케스트레이션 서비스의 일부였던 특수 비즈니스 로직이 포함되어 있습니다. 이 로직을 새로운 마이크로 서비스로 마이그레이션함으로써 오케스트레이션 서비스를 단순화하고, 도메인에 대한 소유권을 명확히합니다. 이렇게 함으로써 다른 서비스도 SKU 데이터를 사용할 수 있습니다.
둘째, SKU 서비스가 이제는 Rule Engine과 SKU Catalog DB를 활용하는 플랫폼으로 확장 되었습니다. 이 플랫폼은 Growth 엔지니어링팀이 코드 변경 겅의 없이 전 세계 고객을 위해 다양한 서비스 제공을 실험할 수 있기 때문에 엄청난 비즈니스 가치를 제공합니다. 이는 엔지니어가 지루한 작업을 수행하는데 소요되는 시간을 줄이고 미래의 요구에 잘 대응할 수 있는 조금더 창의적인 작업에 더 많은 시간을 할애 할 수 있음을 의미합니다.
1단계: 디바이스가 Plan 선택 페이지에 대한 요청을 보냅니다.
과거에는 클라이언트 UI와 중간 계층 오케스트레이션 서비스간에 사용자 지정 JSON 프로토콜을 사용했었습니다. Plan 선택 페이지를 검색하기 위한 브라우저 요청에 대한 프로토콜의 예는 아래와 같습니다.
GET /plans
{
“flow”: “browser”,
“mode”: “planSelection”
}
이 요청에는 두 가지 중요한 정보가 존재합니다.
- flow: flow는 플랫폼을 식별하는 정보입니다. 이를 통해 오케스트레이션 서비스는 해당 요청을 적절한 플랫폼에 라우팅 할 수 있습니다.
- mode: 요청되는 페이지의 이름입니다.
flow와 mode 정보에 의해 오케스트레이션 서비스가 요청을 처리하게 됩니다.
2단계: 요청 처리를 위해 오케스트레이션 서비스로 라우팅합니다.
오케스트레이션 서비스는 upstream 요청의 유효성을 검사하고, downstream 서비스에 대한 호출을 오케스트레이션하고, JSON 응답을 작성합니다. 특정 요청의 경우 오케스트레이션 서비스를 SKU Eligibility 서비스에서 SKU 데이터를 검색하고 UI 레이어에서 사용할 수 있는 JSON 응답을 빌드합니다.
해당 요청에 대한 JSON 응답은 아래와 같습니다. 아래의 응답은 재사용률을 높이고 30일 무료 평가판 이외의 제안을 잠재적으로 지원할 수 있도록 합니다.
{
“flow”: “browser”,
“mode”: “planSelection”,
“fields”: {
“skus”: [
{
“id”: 123,
“incentives”: [“FREE_TRIAL”],
“plan”: {
“name”: “Basic”,
“quality”: “SD”,
“price” : “$8.99”,
…
}
…
},
{
“id”: 456,
“incentives”: [“FREE_TRIAL”],
“plan”: {
“name”: “Standard”,
“quality”: “HD”,
“price” : “$13.99”,
…
}
…
},
{
“id”: 789,
“incentives”: [“FREE_TRIAL”],
“plan”: {
“name”: “Premium”,
“quality”: “UHD”,
“price” : “$17.99”,
…
}
…
}
],
“selectedSku”: {
“type”: “Numeric”,
“value”: 789
}
“nextAction”: {
“type”: “Action”
“withFields”: [
“selectedSku”
]
}
}
}
위의 응답에는 SKU 목록, 선택한 SKU 정보가 포함됩니다.
3단계 및 4단계: SKU Eligibility Service에서 적격성 결정 및 SKU 검색
Netflix는 글로벌 기업이기에 지역마다 다른 SKU가 존재합니다. 즉, SKU 가용성과 SKU 적격성을 구분해야 합니다. 가용성은 국가 수준에서 적용이되며 적격은 사용자 수준에서 적용이 됩니다. SKU 플랫폼에는 글로벌 SKU 세트가 포함되어 있기에 SKU의 가용성을 제어할 수 있습니다. 그리고 SKU 적격성은 SKU Eligibility Service에 의해 결정됩니다. 이렇게 구분함으로써 명확한 경계를 만들고 Growth 엔지니어링팀이 방문자를 위해 올바른 SKU를 표현하는데 집중 할 수 있습니다.
SKU Eligibility 서비스는 Netflix 서비스의 여러 부분에서 혁신을 가능하게 합니다. 이제 다양한 서비스가 SKU 데이터를 검색하기 위해 SKU Eligibility 서비스와 직접 통신을 할 수 있습니다.
5단계: SKU 플랫폼에서 적격 SKU 검색
SKU 플랫폼은 Rule Engine, 데이터베이스 및 애플리케이션 로직으로 구성됩니다. 데이터 베이스에는 Plan, Pricing 및 Offer가 포함되어 있습니다. Rule Engine은 규칙내 특정 조건이 일치 할 때 사용 가능한 Plan 및 Offer를 추출할 수 있도록 합니다. 미국에서 Offer를 검색하는 아래의 예제를 참고하세요.
SKU 플랫폼에는 이제 단 하나의 책임만 존재합니다. 즉, 모든 Netflix의 SKU를 관리합니다. 고객 컨텍스트를 가져와 SKU Rule 세트와 일치 시킵니다. SKU 자격은 Upstream으로 계산되며 SKU Rule 세트에 있는 다른 조건과 같은 방식으로 처리됩니다. 자격 및 가용성 개념을 단일 서비스에 결합하지 않음으로써 각 팀이 핵심 역량에 집중할 수 있고 자격 변경이 SKU 플랫폼에 영향을 미치지 않기에 개발자 생산성을 높일 수 있습니다. Netflix의 다음 단계는 SKU UI를 통해 셀프 서비스 및 Rule 변경에 대해 더 많이 지원하는 것입니다.
결론
SKU에 대한 아키텍처 변경 작업을 통해 Netflix는 모호했던 SKU 가용성 및 자격에 대한 경계를 명확하게 정의했습니다.
새 아키텍처가 기존 아키텍처에 비해 갖는 장점은 아래와 같습니다.
- 재사용 및 확장 가능한 “Shape”을 가진 도메인 객체 (이 형태는 서비스 계층 뿐만 아니라 UI 계층에서도 코드 재사용을 용이하게 합니다.)
- 최소한의 엔지니어링 개입으로 제품 혁신을 가능하게 하는 SKU 플랫폼 (이는 엔지니어가 다른 문제에 대해 더 도전적이고 창의적인 작업에 집중할 수 있음을 의미합니다.)
- SKU 데이터 업데이트를 위한 코드 변경 대신 구성을 통해 혁신 속도를 높입니다.
- 더 적은 서비스 호출로 인해 지연 시간이 줄어들어 방문자의 오류가 줄어 듭니다.
지금 이 세상은 끊임없이 변화하고 있고, 디바이스의 기능은 계속해서 향상되고 있습니다. 사람들이 즐거움을 원하는 방법, 시기, 장소는 계속해서 진화하고 있습니다. 이러한 유형에 대해 Netflix의 Growth 엔지니어링팀은 지속적으로 견고한 기반을 구축할 수 있도록 노력하고 있습니다.
Netflix가 SKU에 대해 이정도로 고민하는지 몰랐네요. 혁신적인 기업이라고 생각됩니다.^^/
“flow”: “browser”,
