9/17/2019

마이크로 서비스에서 분산 트랜잭션

분산 트랜잭션은 무엇인가?

아래는 트랜잭션을 사용한 Monolithic 커머스 시스템이다.

위의 경우는 체크 아웃 요청에 대해 데이터베이스에서 트랜잭션이 생성된다. 각 비즈니스 단계에 대해서 데이터베이스에서 보장한다. ACID(Atomicity, Consistency, Isolation, Durability)로 알려져 있다.

아래는 마이크로 서비스에서의 커머스 시스템이다.

모놀리틱은 데이터베이스에 의존하여 트랜잭션을 처리하지만, 마이크로 서비스의 경우 데이터베이스에 의존할 수가 없다. 그 이유는 각 서비스마다 별도의 데이터베이스를 가지고 있기 때문이다.

마이크로 서비스에서 트랜잭션에 대한 문제

마이크로 서비스 아키텍처가 나온 후, 데이터베이스의 ACID 특성을 사용할 수 가 없다. 특정 로직을 처리하기 위해서는 여러 마이크로 서비스(여러 데이터베이스)에 걸쳐 있게 된다.

Atomic 트랜잭션을 어떻게 유지 할 것인가?

Atomic 트랜잭션은 모든 단계 중에 하나를 완료하는 것을 의미한다. 완료 되지 않은 작업(Inventory Microservice)에 대해서는 어떻게 롤백을 해야 하는지 고민이 되는 부분이다.

동시 요청에 대한 처리

Order 서비스가 완료된 후 Inventory 서비스의 정보를 보여줘야 하는데, Order가 완료 된 후 Inventory에 업데이트를 해야 하는지? 이렇게 되면 개발하는 개발자는 본인이 개발해야 할 부분외에 많은 것을 고민해야 하는 상황에 직면하게 된다.

가능한 해결책들

Two-Phase Commit

처리 방법을 준비 단계와 커밋 단계를 가지고 처리하는 기법이다.
연관된 모든 마이크로서비스에서 커밋을 준비하고 트랜잭션을 처리할 준비가 되었다고 코디네이터에게 통지를 해야 한다.
커밋 또는 롤백을 코디네이터에 의해 모든 마이크로 서비스에 전달된다.

아래는 성공 시나리오이다.

Transaction Coordinator는 글로벌 트랜잭션을 시작한다.
Order 서비스를 호출하고 OK를 받으면 Invventory 서비스를 호출한다.
즉, 모든 트랜잭션에 대한 부분을 Transaction Coordinator가 관여하게 된다.

아래는 실패 시나리오이다.

트랜잭션이 엮여 있는 서비스중에 하나라도 실패가 발생하게 되면, Transaction Coordinator는 롤백 프로세스를 수행한다.

Two-Phase commit의 장점은 아래와 같다.

  • 동기 호출 방식이기에 프로세스가 꼬이지 않는다.
  • 트랜잭션을 보장한다.
단점은 아래와 같다.
  • 두 단계 커밋이기에 속도가 느리다.
  • Transaction Coordinator에 대한 의존성이 증가한다.
  • 교착 생태가 발생 할 수 있다.

SAGA pattern

각 마이크로 서비스는 데이터를 업데이트 할 때마다 이벤트를 개시한다. 다른 서비스는 이벤트를 구독하고, 이벤트가 수신되면 데이터를 업데이트 하는 방식이다.

각 마이크로 서비스는 이벤트 버스를 통해 상호 통신하게 된다.

아래는 성공 시나리오이다.

Choreographer에 의해 트랜잭션 이벤트를 생성하고 각 서비스에서는 이벤트를 수신하여 업무를 처리하는 방식이다.


아래는 실패 시나리오이다.

Inventory 서비스가 실패하게 되면, Choreographer에 실패 이벤트를 전달하고 Choreographer는 Order서비스에 삭제 이벤트를 생성한다.

이 방식의 장점은 아래와 같다.

  • 비동기 이벤트 기반이기에 시스템 부하 측면에서 유리하다.

이 방식의 단점은 아래와 같다.
  • 순서가 보장되지 않는다. (비동기 방식)
  • 마이크로 서비스가 많을 수록 디버깅 및 유지 보수가 어려워진다.

결론

