← 홈으로 돌아가기

[번역] Data Gateway — 데이터 계층을 확장하고 보호하는 플랫폼

ressac•0 points•약 9시간 전•원본 링크 (netflixtechblog.medium.com)

Netflix Online Datastore 팀은 데이터 스토어 엔지니어들이 Netflix 애플리케이션 개발자들이 복잡한 분산 데이터베이스와 호환되지 않는 API 변경으로부터 보호받으면서 강력한 데이터 추상화를 제공할 수 있도록 하는 Data Gateway라고 부르는 플랫폼을 구축했습니다. 이 첫 번째 포스팅에서는 애플리케이션 개발자가 매일 온라인 데이터를 생성, 액세스 및 유지 관리할 때 사용하는 추상화 수준을 높이기 위해 이 플랫폼을 어떻게 활용하는지를 보여주는 시리즈의 첫 부분으로 플랫폼을 다룹니다.

동기

Netflix는 Apache Cassandra, EVCache(memcached), OpenSearch 등 데이터 계층에서 수많은 오픈소스(OSS) 기술과 데이터베이스를 채택하고 기여해왔습니다. 과거에는 Online Data Platform이 이러한 데이터스토어를 운영하고 클라이언트 라이브러리를 통해 OSS API를 제공했습니다. 예를 들어, Apache Cassandra 클러스터를 운영하며 Thrift 또는 Cassandra Query Language(CQL) 프로토콜 기반의 클라이언트 라이브러리를 개발자들에게 제공했습니다. 이 전략은 OSS 덕분에 적은 수의 엔지니어가 더 많은 사용자와 다양한 유형의 데이터베이스를 운영할 수 있도록 했습니다. 그러나 이로 인해 빠른 확장은 가능했지만 Netflix가 통제하지 않는 다양한 API에 애플리케이션이 결합되면서 장기적으로 상당한 유지보수 비용이 발생했습니다.

대부분의 데이터베이스는 API 표면이 넓고 가드레일이 부족하여 피해야 할 사용 반패턴들이 존재하며, 이는 이를 피하기 위해 고급 지식이 필요하고 문제점이 수년 동안 드러날 수 있습니다. 예를 들어, 개발자들은 하나의 행이나 필드에 너무 많은 데이터를 쓰지 않아야 하며, 그 한계는 각 데이터스토어마다 다릅니다. Netflix의 엔지니어링 조직이 성장하고 사용 사례가 증가하면서, 데이터베이스 오용을 완화하고 애플리케이션을 재설계하는 데 따른 부담이 커졌습니다. 이로 인해 대부분의 중요한 애플리케이션이 데이터베이스 서비스에 의존하게 됨에 따라 제품 장애 위험도 증가했습니다.

또한, 특정 사용 사례는 원하는 API, 확장성, 가용성 및 일관된 성능을 달성하기 위해 서로 다른 데이터베이스를 결합한 아키텍처가 필요합니다. 시간이 지남에 따라 Netflix 개발자들은 키-값 조회에 캐시를 추가하는 등 동일한 패턴을 반복 구현하는 모습을 보았습니다. 즉, “바퀴를 재발명”하고 있었습니다.

마지막으로, Netflix 애플리케이션이 OSS 데이터베이스를 사용할 수 있도록 Netflix의 표준 서비스 디스커버리, 원격 프로시저 호출 복원력 기술, 인증 및 권한 부여 시스템과 모든 OSS 데이터베이스를 통합해야 했습니다. 각 데이터베이스 및 데이터베이스별 프로토콜을 이 시스템들과 통합하는 것은 구현마다 달랐고, 각기 다른 전문가(예: Memcached 전문가, Cassandra 전문가 등)가 유지보수해야 했기 때문에 어려웠습니다.

Data Gateway 소개

