MSA(마이크로 서비스 아키텍처)에서 단일 데이터베이스를 분리해야 하는 이유

기존 Monolithic 서비스를 분해하여 Micro Service 아키텍처를 사용할 경우 데이터베이스에 중점을 두는 것이 중요합니다. 어플리케이션과 연계된 데이터베이스를 여러개의 작은 데이터베이스로 분할하는 확실한 전략이 필요합니다.

즉, 기존에 사용하던 Monolithic의 통합 데이터베이스를 분리해야 합니다.

마이크로 서비스 아키텍처는 각 마이크로 서비스가 자체 도메인 데이터가 있는 별도의 데이터베이스를 가지도록 설계해야 합니다. 이렇게 해야 마이크로 서비스를 독립적으로 배포하거나 확장 할 수 있기 때문입니다.

기존 Monolithic 서비스에는 단일 데이터베이스가 있고 데이터는 다른 컴포넌트간에 공유됩니다. 데이터가 단일 저장소에 관리되기 때문에 개발이 더 간단하다는 장점이 있지만, 데이터베이스 설계에는 여러 가지 문제가 존재합니다.

단일 데이터베이스 설계의 문제점

위의 그림처럼 Monolithic 데이터베이스를 사용하는 설계는 서비스 변경 사항을 독립적으로 배포 할 수 없도록 상호간의 밀접한 결합 방식을 통해 무능력하게 만듭니다. 동일한 데이터베이스에 엑세스하는 여러 서비스가 있는 경우 모든 서비스간에 스키마 변경 사항을 조정해야 합니다.(어디서 어떤 데이터를 사용하는지 알 수 없기에…) 변경 사항을 적용 할 때 추가 작업에 대한 지연이 발생할 가능성이 큽니다.

단일 데이터베이스를 수평 확장 할 수 있는 옵션만 있기에 어플리케이션 단에서 개별 서비스를 확장하는 것이 어렵습니다.

어플리케이션 성능을 향상 시키고자 할때, 단일 데이터 베이스를 사용하면 여러 개의 큰 테이블을 조인하여 필요한 데이터를 가져와야 하기에 데이터 검색이 어려워집니다.

그리고 가장 큰 문제는 모든 어플리케이션에서 관계형 데이터베이스만 사용하도록 제한하게 됩니다. No-SQL 데이터베이스가 특정 서비스에 더 적합할 수 있어도 제한으로 인해 사용할 수 없게 됩니다.

마이크로서비스 아키텍처에서 데이터를 처리하는 방법

각 마이크로 서비스는 자체 데이터베이스를 가지고 있어야 하며 해당 마이크로 서비스와 관련된 데이터를 모두 포함해야 합니다. 이렇게 하면 각 서비스를 독립적으로 배포 할 수 있습니다. 각 서비스마다 독립적인 데이터베이스를 소유할 수 있게 됩니다.

마이크로 서비스의 설계 사상은 도메인 기반이어야 하며 한정된 컨텍스트를 가져야 합니다. 데이터 우선 접근 방식보다 코드 우선 접근 방식을 따라야 합니다. 따라서 가장 먼저 모델을 설계해야 합니다. 이 작업은 새로운 요구 사항이나 프로젝트를 시작할 때 데이터베이스 테이블을 먼저 설계하는 전통적인 사고 방식과는 근본적으로 다른 접근법입니다. 항상 비즈니스 모델의 무결성을 유지하려고 노력해야 합니다.

데이터베이스를 디자인할때 어플리케이션 기능을 살펴보고 관계형 스키마 필요 여부를 결정해야 합니다. No-SQL에 대한 가능성도 열어 두어야 합니다.

데이터베이스는 각 마이크로 서비스에 대해 개별적으로 취급되어야 합니다. 다른 마이크로 서비스는 다른 마이크로 서비스의 데이터베이스 내부에 저장된 데이터를 직접 수정할 수 없습니다.

아래의 그림에서 Order Service는 가격 데이터베이스를 직접 업데이트 할 수 없으며 해당 마이크로서비스의 API를 통해서만 엑세스가 가능해야 합니다. 이를 통해 서로 다른 서비스간에 일관성을 유지할 수 있습니다.