가장 좋은 대안은 분산 트랜잭션을 없애는 것이다.
위의 대안이 불가하다면, 아래의 마틴파울러가 얘기한 내용을 고려해 볼 수 있다.
단일체로 시작하고 점차 마이크로서비스로 분리하는 것.

하나의 결과에 대해 두개 이상의 시스템에 데이터를 갱신할 필요가 있을 때, Two-Phase commit 보다는 SAGA pattern이 조금더 바람직한 방법이다.
그 이유는 Two-phase commit은 확장이 어렵기 때문이다.

References:

9/07/2019

마이크로 서비스를 사용하지 않는 경우

본 글은 찰스 페발의 블로그을 번역한 것이다.

굳이 마이크로 서비스가 필요하지 않는 상황에서도 “마법의 키워드”와 같이 마이크로 서비스를 꼭! 해야 한다는 상황에서 정말 그래야 하는지 고민해 볼 필요가 있다.

마이크로 서비스란?

마이크로 서비스에는 많은 정의가 있다. 일반적으로는 아래와 같이 요약된다.

  • 마이크로 서비스는 구성 요소 설계 및 배치 아키텍처에 적용 되는 패턴이다.
  • 서비스를 작게 유지하고 기능별로 그룹화 한다.
  • 관심사를 분리하여 구현한다.
  • 서로 자율적으로 분리되어 있어야 한다.
  • 독립적 배포 및 버전을 조정하여 확장할 수 있어야 한다.

마이크로 서비스 패턴의 일반적인 구현은 다음과 같다.

주요 문제는 적용 가능한 패턴의 폭이 상당히 넓다는 것이다. 그렇기 때문에 마이크로 서비스를 선택하는 것이 최상의 옵션이 아닐 수 있다는 관점을 보려 한다.

 

마이크로 서비스의 과제

마이크로 서비스를 구현하는 데에 있어서 절충점이 존재한다.

1. 마이크로 서비스는 올바르게 설계 하기가 어렵다.

2. 기술적 복잡성이 포함되어 있다.

몇 가지 고려 사항은 다음과 같다.

  • API 수가 증가한다.
  • Network bottleneck이 증가한다.
  • 여러 서비스간 트랜잭션 관리가 어렵다.
  • 분산 환경에서의 디버깅은 어렵다.

비즈니스 기능외에 기술적으로 고려해야 할 항목들이다.

3. 조직이 변경되어야 한다.

Conway의 법칙에 따라 Front/back end 개발자, 데이터 플랫폼 엔지니어, QA, 제품 관리자 및 운영팀이 단일팀으로 혼합되어 있다.

 

4. 프로세스와 관행의 변화가 필요하다.

마이크로 서비스 아키텍처의 성공 여부는 조직 및 프로세스에 따라 달라지며 이런 부분들을 기존 방식에서 변경하기란 어려운 요소입니다.

 

5. 모든 전문 분야에 팀의 스킬셋을 확장

분산 시스템, 코드 기반의 인프라, 다양한 유형의 데이터베이스, 단위 테스트, Front-end 구성, 프로덕션 릴리즈, 릴리즈 계획, 제품 테스트등을 팀내에서 이해하고 소화해야 한다.

 

마이크로 서비스에 심각하게 의문을 제기해야 할 때

1. 응용 프로그램이 너무 작은 경우

현재 시점에 만들어야 할 어플리케이션이 너무 작은 경우에는 ROI 임계 값에 접근할때 마이크로 서비스 전환을 고려 해야 한다.

2. 도메인이 불분명하거나 불확실한 경우

 

3. 조직은 변경할 수 없다.

Conway의 법칙은 서비스를 계층화 된 아키텍처로 구성하는 것이 합리적이라는 의미이다.

아래의 그림은 각 서비스 별로 혼합팀이 구성되어 있기에, 업무 협업에 큰 문제가 없어 보인다.

 

아래의 그림에서는 각 팀간 업무 우선순위가 다르기에 팀 간 종속성이 서로 충돌되거나 업무 지연이 발생할 것이다.

 

4. 마이크로 서비스의 개념 및 설계에 대한 경험과 이해가 부족한 경우

우리는 대부분 새로운 것을 배우는 것을 좋아하지만, 이런 상황은 실수에 대한 시간과 에너지가 필요하다.

 

