Seminar

Netflix OSS 사내 세미나 내용 정리

Dev.BeryL 2022. 2. 8. 23:36
728x90

Netflix OSS

  • 등장 배경
    • 심각한 데이터베이스 손상으로 3일간의 DVD 배송 지연 문제 발생
    • 수직 확장되는 **단일 실패지점(Single fail of point)**에서 벗어나기를 희망
    • 이후 Netflix는 신뢰성 있고, 수평 확장이 가능한 클라우드 내 분산 시스템으로 전환하기로 함
    • 최고의 확장성과 다양한 서비를 제공하는 AWS 클라우드를 선택
    • 자체 개발한 Netflix Stack을 이용 2008년 8월부터 클라우드 마이그레이션을 시작
  • ‘7’년의 마이그레이션
    • 클라우드의 장점이 많은데도 불구하고 7년이 걸려서 마이그레이션이 최종 완료
    • 데이터 센터의 모든 시스템을 AWS로 가져다 놓는 것이 가장 쉬운 방법이지만 이러한 방법은 데이터 센터가 지닌 문제점과 한계점을 그대로 옮기는 것 밖에 되지 않음
    • 클라우드 네이티브 방식을 택하여 사실상 모든 기술을 재구축하고 운영 방식도 재구축함
    • 데이터 센터의 경우 서비스 중단이 잦았지만 지금은 서비스 가용성이 증가하여 서비스 가동시간 99.99% 목표 달성
  • Netflix OSS 공개 이유
    • 오픈 소스에 기여한 많은 사람들로부터 이익을 얻었기 때문에 그렇한 부분을 돌려 주고자. 오픈소스화로 기여하기로 함
    • 모든 스트리밍 서비스를 AWS 인프라 위에서 실행할 수 있는 초기 클라우드 어댑터였고 그로 인해서 많은 문제들과 한계에 직면하게 되었고, 그러한 부분의 해결책을 오픈소스 커뮤니티를 통해 얻고자 함
    • 여기서 플래폼 구성 요소 및 자동화 툴에 적용되는 패턴을 파악하였고 유사한 패턴을 채택하는 서비스 생태계 발전을 위해 공개
    • 대규모의 개발자 커뮤니티를 만들어 본인들의 컴포넌트에 대한 버그 수정, 리뷰, 테스트 케이스 추가와 같은 기여를 통해 모두에게 혜택을 제공 할 분만 아니라 여러 피드백을 통해서 해당 기능들을 향상 시킬 목적
    • ⇒ 결국 오픈소스커뮤니티 힘을 빌려 같이 해결하고, 좋은 건 나눠쓰자.

Monolithic to Microservice

  • Monolithic 구조에서 Microservice 구조로 바뀜
  • 사용자가 모든 서비스로 개별 접속 할수는 없음
  • Netflix 사례- 이하 다음

Netflix OSS 핵심 컴포넌트

 

Eureka 란?

  • AWS 클라우드에서 middle-tier 서버의 로드 밸런싱 및 fail-over를 위해 서비스를 찾는 데 사용 되는 REST 기반 서비스
  • Eureka Server와 Java 기반 클라이언트 구성 요소인 Eureka Client와 함께 제공
  • Microservice를 EUREKA에 등록하여 id 기반으로 endpoint 탐색이 가능하게 함
  • 클라이언트에는 기본 라우드 로빈 로드 밸런싱을 수행하는 로드 밸런서가 내장
  • Eureka를 감싸고 있는 정교한 로드 밸런서는 트래픽, 리소스 사용, 오류 조건 등과 같은 여러 요소를 기반으로 가중된 로드 밸런싱을 제하여 우수한 탄력성을 제공

Eureka의 필요성

  • 클라우드는 본질적인 특성 때문에 네트워크 위치(IP 주소 및 포트)가 동적으로 할당 되고 변경이 일어 날 수 있습니다. 즉 클라이언트가 호출 할 서비스 인스턴스 주소를 확실히 알 수가 없다는 것이 문제
  • 클라이언트는 사용 가능한 서비스 인스턴스의 네트워크 위치를 결정하고 클라이언트 로드 밸런싱을 담당하기 위해서 서비스 인스턴스의 정보를 가진 레지스트리가 필요

  • AWS 로드 밸런싱은 로드밸런서를 사용하여 서버 등록 및 등록 취소 작업을 훨씬 더 정교하게 수행해야 됨(IP와 Host Name 기반으로 작동하기 때문)
  • AWS ELB는 server-side-discovery-router이며 별도의 레지스트리가 없고 EC2인스턴스는 ELB자체에 등록 됩니다. 따라서 middle-tier 로드 밸런서를 위해서는 eureka가 필요