Netflix의 Data Gateway는 이러한 문제를 해결하기 위해 구축된 플랫폼으로, Netflix가 안정적인 온라인 데이터 액세스 계층(DAL)을 쉽게 구축하고 관리할 수 있도록 합니다. Data Gateway는 gRPC와 HTTP 같은 표준 IPC 프로토콜을 사용하여 맞춤 API를 제공함으로써 데이터 액세스를 단순화하고 보안을 강화하며, 백엔드 분산 데이터베이스의 복잡성을 추상화하고 잘못된 사용 패턴으로부터 보호하는 동시에 보안, 신뢰성 및 확장성을 향상시킵니다.

구성 요소 개요

Data Gateway는 애플리케이션과 데이터베이스 사이에 위치하여 Netflix가 사용자 친화적이고 안전하며 신뢰할 수 있는 대규모 데이터 지속성 서비스를 제공할 수 있도록 합니다. 이 플랫폼은 다음과 같은 특징을 목표로 합니다:

  • 사용자 친화적: Netflix에서 일반적으로 사용되는 키-값 또는 시계열과 같은 사용 패턴에 맞춘 친숙한 gRPC 또는 HTTP API를 제공하는 데이터 액세스 계층을 호스팅합니다.
  • 안전: mTLS, 연결 관리, 인증 및 권한 부여를 성능이 우수한 서비스 메시로 위임하는 공통 솔루션을 제공합니다.
  • 신뢰성: OSS 데이터스토어의 API 표면을 안전하게 확장 가능한 하위 집합으로 축소하여 사용 반패턴을 방지하고 회로 차단, 백프레셔, 부하 분산과 같은 복원력 기술을 위한 간접 계층을 제공합니다.

Data Gateway 인스턴스

Data Gateway 데이터 플레인 인스턴스는 다음으로 구성됩니다:

  • EC2 인스턴스: Netflix 성능팀이 고성능과 저지연을 위해 조정한 표준 클라우드 컴퓨트 Linux 가상 머신.
  • Data Gateway Agent: 목적에 맞게 제작된 컨테이너 이미지를 오케스트레이션하고, 건강 상태가 양호할 때 서비스 등록(예: 디스커버리)을 관리하는 사이드카 프로세스.
  • 컨테이너 런타임: 프록시와 DAL 컨테이너를 실행, 모니터링, 재시작 및 연결하는 표준 OCI 컨테이너 런타임.
  • Envoy Proxy: 리버스 프록시 역할을 하는 업계 표준 서비스 메시 컨테이너.
  • 데이터 추상화 계층(DAL): Key-Value와 같은 맞춤형 HTTP 또는 gRPC 데이터 액세스 서비스를 호스팅하는 컨테이너로 배포된 애플리케이션 코드.
  • 선언적 구성: 목표 클러스터와 데이터 플레인 인스턴스 상태를 제공하는 간결한 선언적 구성.

애플리케이션 클라이언트는 Netflix의 표준 디스커버리 서비스 또는 AWS 로드 밸런서(예: ALB/NLB)를 통해 이러한 게이트웨이에 연결합니다. Envoy는 TLS를 종료하고, 모든 연결을 인증한 후, 각 요청을 데이터베이스 특정 프로토콜로 쿼리를 완료하기 위해 통신하는 해당 DAL 컨테이너로 전달합니다.

구성 및 선언적 배포

선언적 구성은 Data Gateway Agent를 통해 인스턴스에서 배포를 구동하며, 전체 플릿에 걸쳐 적용됩니다. 선언적 구성은 런타임과 배포의 두 가지 범주로 구분됩니다.

런타임 구성

단일 인스턴스의 목표 상태 구성을 “런타임” 구성이라고 합니다. 이 구성은 데이터 추상화 컨테이너의 원하는 구성, 해당 환경 및 프록시와의 네트워킹을 포함하여 데이터 플레인 인스턴스를 형성합니다. 아래는 샘플 런타임 구성입니다:

# 프로토콜을 수용하기 위한 프록시 구성
proxy_config:
  public_listeners:
    secure_grpc: {mode: grpc, tls_creds: metatron, authz: gandalf, path: 8980}