5. 성숙되지 않은 스킬을 적용

일반적으로 사람들은 자신이 아는 것으로 대체하려는 습성이 있다. 자신이 알거나 가장 짧은 길을 가면서 복잡성을 피할 것이다.

성숙되지 않은 기술로 도배하면 각 구성요소간 연관된 부분, 복잡성을 이해하기도 어려울 것이다.

운영 및 디버깅의 복잡성으로 인해 효율성이 저하될 가능성도 있다. 

 

하고 싶은 말

구축하려는 서비스에 명확한 도메인이 있고, 각 영역별 혼합된 형태의 팀을 구성할 수 있고, 팀내의 구성원이 기술에 대해 자신감이 있거나 경험이 있을 경우에는 마이크로 서비스로 갈 수 있는 가능성이 높다고 생각한다.

그렇지 않은 경우에는 역효과를 낳을 수 있다는 점을 명심해야 한다. K8S와 같은 컨테이너 플랫폼은 마이크로 서비스 아키텍처 혹은 마이크로 서비스 아키텍처 없이도 사용이 가능하다.

마이크로 서비스는 복잡한 분산 시스템 환경에서는 확실히 적합한 옵션이다. 하지만, 이것이 유일한 것은 아니기에 앞서서 언급한 것들을 고려하여 합리적인 선택을 해야 한다.

9/06/2019

마이크로 서비스의 경계

마이크로 서비스를 사용하면 이점을 얻을 수 있지만, 경험에 비추어보면 몇 가지 문제가 있었다.
영향을 최소화 할 수 있도록 도출된 문제를 인식하는 것이 중요하기에 여기에 몇 가지 적는다.

문제 중 하나는 마이크로 서비스의 경계를 잡는 일이다. 이것은 가장 어려운 작업이다.

마이크로 서비스 범위 설정

각각의 마이크로 서비스가 단일 책임의 원칙을 수용하는 구조라면 이 글을 쓸일이 없었을 것이다.
커머스 플랫폼에서 결제를 담당하는 서비스를 생각해보자.
처음에는 두 가지의 지불 방법 (카드와 바우처)만 존재했고, 이 두가지 방법이 동일한 서비스에서 구현되었다고 가정한다. 여기에 계좌 이체, Paypal등 다른 결제 방식이 추가된다고 하면 어떻게 해야 하는가?
미래의 요구 사항을 미리 알면 설계 시 혹은 경계 설정시 보다 현명한 결정을 내리겠지만, 현실은 그렇지 않다. 따라서 현재의 정보를 바탕으로 결제를 담당하는 서비스를 단일로 하기로 결정 했다고 가정해보자.

요구 사항 변경

시간이 지나서 Paypal 및 Apple Pay로 결제를 하기 위한 새로운 요구사항이 생겼다. 기존 서비스에서 이런 새로운 결제 방식을 구현 하면 서비스가 커지게 되고 의도치 않게 "많은 책임"이 생기게 된다.

따라서 새로운 요구 사항은 결제 방식에 따라 다른 서비스로 결제할 수 있도록 책임을 분할하기로 결정을 하게 된다.

Paypal과 Apple Pay를 사용하는 결제는 별도의 서비스로 구현되지만 이미 결제를 구현한 기존 서비스는 어떻게 되는지 고민이 필요하다.

Paypal과 Apple Pay를 결제 방식에 따라 단일 책임을 정의했기에 기존 서비스는 위에서 결정된 접근 방식과 맞지 않게 된다.

결과적으로 기존 서비스를 새로운 서비스로 분할이 되어야 한다.

Monolithic 어플리케이션에서는 위의 예시가 비교적으로 간단한 코드 리팩토링에 해당되지만, 마이크로 서비스 아키텍처에서는 새로운 서비스를 옮겨져야 한다. (새로운 코드 저장소, 새로운 빌드 파이프라인, 환경 구성등등)

마이크로 서비스 이름 짓기

서비스의 범위가 변경되면 이름도 변경되어야 한다. 위의 예에서 원래 서비스의 이름이 “Payment"라고 가정하면, 결제 방식이 새롭게 정의되었기에 기존 이름은 더 이상 사용하기가 애매해진다.

“Paypal” 및 “Apple Pay”라는 서비스가 있는 공간에서 기존 이름인 “Payment”는 무엇을 의미하는지 고민을 하게 된다.