이벤트 중심 아키텍처는 서로 다른 서비스간에 데이터 일관성을 유지하는 패턴입니다. 작업을 완료하고 시스템 리소스를 차지하기 위해 ACID 트랜잭션을 기다리는 대신 메세지를 대기열로 Offload하여 어플리케이션을 보다 유용하고 효율적으로 만들 수 있도록 고려 해야 합니다. 이는 서비스 간의 Loosely Coupled를 제공합니다.

Queue에 대한 메시지를 이벤트로 처리 될 수 있으며 Pub-Sub 모델을 사용할 수 있습니다.

Monolithic에서 마이크로서비스로의 여정중 데이터베이스 변경 사항을 처리하는 것은 쉽지 않지만, 꼭! 넘어야 하는 부분입니다.

Source: https://dzone.com/articles/breaking-the-monolithic-database-in-your-microserv

Read More

Netflix OSS — Eureka 2.0

 

What is Eureka?

Eureka는 중간 계층 서버의 로드 균형 조정 및 장애 조치를 위한 REST기반 서비스이다. Eureka는 Java 기반 클라이언트 구성 요소인 Eureka Client가 함께 제공되므로 서비스와의 상호 작용이 훨씬 쉬워진다. 또한 클라이언트에는 기본 Round Robin 알고리즘 및 기본 제공 로드 밸런싱 알고리즘이 존재한다.

What is the need for Eureka?

AWS 클라우드에서는 IP 주소와 host name으로 작동하는 기존 로드 밸런서와 달리 서버 등록 및 등록 취소 작업을 정교하게 수행해야 하는 로드 밸런서가 필요하다. AWS는 미들 티어 로드 밸런서를 제공하지 않으므로 미드 티어 로드 밸런싱을 직접 구비할 필요가 있다.

How different is Eureka from AWS ELB?

AWS ELB는 최종 사용자의 웹 트래픽에 노출된 Edge Service용 로드 밸런싱 솔루션이다. Eureka는 미드 티어 로드 밸런싱용이다. 이론적으로 AWS ELB 뒤에 중간 계층 서비스를 배치 할 수 있지만 EC2 클래식에서는 AWS 보안 그룹의 모든 유용성을 잃어 버리고 외부 세계에 노출될 수 있는 문제점이 존재한다.

AWS ELB는 전통적인 Proxy 기반 로드 밸런서이기도 하지만 Eureka에서는 로드 밸런싱이 인스턴스/서버/호스트 수준에서 발생한다는 점이 차이점이다. 클라이언트 인스턴스는 연동할 모든 서버에 대한 정보를 알고 있어야 한다.

Eureka를 사용하여 로드 밸런싱과 Proxy기반의 로드 밸런싱을 차별화하는 또 다른 측면은 사용 가능한 서버에 대한 정보가 Client에 Cache되므로 어플리케이션이 로드밸런싱 장애에 대해 복원력을 가질 수 있다라는 점이다.

How different is Eureka from Route 53?

Route 53은 DNS 레코드를 호스팅 할 수 있는 DNS 서비스이다. Eureka는 내부 DNS와 유사하지만 전 세계 DNS서버와 관련이 없다. Eureka는 다른 AWS 지역의 서버에 대해 알지 못한다.(지역 분리) 정보를 보유하는 유일한 목적은 한 지역내의 로드 밸런싱을 위한 것이다.

미드 티어 서버를 Route 53에 등록하고 AWS 보안 그룹을 사용하여 공용 엑세스에서 서버를 보호 할 수 있지만 미드 티어 서버 ID는 여전히 외부 세계에 노출되어 있다. 또한 Traffic이 건강하지 않거나 존재하지 않는 서버로 라우팅 될 수 있는 전통적인 DNS 기반 로드 밸런싱은 단점이 존재한다. (서버가 언제든지 사라질 수 있는 클라우드의 경우)

How is Eureka used at Netflix?

Netflix에서 Eureka는 미드 티어 로드 밸런싱에서 중요한 부분을 차지하지만 다음과 같은 목적으로 사용된다.

• Netflix Asgard를 사용하는 red/black 배포의 경우 Eureka는 Asgard와 상호 작용하여 문제가 발생했을때 신속하고 원할하게 이전/신규 릴리즈 전환이 가능하다.
• 여러가지 이유로 서비스에 대한 추가 어플리케이션 관련 메타 데이터를 전달하는 용도로도 사용한다.

High level architecture