# 프로토콜을 구현하는 DAL 컨테이너 구성
container_dals:
  cql:
    container_listeners: {secure_grpc: 8980}
    image: "dgw-kv"
  thrift:
    container_listeners: {secure_grpc: 8980}
    image: "dgw-kv"
    env:
      STORAGE_ENGINE: "thrift"

# 프로토콜의 고급 배선을 구성
wiring:
  thrift: {mode: shadow, target: cql}

이 구성은 배포 특정 버전의 dgw-kv 이미지를 사용하여 생성되는 cql 및 thrift라는 두 개의 키-값 DAL 컨테이너와, 외부에서 상호 TLS(mTLS via metatron) 연결을 위해 호스트 포트 8980에서 수신 대기하는 프록시를 지정합니다. 이 프로토콜은 secure_grpc로 명명되며, 이러한 연결은 상호 TLS로 인증되고 Netflix의 Gandalf 권한 부여 시스템을 사용하여 권한이 부여되며, 내부에서 secure_grpc 포트 8980에서 수신 대기 중인 DAL 프로세스로 각 요청이 전달됩니다. 마지막으로 wiring 섹션은 thrift 호출을 cql 컨테이너로 그림자 모드(shadow)로 전달하도록 지정합니다. 아래 다이어그램으로 시각화됩니다.

배포 구성 (Desires)

런타임 구성은 단일 인스턴스에 국한되지만, 이러한 인스턴스들의 원하는 배포를 구성해야 합니다. 배포 구성은 Data Gateway 배포의 속성을 선언적으로 설명합니다. 아래는 샘플 배포 구성입니다:

deploy_desires:
  # 접근 패턴과 용량
  capacity:
    model_name: org.netflix.key-value
    query_pattern:
      access_pattern: latency
      estimated_read_per_second:  {low: 2000, mid: 20000, high: 200000}
      estimated_write_per_second: {low: 2000, mid: 20000, high: 200000}
    data_shape:
      estimated_state_size_gib:   {low:   20, mid: 200,   high: 2000}
      reserved_instance_app_mem_gib: 20
  # 이 배포가 Netflix에 얼마나 중요한지
  service_tier: 0
  # 배포할 소프트웨어 버전 세트
  version_set:
      artifacts:
        dals/dgw-kv:  {kind: branch, value: main}
        # 런타임 구성도 컨테이너입니다!
        configs/main: {kind: branch, sha: ${DGW_CONFIG_VERSION}}
  # 여러 클러스터를 포함한 배포 위치
  locations:
    - account: prod
      regions: [us-east-2, us-east-1, eu-west-1, us-west-2]
    - account: prod
      regions: [us-east-1]
      stack: leader
  # 이 배포를 소유(책임지는)하는 사람
  owners:
    - {type: google-group, value: our-cool-team@netflix.com}
    - {type: pager, value: our-cool-pagerduty-service}
  # 이 배포를 소비(사용)하는 사람과 그 역할
  consumers:
    - {type: account-app, value: prod-api, group: read-write}
    - {type: account-app, value: studio_prod-ui, group: read-only}

이 구성은 용량, 서비스 중요도, 이미지 및 런타임 구성 버전, 배포 위치(지역 및 계정) 및 접근 제어와 같은 높은 수준의 요구 사항을 명시합니다. Service tier는 0에서 3 이상의 숫자로 제공되며, 이는 중요도를 나타내며 플릿 관리, 용량 계획 및 경고에 영향을 줍니다.

우리는 배포 구성을 사용하여 자동 용량 계획 도구의 입력으로 RPS(초당 요청 수)와 데이터 크기 등의 높은 수준의 용량 요구 사항을 활용하여 각 샤드에 대해 하드웨어와 소프트웨어를 프로비저닝합니다. 또한 배포 구성은 플릿의 지속적 배포에 정보를 제공하며, 덜 중요한 계층부터 순차적으로 롤아웃하고, 아티팩트 고정 및 기타 주요 기능을 가능하게 합니다.