마이크로 서비스 경계에 대한 접근법

끊임없이 변화하는 환경에서 불가피하게 일부 서비스의 책임은 시간이 지남에 따라 재정의 될 필요가 있다. 마이크로 서비스의 크기에 대한 규칙으로 재정의 하긴 애매하다. 최적의 솔루션이 없다면 경험에 기반한 접근 방식이 최선의 방법일 수 있다.
  1. 서비스의 일부가 자주 변경되면 서비스를 두 가지로 나눌 수 있다는 신호
  2. 특정 테스트가 필요하거나 테스트 시간이 오래 걸리는 서비스는 다른 서비스를 방해하지 않도록 자체 서비스로 만드는 것이 좋다.
  3. 데이터 베이스 또는 Queue와 같은 외부 리소스에 접근하는 코드도 서비스에 캡슐화 해야 한다. 서비스를 시작한 다음 외부와 전혀 관련이 없는 일부 기능을 사용하기 위해 외부 리소스를 사용하여 로컬 환경을 구성하지 않아도 되기 때문이다.
하나의 사례를 보자.
Eurostar라는 회사는 25년 동안 런던과 다른 유럽간 열차 티겟을 판매해오는 회사이다. 약 3년전에 그들은 Monolithic을 마이크로 서비스 아키텍처로 변경하기 위해 “검색", “체크아웃"과 같은 새로운 서비스를 개발했다.

새로운 마이크로 서비스가 개발된 직 후, Eurostar는 기차표를 판매하는 비즈니스외에 여행사가 되고, 호텔 숙박 및 패키지 상품을 판매하기로 전략적으로 결정을 하게 된다. “호텔 검색", “호텔 체크아웃"등의 새로운 서비스가 만들어졌다.

기존 기차표를 판매하던 “검색", “체크아웃"등의 서비스의 이름이 적절하다고 생각되지는 않는다.

결국 비즈니스가 변하는 시기에 서비스를 다시 검토하고 리팩토링을 해야 할 시점이 오게 된다는 것을 인지해야 한다.

즉, 비즈니스가 변경되는 상황에서는 처음 수립한 마이크로 서비스의 경계가 적절하지 않기에, 상황 발생시 기존 서비스에 대해서도 리팩토링을 염두해야 한다는 것이다.

따라서, 마이크로 서비스 경계 설정시 그 당시의 정보를 기준으로 설정하고 이 후 비즈니스 상황이 변경되면 리팩토링에 대한 접근법을 지녀야 한다.

7/21/2019

마이크로 서비스에 대해서 생각해보기

마이크로 서비스는 지난 몇년 동안 매우 인기 있는 주제였다.

마이크로 서비스는 왜 그렇게 인기가 있을까?

아래는 가상 비디오 공유 플랫폼이 Monolithic 형태로 구현 된 후에 마이크로 서비스 형태로 구현되는 방식이다.
enter image description here
위의 시스템의 차이점은 하나의 큰 덩어리와 작은 단위라는 점이다.
독립 개발: 작고 독립적인 구성 요소는 그에 맞춰진 작고 독립적인 팀으로 구성할 수 있다.
독립 배포: 각 구성 요소는 독립적으로 확장 할 수 있다. 새로운 서비스가 출시 되면 모든 구성 요소를 배포하지 않고 해당 구성 요소만 배포가 가능하다.
재사용성: 구성 요소들은 작고 특정한 기능을 수행한다. 다른 서비스 또는 제품에 쉽게 적용할 가능성이 높다.

대단한 것 같은데, 왜 이전에는 사용하지 않았나?

컨테이너 기술의 인기가 폭발적으로 증가함에 따라 MSA는 기술적 관점에서 구현하기에 훨씬 실용적으로 되었다.
과거에는 컨테이너 기술의 인기가 높지 않았기에 그러지 않았을까?

마이크로 서비스의 문제점은 무엇인가?

마이크로 서비스가 너무 방대해지게 된다면 어떤 문제점들이 발생하는지 알아보자.

개발자의 복잡성 증가

일반적으로 개발자는 로컬 PC에서 개발을 진행하기에 Monolith 처럼 단일 프로그램을 실행하는 것 보다 훨씬 복잡해진다. Docker Compose를 이용하여 부분적으로 완화 될 순 있지만, 시스템을 구성하는 서비스가 증가할수록 개발자가 직면하게 될 문제는 늘어나게 된다.