위의 아키텍처는 Eureka가 Netflix에서 어떻게 사용되는지를 보여 주는 일반적인 방법이다. 해당 지역의 인스턴스에 대해서만 알고 있는 Eureka Cluster가 하나 존재한다. 어플리케이션 서비스를 Eureka에 등록한 다음 30초마다 갱신하기 위해 Heartbeat를 보낸다. 클라이언트가 임대를 몇 번 갱신 할 수 없으면 약 90초내에 서버 레지스트리에서 제거된다. 등록 정보와 갱신은 클러스터의 모든 유레카 노드에 복제된다. 모든 영역의 클라이언트는 레지스트리 정보(30초마다 발생)를 찾아 해당 서비스를 찾고 원격 호출을 할 수 있다.

Non-Java services and clients

Java 기반이 아닌 서비스의 경우 서비스 언어로 Eureka의 클라이언트 부분을 구현 할 수 있고 등록을 처리하는 Eureka 클라이언트가 내장된 Java 프로그램을 실행 할 수 도 있다. Java가 아닌 클라이언트는 REST를 사용하여 다른 서비스에 대한 정보를 Query할 수 있다.

Configurability

Eureka를 사용하면 클러스터 노드를 즉시 추가하거나 제거 할 수 있다. 시간 제한 부터 Thread pool까지 내부 구성을 조정할 수 있다.

Monitoring

Eureka는 성능, 모니터링 및 경고를 위해 Servo를 사용하여 클라이언트와 서버 모두에서 정보를 추적한다. 데이터는 JMX 레지스트리에서 사용할 수 있으며 AWS Cloud Watch로 보낼 수 있다.

Architecture Overview

Eureka 2.0은 클라우드 구축을 위해 설계된 Service Discovery Framework이다.

아래 그림은 일반적인 Eureka 2.0의 주요 구성 요소를 나타낸다.

Write Register는 Client 등록을 처리하고 내부 서비스 Registry를 관리하고 유지하는 상태 저장 시스템이다. Registry의 내용은 모든 Write Server Node간에 일관성 있게 복제된다. Write Registry의 내용은 Eureka Client가 사용하는 Read Cluster에서 읽게된다.

Read Cluster는 Cache 계층이기 때문에 Traffic Volume에 따라 쉽게 빠르게 확장 및 축소될 수 있다. Write Cluster는 Peak time의 Traffic을 처리할 만큼 충분한 용량을 미리 산정해서 준비해야 한다.

Client Registration

Eureka Client는 Registration, Heartbeat 및 Update를 통해 Discovery 되도록 할 수 있다. Registration에는 검색 가능한 식별자 및 서비스 상태 그리고 자유로운 메타 데이터가 포함된다. 이러한 작업을 담당하는 Eureka 2.0 서버는 Write Cluster로 구성된다.

단일 Client는 여러 서비스 인스턴스를 등록할 수 있다. 가상화된 환경에서 Network stack을 100% 신뢰할 수 없기 때문에 연결의 유효성을 결정하는데에 Heatbeat를 사용한다. 연결이 끊어지면 Write Cluster Registry의 등록 항목이 추출 대기열에 들어가고 궁극적으로 Registry에서 제거됩니다. 정상 동작인 Client는 연결을 해제하기 위해서는 항상 등록 취소 요청을 보내야 한다. 등록 후에 Client는 인스턴스 데이터를 변경하면서 원하는 수의 업데이트 요청을 전송 할 수 있다.

Registry Discovery

Eureka Client는 세트에 가입할 수 있다. 성공적인 Subscription 후에 모든 변경 사항이 서버에 의해 Client에 push된다. 이러한 작업을 담당하는 Eureka 서버는 Read Cluster를 구성한다.

Service registry data model

Eureka 2.0은 서로 다른 클라우드 공급자 및 데이터 센터에서 작동하도록 설계되었고 현재 또는 미래의 배치를 수용할 수 있도록 기본 데이터 모델을 확장하도록 설계되었다. 기본 데이터 센터 모델 및 Amazon AWS / VPC 클라우드가 지원된다.

사전 정의 된 서비스 인스턴스 속성 세트는 메타 데이터 맵에 추가 할 수 있는 Key / Value 구조의 사용자 정의 세트를 통해 확장할 수 있다. Network Topology는 미리 정의되지 않는다. 따라서 간단한 공용/개인 IP 모델이 AWS 배포에 제공되지만 VPC에는 다중 NIC/ENI가 지원된다.