우리는 데이터베이스의 오용과 관련하여 상태 기반 서비스를 위해 결함 격리 경계를 제공하기 때문에, 이러한 클러스터 그룹을 “샤드”라고 부릅니다. 샤드된 배포 또는 단일 테넌트 아키텍처는 잘못 동작하는 애플리케이션의 영향을 최소화하고, 전체 Netflix 제품을 방해하는 문제를 예방하기 위해 Netflix에서 선호됩니다. 2024년에는 Data Gateway 플랫폼이 수십 가지의 다양한 데이터 추상화를 위해 수천 개의 샤드를 선언적으로 관리하고 있습니다.

Data Gateway Agent: 목적에 맞게 제작된 컴포넌트 오케스트레이션

각 데이터 게이트웨이의 핵심에는 Netflix EC2 VM에 배포되는 에이전트가 있습니다. 이 에이전트는 간결한 구성 파일로 부트스트랩되어 필요한 컨테이너를 관리하고, 프록시를 연결하여 최종적으로 사용자에게 데이터 추상화의 구성을 노출합니다.

docker-compose에 익숙하다면, 데이터 게이트웨이는 철학적으로 유사하지만, 최고 수준의 메시 프록시와 목표 구성 상태를 향해 지속적으로 인스턴스를 구동시키는 에이전트가 통합된 형태입니다. 우리는 다음과 같은 컴포넌트를 통합하여 게이트웨이를 제공합니다:

  • 신뢰할 수 있는 시스템 컴포넌트: EC2 VM, containerd, Data Gateway Agent, 효율적으로 압축된 소프트웨어 이미지
  • 프로세스 간 통신: 플러그형 서비스 레지스트리 등록, mTLS, 인증, 권한 부여, 연결 관리 및 내부/외부 인스턴스 네트워킹
  • 모니터링: 전체 시스템 상태 검사, 자동으로 실패한 컨테이너 복구
  • 구성 및 소프트웨어: 환경 기반 구성과 함께 소프트웨어 및 구성의 버전 세트

“왜 Kubernetes를 사용하지 않느냐”고 물을 수 있습니다. Kubernetes의 Pod와 Istio가 더 일반적인 컴퓨팅 플랫폼임은 맞지만, 이는 우리의 상대적으로 단순한 문제를 해결하기 위해 너무 복잡한 솔루션입니다. Netflix에서는 Compute Platform 팀이 잘 마련된 단일 테넌트 EC2 인스턴스 배포를 가지고 있으며, 성능 격리와 도구 지원이 이 방식에서 우수합니다. 만약 우리가 이 경로에서 벗어난다면, 우리 팀은 Kubernetes와 Istio 모두를 운영해야 했을 것입니다. 우리는 복잡한 다중 테넌트 스케줄러와 컨테이너 솔루션을 채택하고 유지보수할 의향이 전혀 없었습니다.

간단히 말해, Kubernetes는 Pod와 독립적으로 컨테이너를 시작 및 중지할 수 없고, 더 복잡하며, 우리의 백본 데이터 계층에서 원치 않는 여러 종속성을 초래하기 때문에 실제 문제들을 해결하지 못합니다. Data Gateway 플랫폼은 외부 의존성이 정확히 세 가지로 설계되었습니다: Linux VM(EC2), 강력한 스케줄러(ASG), 그리고 블롭 스토리지 시스템(S3). 이러한 표면적 축소는 모든 Netflix를 위한 기초 데이터 액세스 계층을 배포하는 백본 인프라 컴포넌트에 매우 매력적이며, 소수의 팀이 유지보수할 수 있습니다.

사례 연구: 키-값 서비스

Netflix에서는 Data Gateway 플랫폼에서 DAL로 키-값 서비스(KV)를 배포합니다. 키-값 서비스는 HashMap[String, SortedMap[Bytes, Bytes]] 형태의 맵-오브-맵 데이터 모델과 쿼리 API를 기반으로 네임스페이스별 일관성과 내구성 제어 기능을 제공하며, 데이터스토어의 복잡성을 추상화합니다. 키-값 서비스는 수백 개의 Netflix 팀이 미션 크리티컬한, 완전 활성화된 글로벌 애플리케이션의 온라인 데이터 지속성을 제공하기 위해 사용합니다.