운영자의 복잡성 증가

서비스를 유지 관리하는 팀의 경우 복잡성이 증가한다. Monolith의 방식처럼 몇 개의 실행중인 서비스를 관리하는 것 대비 수십, 수백 또는 수천 개의 실행중인 서비스를 관리해야 한다. 많은 서비스와 연동 경로로 인해 운영 복잡성이 증가하게 된다.

Devops 복잡성 증가

문제는 많은 조직이 여전히 분리된 개발 및 운영팀으로 운영되고 있다는 사실이다. 이런 조직은 마이크로 서비스 채택에 어려움을 겪을 가능성이 훨씬 높다는 것이다.
이런 단점을 극복하고자 Devops를 채택한 조직도 어렵긴 마찬가지다. 컨테이너 오케스트레이션 시스템 관점에서 진화하는 시스템을 이해하는 것은 매우 어렵다. 개발자와 운영자가 좋은 소프트웨어를 만드는 마음이 강하더라도 말이다.

전문 지식이 필요

전문가가 해당 프로젝트를 수행하면 그 결과는 훌륭할 것이다. 효과적인 자동화, 모니터링, Orchestration등을 통해 모든 것이 가능하다. 그러나 이런 도전은 기술이 아니다. 가장 중요한 점은 효과적으로 사용할 수 있는 사람들을 찾는 것이다.
이런 Skill set은 현재 시장에서 수요가 많기 때문에 찾기가 어려울 수 있다.

실제 시스템은 경계가 잘못 정의된 경우가 많다

마이크로 서비스의 이점을 설명하기 위해 사용한 많은 자료에는 독립 구성 요소에 대한 이야기가 많다. 하지만 대부분의 경우 구성 요소들은 단순히 독립적이지 않다.
경계가 잘 정의되어 있지 않으면, 이론적인 관점에서 서비스를 독립적으로 배포 할 수 있다고 해도 서비스간의 상호 종속성으로 인해 결국 서비스 집합을 하나의 그룹에 배포해야 하는 상황이 발생한다.
즉, 새 기능을 배포하려면 여러 서비스를 동시에 배포해야 하기 때문에 실제로는 독립적으로 배포할 수 있는 시스템은 거의 없다.

의사 소통의 복잡성

서로에 의존하는 대규모 서비스를 구축할때에는 많은 서비스간 의사 소통이 발생 할 수 있다. 그리고 이로 인해서 몇 가지 문제가 발생한다.
첫째, 네트워크 호출이 실패 할 것을 예상해야 한다. 즉, 하나의 서비스가 다른 서비스를 호출 할때 최소한 여러번은 재시도를 해야하는 것을 의미한다. 이제는 서비스가 잠재적으로 많은 서비스를 호출해야 하기에 복잡한 상황에 처하게 된다.
사용자가 비디오 공유 서비스에서 비디오를 업로드한다고 가정하자. 업로드 서비슬르 실행하고, 데이터를 Transcode 서비스에 전달하고, Subscription을 업데이트하고, 권장 사항을 업데이트해야 할 수 있다. 이 모든 호출에는 일종의 Orchestration이 필요하다.
해당 작업이 실패하면 다시 시도해야 한다.
위의 재시도 논리는 관리하기가 어려울 수 있다. 동기적으로 일을 시도하는 것은 종종 끝나지 않고 많은 실패 지점이 존재하기 때문이다. 이 경우에 보다 안정적인 솔루션은 비동기 통신을 사용하여 통신을 처리하는 것이다. 비동기 패턴은 본질적으로 시스템을 stateful 상태로 만든다. 분산 처리에서 Stateful 시스템을 만드는 것은 어렵다.

버전 관리는 어려울 수 있다.

노드 모듈, Java 모듈, C 라이브러리등 소프트웨어 시스템의 종속성 관리는 매우 어렵다. 독립 구성 요소간의 충돌 및 여러 문제를 처리하기가 매우 어렵다.

분산 트랜잭션

