[Stream Process as a Platform] Netflix의 실시간 스트림 처리 플랫폼 Keystone 소개

아래 포스트는 Keystone Real-time Streaming Processing Platform(medium)을 읽고 정리한 글입니다.

원글 글쓴이 : Zhenzhong Xu in Real-time Data Infrastructure team 

Keystone Stream Processing Platform은 넷플릭스의 Data-driven culture을 가능케한 Data backbone 이자 infrastructure의 필수적인 부분을 뜻한다. Netflix Keystone은 2015년 기준, 8,000,000tps의 데이터를 처리하고 있으며 약 1PB 양의 데이터를 처리하고 있다.

오늘날 Keystone Platform은 두가지의 핵심 서비스를 제공한다.

1) Data Pipeline

Routing service, Messaging service를 통해 Data의 producing, collecting, processing, aggregating 역할을 하며, microservice event를 실시간으로 전달해주기도 한다.

2) Stream Processing as a Service(SPaaS)

사용자들이 Stream processing application을 빌드하고 커스텀하게 운영할 수 있도록 제공한다. 또한 플랫폼에서 Data scale, operation, domain expertise를 제공하여 사용자들은 Application logic에 집중하도록 도와준다.

그림. 넷플릭스 키스톤 파이프라인

이제, 상기 그림과 같은 Keystone platform을 설계하기 위해 직면했던 도전과제(challenges)와 설계원칙(Design principle)을 살펴보자.

---

Challenges

Netflix Keystone과 같이 대규모 데이터 플랫폼을 운영하기 위해서는 많은 장애물이 발생하고 이를 극복해나가야 한다. Netflix에서 keystone을 운영하기 위한 도전과제를 아래와 같이 정의하였다.

1. Scale

넷플릭스 서비스는 약 190개국의 1억 3천만 구독자가 사용한다. 데이터 스트리밍 플랫폼은 하루에 1조번 이상의 event와 페타바이트(petabyte)단위의 데이터를 처리하게 된다. 그러므로 구독자가 늘어남에 따라 Keystone platform은 scale out되는 구조를 가져야 한다.

2. Diverse Use-cases

Keystone Routing Service : 이 서비스는 사용자의 요구에 따라 입수되는 이벤트를 라우팅하는 역할을 한다. 각 라우팅된 이벤트들은 병렬로 스트리밍 프로세싱 처리 된다. 사용자는 선택적으로 해당 이벤트들에 대해 filter 혹은 aggregation 가능하다. 입수된 데이터들은 batch/stream processing을 위해 storage에 저장된다.

Stream Processing as a Service: SPaaS 플랫폼은 2017년부터 넷플릭스에서 사용되었다. 아직 성숙되지 않은 플랫폼이지만 아래와 같이 몇가지 고려해야할 사항이 있다.(Job state, Job Complexity, Traffic pattern, Failure recovery 등)

3. Multi-tenancy

Keystone은 수천개의 스트리밍 작업을 지원하면서 데이터 전달, 분석을 수행하고 microservice architecture pattern을 돌아가게 한다. 이러한 스트리밍 작업의 다양한 특성에도 안정적으로 데이터플랫폼을 운영하려면, 사용자들에게 의미있는 서비스 수준을 보장하기 위해 infrastructure level에서 실행&운영의 격리가 필요하며, 공유 자원의 overhead를 최소화 해야한다.

4. Elasticity

보통 스트림의 트래픽 패턴은 고정적이지만, 예상치 못한 급격한 트래픽 변화에 따른 시스템 자동 조정 및 대응이 필요하다.

5. Cloud Native Resiliency

넷플릭스의 마이크로서비스들은 모두 cloud service에 올라가 있다. Cloud service로 인한 네트워크 장애, 인스턴스 장애, regional disaster failure등 모든 단계에서 장애를 모니터링 탐지 할 수 있는 시스템을 설계해야한다.

6. Operation overhead

Keystone은 수천개의 라우팅 작업과 스트리밍 애플리케이션을 서비스한다. 모든 스트림을 수동으로 관리하게 되면 플랫폼팀에 의존하게 되므로, 운영하는데 비용이 증가하게된다. 그러므로, 사용자는 스트리밍 서비스의 각 job에 대해 lifecycle을 명시해야하며, 인프라는 가능한한 자동화 해야한다.

7. Agility