키-값 서비스 Data Gateway

키-값 DAL은 Java Spring Boot 애플리케이션으로 실행되며, 키-값 API를 위한 gRPC와 HTTP 인터페이스를 노출합니다. 이 애플리케이션은 다양한 스토리지 엔진을 조합하고, 헤징, 레이캐싱, 투명한 대용량 데이터 청킹, 적응형 페이지네이션, 자원 제한기를 통한 회로 차단 등 다양한 기능을 구현합니다.

키-값 DAL 이미지는 JIB를 사용하여 빌드됩니다. Netflix의 표준 애플리케이션 프레임워크는 Spring Boot이지만, Data Gateway 플랫폼은 애플리케이션 프로그래밍 언어나 게스트 OS와 관계없이 모든 OCI 준수 이미지를 지원합니다. DAL 이미지는 CI(지속적 통합) 중에 S3 아티팩트 스토어에 안전하게 업로드되며, 공급망 변조를 감지하기 위해 체크섬 검사를 수행합니다.

키-값은 런타임 구성을 사용하여 환경별 구성을 구현합니다. 예를 들어:

proxy_config:
  public_listeners:
    secure_grpc: {authz: gandalf, mode: grpc, path: "8980", tls_creds: metatron}
    secure_http: {authz: gandalf, mode: http, path: "8443", tls_creds: metatron}

container_dals:
  kv:
    # 플러그형 시작 명령어
    container_cmd: /apps/dgw-kv/start.sh
    container_listeners: {http: "8080", secure_grpc: "8980", secure_http: "8443"}
    # 힙 및 기타 속성 구성
    env:
      MEMORY: 8000m
      spring.app.property: property_value
    # 시작 검사에서 "건강함"을 정의
    healthcheck:
      test:
        - CMD-SHELL
        - /usr/bin/curl -f -s --connect-timeout 0.500 --max-time 2 http://envoy:8080/admin/health
    image: "dgw-kv"

# Netflix 디스커버리 대상 구성
registrations:
  - address: shard.dgwkvgrpc,shard.dgwkv
    mode: nflx-discovery

에이전트는 container_dals.kv 객체에 의해 구성된 kv라는 컨테이너를 실행하며, 여기에는 이미지 이름, 환경 변수, 컨테이너 건강 검사 명령 및 노출할 컨테이너 포트가 포함됩니다.

에이전트는 public_listeners의 각 항목에 대해 Envoy 호스트 리스너를 구성하며, 모든 주소(0.0.0.0 IPv4 또는 :: IPv6)에 바인딩합니다. 이 리스너들은 이름으로 컨테이너 리스너에 전달되며, 예를 들어 secure_grpc는 호스트 포트 ::8980에서 DAL 컨테이너 포트 8980으로의 라우팅을 지정합니다. 에이전트는 호스트 포트 충돌이 없도록 보장합니다. 마지막으로 에이전트는 registrations 구성을 사용하여 서비스 디스커버리에 등록할 Data Gateway 샤드를 결정합니다.

컨테이너 수준의 런타임 구성은 리스닝 포트나 건강 체크 엔드포인트와 같은 애플리케이션 세부 사항에 구애받지 않으며, 다양한 Data Gateway 애플리케이션과 호환되어 빠르게 변화하는 구성을 애플리케이션 코드베이스와 분리함으로써 비용 효율적인 롤아웃을 가능하게 합니다.

사례 연구: Secure RDS