Interest subscription model

구독 모델은 사전 정의된 클래스 집합으로 구성된다.

• application interest — 주어진 어플리케이션에 속한 모든 서비스 인스턴스
• vip interest — 특정 Eureka 가상 주소(vip)에 속한 모든 서비스 인스턴스
• instance id — 지정된 ID를 가지는 특정 인스턴스
• full registry — Registry의 모든 항목을 나타내는 특수한 관심 유형(대규모 레지스트리의 경우 막대한 트래픽을 생성할 수 있으므로 거의 사용하지 않아야 함)

어플리케이션/VIP/Instance ID interest에는 연결된 운영 Rule이 있어야 하며 허용되는 값은 다음과 같다.

• Equals — 정확히 제공한 값과 일치
• Like — 관심 값을 정규 표현식으로 취급

Dashboard

Eureka 2.0 Dashboard는 Eureka Cluster 관리/모니터링을 위한 선택적 구성 요소이다. 특정 인스턴스로 드릴 다운하여 쉽게 문제를 해결하거나 시스템 진단을 수행할 수 있는 수준의 Dashboard를 제공한다.

CAP theorem

CAP 정리 관점에서 Eureka의 Write Cluster는 AP 시스템이고(고가용성 및 파티션 허용). 이 선택은 클라우드 기반 검색 서비스의 기본 요구 사항에 의해 결정됩니다. 클라우드에서 특히 대형 배치의 경우 장애는 항상 발생한다. 이것은 Eureka 서버 자체, 등폭된 클라이언트 또는 네트워크 파티션에서 문제가 발생한 것일 수 있다. 이러한 모든 상황에서 Eureka는 Registry 정보를 제공하고 사용 가능한 각 노드에서 새등록을 격리하여 사용할 수 있어야 한다. Eureka는 가용성을 선택하기 때문에 이러한 시나리오의 데이터는 노드간에 일관성이 없다. 이 모델은 레지스트리 데이터가 항상 일정 수준 이상 유지되도록하기 때문에 적절한 클라이언트 측 로드 균형 조정 및 장애 조치 매커니즘으로 보완되어야 한다.(e.g. Ribbon)

sources: https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

Read More

비디오 메타 데이터 확장을 위한 Object Cache

 본 글은 Netflix의 Tech 블로그의 글을 기반으로 작성되었습니다.

Netflix의 도전 과제중 하나는 40개국 이상의 3천 6백만명의 고객의 요구사항을 맞춰 서비스를 확장하는 것입니다.

Netflix의 영화, TV Shows는 복잡한 메타데이터를 지니고 있습니다. 메타데이터에는 제목, 장르, 시놉시스, 출연진, ratings등의 정보가 포함되어 있고 이미지, 예고편, 인코딩 된 비디오 파일, 자막 및 에피소드 그리고 시즌에 대한 링크 정보도 포함되어 있습니다. 그리고 맞춤 장르를 위한 tag가 존재합니다. Netflix의 경우 Global 서비스를 하기에 메타데이터들이 다국어로 번역되어야 합니다.

메타데이터는 서비스에서 활용되며, 각 서비스마다 다른 형태로 사용됩니다. 사용자에게 콘텐츠 정보를 제공하는 Front-end 서비스는 이미지에 대한 링크가 필요하지만, 검색 및 추천 서비스는 Tag를 활용하여 사용자에게 추천할 영화를 검색합니다. Netflix의 경우 이런 메타 데이터 자원들을 효율적으로 제공하기 위해서 VMS(Video Metadata Services) 플랫폼을 구성했습니다.

VMS에서는 메타데이터의 상관 관계를 제공합니다. (콘텐츠 추천, 배우등 사용자가 콘텐츠를 선택하는데 도움이 되는 메타데이터의 상관 관계)

VMS를 구축하면서 해결해야 하는 몇 가지 요구사항이 존재했습니다.

• 하루 1000억 건이 넘는 요청을 처리 해야 한다.
• 20–30GB 사이즈의 대용량 데이터 처리, 모든 국가 및 디바이스 대상
• 높은 복잡성을 지니고 있는 메타 데이터 처리 작업
• Auto Scaling을 효율적으로 수행

초기에는 클라우드 배포를 아래의 방식으로 접근했습니다.