AWS ELB와의 차이

  • AWS ELB는 최종 사용자 웹 트래픽에 노출되는 Edge서비스를 위한 로드 밸런싱, Eureka는 중간 계층 로드 밸런싱의 필요성을 충족 시켜줌
  • 중간 계층 서비스를 AWS ELB 뒤에 둘 수 있지만, 이것을 외부에 노출 시키면 AWS Security Group의 기능이 손실 됨
  • AWS ELB는 전통적인 프록시 기반 로드 밸런싱이지만 Eureka의 로드 밸런싱은 instance, server, host 수준에서 일어남 (클라이언트 인스턴스는 접근이 필요한 서버에 대한 정보를 알고 있고 직접 연결이 가능함)
  • Eureka 로드밸런싱과 프록시 기반의 로드 밸런싱의 큰 차이점 중 하나는 서버에 관한 정보가 클라이언트에 캐시되므로 응용 프로그램이 로드 밸런스의 장애에 대해 복원력을 가질 수 있음 (메모리를 차지하지만 탄력성이 좋음)

 

Eureka서버와 Eureka 클라이언트의 통신

  • Eureka client를 내장한 Application Service와 Client가 Eureka Server에 등록을 요청하고 30초마다 갱신을 위한 하트 비트Eureka client를 내장한 Application Service와 Client가 Eureka Server에 등록을 요청하고 30초마다 갱신을 위한 하트 비트
  • 이러한 등록 정보와 갱신 정보는 클러스터의 모든 유레카 노드에 복제가 되고 클라이언트들은 레지스트리 정보를 찾아 해당 서비스를 찾고 원격 호출이 가능하게 됨

 

Zuul의 필요성

  • Netflix의 스트리밍 응용 프로그램은 서로 연결 되어서 복잡한 시스템을 구성하고 있었고 클라우드 내 분산 시스템으로 전환함에 있어서 다양한 장치 유형을 지원하고 다양한 요청을 받기 위한 진입점이 필요하게 되었습니다.
  • AWS region은 국제적인 확장을 지원하기 위해 새로운 국가에 배치되고 카탈로그가 추가 되는데 이러한 변화를 처리하기 위해서는 신속한 개발, 뛰어난 유연성, 복원력을 가능하게 하는 엣지 서비스가 필요
  • 2013년 기준 Netflix API는 1000개가 넘는 디바이스 유형을 지원하고 피크 시간에 초당 50000개 이상의 요청을 넘기는 Zuul(Edge Service)을 구축하고 있음

 

Zuul Filter 동작 방식

  • Pre 필터는 라우팅 직전에 인증, Origin Server 선택, 디버그, 정보 로깅등을 담당
  • Routing 필터는 요청은 Origin Server로 라우팅하는 것을 처리하고 이 단계에서 리본을 사용
  • Post 필터는 요청이 라우팅 된 이후에 실행
  • Error 필터는 다른 단계 중 하나에서 오류가 발생하면 실행

Zuul의 기능

  • API 트래픽의 양과 다양성으로 인해 경고 없이 문제가 발생할 수 가 있습니다.
  • Zuul은 다양한 유형의 필터를 사용하여 신속하게 edge service에 기능을 적용 할 수 있습니다.
  • 여러 필터를 이용해 아래와 같은 기능을 수행 할 수 있습니다.
  • 인증 및 보안 - 각 리소스에 대한 인증 요구사항을 식별하고 이를 만족시키지 않는 요청을 거부합니다.
  • 통찰력 및 모니터링 - 다른 Netflix OSS 구성요소를 함께 사용하여 의미 있는 데이터 및 통계를 추적하여 정확한 보기를 제공