Secure RDS는 Data Gateway 플랫폼을 사용하여 PostgreSQL과 MySQL에 대한 L4 연결을 보호하는 간단한 패스스루 아키텍처를 구현합니다. 이 아키텍처는 Envoy 프로세스에서 mTLS 연결을 종료하고, 이후 백엔드 AWS RDS 클러스터로 기본 L4 스트림을 프록시합니다. 이를 통해 클라이언트는 Netflix의 표준 mTLS 인증 및 권한 부여 시스템을 통해 보안 접근을 하고, 백엔드에서는 AWS 서버 TLS를 사용하여 연결을 종료합니다.

클라이언트는 Data Gateway를 디스커버리하고 클라이언트 호스트 포트 localhost:5432(PostgreSQL)에서 수신 대기하는 포워드 프록시 사이드카 프로세스를 설치합니다. 클라이언트가 JDBC와 같은 표준 RDBMS 클라이언트를 사용하여 포워드 프록시에 연결하면, 포워드 프록시는 클라이언트 애플리케이션의 metatron TLS 인증서를 사용하여 Data Gateway 포트 5432로 mTLS 연결을 시작합니다. Data Gateway 서버에서는 해당 연결이 클라이언트의 신원에 대해 권한 부여되며, 허용되면 클라이언트 애플리케이션은 아웃고잉 프록시를 통해 L4 mTLS 터널을 연결하여 Data Gateway를 거치고, mTLS를 해제한 후 RDS로 연결하여 표준 서버 측 TLS로 연결을 종료합니다.

이 아키텍처를 통해 Netflix는 인증 및 권한 부여의 표준 경로를 이용해 어떤 데이터베이스 프로토콜이든 원활하게 보안할 수 있었으며, AWS RDS, Open Search, CockroachDB, Neptune 등에서 사용되었습니다. 또한, 우리는 이 기법을 다른 상용 데이터베이스에도 적용하여 패치 없이 보안할 계획입니다. 데이터베이스 클러스터가 단일 테넌트인 경우, Netflix의 Metatron mTLS와 Gandalf 시스템이 각각 인증과 권한 부여를 담당하므로 사용자 이름/비밀번호 인증은 불필요해집니다. 기존 사용자 이름/비밀번호 인증 데이터베이스도 Netflix의 비밀 관리 시스템을 사용하여 자격 증명을 안전하게 암호화함으로써 이 플랫폼에 온보딩할 수 있습니다.

Secure RDS 런타임 구성은 컨테이너 DAL을 구성하지 않고, 대신 reverse proxy를 구성하여 network_dals.rds.listeners.secure_postgres 및 네트워크 DAL 대상을 통해 RDS 인스턴스로 라우팅합니다:

proxy_config:
  public_listeners:
    secure_postgres: {mode: tcp, path: "5432", tls_creds: metatron, authz: gandalf} 

# RDS 게이트웨이는 DAL 컨테이너를 실행하지 않음
container_dals: {}        

network_dals:
  rds:
    listeners:
      secure_postgres: postgresql://rds-db.ih34rtn3tflix.us-east-1.rds.amazonaws.com:5432
    mode: logical_dns

사례 연구: 원활한 데이터 마이그레이션

엔지니어들은 다양한 이유로 데이터스토어 간의 데이터 마이그레이션이 필요합니다. 현대 데이터스토어는 특정 사용 패턴과 데이터 모델에 맞춰 설계되므로, 사용 패턴이 바뀌면 데이터스토어 기술도 변화하게 됩니다. 보안 취약점, 사용 중단된 API, 구식 소프트웨어 또는 성능/기능 향상의 필요성 등 여러 요인 때문에 데이터 마이그레이션은 종종 필수적입니다. 데이터 마이그레이션은 시끄러운 이웃 문제를 완화하거나 새로운 기능을 제공하기 위해 수행되며, 제자리 업그레이드가 불가능할 때 시스템 무결성과 효율성을 유지하는 데 중요한 역할을 합니다. 이러한 과정을 개발자에게 원활하게 제공하기 위해, Data Gateway 플랫폼은 트래픽 쉐도잉(traffic shadowing) 계층을 제공하여 다른 스토리지 엔진 간의 데이터 복제와 성능 테스트 쿼리 부하를 관리할 수 있게 합니다. Data Gateway를 통해 우리는 전체 마이그레이션 수명 주기를 관리할 수 있습니다.