넷플릭스는 변경사항에 대해 하루에도 여러번 신속하게 개발하고 배포 할 수 있기를 원한다. 또한 사용자도 또한 동일한 수준으로 서비스를 자신있게 사용 할 수 있도록 플랫폼을 제공해주고자 한다.

Platform Mindset & Design Principle

Netflix Keystone 플랫폼의 주요 목표 중 하나는 다른 팀이 비즈니스 로직에 집중할 수 있께 하여 실험, 구현 및 스트림 처리 작업을 쉽게 수행할 수 있도록 도와주는 것이다. 또한 실패에 대해 생각을 해야하며, user과 플랫폼의 관계, 그리고 스트리밍 프로세스를 운영함에 있어 resource(CPU, Network, Memory)에 대한 효율적인 운용방법에 대해 고민해야한다.

---

Netflix's Approach

앞서 언급한 문제점들과 설계원칙을 고려하여 Key stone을 설계하였고 각 세부 설계 내용은 아래와 같다.

1. Declarative Reconciliation

Declarative Reconciliation protocol(선언적 조화?)는 전체 아키텍쳐에서 사용된다. 'Source of Truth(진실의 근원)'는 AWS RDS를 사용하여 저장한다. 이것은 Keystone의 전체시스템의 Single source of truth이다. 만약 Kafka cluster가 ZK의 실패로 인해 날라간다면, 넷플릭스는 항상 'source of truth'을 기반으로 전체 클러스터를 재창조 할 수 있다.

글쓴이 : 아마도 넷플릭스 키스톤의 모든 플랫폼, 모든 job들에 대해 source로서 선언을 해서 사용한다는 뜻을 풀어 쓴것 같다. Infra 단위에서는 Infrastructure as a Code(IaaC)를 말한 것 같고, Data Job단위로는 각 data에 대한 정보를 특정 저장공간에 저장하여 cloud에 존재하느 모든 cluster가 실패하여 동작을 멈추더라도 재빨리 재시작 가능하다는 점을 말하고 싶은 것으로 보인다.

2. Deployment Orchestration

Netflix 자체 Continuous deployment tool인 스피나커를 활용하여 application을 배포한다. Streaming dataflow 엔진을 기반으로 한 스트리밍 & 배치 프로세싱 플랫폼인 Flink의 효율적인 운영에도 spinnaker을 사용한다.

3. Self-service Tooling

For routing jobs : 사용자들은 자신이 원하는 event에 대해 filtering을 걸거나 elasticsearch, hive 혹은 기타 real-time consuming downstream으로 sink되도록 설정 가능하다. UI를 통해 사용자는 간편하게 input output을 설정할 수 있다.

스크린샷. Keystone platform | 사용자가 직접 데이터 입수부터 저장까지 경로를 설정 할 수 있다.

For custome SPaaS jobs : 넷플릭스는 사용자들에게 flink template code를 generate하고 CI를 제공해주는 command line tool을 제공한다. 사용자가 code를 수정하게 되면, CI automation으로 자동적으로 docker image로 생성, 등록, configuration이 유연하게 진행된다.

스크린샷. Keystone self service | Spinnaker과 비슷하게 생긴 Flink code CI tool

4. Stream Processing Engines

넷플릭스는 현재 Apache Flink를 활용하고 Keystone 분석 사용 사례를위한 생태계를 구축하는 데 중점을두고 있다. 넷플릭스는 운영 use case를 위해 Mantis 스트림 처리 엔진을 통합하고 확장 할 계획을 가지고 있다.

5. Connectors, Managed Operators and Application Abstraction

넷플릭스는 Kafka, Elasticsearch, Hive 등의 관리되는 커넥터를 제공한다. 커넥터는 사용자가 여러 동작, 일괄처리, 직렬화 등을 커스터마이징 할 수 있으며, 이를 통해 processing DAG(Directed Acyclic Graph)를 쉽게 만들 수 있다. 

글쓴이 : 유향 비순환 그래프란 방향 순환이 없는 무한 유향 그래프를 뜻하는데, 데이터의 입수가 된 이후의 데이터 처리동작들을 뜻하는 것으로 보인다.

그림. Directed Acyclic Graph

6. Configuration & Immutable Deployment

소프트웨어 멀티 테넌시 구성의 관리는 쉽지 않다. 넷플릭스는 동적으로 구성할수 있도록 만듦으로서, 쉽게 관리하고자 하였다. 기본 관리는 모두 파일에 저장되며, 구성을 환경 변수로서 사용 가능하다. 이 모든것들이 UI로 제공된다.