• 기존 RDBMS와 상호 작용하는 서버를 구현, 주기적으로 데이터 스냅샷 생성 및 S3에 업로드
• 특정 서버는 국가별 데이터를 처리하고 데이터 상관 관계를 평가하고 비즈니스 및 필터를 적용한 후 데이터 스냅샷을 생성하도록 구성
• 클라이언트측의 Object Cache는 관련 스냅샷을 로드하고 메모리 객체에서 데이터를 사용할 수 있도록 지원

Cache는 VMS에서 생성되는 스냅샷을 기반으로 주기적으로 새로 고쳐집니다.

위의 아키텍처는 Netflix가 Global하게 확대되기전까지 매우 효과적이었습니다. 위 아키텍처에서는 서버 인스턴스를 구성하고 국가 또는 글로벌 여부에 관계없이 각 국가별 메타 데이터를 처리해야 했습니다. 예고편 데이터, 자막, 더빙, 언어 번역 및 현지화 그리고 계약 정보와 같은 메타 데이터는 국가에 따라 다르지만 장르, 배우, 감독등의 메타데이터는 같습니다. 처음에는 미국 기준으로 Catalog를 제공하고, 캐나다에 서비스를 하면서 두번째 서버를 추가했지만, 남미를 추가할 때 모든 지역마다 다른 콘텐츠를 제공해야 했습니다. 50개 서버의 운영 오버 헤드외에도 국가별로 데이터 중복이 있기 때문에 클라이언트의 Object Cache Footprint가 증가했습니다. 이런 점 때문에 클라이언트의 로드 시작이 길어지게 되었습니다. (중복 제거 작업을 해야 했기에…) 이러한 측면에서 Netflix는 확장할 수 있는 솔루션을 고민하게 되었습니다.

• 국가 단위가 아닌 섬(유사한 특성을 가진 국가 컬렉션)을 중심으로 체계화 된 VMS 서버 간소화
• NetflixGraph를 기반으로 적용된 메모리 최적화 기술로 메타 데이터 처리 및 중복 제거
• 모든 데이터가 아닌 Application이 원하는 메타 데이터 기반으로 운영

위의 기능을 반영하였고, 아래 노란색으로 표시된 부분이 변경되었습니다.

VMS는 Karyon, Netflix Graph, Governator, Curator, Archaius와 같은 Netflix에서 개발한 오픈 소스 솔루션을 활용하여 구성되었습니다. 그리고 전체 Metadata Platform Infra는 Chaos Monkey, Simian Army를 사용하여 테스트 합니다.

Netflix Metadata Template — 한국어

Read More

음악과 영화의 장르 그리고 큐레이션

 

우리가 흔히 일상에서 접하는 음악의 장르는 보통 아래와 같이 분류한다.

• 클래식
• 재즈
• 블루스
• 리듬 앤 블루스
• 힙합
• 컨트리 음악
• 팝
• 전자 음악
• … (엄청 많다. 인류는 음악 분류를 정말 좋아한다.)

음악에서의 장르란 광범위한 음악들을 형식적으로 카테고리화한 것이다.

음악을 좀 듣는 사람들은 처음 듣는 음악이라도 장르를 구분한다. 음악의 장르를 구분하는 AI 기술도 이미 존재한다. 대체로 음악의 장르 구분 기준은 듣는 사람의 감성과는 무관하다. 그리고 시간이 지남에 따라 음악은 엄청 많아졌다. 역설적으로 나의 감성/상황에 적합한 음악을 찾기가 어려워진것이다. 그래서 감성/상황 기반의 Playlist를 제공하고 있다. 부족한 부분을 보완한 분류체계인것이다. Spotify, Youtube Music 등의 음악 서비스에서 기본적으로 제공하고 있고, 사용자가 Custom하게 만들고 공유할 수 있다. 이 기능 덕분에 누군가가 공유한 “운동할 때 듣는 음악”, “여행 갈때 듣는 음악”, “슬플때 듣는 음악”등등의 플레이리스트를 잘 활용하고 있다. 특정 사용자가 큐레이터가 되는 것이다.

이제 영화를 살펴보자. 영화 장르는 보통 아래와 같이 분류한다.

• 액션 영화
• 범죄 영화
• SF 영화
• 코미디 영화
• 스릴러 영화
• 공포 영화
• 전쟁 영화
• 스포츠 영화
• 판타지 영화
• 음악 영화
• 뮤지컬 영화
• 멜로 영화
• …