Data Gateway는 데이터 플레인 인스턴스에 두 개의 DAL 컨테이너를 배포하여 트래픽 쉐도잉을 지원합니다. 하나는 기존 데이터스토어에 연결되는 “주(primary)” 컨테이너이고, 다른 하나는 새로운 데이터스토어에 연결되는 “보조(secondary)” 컨테이너입니다. 리버스 프록시는 실제 트래픽을 주 컨테이너로 전달하고, 보조 컨테이너로는 그림자(duplicate) 트래픽을 전달하도록 구성합니다. 주에서 보조로 데이터 백필(backfill)을 완료한 후, 보조 컨테이너를 승격시켜 주 트래픽을 수신하게 함으로써 데이터 마이그레이션을 완료합니다. 아래는 thrift를 주 DAL로, cql을 보조 DAL로 사용하는 샘플 런타임 구성입니다:

proxy_config:
  public_listeners:
    secure_grpc: { mode: grpc, path: 8980 }

container_dals:
  cql:
    container_listeners:
      secure_grpc: 8980
  thrift:
    container_listeners:
      secure_grpc: 8980

wiring:
  thrift: { mode: shadow, target: cql }

우리는 이 플랫폼이 제공하는 데이터 마이그레이션 기능을 사용하여 수백 개의 더 이상 지원되지 않는 Apache Cassandra 2 데이터베이스를 새로운 주요 버전인 Cassandra 3으로 마이그레이션했습니다. Cassandra 3은 Thrift 스토리지 엔진과의 역호환성이 없었기 때문에 제자리 업그레이드가 안전하게 수행될 수 없었고, 수백 개의 애플리케이션과 Cassandra 클러스터를 마이그레이션해야 했습니다. 우리는 먼저 애플리케이션을 Cassandra에 직접 접근하는 방식에서 Data Gateway를 통한 키-값 서비스로 마이그레이션하고, 그 후 트래픽 쉐도잉과 백필을 통해 Cassandra 2에서 Cassandra 3으로 사용자 데이터를 이전하는 방법으로 이 마이그레이션을 수행했습니다.

데이터 마이그레이션을 동일한 인프라 컴포넌트를 사용해 중앙집중화한 것은 전문가로서 프로세스를 자동화할 수 있게 해 수천 시간의 엔지니어링 작업을 절감하고 데이터 손상 위험을 완화하는 데 크게 기여했습니다.

결론 및 향후 작업

Data Gateway는 Netflix가 온라인 데이터 계층에서 기술 혁신과 운영 우수성을 추구하는 의지를 보여줍니다. 이 플랫폼은 당면한 운영상의 문제를 해결할 뿐만 아니라, Netflix의 증가하는 SVOD 비즈니스와 광고, 게임, 라이브 스트리밍과 같은 신규 사업 라인에서 요구하는 비즈니스 확장을 충족하기 위해 향후 운영 데이터스토어의 발전 방향을 제시합니다.

후속 포스팅에서는 다음과 같이 개발자들을 위해 고수준 데이터 추상화를 빠르게 개발, 배포, 유지 관리하는 방법에 대해 자세히 공유할 예정입니다:

  • 임의의 L4/L7 데이터베이스 앞에 통합 인증 및 권한 부여
  • Cassandra, EVCache, Netflix에서 구축한 기타 맞춤형 스토어 등 변화하는 키-값 스토리지 엔진을 추상화하는 gRPC 키-값 서비스
  • 고속 데이터 수집, 보존 정책, 검색 및 검색 기능을 구현하기 위해 여러 스토리지 엔진을 조합한 gRPC 시계열 서비스
  • CockroachDB, 키-값, Kafka, Elasticsearch를 혼합한 유연한 CRUD+QE(쿼리 및 이벤트) 인터페이스를 제공하는 gRPC 엔터티 서비스

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인하기