Ribbon

  • Netflix는 클라우드 기반에서 정교한 서비스를 지향하는 아키텍처를 지향합니다. 현재 Netflix API 서비스와 같은 수백개의 정교한 서비스를 Edge 서비스를 통해서 지원하고 있습니다. 경량급 REST 기반 프로토콜은 이러한 서비스 프로세스 간 통신을 위한 선택입니다.
  • Ribbon은 소프트웨어 로드 밸런싱 알고리즘과 함께 Netflix Internal Web Service Framework (NIWS) 를 구성하는 몇가지 요소를 제공합니다. 유레카와 함께 사용되는 내부 클라이언트 로드 밸러서로서 주로 middle-tier 서비스에 대한 로드 밸런싱 요청에 사용되고 있습니다.

Ribbon의 역할

  • Netflix의 일반적인 배포 아키텍처는 가용성과 탄력성을 향상시키는 다중 지역, 다중 영역 배포입니다.
  • Ribbon 프레임워크는 middle-tier간 요청을 로드 밸런싱 처리하고 반면 Amazon ELB는 고객과 장치 요청에 대한 로드 밸런싱을 수행합니다.
  • Ribbon 클라이언트는 대상 서비스 각각에 대해 생성 되고 구성이 됩니다. Ribbon 클라이언트 구성 요소는 연결 시간 제한, 재시도, 재시도 알고리즘 등을 제공합니다.
  • Ribbon 내부에는 사용자가 정의 가능한 로드 밸런싱 구성 요소가 내장 되어 있습니다. 제공되는 로드밸런싱 전략 중 일부는 다음과 같습니다.
    • Simple Round Robin LB
    • Weighted Response Time LB
    • Zone Aware Round Robin LB
    • Random LB

Netflix의 대표적인 배포 아키텍쳐

 

Battle Tested Features

  • Ribbon의 주요 이점은 Amazon Cloud에서 운영하면서 얻은 경험을 기반으로 구축된 상호 작용 통신 메커니즘을 제공합니다.
  • Ribbon의 Zone Aware Round Robin 로드 밸런서는 회로 트릭 로직과 함께 구축되어 지역 선호도(Zone Affinity)에 따라 특정한 대상 서비스 인스턴스를 선호하도록 구성 될 수 있습니다.
  • 이러한 방식은 특정한 Zone이 갑작스럽게 운영 중단 되어도 탄력적으로 대응이 가능합니다.

Zone Aware Load Balancer (지역 선호 로드 밸런서)

  • 로드 밸런서는 사용 가능한 모든 구역의 통계를 계산하고 검사합니다.
  • 서버 별 활성 요청이 설정한 임계 값에 도달하면 Zone은 활성 서버 목록에서 삭제 됩니다.

(Average Active Requests = outstanding request / (instance수 - tripping instance))

  • 최악의 Zone이 삭제 되면 나머지 Zone 중에서 인스턴스의 수에 비례해서 Zone이 선택 됩니다.
  • 선택된 Zone에서 요청을 받을 서버는 Ribbon에 설정한 로드밸런싱 전략에 따라 반환 됩니다.

 

결함에 대한 내성(Fault Tolerance)

  • 결함에 대한 내성은 필요 사항입니다. 간헐적인 실패는 서비스가 아무리 뛰어난 가용성과 가동시간을 가지고 있더라도 매우 큰 변수가 될 수 있습니다.
  • 하나의 API 의존성이 대기 시간 증가와 함께 실패하게 된다면 사용 가능한 모든 요청 스레드를 포화시키고 API를 다운 시킬 수 있습니다.
  • 따라서 아키텍처에 결함에 대한 내성을 구축하고 인프라가 이를 해결 할 것이라는 기대감을 갖지 않는 것이 고가용성 어플리케이션의 요구 사항입니다.

 

Hystrix 란?

  • 서비스 간 액세스 지점을 격리하고 이를 통해 계단식 오류를 중지하며 대체 옵션(fall back)을 제공하여 전반적인 복원력을 향상 시키는 솔루션입니다.
  • third-party 라이브러리를 통해 접근 된 종속성으로부터 보호하고 장애를 제어합니다.
  • 실패를 빠르고 반복적으로 복원합니다.
  • 실시간으로 모니터링을 가능하게 합니다.

 