영화에서의 장르 역시 광범위한 영화들을 형식적으로 카테고리화한 것이다.

그럼 음악에서 제공하는 상황/무드 기반의 분류 체계는 없는 것일까? 음악 서비스 업체처럼 Custom하게 사용자가 Playlist를 만들고 공유하는 기능은 없을까? “수학자가 나오는 영화”, “우울할때 볼만한 영화”등등… 누군가가 큐레이션를 해줄 수는 없는걸까?

유튜브는 사용자가 제작한 콘텐츠를 공유하는 플랫폼이기에 대체로 영상이 짧다. 그렇다보니 콘텐츠 양이 어마어마하다. 그래서일까? Playlist 기능을 제공한다. 아시는분은 아시겠지만 유튜브는 영화 콘텐츠도 제공한다. (https://www.youtube.com/movies)

Netflix는 더 재밌는 서비스가 존재한다.

2016년에 Flixtape 서비스를 런칭한다.

Flixtape는 Netflix가 제공하는 콘텐츠의 짧은 플레이리스트를 만드는 기능이고 공유할 수 있다. 예전에 카세트 테이프에 좋아하는 음악을 Mix해서 들었던 기억이 있는지?

Netflix안에만 머물던 콘텐츠가 외부 SNS, SMS등을 통해 사용자들이 직접 입소문 마케팅을 할 수 있는 간단한 방법을 Flixtape가 제공한다.

혹시 국내 서비스중에 사용자에 의한 큐레이션 기능을 제공하는 서비스가 있으면 소개좀…

Read More

Netflix Artwork의 개인화

본글은 “Artwork Personalization at Netflix”의 글의 내용중 일부를 발췌해서 작성했습니다.

Netflix 추천 시스템의 주요 목표는 사용자에게 맞는 콘텐츠를 추천하는 것이었습니다. 사용자가 콘텐츠에 흥미를 가지고 해당 콘텐츠가 가치가 있는지를 확인하는 방법이 무엇일지 많은 고민을 했습니다. 콘텐츠의 포스터가 관문 역할을 하며 사용자에게 콘텐츠에 대한 매력을 어필할 수 있다고 판단했습니다.

구구절절한 설명보다 단 한장의 이미지로 함축적인 내용을 전달 할 수 있습니다. Netflix는 이점에 착안하여 Artwork의 개인화를 시스템에 반영했습니다.

“Good Will Hunting”이라는 영화를 묘사할 때 사용하는 이미지를 개인화하려고 시도해봅시다. 로맨틱한 영화를 즐겨본 사용자는 Matt Damon과 Minnie Driver가 포함된 포스터를 보여주면 “Good Will Hunting”에 관심이 있는 반면, Robin Williams가 포함된 포스터를 사용하면 코미디 영화를 좋아하는 사용자가 영화에 관심이 있을 수 있습니다.

또 다른 시나리오를 생각해봅시다. Pulp Fiction의 포스터의 경우, 우마서먼이 출연한 영화를 많이 본 사용자(바로 저)는 우마서먼이 나오는 포스터에 호감을 가지게 될 것입니다. 한편 존 트라볼타의 팬은 존 트라볼타가 나오는 포스터에 더 관심이 있을 수 있습니다.

Netflix는 포스터를 개인화함으로써 모든 사용자가 최상의 선택을 할 수 있도록 사용자 경험을 향상 시킵니다.

포스터를 개인화하는 방법을 알기 위해서는 한 콘텐츠에 대해 어떤 포스터가 더 효과가 있다라는 신호를 찾기 위해 많은 데이터를 수집해야 합니다.

효과적인 개인화를 달성하려면 각 콘텐츠에 대해 훌륭한 포스터 풀이 필요합니다. clickbait(독자가 흥미롭지 않거나, 가치가 떨어지는 콘텐츠의 링크를 클릭하도록 유도하는 행위)를 피하기 위해 매력적이면서 유익한 포스터 자산이 필요하다는 것을 의미합니다. Netflix의 아티스트 및 디자이너팀은 다양한 차원에서 다양한 이미지를 만들기 위해 노력을 기울입니다.

포스터를 개인별로 제공하기 위해서는 엔지니어링 관점에서 Challenge가 필요합니다. 사용자의 시각적 경험을 위해 많은 이미지를 포함한다는 점입니다. 각 콘텐츠에 대해 개인별 맞춤형 포스터를 제공하면 초당 2천만건의 요청을 처리할 수 있는 견고한 시스템이 필요합니다. UI에서 포스터를 제대로 렌더링 하지 못하면 사용자의 경험이 크게 저하됩니다. 사용자의 취향이 변함에 따라 포스터의 효과가 시간이 지나면서 바뀌게되므로 알고리즘이 지속적으로 대응해야 합니다.

Netflix의 추천엔진 대부분은 기계학습에 의해 동작됩니다. 사용자의 서비스 사용에 대한 데이터를 수집하고 그 데이터를 기반으로 알고리즘을 실행합니다.

그리고 A/B 테스트를 통해 새로운 알고리즘을 테스트 합니다. A/B 테스트는 새로운 알고리즘이 무작위로 구성된 사용자를 대상으로 진행하며, 현재 프로덕션 시스템보다 우수한지를 확인합니다.

그룹B의 사용자가 새로운 알고리즘 환경에 접속하는 동안 그룹A의 사용자는 현재의 프로덕션 환경으로 접속합니다. 그룹B의 사용자가 참여도가 높으면 새로운 알고리즘을 전체 사용자에게 배포합니다. 그러나 불행하게도 이러한 접근법은 실패했습니다. 오랜동안 많은 사용자가 더 나은 경험을 얻지 못했습니다.

Netflix는 이 실패를 해결하기 위해 Batch성 기계학습에서 벗어나 실시간 기계학습을 고려했습니다. Netflix가 사용하는 학습 알고리즘은 Contextual bandits입니다. (참조: https://medium.com/netflix-techblog/artwork-personalization-c589f074ad76)

이러한 접근 방식을 통해 Netflix는 사용자가 새로운 콘텐츠를 선택하는 방법에 대해 의미있는 개선을 했습니다. 대단합니다.

콘텐츠의 첫 관문인 포스터는 정말 중요합니다.

성인은 첫번째, 어린아이들은 두번째 포스터를 선택하지 않을까요? 개인화 Artwork를 통해 사용자 경험을 증대시키는 Netflix에게 박수를 보냅니다.

Read More

Robot이 불러오는 변화들

 

인공지능과 함께 로봇은 이미 우리 생활 곳곳에 파고 들고 있고 큰 변화를 가져올 것으로 예상되고 있다.

과거에는 싼 인건비를 찾아서 동남아등에 공장을 설립했지만, 요 근래 리쇼어링 현상이 발생하고 있다. 로봇 적용으로 인해 인건비 부담이 줄게되었고 물류 비용과 행정적 비용을 고려하면 동남아에 있을 이유가 없어진다.

가장 대표적인 사례가 아디다스(Adidas)의 스피드 팩토리(Speed Factory)이다.

아디다스가 2006년 독알 안스바흐에 만든 스피드 팩토리는 독일정부 + 아헨공대 + 아디다스의 작품이다. 여기에 들어간 기술은 지멘스의 Mind Sphere(클라우드 기반의 IoT)이며 그 외 여러 업체들이 참여해 센서와 시스템을 구축했다.

신발 제조 산업은 대표적 노동집약적 산업이고 인력이 가장 중요했다. 스피드 팩토리로 인해 필요 인력이 가장 크게 줄어들 것으로 보인다. 신발 제조 근로자 75% 이상이 베트남, 인도네시아, 중국등 아시아 지역에 집중되어 있고 타격이 불가피할 것으로 전망된다.

스피드 팩토리의 목적은 다음과 같다.

1. “급변하는 트렌드에 발빠른 대응” - 다른 신발 공장처럼 같은 소재, 디자인의 신발을 계속 만드는 것이 아니라 고객의 주문을 넣으면 원단 직조에서 마감까지 로봇이 처리하고 스타일, 깔창, 소재, 색깔 및 신발끈까지 고객의 요구 사항 그대로 맞춤형으로 생산된다.
2. “저임금 근로자에 대한 의존도 축소” - 스피드 팩토리의 연간 생산량은 약 50만 켤레이다. 여기에 투입된 인력은 약 10명이다. 로봇없이 사람으로 50만 켤레를 생산하려면 약 600명의 근로자가 필요했다.
3. “재고 감소” - 스피드 팩토리는 고객이 제품을 주문하면 생산하는 개념이다. 재고 관리에 대한 부담이 적어진다.

만약, 모든 제조업체가 스피드팩토리를 도입한다면 어떤 일이 발생할까?

과거 산업 혁명 시절에도 기계로 인해 인간의 일자리가 사라질거라고 생각했었지만, 다른 형태의 일자리를 창출하게 되었다. 하지만 이번은 조금 다르다. 아디다스가 독일에 스피드 팩토리를 지으면서 일자리 창출에 대한 기대감이 있었지만 결과적으로는 그렇지 않았다.

로봇으로 대체할 수 있는 일자리는 사라질 것이고, 대체하지 못하는 일자리는 창출 될 것이다. 현재 우리가 일하고 있는 분야에서 우리의 역할이 어떻게 변화하고 로봇을 리드할 능력을 어떻게 갖출지 고민이 필요해보인다.

Read More

GraphQL과 RESTful

 

GraphQL(Graph Query Language)은 Server API를 만들기 위해 Facebook에서 만든 Query Language입니다.

Query Language는 질의문(Query)과 컴퓨터언어(Language)의 조합입니다. 기존에 RESTful이라는 개념이 존재하였고, 그동안 잘 사용하고 있었는데 Facebook은 왜 이런 개념을 만든 것일까요?

https://graphql.org/blog/graphql-a-query-language/에 의하면 아래와 같은 문제점이 존재했다고 합니다.

• 다양한 기기에서 필요한 정보들을 REST로 일일히 구현하기 힘듬
• 각 기기마다 UI/UX가 다르기에 Server에서 일일히 대응하기가 어려움

그래서 Facebook은 서버가 데이터를 노출하는 방법을 정의한 기술 표준이 필요했고 내부적으로 만들어서 사용하다가 2015년도에 오픈소스로 공개하게 되었습니다.

RESTful과 GraphQL의 차이점은 무엇일까요?

RESTful과 GraphQL의 차이점

API Endpoint

REST의 핵심 아이디어는 Resource입니다.각 Resource는 URL로 식별되며 해당 URL 에 요청을 보내 정보를 얻습니다. REST는 Resource의 유형 및 모양과 리소스를 가져오는 방법이 결합된 방식을 제공한다는 점입니다.

GET / books / : id 
GET / authors / : id 
GET / books / : id / comments 
POST / books / : id / comments

GraphQL의 경우는 위에서 언급한 두 개념이 완전히 분리되어 있습니다. 전체 API를 위해서 단 하나의 Endpoint만 사용합니다. github의 경우 v3 API와 v4의 API의 기술 표준이 다릅니다. v3의 경우는 v3 루트 element하위에 각 Resource들의 endpoint가 존재하지만, v4의 경우 루트 element만 존재합니다. 이 의미는 사용측에서 Query 스키마 유형을 만들어야 합니다.

type Query {
  book(id: ID!): Book
  author(id: ID!): Author
}
type Mutation {
  addComment(input: AddCommentInput): Comment
}
type Book { ... }
type Author { ... }
type Comment { ... }
input AddCommentInput { ... }

API Response

RESTful의 경우 각 API마다 spec이 존재하며, 정의해놓은 format대로 각 Resource의 정보를 Response합니다.

GraphQL의 경우 사용하는 측에서 Response 구조를 원하는 방식으로 변경할 수 있습니다.

이 둘간의 차이점을 보여주는 그림입니다.

GraphQL을 사용하게되면 아래의 장점을 지니게 됩니다.

• HTTP 요청 횟수를 줄일 수 있기 때문에, Network Latency가 감소됩니다.
• HTTP 응답 Size가 줄게 됩니다.

결론

그동안 RESTful은 N+1 쿼리의 제약에서 자유롭지 못했습니다. 특정 사용자가 작성한 글의 모든 내용을 보고 싶다고 하면 모든 글의 목록을 가져오고 내용은 목록 리스트를 루프를 돌면서 fetch를 해야 했었습니다. 그리고 필요 정보만 가져오고 싶어도 API에서 제공해주는 모든 정보를 받은 후에 필터 처리를 해야 했었습니다. 이런 점은 성능에도 영향을 주게 되었고요.

물론, RESTful의 단점을 개선한 GraphQL도 장점만 존재하는 것은 아닙니다. 높은 학습 곡선이 존재하고 적절한 상황에서 사용해야 합니다.

Read More