스크린샷. Keystone self service | kafka의 option들에 대해 환경변수를 설정 할 수 있다.

7. Self-healing

분산시스템에서 Failure은 불가피하다. 넷플릭스는 언제든지 failure이 날 수 있다고 예상하고 시스템이 자동적으로 감지, 장애 복구할 수 있도록 설계하였다. 구조적으로도 Keystone 플랫폼의 구성요소가 장애가 나더라도 영향이 커지지 않도록 격리된 아키텍쳐로 설계하였다.

8. Backfill & Rewind

한번더 말하지만, 분산시스템에서 Failure은 불가피하다. 그렇기에 가끔 사용자들에게 processing중인 job들에 대해 backfill 혹은 rewind를 요구하기도 한다. Failure상황에서 사용자들이 코드를 다시 짜는 등 불필요한 작업을 막기 위해서 UI를 사용하여 플랫폼에서 job을 재시작 할 수 있도록 설계, 제공하고 있다. 다만, 이러한 배경에는 stateless한 job들에 대해서만 제공된다.

9. Monitoring & Alerting

모든 개별 스트리밍 작업에는 개인화 된 모니터링 및 경고 대시보드를 제공한다. 이를 통해 넷플릭스의 데이터 플랫폼, 데이터 인프라 팀, application을 개발하는 팀 모두 같이 문제를 진단하고 모니터랑이 가능하다.

스크린샷. 넷플릭스 데이터 플랫폼 모니터링 웹페이지

10. Reliability & Testing

플랫폼 및 기본 인프라 서비스가 새로운 기능과 개선사항을 사용자에게 제공하기 위해 변경사항을 신속하게 채택해야한 하는 부담은 구조적으로 Bottom-up으로 올라간다. 그리고 Application이 개발되고 사용에 배포됨에 따라 신뢰성에 대한 압박은 Top-down 방식으로 내려가게 된다. 이렇게 양방향으로 들어오는 압력에서 넷플릭스 데이터 플랫폼팀이 신뢰를 얻기 위해서는 전체 스택을 효율적으로 테스트 할 수 있어야 한다. 이에 따라, 넷플릭스의 데이터 플랫폼 팀은 스트림 처리 패러다임에서 unit test, integration test, canary test 등을 모든 사용자가 이용할 수 있고  쉽게 적용 가능하게 하도록 만들게 하고 있으며, 이러한 노력은 진전을 이루고 있다.

---

Now and Future

위에서 설명한것과 같이 넷플릭스의 Keystone 플랫폼은 지난 18개월동안 수조의 데이터를 처리할 수 있는 것을 증명하였다. 넷플릭스의 여러팀들이 streaming use case들을 만들었고, 상용으로 배포되었다. 또한 높은 수준의 플랫폼을 구축할 수 있다는 것을 보여줄 수 있었다. 그러나 아직 나아가야할일이 많이 남아있다. 아래는 미래의 넷플릭스 데이터팀이 고민해야할 문제들이다.

# Schema

# Service layer to enable more flexible platform interaction

# Provide streaming SQL and other higher level abstractions to unlock values for different audiences

# Analytics & Machine Learning use cases

# Microservices event sourcing architectural pattern

결론

이번 medium글을 읽으면서 머리속에 박혀있던 Data-driven기업이란 정의가 다시금 재정의 되게 되었다. 이전에는 단순히 고객들의 Data를 모아서 Data를 분석하여, 의미 있는 수치, 자료들을 찾아서 다시금 고객들에게 효과적인 서비스를 제공하는 것에 머물러 있었다. 하지만 이것은 1차원적인 생각에 지나지 않았다. 

이미 Netflix는 2012년부터 Data-driven culture을 수행하고 있었다. (House of Card의 성공 비결 기사, 2013년) 여기서 더 나아가 Netflix는 데이터 기반의 플랫폼을 확산시키고 application개발자들도 data-driven development를 할 수 있는 Platform인 Keystone platform을 운영하기까지 이르렀다. 플랫폼을 신규 개발하고 운영하는 것은 resource도 많이들고 도전하기에 어려운일임에 틀림없다. 그럼에도 불구하고 Netflix가 Keystone이라는 플랫폼을 개발 시도했던 이유는 바로 Data-driven culture에서 data를 모든 개발자가 효과적이고 간편하게 적용, 사용할 수 있게 하는 것이 Data기반 기업으로서 성장하는데 필수불가결하기 때문이지 않을까? 라는 생각이 든다.

End of Document.