회로 차단기 (Circuit breaker)

  • 마이크로서비스 혹은 분산 아키텍처 상에는 수십가지의 종속성이 있고 원치 않게 어느 시점에서 실패할 가능성이 존재합니다. 이러한 오류로부터 격리되지 않으면 다른 응용프로그램 마저 종료 될 수 있습니다.
  • 99.99%의 가동성을 가진 30개의 서비스가 있을 경우 각각에 대해 0.01%의 중단 시간이 미치는 전체적인 영향은 전체 시스템에서 한달에 한시간 이상의 중단 시간을 초래 할 수 있습니다.
  • 아래의 그림처럼 대용량 트래픽이 발생하면 백엔으 종속성이 잠재 되어 있는 모든 서버에서 모든 리소스가 몇 초내에 포화 상태가 될 수 있습니다. 실패보다 더 심각 한 것은 이러한 응용 프로그램이 대기열, 스레드 및 서비스 간의 대기 시간을 증가 시켜 계단식 오류를 발생 시킬 수 있습니다.
  • 이러한 문제는 thrid-party 라이브러리를 사용 할 경우(특히 내부를 알 수 없고 언제든지 변경 할 수 있는 black box로 제공된 경우) 더욱 더 악화가 될 수 있습니다.
  • 따라서 아래 그림과 같이 실패가 일어날만한 지점(종속성이 있는 부분)에 회로 차단기를 설치합니다.

  • 회로 차단기는 쓰레드 pool, timeout, 로직적인 실패 등을 탐지하여 만약 실패가 발생한다면 빠르게 fallback을 수행합니다.

  • 의존성 호출을 별도의 스레드로 분리하면 얻을 수 있는 장점이 단점보다 크다고 판단이 되었고 최종적인 그림은 아래와 같이 별도의 스레드 풀을 통해 라우팅 되게 됩니다. 하위 시스템에 대한 최악의 고장 유형 중 하나인 의존성이 숨어버린 경우, 자체 스레드 풀의 모든 스레드를 포화 시킬 수 있지만 Tomcat 요청 스레드는 블로킹 되지 않고 단순히 시간이 초과되거나 거부 됩니다.
  • 별도의 스레드 오버헤드가 크기 때문에 메모리 내 캐시 검색만 수행과 같은 네트워크 호출을 수행하지 않을 경우 세마포어가 사용 됩니다. 또한 대체기능(fallback)에도 세마포어가 사용 됩니다.

 

Config Server

  • 서비스들의 config를 통합 관리할 수 있음
  • Config 변경 내용 무중단 반영 가능

Spring Cloud Netflix Sidecar 란?

  • Non-JVM 어플리케이션을 Spring Cloud(Zuul, Eureka, Spring Cloud Config ...)에 쉽게 편입 시키는 기능을 지원한다.
  • 사용하는 이유
    • service discovery : host:port/ 를 통하여 다른 방법에 비해 편하게 Non-JVM 어플리케이션에서 다른 Eureka 클라이언트를 찾을 수 있다.
    • monitoring : health check uri 설정을 통해 Eureka서버에서 Non-JVM 어플리케이션의 동작 여부를 알수 있다.
    • routing / proxying : Zuul을 통하여 Request를 받을 수 있다.
    • balancing : 내장된 Ribbon을 통해 Client side load balancing 기능을 지원 한다.
    • configuration : Spring Cloud Config를 통하여 configuration properties를 받을 수 있다.

Spring Cloud Netflix

  • Spring은 Netflix OSS를 Spring Boot 프로젝트와 쉽게 통합 할 수 있도록 Spring Cloud Netflix를 만들게 됨
  • Spring Cloud Netflix는 Spring Boot어플리케이션을 위한 Netflix OSS통합을 제공
  • 간단한 어노테이션을 사용하면 Netflix OSS에서 사용되는 모든 패턴을 신속하게 활성화 및 구성하여 확장 가능한 성능 분산 시스템을 구축 할 수 있게 됨
  • 제공 되는 서비스로는 Eureka, Hystrix, Zuul, Ribbon, Sidecar 등이 포함 됨

 

DEMO

Petclinic

반응형
저작자표시 비영리 변경금지

'Seminar' 카테고리의 다른 글

Azure Conference  (0) 2022.02.01
RPA 그랜드 웨비나 2021  (1) 2022.01.24

'Seminar'의 다른글

  • 현재글Netflix OSS 사내 세미나 내용 정리

관련글

티스토리툴바