트랜잭션 무결성이 필요한 상황에서 마이크로 서비스는 매우 고통스러울 수 있다.
분산 상태는 매우 다루기가 어렵기에 이 문제를 해결하기 위해서는 마이크로 서비스 모델에서 구현하는데 드는 비용이 매우 클 수 있다.

네트워킹 악몽

마이크로 서비스를 사용할 때 일반적으로 많은 노드에 분산 된 많은 서비스가 존재하고 이는 일반적으로 훨씬 복잡한 네트워킹 배치가 될 것이라는 것을 의미한다. 서비스 간 로드 밸런싱, DNS가 더 많이 사용되는 것, 가상 네트워킹 계층 등이 네트워킹의 복잡성을 숨기기 위해 시도한다.

결론, 마이크로 서비스와 아키텍처를 혼동하지 말자

마이크로 서비스는 구성 요소의 또 다른 패턴 또는 구현일 뿐이며 그 이상은 아니다. 마이크로 서비스가 시스템에 존재한다고 해서 시스템의 아키텍처가 해결되었다는 것을 의미하지 않는다.
마이크로 서비스는 시스템 고유의 설계가 아니라 패키징 및 운영과 관련된 기술 프로세스와 관련이 있다. 구성 요소에 대한 적절한 경계는 시스템에서 가장 중요한 과제 중 하나이다.
Docker 컨테이너 여부 및 서비스 크기에 관계없이 항상 시스템을 함께 배치하는 방법에 대해 신중하게 생각해야 한다. 이에 대한 정답은 없으며 어려운 점을 해결하기 위한 많은 옵션은 존재한다.

7/04/2019

Microservice의 ROI를 측정을 위한 매개변수

enter image description here

마이크로서비스 개발을 위한 ROI를 알고자 하는 CIO/CTO가 상당히 많습니다. 그들 중 일부는 수익대비 비용으로 측정하려고 노력하고 있습니다.

이런 사항들은 CIO/CTO가 고민해야 할 관심사이고 비즈니스에 미치는 영향이 중요하고 변경된 개발 사항이 매출 증가로 이어져야 하기 때문입니다.

그러나 개발은 다른 고려 사항을 염두하고 시작해야 합니다.

고객 및 이해 관계자를 행복하게 만드는 것은 중요한 행동이며 더 좋은 비즈니스 결과로 이어지게 됩니다. MSA(Microservice Architecture)는 즉각적인 영향을 줍니다. 마이크로서비스 구현시 ROI를 측정하는 가장 좋은 방법은 아래의 매개 변수를 고려해야 합니다.
  1. 다국어 기술 환경 수용
  2. 신속한 애자일 환경 제공 — 최단 시간내에 가장 빨리 기능을 전달
  3. 빠르게 운영환경으로의 이동
  4. 응용 어플리케이션의 크기 조정 — Heavy한 어플리케이션은 많은 양의 자원을 사용합니다.
  5. 제품/기능/서비스가 복잡하거나 얽혀 있는 경우
  6. Resilience/Fault Tolerance가 중요한지
마이크로서비스 아키텍처의 특징은 민첩한 방식의 지속적인 Deploy입니다.제품/서비스가 고객에게 다가 갈수록 피드백을 빨리 받을 수 있기 때문입니다.

결국 기업은 올바른 피드백이 실행되기를 기다리고 있고, 이 피드백을 빨리 반영한 제품/서비스를 출시해야 하기 때문입니다.

짧고 긴밀한 피드백 주기는 모든 제품/서비스 회사에게 주는 선물입니다.

MSA는 이를 달성하는데 도움을 줍니다.

2/12/2019

Netflix 미디어 데이터베이스

Netflix의 목표는 전 세계 수백만 회원의 재생 시작 시간을 최소화하는 것이다. 이를 위해서 ISO BMFF의 Header 크기에 대한 통계량(최소값, 최대값, 중간값, 평균값등)을 수집해야 한다.
Netflix의 Transcoding Pipeline은 방대한 콘텐츠 카탈로그를 서비스하며 모든 콘텐츠에 대해 다양한 코덱+품질 조합을 생성한다.

과거에는 비트 스트림 헤더 정보를 클롤링하는 일회성 스크립트를 작성해야만 데이터를 분석할 수 있었고 이러한 접근 방식에는 확장성이 없었다.

본 글에서는 Netflix의 Media Data Base 시스템에 대해서 소개하고자 한다.

왜 미디어 전용 데이터 베이스가 필요한가?

의미있는 개인화 및 효율적인 스트리밍은 최종 사용자가 서비스를 정의하는 주요 요소이다.
이러한 경험을 제공하기 위해서는 복잡한 비즈니스 워크 플로우가 필요하다.

enter image description here

위 그림처럼 아트워크상의 이미지 및 타이틀은 사용자가 관련 영화를 찾는데 도움이 된다. Netflix에서는 콘텐츠를 처리하는 단계에서 디지털 상품 Asset을 합성하는데 도움이되는 시스템을 개발해야 하는 상황이 있었다.

예를 들어서 소스 비디오 Asset에서 자동으로 추출 된 의미 있는 원시적인 이미지 및 비디오 클립을 제공하는 부분이다. 이는 콘텐츠에서 매력적인 디지털 미디어 자산을 창출하는 출발점이 될 수 있다고 생각했다. 이런 기능을 제공하게되면 사용자가 관련 프로그램 및 영화를 찾는데 큰 도움이 될 수 있다.

enter image description here

위의 그림처럼 콘텐츠 추천 시스템은 최종 사용자의 취향에 맞게 개인화 된 항목을 보여준다. Netflix 카탈로그에 있는 콘텐츠의 작고 효과적인 기능 표현은 매우 중요하다. 이러한 표현은 미디어 파일(오디오, 텍스트, 비디오)과 메타 데이터(장르 태그, 개요)를 기반으로 학습하는 기계 학습 모델을 구축하여 얻을 수 있다.

마지막으로 Netflix에서 수집 된 콘텐츠의 품질에 대한 높은 기준을 유지하는 것이 최종 사용자의 경험을 위해서는 필수적이다. 아래의 이미지는 이런 사례중 하나를 보여준다.

아래의 이미지는 Western Classical 장르의 비디오 프레임에 해당되고 이 경우 카메라가 동영상에 표시되고 있다. 카메라의 존재를 감지하는 자동화 된 분석 시스템을 갖는 것은 매우 바람직하다.

enter image description here

다음 그림의 경우, 자막은 영상에서 표시한 텍스트 위에 놓여지면 읽기가 어려울 수 있다. 자막의 타이밍 및 위치에 대한 지식과 함께 영상내 텍스트 검출 알고리즘을 사용하여 이 문제를 자동으로 해결 할 수 있다.

enter image description here

위와같은 분석 중 많은 부분을 계산하기 위한 비용은 매우 비싸다. 서로 다른 유즈 케이스를 처리할때 동일한 계산을 반복하는것도 매우 비효율적이기 떄문에 미디어의 타임라인과 관련된 모든 분석을 위한 보편적인 저장소 역할을 할 수 있는 데이터 시스템이 필요했다. 즉, 미디어 데이터베이스가 필요하다.

미디어 데이터베이스의 특징

미디어 데이터베이스는 다양한 형식의 미디어에 대한 분석 데이터가 들어있다. 여기에는 오디오, 비디오, 이미지 및 텍스트가 포함된다. 미디어 타임라인에서 임의의 쿼리를 처리할 때 사용된다. 예를 들어서 오디오 트랙의 타임라인에서 음악이 포함된 부분에 대한 시간 간격 또는 텍스트가 포함된 비디오의 비디오 프레임 목록 또는 자막 파일의 시간 간격 집합이 그것이다. 다음과 같은 사항이 미디어 데이터베이스의 중요한 특징이다.
  1. 구조화 된 데이터와의 유사성: 스키마가 있는 데이터는 기계 기반 처리가 가능하기에 분석이 가능하다. Netflix의 경우 스키마를 통해 데이터 검색 및 마이닝 기회를 제공하는 데이터를 색인할 수 있다.
  2. 효율적인 미디어 타임라인 모델링: 비디오 프레임에서 이벤트 기반에 이르기까지 다양한 유형의 미디어 타임라인 데이터를 서비스하는 기능은 미디어 데이터베이스의 기본 특성이다.
  3. 시공간 쿼리 기능: 미디어 데이터베이스는 미디어 데이터의 공간적(e.g. 이미지의 일부) 특성외에 시간적(e.g. 오디오 트랙의 시간 간격) 특성을 기본적으로 지원하며 이러한 부분에서 꽤 괜찮은 쿼리 기능을 제공한다. 예를 들어서, 미디어 데이터베이스를 사용하면 비디오 프레임내의 연속 시퀀스에 비디오 프레임의 특정 공간 영역(e.g. 왼쪽 상단 모서리)에 텍스트가 포함되어 있는지 쉽게 확인 할 수 있다. 이러한 쿼리를 비디오에 있는 텍스트와 자막 사이의 충돌을 탐지 하는데 유용하다.
  4. 다중 소유: 잘 설계된 미디어 데이터베이스는 복수의 어플리케이션으로부터 복수의 분석 데이터를 지원하기 위한 플랫폼으로써 사용될 수 있다. 이 부분이 구조화되어 있으면 임의의 데이터를 저장할 수 있고 해당 데이터가 미디어 리소스의 특정 시간 간격에도 연관 될 수 있을 경우에는 효율적인 쿼리 기능에 활용 될 수 있다.
  5. 확장성: 확장 가능한 마이크로 서비스 기반 모델은 필수적이다. 시스템은 다양한 시나리오에서 가용성 및 일관선과 관련된 문제를 해결해야 한다.

Netflix 미디어 데이터베이스 소개

Netflix는 위에서 소개된 내용을 통해 미디어 타임라인의 시공간 쿼리에 대규모로 응답이 가능한 미디어 타임라인과 관련된 분석을 위한 NMDB를 만들었다. Netflix 카탈로고는 다양한 형식의 많은 미디어 자산으로 구성되고 정적 자산의 경우 이미지가 포함되며 재생 가능한 자산의 경우 오디오, 텍스트 및 비디오가 포함된다. 위에서 설명한 것처럼 수많은 비즈니스 어플리케이션이 이러한 자산과 관련된 정보를 얻을 수 있다. NMDB의 주요 목표는 어플리케이션에서 필요한 필수 데이터를 제공하는 것이다.

NMDB는 다양한 Netflix 미디어 처리 시스템의 백본을 형성하는 데이터 시스템인 것이다.

References

2/04/2019

Netflix OSS 및 Spring Boot

Netflix의 Backend 및 Mid-tier 어플리케이션의 대부분은 Java를 사용하여 구축되었고, Micro Service를 위해 필요한 Ribbon, Eureka, Hystrix등 클라우드 인프라 라이브러리 및 시스템을 구축했다.

2015년도에 Spring Cloud Netflix는 1.0 버전이 나왔고, Spring Boot를 사용하여 Netflix OSS 구성 요소를 결합하기 위한 커뮤니티 노력의 일환이었다. Netflix는 2018년 부터 Spring Cloud Netflix를 통한 커뮤니티의 산출물을 이용하여 Java 프레임워크로 Spring Boot로 전환하였다.
enter image description here
Netflix가 내부 구성 요소 구축에 많은 투자를 했음에도 불구하고 Spring Boot를 채택하는 이유는 무엇일까? 2010년 초에 Netflix는 클라우드 인프라 핵심 요구사항을 안정성, 확장성, 효율성 및 보안을 최우선으로 여겼다.

이에 대한 대안이 없기에 자체 솔루션을 제작하게 되었다. 2018년에는 그때와 상황이 달라졌다 Spring 제품은 Netflix의 고유한 소프트웨어를 도입하였고 이를 통해 진화하고 확장되었다. Spring은 데이터 엑세스(Spring Data), 보안 관리(Spring Security), 클라우드 공급자와의 통합 등., 편리한 경험들을 제공하고 있다.

Spring의 진화 방향과 기능은 Netflix의 방향과 일치한다고 한다. Spring은 문서화가 잘되어 있고, 오랫동안 지속되어왔고, Netflix의 핵심 원칙인 “highly aligned, loosely coupled” 원칙과 잘 부합된다고 한다.

Netflix의 Spring Boot 전환은 Netflix가 단독으로 수행하는 작업이 아니다. Pivotal과 함께 협력하고 있다고 한다. Netflix OSS와 Spring Boot는 Netflix 외부에서 시작되었고, 이제 Netflix 내부에서 채택하고 사용한다고 한다.

Netflix의 Spring Cloud 도입 후 커뮤니티에 더 많은 기여가 일어날 수 있길 희망한다.

References