12/31/2018

블록체인 기술을 바라보는 개인적 시각

enter image description here

블록체인 기술을 한마디로 정의하기는 어렵다. 개념이 명확하게 정리되지 않은 상태이기에 기술적 정의 및 설명하는 방식도 상황에 따라 달라진다.

블록체인 기술을 이해하기 위해서는 비트코인에 대해서 알아야한다. 비트코인은 블록체인 기술을 기반으로 2009년에 배포된 암호 화폐이다. 비트코인으로 인해 그 기반 기술인 블록체인이 이목을 끌기 시작했다.

블록체인은 “블록"이라고 하는 소규모 데이터들이 P2P 방식을 기반으로 생성된 체인 형태의 연결고리 기반의 분산 데이터 저장환경에 저장되어 누구라도 임의로 수정할 수 없고 누구나 변경의 결과를 열람할 수 있는 분산 컴퓨팅 방식의 데이터 변조 방지 기술이다.

계모임을 한다고 생각해보자. 계모임의 경우에는 돈을 관리하는 계주나 계원이 잠적하면 문제가 생긴다. 종종 뉴스에서 이런 사례가 보인다. 계모임은 인간관계를 바탕으로 신뢰를 얻기 때문이다.

여기서 논제를 약간 틀어서 계모임을 하는데 각자 입금하는 금액이 상이하다고 가정해보자. 그리고 입금한 금액은 장부에 기록한다고 치자. 그런데 장부를 기록하는 과정에서나 실제 기록한 이후에 다르게 바뀔 수 가 있다. 장부 관리자가 특정 계원과 기록을 허위로 작성하거나 기록된 내용을 변조할 수 있는 가능성이 있기 때문이다.

여기에 블록체인 기술을 적용해보자.
각자의 내역을 쪽지에 적어 나머지 사람에게 전달하고 나머지 사람은 자기 기록을 포함해 각각 다른 사람의 내용을 기록한 쪽지를 갖게 된다.

이 내용을 근거로 1장의 장부를 각각 만든다. 그리고 참여하는 사람이 합계를 각각 산출한다. 이 과정에서 가장 먼저 합계를 산출한 사람이 손을 들고 사본을 만들어 나머지 사람들에게 배포한다.

사본을 전달 받은 사람들은 합계가 맞는지 일치하는지 점검하고 이상이 없다면 보관한다. 만약 내용이 틀리면 잘못되었음을 알리고 다른 누구가 정확한 자료를 만들때까지 작업을 계속한다.
enter image description here
위의 방식으로 처리하기 때문에 기술적 특성에서 생긴 처리 속도의 제한적 문제가 발생한다. 모든 참여자가 데이터를 기록하고 관리하는 방식의 한계이기도 하다.

이를 해결하는 방안을 “Consensus 알고리즘"이라고 한다. 속도 문제를 해결하기 위해 여러가지 다양한 Consensus 알고리즘이 나타났고., 최초의 블록체인이 추구하던 개념과는 거리가 먼 알고리즘도 생겨났다.

블록체인은 개방형과 폐쇄형으로 나뉘게 된다. 개방형은 요건을 갖추면 누구나 참여할 수 있고, 폐쇄형은 특정 조건의 참가자만 참여가 가능하다.

enter image description here

초반에는 블록체인이 기존 비즈니스에 혁신을 가져다 줄 것이라는 기대가 많았다. 특히 중개 거래상에서 투명성을 제공하고 거래 비용을 낮춰줄꺼라는 기대가 많았다. 하지만 현실은 녹녹치 않은 상황이다.

이미 중앙화된 시스템에서 신뢰가 확보된 분야에서는 블록체인으로 인해 투명성과 신뢰도를 제공한다고 해서 기존 대비 큰 가치를 제공하지 못한다면 굳이 도입할 이유가 없다. 이미 잘 운영되고 있는 분야에 적용하는 것은 어렵지 않을까?

오히려 블록체인 기술은 양성 시장보다는 음성 시장에 적합할 수 있다. 인류가 생긴 이래 음성적인 시장이 계속 활성화된 이유는 무엇일까? 싸게 사고, 세금을 내지 않기 위해서? 이런곳에 블록체인 기술을 응용해서 음성 시장의 입지를 줄이는건? 혹은 온라인 투표 혹은 선거에 도입하는건?

분산, 개방, 공유를 통한 투명성/신뢰성이라는 장점을 지닌 블록체인 기술을 적용할 수 있는 분야는 무엇일까? 블록체인에 대한 환상을 깨고 기존 기술로는 적합하지 않은 비즈니스 분야를 개척해야 하지 않을까?

12/25/2018

[독서] 지지 않는다는 말

enter image description here

다이어리 정리를 하다가 얼마전 읽은 지지 않는다는 말에 나온 글귀를 적은 페이지를 발견하고 여기에 옮겨 적는다.
  • 내 삶에서 가장 큰 영향을 끼친 건 지지 않는다는 말이 반드시 이긴다는걸 뜻하는 것만은 아니라는 깨달음이었다. 지지 않는다는 건 결승점까지 가면 내게 환호를 보낼 수많은 사람들이 있다는 걸 안다는 뜻이다. 아무도 이기지 않았건만, 나는 누구에게도 지지 않았다. 그 깨달음이 내 인생을 바꿨다.
  • 너는 네가 하고 싶은 일만하면서 살 수 있을 것 같니? 그러나 하고싶은일만 하면서 살수없다고 해서 하기 싫은 일을 반드시 하면서 살아야 한다는 의미는 아니지 않은가? 오히려 하고 싶은 일만 하면서 살수 없으니까 하기 싫은 일을 더구나 하지 말아야지
  • 후달리지 않은 것 만으로 당신은 이미 달리기의 반을 이룬 셈이다. 달리고 싶지 않을때 달리지 않고 달리고 싶을때 달릴수 있는 사람, 그가 바로 러너니까…
  • “칭커"란 친하게 지내고자 하는 사람들을 한데 모아 그들이 “이러다가 배가 터지지 않을까?” 라고 걱장할 즈음에 “이제 그럼 주문을 해볼까?” 라는 표정으로 요리와 술을 더 시킨뒤 “많이 드셨는지 모르겠다.”고 말하며 계산하는 행위를 뜻한다.
  • 내가 집으로 돌아가는 순간은 여행지가 집처럼 느껴질때…
  • 오래산 사람은 덜 산 사람처럼 호기심이 많고, 덜 산사람은 오래산 사람처럼 사려싶은 사람이 되었으면 좋겠다.
  • 근본적인 질문은 우리에게 한계가 존재할때만 가능하다.
  • 누군가와 같이 뭔가를 하는일은 정말 번거롭다. 추억을 만드는데는 최소한 두 사람이 필요하다는 것을, 혼자서 하는 일은 절대로 추억이 될 수 없다는 것을…
  • 대개 어른들이 그런건 나중에 얼마든지 할 수 있다고 말하는 일 위주로 생활하면 인생에서 후회할 일은 별로 없는 것 같다.
  • 옛날에는 지물포에서 롤페이퍼 형태로 둘둘말린 종이를 잘라서 팔았다. 그래서 “론지"라는 말이 “노루지"라는 아름다운 이름으로 불렸다.
  • 난 줄넘기를 하고 있었어… 모든게 다 괜찮았는데… 순간… 나도 모르게… 갑자기 다 부질없어 보였어
  • Winter Journey를 들으며 이제 그 길은 혼자 걸어도 괜찮은 길이라기 보다는 혼자 걸어야만 좋은 길이 된다.
  • 결승점까지 들어가면 아픔은 씻은듯이 사라졌으니까, 아이로써 출발선에서 뛰어나와 어른으로 결승점에 들어가는 법을 알게됐으니까…
  • 아픔과 고통의 경계선을 넘어서면서 어른들은 아이들과 헤어진다.

12/12/2018

GraphQL 채택 후 Netflix가 배운 것들

Netflix에서는 콘텐츠 인기도 파악과 같은 다양한 데이터 및 집계 데이터를 활용하여 관련성이 높은 광고를 제공한다. Netflix의 목표는 모든 외부 채널에 대해 광고가 사용자와 잘 어우러지게 만드는 것이다. Netflix는 보다 효율적으로 하기 위해 끊임없는 실험을 하고 있다.
enter image description here
Monet의 React UI는 Apache Tomcat에 의해 구동되고 REST API에 Access를 했다. 시간이 지나고 어플리케이션이 발전함에 따라서 사용 사례가 복잡해지기 시작했다.

Simple page는 다양한 소스의 데이터를 가져와야 한다. 이 데이터를 클라이언트에서 효과적으로 로드하기 위해서 Backend 데이터를 비정규화 하는 노력을 시도했다. 그 이유는 모든 페이지가 모든 데이터를 필요로 하지 않기 때문에 유지하기가 어려워지기 때문이다. Network 병목 현상에 발생했다.

Backend에서 클라이언트에게 보내는 field의 수를 줄이는 방법은 모든 페이지에 대해서 endpoint를 만드는 것이었지만, 효율적이지 못했다. 대신 GraphQL을 Middleware로 선택했다.

이미 개발되어 사용중이던 Falcor도 훌륭한 솔루션이었지만 GraphQL의 Eco시스템을 이용하기 위해 Falcor가 아닌 GraphQL을 사용했다. 데이터 구조가 점차 그래프 지향적으로 변경됨에 따라 Network 병목도 해결했고, 기능을 더 빨리 추가 할 수 있게 되었다.

enter image description here

장점

NodeJS에서 GraphQL을 약 6개월 정도 사용하였고 개발 속도 및 페이지 로드 성능을 크게 향상시키는 것을 입증했다.

Redistributing load and payload optimization

GraphQL을 Middleware로 추가 할 때 GraphQL 서버는 Client가 직접 호출했을 때와 같이 동일한 서비스 및 REST API를 호출해야 했다. 대부분의 데이터가 동일한 DC내의 서버사이로 전달 되기에 이러한 Server to Server 호출은 대기 시간이 낮고 대역폭이 높기 때문에 브라우저에서 직접 네트워크를 호출하는 것에 비해서 약 8배의 성능이 향상되었다. GraphQL 서버에서 Client Browser의 데이터 전송 구간은 여전히 느린 속도지만, 단일 네트워크 호출로 축소시켰다.

GraphQL을 사용하면 Client가 필요한 데이터만 취할 수 있기 때문에 REST API 에 비해 상당히 작은 Payload를 가져온다. Netflix의 Application에서 이전에는 10MB의 데이터를 가져온 페이지는 약 200KB를 받는다. Page load는 데이터가 제한된 모바일 네트워크에서 훨씬 빨라졌고 훨씬 적은 메모리를 사용한다.

Reusable abstractions

개발자는 일반적으로 단일 목적으로 하는 코딩보다 재사용이 가능한 추상 방식을 사용하기를 원한다. GraphQL을 사용하면 각 데이터를 한번 정의하고 시스템의 다른 데이터와의 연관성을 정의한다.

아래의 예제를 보면, GraphQL의 Entitiy를 Catalog, 주석과 같이 한번만 정의한다. 이 정의에서 여러 페이지에 대한 View를 정할 수 있다. Client App의 한 페이지는 다른 Client Page에 광고가 속한 Catalog를 모든 댓글과 함께 보기를 원한다고 하면 동일한 그래프 모델을 사용하면 Backend 서버의 코드를 변경하지 않고도 두가지 View를 수용할 수 있게 된다.

enter image description here

Chaining Type Systems

GraphQL에서 Entitiy를 정의하고 나면 자동 코드 Generater 도구를 사용하여 Client 어플리케이션의 TypeScript 유형을 생성한다. 이러한 유형과 Query는 서버 Schema에 대해서도 유효성이 검사 되기에 서버에서 발생한 모든 변경 사항은 데이터를 사용하는 Client가 알게 된다.

GraphQL과 함께 여러 서비스를 묶고 이러한 검사를 Build Process에 연결하면 잘못된 코드를 배포하기 전에 더 많은 문제를 파악할 수 있다.

enter image description here

개발 단순화

Client 어플리케이션을 만들 때 공통적으로 고려해야 하는 사항은 UI/UX 이지만, 개발자 인터페이스와 개발자 경험은 유지 관리 가능한 어플리케이션을 빌드하는 것만큼 중요하다.

GraphQL을 사용하기 전에는 새로운 React 컨테이너 구성 요소를 작성하기 위해 복잡한 로직을 관리하여 필요 데이터에 대해 요청을 해야했다. 개발자는 하나의 데이터가 다른 데이터와 어떻게 관련되는지, 데이터를 Cache하는 방법, 병렬 또는 순차적으로 호출할 지 여부, Redux에서 데이터를 저장할 위치 등을 고려해야 한다.

GraphQL Query Mapper를 사용하게 되면 각 React 구성 요소는 필요한 데이터를 설명하기만 하면 되고 Wrapper는 이러한 것들을 처리하게 된다.

다른 장점

몇 가지 다른 이점이 있다.

첫째 GraphQL Query의 Resolver가 실패하면 성공한 Resolver는 가능한 많은 페이지를 Rendering하기 위해 Client에 데이터를 반환하게 된다.

둘째, Backend 데이터 모델은 CRUD 인터페이스를 제공하기 때문에 매우 간단하다.

마지막으로 GraphQL Query가 테스트를 위해 stub으로 자동 변환될 수 있고 React 구성 요소와 분리되어 Resolver를 테스트 할 수 있기에 구성 요소를 테스트하는 것이 더 쉬워진다.


진화

GraphQL로 마이그레이션은 단순한 경험이었고, 네트워크 요구 사항을 정의하고 데이터를 변환하기 위해 구축한 대부분의 인프라는 코드 변경없이 React 어플리케이션에서 NodeJS 서버로 쉽게 이전 할 수 있었다. 하지만 몇가지 장애물이 존재했다.

GraphQL의 Resolver는 다른 Resolver와 관련없이 독자적으로 실행되기 때문에 동일하거나 유사한 데이터에 대해 중복적으로 네트워크 요청을 하는 것으로 나타났다.

모든 Resolver가 끝날 때 까지 네트워크 응답을 메모리에 저장하는 간단한 Caching Layer를 Wrapping하여 복제를 해결했다. Caching Layer를 사용하여 단일 서비스에 대한 여러 요청을 모든 데이터 대한 대량 요청으로 할 수 있게 되었다.

Resolver는 Fetch 프로세스를 최적하는 방법에 대해 고민하지 않고도 필요한 모든 데이터를 요청 할 수 있다.

enter image description here

GraphQL은 다른 서비스에 대한 네트워크 호출을 자동으로 조정하여 복잡성을 숨긴다. 디버그 flag가 활성화되면 디버깅을 쉽게 하기 위해 GraphQL Response Payload에 로그가 나타난다. Netflix는 Debug Flag를 활용하여 브라우저의 네트워크 탭을 통한 자연스러운 디버깅 방법을 고안했다.

Netflix의 경우 GraphQL 사용의 초기 단계에 있지만, 현재까지 진행한 사항으로는 긍정적인 경험이었다고 한다. Netflix가 GraphQL을 사용하는 핵심 목표는 시스템이 점차 정교해짐에 따라 개발 속도를 높이는데 도움이 될 것으로 보고 있고 복잡한 데이터 구조로 어려움을 겪지 않고 Graph Data Model에 투자하여 시간이 지남에 따라 팀의 생산성이 향상되는 것이라고 한다.

지난 기간 동안, 만들어 놓은 Graph Model이 강력하기에 일부 기능을 구현하기 위해 Graph를 변경하는 일은 없었다고 했고, 확실히 더 생산적이었다고 한다. 그리고 Schema stitching과 같은 개념을 사용하여 다른 서비스와의 통합을 수월하게 하고 개발 시간을 절약되길 기대한다고 한다.

현재 진행중인 프로젝트에서도 GraphQL에 대해서 테스트중이고, Netflix와 같은 효과가 생기길 기대한다.

References: https://medium.com/netflix-techblog/our-learnings-from-adopting-graphql-f099de39ae5f

12/10/2018

NetflixOSS Hollow

“모든 것을 효율적으로 Cache 할 수 있다면 게임 체인저가 될 수 있다.”
enter image description here

Netflix는 메타 데이터 Caching을 위해 Java로 작성된 범용 Cache인 Hollow를 OSS로 제공하고 있다.

일반적으로 소프트웨어 엔지니어들은 “빅데이터"라는 데이터를 보급을 요구하는 문제에 직면한다. 이런 유형의 문제는 다음과 같다.
  • 전자 상거래 사이트내 제품의 메타 데이터
  • 검색 엔진의 메타 데이터
  • 영화 및 TV 프로그램에 대한 메타 데이터
이런 문제에 직면할 때 일반적으로 아래의 두 가지 방법 중 하나를 선택한다.
  • Consumer의 원격 접근을 위해 데이터를 중앙 집중화하여 보관 (e.g. RDBMS, NoSQL, Memcached, Redis.,)
  • 데이터를 직렬화(e.g. json, xml)하고 Consumer에게 배포하여 사본을 보관
위에서 언급된 방법의 확장에는 여러 가지 문제점이 존재한다. 데이터를 중앙 집중화하면 데이터 집합이 무한히 커질 수 있지만,
  • 데이터와 상호 작용할 때 대기 시간 및 대역폭 제한이 존재
  • 원격 데이터 저장소는 데이터의 로컬 복사본만큼 신뢰할 수 있음
반면, 로컬 복사본을 전체적으로 직렬화하여 메모리에 저장하면 지연 시간이 늘어나고 주파수 Access가 훨씬 늘어날 수 있지만 이 접근법은 데이터 집합의 크기가 커짐에 따라 Scaling 문제가 존재한다.
  • 데이터 집합의 Heap 공간이 커진다
  • 데이터를 가져오려면 더 많은 비트를 다운로드 해야 한다.
  • 데이터를 업데이트하려면 상당한 CPU 리소스가 필요하거나 GC 동작에 영향을 미칠 수 있다.
엔지니어는 대부분 자주 Access하는 데이터를 로컬에 Cache하고 자주 Access하지 않는 데이터는 원격에서 가져오는 Hybrid 방식을 선택한다. 이 접근 방식에는 다음과 같은 문제가 있다.
  • 자료 구조는 상당한 Heap 공간을 소비 할 수 있다.
  • GC 행동에 부정적인 영향을 줄 수 있다.
Netflix에서는 로컬 Cache의 크기 조정은 많은 레코드의 원격 대기 시간과 더 많은 데이터를 로컬로 유지하는 Heap 요구 사항 사이의 조심스러운 조율이라는 관점으로 보고 있다.

Hollow는 Consumer에게 전체 읽기 전용 데이터를 메모리에 보관하는 기능을 제공한다. 부분 Cache에서 데이터를 업데이트하고 제거하는 결과를 회피한다.

Hollow를 사용하기전까지 Netflix는 Zeno를 사용했다. Hollow의 선구자인 Zeno는 크기가 제한되는 POJO(Plain Old Java Objects)로 데이터를 저장했다.
enter image description here
Hollow는 변화하는 데이터의 상태사이에 자동으로 delta를 생성한다. Consumer가 데이터 업데이트 상태를 유지하는데 필요한 노력을 최소화 시킨다. 또한 자동으로 데이터 중복을 제거하여 Consumer 데이터 셋의 Heap크기를 최소화 한다.

Hollow는 POJO 대신 데이터를 압축하고 고정 길이의 인코딩 방식으로 대체한다. 이 인코딩은 데이터 셋의 Heap 공간을 최소화하고 즉시 데이터에 Access하는데 드는 CPU 비용을 최소화하도록 설계 되었다. 인코딩 된 모든 레코드는 사용량이 많은 서버에서 GC 동작에 영향을 주지 않도록 JVM Heap에 풀링 된 메모리내의 재사용 가능한 slab에 저장된다.

enter image description here

Object 레코드가 메모리에 배치되는 방법 예시
Hollow는 여러 서버에 데이터를 분산하고 데이터 내구성을 위해 복제 알고리즘을 제공하지 않고 모든 Consumer가 모든 데이터를 사용할 수 있는 방법을 사용한다.

Hollow가 memcached와의 다른점은 아래와 같다.
  • Memcached의 주요 이점은 분산 Caching 시스템으로 많은 인스턴스에서 메모리를 풀링한다는 점이다. 그러나 Hollow는 분산된 Caching 시스템은 아니며, 여전히 중앙 집중화되어 있다. 데이터 관점에서는 각 시스템으로 Caching되기에 분산 시스템이라 볼 수 있다.
  • Hollow는 Netflix의 매우 높은 처리량에 대한 Cache 요구 사항을 충족 시키기 위해 제작되었다. Consumer에게 전체 데이터 셋을 복제한다는 것은 데이터를 수집하기 위해 네트워크 Hop을 만들 필요가 없으므로 데이터 셋의 어느 부분에나 Access할때 대기 시간이 거의 없음을 의미한다.
  • Hollow는 전체 데이터 집합의 폭에 Access하기 위해 CPU 비용을 줄이는데에 중점을 두고 있다. Memcached와 같이 느슨한 형식의 key/value 저장소와는 달리 구조화된 데이터 모델을 요구하면 Access 비용 문제를 한번에 해결 할 수 있다.
  • Hollow는 파일 저장소를 제공한다. S3, NFS, FTP도 가능하다. Consumer는 데이터 저장소의 전체 Snapshot을 읽고 데이터 셋을 메모리로 Boot Strap한다. 데이터 셋은 Delta 적용을 통해 메모리에 최신 상태로 유지된다. 각 Consumer의 메모리 내 사본은 일시적이다. 시스템 Restart시 BLOB 저장소에서 Snapshot을 다시 검색해야 한다.
  • Blob 파일의 형식은 간단하다. 메모리내의 Layout과 거의 동일한 구조이기에 데이터를 초기화하는 작업은 Blob to 메모리로 복사하듯이 이루어지며 신속하게 수행된다.
그외 Hollow에 대한 궁금증을 아래에 정리했다.

CAP 이론에 담긴 우려 사항을 해결 할 수 있는지? 간헐적인 네트워크 연결 문제가 발생했을때 오래된 데이터로 작업이 가능한지?
  • Consumer는 각각 메모리에 데이터 셋의 전체 복사본을 가지고 있기 때문에 가용성은 타의 추정을 불허한다.
  • 일관성에 대해서는 변화하는 데이터 셋에 대한 Timeline을 개별 데이터 상태로 분해해야 하며, 각 상태는 특정 시점의 데이터에 대한 완벽한 Snapshot을 의미한다.
Hollow는 주로 작은 메타 데이터에서만 활용되는 것인가? Local 서버의 메모리 리소스가 고갈 된 경우는 어떻게 되는가?
  • Hollow는 주로 중소 규모의 데이터 세트를 대상으로 한다. Hollow는 Tera Byte, Peta Byte가 아닌 Mega byte, Giga byte에 대한 경험을 제공한다. 일반적으로 JSON형태의 문서 저장소보다 Hollow의 인코딩을 활용하여 저장할 경우 사용하는 용량이 훨씬 작다. 그래서 Tera Byte이상의 데이터 셋을 중형 데이터 셋으로 전환 하는 것을 고려할 수 있다.
  • 데이터 모델링이 중요하다. 데이터가 구조화 되는 방식은 Holloww가 데이터 집합을 중복 제거 할 수 있는지, 압축률이 어떤지에 따라 영향을 미친다. 일반 압축 알고리즘은 허프만 트리를 사용하여 데이터의 패턴을 찾는 반면 Hollow는 데이터 모델의 코드 구조를 사용하여 패턴을 지정한다.
POJO에서 멀어지는 전략은 어떤 효과가 있는가?
  • Hollow의 경우 중복 제거, 인코딩, 패킹 및 Java 객체의 Overhead 제거와 같은 다양한 방식으로 압축을 수행한다. 중복 제거의 방법과 범위는 주로 Zeno에서 가져왔지만, POJO에서 벗어나지 않으면 인코딩, 패킹 및 Object Overhead 제거가 불가능했다.
  • Hollow는 데이터 셋의 데이터에 Access할때 CPU 영향을 최소화하고 해당 데이터를 저장하는데 필요한 Heap 공간을 최소화해야 했다.
비 Java 어플리케이션이 Hollow를 활용할 수 있는가?
  • 비디오 메타 데이터용 시스템은 JVM 기반 언어를 사용하여 제작되었기에 Java용 Hollow를 구축했다. 비 JVM 기반 언어는 현재 Hollow를 활용할 수 없다.
참고: https://github.com/Netflix/hollow

12/09/2018

스마트 시대에 헌책방이 공존할 수 있는 이유

enter image description here

종종 헌책방에서 책을 사기도 한다. 우연히 들려 마음에 드는 책을 사는 경우가 보통이었고, 그렇게 내손에 잡힌 책에서 타인의 흔적을 발견하는 것이 헌책을 사는 것에 대한 매력이었다. 헌책방은 추억을 사고파는 곳이다.

헌책방에서 주로 사는 책은 유행(세월)을 타지 않는 책이다. 가치가 있는 책은 오래되고 낡아도 관계가 없다. 좋은 책인지 아닐지는 감으로 알 수 있다.

그렇게 구매한 책은 다 읽고나서도 내곁을 떠나지 않는 것이 대부분이다. 반면 자기 계발서 같은 책은 내손을 쉽게 떠났다.

요즘은 예스24, 알라딘 처럼 큰기업이 중고 서점을 오픈하고 운영중이다. 그리고 멀지 않은 거리에 대형 서점이나 도서관이 즐비하다.

하지만 이런 곳에서 쉽게 찾을 수 없는 책들이 있다. 결국 이 경우에는 마지막으로 헌책방에 갈 수 밖에 없다. 쉽게 구할 수 없는 책들이 모이는 곳이 헌책방이니까…

12/06/2018

PaaS vs. CaaS

PaaS

PaaS가 나오기 전에 개발팀은 개발한 어플리케이션에 대해서 인프라를 구축하고 유지해야 했다. PaaS는 어플리케이션이 실행되는 플랫폼을 제공하기에 개발자에게는 전례없는 민첩성을 제공했다.
PaaS는 생산성을 향상 시켰지만, 개발자의 선택을 제한 시켰다. 그러나 이런 제약에도 불구하고 인프라를 구축하고 유지해야 했던 기존 단점을 상쇄시키기에 충분 했기에 오랜 기간동안 많은 기업에서 선호했었다.

강점

  • 개발자에게 작업에 대한 오버 헤드가 발생하지 않음, 개발자는 코드만 집중할 수 있고 어플리케이션은 자동으로 배포됨
  • 12 factor 어플리케이션에 적합

단점

  • 기본적으로 Stateless 어플리케이션만 지원
  • 벤더를 기준으로 Resource가 제한 될 수 있음
  • 사용 편의성이 유연성을 희생 시킴
  • 많은 PaaS 제공 업체가 Enterprise에서 진전을 이루지 못한 이유는 제공하는 모델이 제한적이기 때문, 수 Peta byte의 데이터를 가진 수잭 개의 어플리케이션을 관리하는 조직의 경우 동그란 구멍에 정사각형 구멍을 맞추기 위해 비즈니스를 크게 변경하지 않고 모든 것을 관리할 수 있는 팀을 만드는 것이 효율적

CaaS

Container의 출현으로 PaaS를 무용지물로 탈바꿈 시켰다. Container를 사용하면 개발자가 어플리케이션 구성 요소를 쉽게 설명하고 Container 이미지를 작성할 수 있다. 이런 방식으로 구축 된 Container 이미지는 Middleware 또는 가상화 계층없이 모든 시스템에서 원할하게 실행되는데 필요한 모든 기능을 갖추고 있다. 따라서 일반적인 가상화 시스템보다는 효율적이다.
Container와 같은 기술을 사용하면 어플리케이션이 플랫폼에 독립적으로 된다.

강점

  • 복잡한 엔터프라이즈 배포
  • Stateful and Stateless 어플리케이션 모두 이용 가능
  • Orchestration 지원
  • Container를 사용하여 Public Cloud로 Lift & Shift
  • VM 관리 대비 Container는 수백개가 존재해도 관리 할 운영체제는 단 하나

단점

  • 개발자가 어플리케이션을 배포하기 위한 작업을 숙지해야 함 (PaaS와 비교하여 자동화된 DevOps 지원이 부족)

PaaS의 미래

Container는 PaaS를 만들게 된 문제에 대해서 새로운 해결책을 만들었다. Container는 개발자가 PaaS를 사용하여 수행했던 많은 협약에서 자유롭게 해줄 것을 약속한다. 예를 들어서 Container 관리툴을 사용하여 어플리케이션을 배포할때 원하는 언어로 코드를 작성하고 원하는 구성 요소를 사용할 수 있지만, PaaS는 일반적으로 몇 가지 언어와 구성 요소로 제한한다.
Container도 PaaS와 마찬가지로 운영 관점에서 관리가 필요하다. Container 관리 소프트웨어는 Container Deploy, Monitoring 및 관리를 위한 서비스를 제공함으로써 고정적 제약없이 PaaS가 할 수 있는 모든것을 할 수 있다.
현재 PaaS를 사용하고 있는 일부 회사에서는 PaaS를 유지할 수 도 있다. 그러나 Container는 어플리케이션을 간단하고 다양한 프로세스로 제공하기에 많은 회사들이 Container로 전향을 한다.

Why Kubernetes?

Kubernetes는 AWS, Azure, GCP 또는 Private에서의 실행 여부에 관계없이 어디서나 실행할 수 있고, 동일하게 작동한다.
Kubernetes는 PaaS가 아니며 PaaS를 구축하기 위한 기반이고, 커뮤니티에 의해 Kubernetes를 둘러싼 도구 및 애드온이 많이 생기고 있다.

모듈성을 통한 관리 향상

Container를 사용하면 어플리케이션을 명확하게 분리하여 더 작게 분해 할 수 있다. 개별 Container 이미지에 제공되는 추상화 계층을 통해서 분산 어플리케이션을 구축할 수 있다. 이런 모듈식 접근 방식은 의존성을 격리하고 작은 구성 요소를 잘 조율하게 광범위하게 사용할 수 있다.
그러나 이런 부분은 Container 만으로 달성 할 수 없다. 통합하고 조율하는 시스템이 필요하고 Kubernetes는 단일 어플리케이션으로 제어 되는 Container Collection in Pods를 사용하여 지원한다. Container는 파일 시스템, Kernel name space 및 IP주소와 같은 자원을 공유함으로써 너무 많은 기능을 하나의 Container 이미지로 만드는 유혹을 제거한다.

배포 및 업데이트

Kubernetes 배포 컨트롤러는 여러가지 복잡한 관리 작업을 단순화 한다.
  • Scalability: Pod를 수평 확장 방식으로 배포 할 수 있고, 언제든지 확장/축소가 가능하다.
  • Visibility: Status Query기능을 사용하여 프로세스 및 실패한 배포를 식별한다.
  • Time savings: 언제든지 배포를 중지하고 다시 시작할 수 있다.
  • Version control: 최신 버전의 어플리케이션 이미지를 사용하여 배포 된 Pod를 업데이트하고 현재 버전이 안정적이지 않을 경우 이전 배포로 Rollback할 수 있다.
References:

12/04/2018

AWS Outposts

AWS는 지난 수년간 Amazon VPC(Virtual Private Computing), AWS Direct Connect와 Amazon Storage Gateway와 같은 서비스를 제공하여 AWS와 함께 사내 구축형 데이터 센터를 손쉽게 실행할 수 있도록 지원해왔다.

2017년에는 VMware와 공동 작업을 통해 AWS에 VMware Cloud를 도입하여 VMware 가상화 기업의 대다수가 AWS에 쉽게 인프라를 관리 할 수 있도록 VMware 도구도 지원하고 있다.

이런 지원에도 불구하고 고객들은 일부분은 사내 데이터센터에 머물기를 희망하고 있었다. 그리고 AWS는 현재 많은 회사들이 여전히 사내에 머물고 싶어한다는 점을 인정했다.

AWS Outposts는 AWS Computing 기반의 Rack에 Amazon EC2(Amazon Elastic Compute Cloud), Amazon EBS(Amazon Elastic Block Store)와 같은 서비스를 실행 할 수 있도록 제공함으로써 이러한 문제를 해결한다. Amazon Outposts는 두가지 Option을 제공한다.
  • VMware Control Plane과 API를 사용하여 인프라를 구성하고자 하는 고객은 AWS Outposts에서 VMware Cloud를 로컬로 실행 할 수 있다. AWS Outposts의 VMware Cloud Option은 On-Premise에서 실행되고 AWS의 VMware Cloud와 동일한 console에서 서비스를 관리할 수 있다.
  • AWS Cloud에 익숙한 고객은 On-Premise에서 AWS Outpost의 AWS Option을 사용할 수 있다. 즉, On-Premise와 Cloud에서 같은 방식으로 관리할 수 있게 된다.

두 경우 모두 AWS는 고객에게 Rack을 제공하고, 고객이 원하는 경우 설치하고, Rack의 유지 보수 및 교체를 모두 처리하게 된다. AWS Outposts는 고객의 Amazon VPC의 연장이며 고객은 AWS Outposts에서 AWS 또는 기타 AWS 서비스의 나머지 어플리케이션과도 원할하게 연결할 수 있게 된다.

AWS의 경우 고객이 AWS가 사용하고 있는 것과 동일한 하드웨어, 동일한 인터페이스, 동일한 API를 사용하여 On-Premise AWS 환경에서 AWS또는 VMware Cloud로 확장하길 원한다고 언급했고, 최신 AWS 기능을 즉시 사용할 수 있어야 하며 하드웨어나 소프트웨어를 고려하고 싶지 않다고 했다. 그래서 AWS는 Hybrid mode에서 실행될 때 고객이 실제로 원했던 것을 재해석하기 위해 AWS Outposts를 개발했다고 말했다.

Google 그리고 Amazon도 On-Premise 시장에 진출을 시작했다. 이미 시장 저변에 깔려있는 VMware라는 우군과 함께…

이 상황에서 국내 Cloud 사업자들은 어떤 전략을 펼칠 것인지 궁금하다. 가장 무서운 점은 익숙함이라는 무기이다.

AWS Cloud를 사용했던 익숙함을 경험한 고객의 선택은 무엇일까?

12/01/2018

우버의 요금 정책

Uber는 스마트폰 기반 차량공유 플랫폼 서비스를 제공하고 있고 전통적인 택시 시장을 위협하고 있다. 특히 우버는 기존 운송 업체에서 사용하지 않는 Surge Pricing이라는 탄력 요금 전략을 사용하고 있다.

택시의 고질적인 문제점은 송년회 및 회식이 많은 연말이나 특별한 날 소비자의 수요가 많을 때에 택시를 잡기 어렵다는 것이다. 우버는 많은 사람들이 택시를 이용하는 시간대에 가격을 인상하는 정책을 도입했다.

이 전략은 차량 드라이버들에게 단기적인 인센티브 제공 효과가 있기에 많은 사람들이 택시 서비스를 이용하는 시간에 짧게 돈을 벌고 싶어하는 드라이버들을 유도할 수 있다고 봤고 수요가 몰리는 시간에도 많은 운송 서비스를 제공할 수 있다고 생각했다.

하지만 2011년 뉴욕의 새해 맞이 전날 밤 우버가 소비자에게 청구한 요금은 평상시의 8배에 달했고, 우버에 대해 소비자들이 불만을 쏟아내기 시작했다. 이런 비난에도 불구하고 우버는 이런 요금 정책을 포기하지 않고 있다.

경제학자들은 우버의 요금 정책에 동의한다. 수요와 공급이 달라질 때 가격 차별을 통해 균형을 찾으면 소비자들도 효용을 본다. 라는 것이다.

정말 Surge Pricing이 전략이 플랫폼과 소비자에게 도움이 될까? 라는 의문이 생겼다.
아래의 그래프는 드라이버가 반응하는데까지 걸리는 시간이 가격 변화와 어떤 연관이 있는지를 보여 준다.

enter image description here

아래의 그래프는 U st.나 K st.에서 Surge 가격이 더 높을 경우 Navy Yard의 소비자가 픽업을 위해 더 많이 기다려야 한다는 것을 나타낸다. 즉, 가격이 어느 한 지역에서 더 높을 경우 인접한 지역의 드라이버 공급을 감소 시킨다는 것이다.
enter image description here

수요를 맞추기 위한 Surge Pricing 정책이 인접 지역의 드라이브를 감소 시키는 결과가 나타난다. 수요가 몰리는 지역에서의 가격 인상은 드라이버가 다른 지역으로 이동한다는 것을 나타내고 다른 지역은 오히려 공급이 없는 상태가 된다.

결국 공급이 없는 지역 또한 드라이버를 구하기 위해 Surge 가격이 반영되어야 한다는 의미다. 이것이 소비자에게 도움이 되는 것일까? Surge Pricing이 적용되는 지역의 소비자와 드라이버만 이득을 볼 것이다. 소비자는 돈을 더 많이 지불해야겠지만, 돈과 시간의 가치의 중요도는 소비자의 판단이기에…

결국, 플랫폼은 공급자(드라이버), 소비자(승객)를 플랫폼 사업자(우버)가 연결해줌으로써 상호 작용이 되어야 한다. Surge Pricing 정책은 고정 가격보다는 상호간에 이득이 되는 것은 분명하다. 수요가 몰리때에 가격이 오를 수 있지만, 수요가 몰리지 않는 시간대에서는 저렴한 가격으로 이용할 수 있기 때문이다.

플랫폼이 성공적으로 성장하기 위해서는 공급자와 소비자 양측에 끊임없이 높은 가치를 제공해줘야 한다. 그래야 사람들이 지속적으로 모이기 때문이다.

참조: https://www.washingtonpost.com/news/wonk/wp/2015/04/17/how-uber-surge-pricing-really-works/?noredirect=on&utm_term=.c2ad3fc1e4a1

11/28/2018

Istio Envoy에서 OpenTracing 사용 하기

Sidecar Proxy는 코드 삽입없이 모니터링 데이터를 얻는 매우 간단한 방법을 제공한다. Tracing은 대규모 분산 시스템에서 가장 어려운 부분이기 때문에 Sidecar Pattern은 큰 이점으로 작용한다.

Sidecar Proxy에서 Tracing을 하기 위해서는 Inbound에서 Outbound 요청으로 일부 Header를 전달해야 한다. Application단에서는 매우 간단하지만 전달받은 Header를 넘기는 로직을 처리하면 불편 할 수 있다. 비즈니스 레이어에서 Header를 전달하는 것을 조정한다고 상상해보면 Sidecar Pattern을 사용하는 이점이 없을 수 도 있다.

Tracing은 Envoy만 사용

Header 전달이 기존 Application 코드에서는 아래처럼 작성된다.
https://gist.github.com/giljae/7ea7c9ff3b12b65a26cf24ac3f3600f9#file-hellocontroller-java
위의 코드상에서는 특별한 것은 없다. 하지만 코드상에 header 정보를 set하기에 변경이 생기면 리팩토링이 필요할 수 도 있다. 그리고 코드에 header 정보를 set하기에 잊어버릴 가능성도 존재한다.

Envoy and OpenTracing

OpenTracing의 일부 기능을 어플리케이션에 추가 한다. Spring Boot는 classpath에 jar를 추가하는 것만으로도 구현이 가능하다. Auto Configuration은 개발자가 개입하지 않아도 필요한 Tracing Code를 어플리케이션에 추가합니다.

OpenTracing은 Vendor 중립적이기에 Tracing 구현을 제공해야 한다. 이 경우 일반적으로 jaeger-java-client를 사용하게 된다. 끝으로 Tracing Bean을 Instance화하고 구성해야 한다. Envoy는 기본적으로 Jaeger에서 활성화되지 않고 명시적으로 등록되어야 한다.

https://gist.github.com/giljae/aa89f9c7259510932194ef02ed364ea6#file-condiguration-java
Istio, Jaeger 및 어플리케이션을 kubernetes에 배포한다. 배포가 완료되면 /chaining endpoint에 요청을 할 수 있다.

enter image description here

Proxy 범위에 적용되는 Timeout 규칙은 두 가지이다.
첫번째는 Proxy Client의 지속 기간이 원래 지속 기간보다 항상 짧아야 한다.
두번째는 첫번째와 반대이며 Proxy Server 기간이 항상 길어야 한다.

enter image description here

span과 관련된 로그 내에서 어떤 컨트롤러 메소드가 호출되었는지 확인할 수 있다.
Envoy만 Tracing하면 설치가 매우 간단해진다. OpenTracing을 사용하면 이 작업을 자동으로 할 수 있으며 모니터링되는 프로세스에 대한 가시성을 높일 수 있다.

11/26/2018

Servie Mesh 알아 보기

지난 몇년간 Micro Service Architecture는 많이 발전되어 왔습니다. 그리고 현 시점에 몇 가지 새로운 개념과 패턴이 등장하고 있습니다. 이 중 “Service Mesh” 개념은 많은 인기를 얻고 있습니다. 본 글에서는 Service Mesh와 관련된 주요 개념에 대해서 설명합니다.

Service Mesh의 등장 배경

현재까지 대부분의 사람들은 마이크로 서비스가 SOA/ESB와 같은 이전 아키텍처에서 가진 문제점들의 해답이라고 생각합니다. 그러나 실제 마이크로 서비스를 구현할 때, ESB가 지원하는 대부분의 기능들이 마이크로 서비스 수준에서 구현 가능하다는 것을 알 수 있습니다.
enter image description here

ESB to Micro Service
예를 들어서 여러 가지 다운 스트림 서비스를 호출하고 이 기능을 다른 서비스로 노출해야 하는 시나리오가 있습니다. 위의 그림에서 볼 수 있듯이 ESB 아키텍처(왼쪽)를 사용하면 서비스 간 통신 중에 Circuit Breaker, Timeout 및 Service Discovery등과 같은 기능을 구축하기 위해 ESB내에 내장된 기능을 쉽게 활용 할 수 있습니다.

Micro Service를 사용하여 동일한 시나리오는 구현한다고 하면, 중앙 집중 방식의 ESB가 아니라 Code Level에서의 마이크로 서비스가 제공됩니다. 따라서 마이크로 서비스를 하기 위해서는 이러한 모든 기능이 구현되어야 합니다.
enter image description here
마이크로 서비스에서의 커뮤니케이션
위의 그림과 같이 상호간 통신하는 마이크로 서비스는 다음과 같이 구성됩니다.
  • Business Logic, Process 및 서비스 구성
  • Network Functions: OS의 네트워크 스택위에 구축(본 기능을 통해 기본 서비스 호출, 탄력성 및 안정성 패턴 적용, Service Discovery등을 적용)
ESB 대비하여 위의 그림처럼 마이크로 서비스를 구현하기 위해서 필요한 노력을 생각해보면 생각보다 심플하지 않습니다. 비즈니스 로직에 초점을 맞추기보다는 서비스 간 통신 기능을 구현하는 데 많은 시간을 투자해야 합니다. 또한 Polyglot 형태의 여러 프로그래밍 언어를 지원해야 할 경우에는 각 언어별로 노력을 들여야 하기 때문에 다중 기술을 사용하여 마이크로 서비스를 구현하는 것은 쉽지 않습니다.
마이크로 서비스 아키텍처 구현에서 가장 복잡한 부분은 서비스 자체를 구축하는 것이 아니라 서비스 간의 통신입니다.
마이크로 서비스간 커뮤니케이션의 요구 사항은 매우 일반적이기에 이러한 모든 작업을 다른 Layer에서 Offloading 하는 것에 대해서 생각해 볼 수 있습니다. 그래서 “Service Mesh”가 등장했습니다.

Service Mesh란 무엇인가?

Service Mesh는 서비스간 커뮤니케이션 인프라입니다. Service Mesh를 사용하게 되면 아래의 특징을 가질 수 있습니다.
  • 마이크로 서비스는 다른 마이크로 서비스와 직접 통신하지 않습니다.
  • 모든 마이크로 서비스간 통신은 Service Mesh(or Sidecar Pattern)를 통하게 됩니다.
  • Service Mesh는 탄력성, Service Discovery등과 같은 일부 네트워크 기능을 기본적을 지원 합니다.
  • Service Mesh를 이용하면 개발자는 비즈니스 로직에 더 집중 할 수 있으며 네트워크 통신과 관련된 대부분의 작업은 Service Mesh로 Offloading 하게 됩니다.
  • 예를 들어서, 마이크로 서비스가 다른 서비스를 더이상 호출하지 않을 때 Circuit Breaker에 대해 걱정할 필요가 없습니다. 이 또한 Service Mesh의 일부로 제공되고 있습니다.
  • Service Mesh는 프로그래밍 언어에 제약을 받지 않습니다. 마이크로 서비스는 항상 HTTP1.x/2.x, gRPC등과 같은 표준 프로토콜을 사용하기 때문에 이를 기반으로 마이크로 서비스를 작성 할 수 있습니다.
enter image description here
Service Mesh와의 통신 서비스
위의 그림에서 언급된 서비스 상호 작용 및 책임에 대해서 설명합니다.

비즈니스 로직

서비스 구현에 필요한 기능을 의미합니다.

기본 네트워크 기능

대부분의 네트워크 기능을 Service Mesh로 Offloading 할지라도 특정 서비스는 Service Mesh / Sidecar Pattern Proxy와 연결하기 위해 기본적인 네트워크 상호 작용 기능을 포함해야 합니다. 따라서 서비스 구현은 주어진 네트워크 라이브러리(ESB와 다르게 간단한 추상화를 사용)를 사용하여 네트워크 호출을 해야 합니다. (Service Mesh 전용)

어플리케이션 네트워크 기능

Circuit Breaker, Timeout, Service Discovery등과 같이 네트워크에 밀접하게 결합된 어플리케이션 기능이 존재합니다. 초기 마이크로 서비스를 구현할 경우에는 ESB Layer에서 제공되는 네트워크 기능을 무시하고 각 마이크로 서비스 수준에서 모든 기능을 처음부터 구현했습니다. 현 시점에서 분산형 Mesh와 비슷한 공유 기능을 갖는 것이 중요하다는 사실을 깨닫기 시작했습니다. 즉 서비스 코드/비즈니스 로직과 명시적으로 분리된 Service Mesh의 기능을 사용 할 수 있도록 합니다.

Service Mesh 제어 기능

모든 Service Mesh Proxy는 Control Plane에 의해 중앙에서 관리됩니다. Access 제어, Service Discovery등과 같은 Service Mesh 기능을 지원할 때 매우 유용합니다.

Service Mesh 기능

Service Mesh는 어플리케이션 네트워크의 기능을 제공하는 반면 일부 네트워크 기능은 여전히 마이크로 서비스 수준 자체로 구현됩니다. Service Mesh에서 어떤 기능이 제공되어야 하는지에 대한 규칙은 없습니다. 아래는 Service Mesh에서 가장 일반적으로 제공되는 기능입니다.
  • Resiliency for inter communications: Circuit Breaker, Timeouts, Retries, Fail injection, fault handling, load balancing, failover
  • Service Discovery: 전용 Service Registry를 통해 Service Endpoint를 검색
  • Routing: 서비스 비즈니스 기능과 관련된 라우팅 제공
  • Observability: Metrics, monitoring, distributed logging, distributed tracing 제공
  • Security: TLS 제공 및 Key 관리
  • Access Control: Blacklist/Whitelist 기반 Access 제어
  • Deployment: Container 배포 지원
  • Interservice communication protocols: HTTP1.x, HTTP2, gRPC 제공

Servie Mesh 구현체

LinkerdIstio와 같은 오픈소스 구현체가 존재합니다. 여기에서 둘 간의 차이를 확인하세요.

Service Mesh 장단점

장점

  • 마이크로 서비스 코드 외부에서 구현되기에 다양한 프로그래밍 언어도 지원하고 재사용 가능합니다.
  • Ad-hoc 솔루션을 사용한 마이크로 서비스 아키텍처의 대부분의 문제를 해결합니다: Distributed tracing, logging, security, access control등
  • 다양한 프로그래밍 언어 지원: 특정 언어가 네트워크 어플리케이션 기능을 구축 할 수 있을지 또는 라이브러리가 지원되는지에 대해 걱정이 없습니다.

단점

  • 복잡성: Service Mesh를 사용하면 런타임 인스턴스 수가 증가합니다.
  • Extra hop 추가: 각 서비스 호출은 Service Mesh의 Sidecar Proxy를 통해서 호출되어야 합니다.
  • Service Mesh는 서비스 간 통신 문제를 다루지만 복잡한 라우팅, Mediation등의 기능을 제공하진 않습니다.

결론

Service Mesh는 마이크로 서비스 아키텍처의 구현과 관련하여 주요 과제중 일부를 해결 합니다. 그리고 다양한 마이크로 서비스 구현 기술 집합을 선택할 수 있고 서비스 간 네트워크 기능을 지원해주므로써 개발자는 비즈니스 로직에 더 집중 할 수 있습니다.
그러나 Service Mesh는 비즈니스 로직과 관련된 서비스 통합 문제를 해결하지는 못합니다.

References: https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a

11/07/2018

GraphQL로 BFF 대체하기

enter image description here
위의 그림에서 BFF의 목적은 Orchestration, Business Logic을 공유하고 Backend 서비스가 제공하는 것보다 UI에 친화적인 모델을 제공하는 것입니다.

그래서 각 클라이언트별로 BFF가 존재하게 됩니다. Netflix는 Client Adapter라는 이름으로 SoundCloud는 BFF라는 이름으로 UI에 친화적인 Backend 서비스를 제공하고 있는데, 이런 BFF에도 문제점이 존재합니다.
  • 업무 조직간 교차 관리가 어렵습니다.
  • Traffic에 대한 용량 사이징을 예측하기 어렵습니다.
  • 단일 실패 지점이 될 가능성이 존재합니다.
  • 추가적인 아키텍처 복잡성이 발생합니다.
enter image description here
다른 접근 방법은 클라이언트가 서비스를 제공하거나 Backend와 직접 상호 작용을 하는 것입니다.
enter image description here
위의 그림처럼 BFF를 걷어내면 심플해보이는 장점이 있지만, 여전히 BFF와 공통된 문제점이 존재합니다. Application Server는 PC, Mobile의 데이터 요구를 구별해야 하며 각 클라이언트별로 API가 달라질 가능성이 존재합니다.

GraphQL을 써보자

이러한 상호 작용을 깔끔하게 하고 최종 사용자에게 더 나은 서비스를 제공하기 위해서 GraphQL을 사용해 볼 계획을 가지고 있습니다. GraphQL은 API Graph에서 구성 요소를 관리하는 복잡성에 대처할 수 있도록 Facebook에서 개발했습니다.

GraphQL을 사용하면 UI가 데이터와 선언적으로 상호 작용할 수 있으며 서버에서 UI를 분리 할 수 있습니다. UI에서 필요한 데이터를 지정하기에 UI에 친화적인 API를 구축하는 것에 대해 고민할 필요가 없습니다. 또한 GraphQL은 일반적인 AJAX 요청보다 더 쉽게 최적화되기에 Request 개수가 줄어들게 됩니다.
enter image description here
앞으로는 GraphQL이 주류가 될 것입니다. Amazon의 AppSync 혹은 Graphcool같은 서비스가 주류가 되는데에 일조 할 것으로 보여집니다.

11/04/2018

Simple Work., 단순하게 일하기

enter image description here

애플의 스티브 잡스와의 회의는 힘든 여정이었다고 합니다. 회의 가 끝난 후 안좋은 표정으로 회의실을 나서는 직원들에게 무슨일이 있냐고 물어보면 "Simple Stick으로 맞았다."라고 얘기한다고 합니다. 

스티브 잡스는 비효율적인 회의, 프로젝트라고 판단될 경우 바로 중단을 시키거나 없애버렸다고 합니다. 이런 스티브 잡스의 Simple Stick이 오늘의 Apple을 만든 원동력이라고 평가되고 있습니다. 모든 업무를 단순화 하여 "세상을 바꿀 수 있는 제품과 서비스를 만들자"라는 핵심 가치에 다가서기 때문입니다.

아마존의 사명은 "클릭 한번이면 된다."입니다. 사실 클릭이 몇 번 필요하긴 하지만 제프 베조스는 이 문장으로 고객이 얻을 수 있는 가치를 설명하고 있습니다.

이러한 회사들의 사명 혹은 리더들의 스타일은 해당 기업의 조직 문화로 이어지게 됩니다. 조직 문화는 추상적으로 받아들여지기 쉽지만, 추상적이라기 보다는 직원들이 이해하고 달성하기 위해 함께 노력해 나가는 것입니다. 이 문화를 이루기 위해 직원들을 설득 하고 이끌어 나가는 것이 리더의 역할입니다.

스티브 잡스와 제프 베조스같은 리더들은 괴짜처럼 보여지기도 하고 냉혹해보이기도 합니다. 이렇게 보이는 것은 그들이 지닌 가치관에 따라 결정하기 때문입니다.

이 가치관에 벗어나는 그 어떤 것에도 타협하지 않기 때문입니다. 작업 수준이 낮으면 다시 만들어야 하고 속임수를 쓰지 않습니다. 좋은 말로 사람을 현혹하지도 않습니다. 현실을 알고 그 상황을 객관적으로 판단 합니다. 남들의 기분을 생각해서 애매하게 말하지 않습니다. 이들은 좋고 싫고가 명확하고 일관성이 있습니다. 그래서 괴짜, 냉혹한으로 보여지기도 합니다.

그리고 이들은 직접 일을 챙기기 때문에 조직을 단순화 시켜 직접 챙기거나 적임자를 배치합니다. 적임자에게는 책임과 권한을 부여하여 철저히 믿고 일을 맡깁니다. 그리고 업무 프로세스를 최대한 단순화 합니다. 그리고 단순화된 업무 프로세스에서 일할 직원을 채용하는데에 심혈을 기울입니다.

스티브 잡스의 경우 직원을 뽑을 때, 엄청 공을 들인다고 합니다. 그의 평가 기준은 "세상을 변화 시킬 수 있는 사람인가"입니다. 그리고 면접자에게 질문을 한다고 합니다. “당신은 세상을 바꾸기 위해 무엇을 했습니까?” 그동안 해왔던 경력을 얘기하던 우리의 면접과정과는 많은 차이가 있지요.

이렇게 직원들을 뽑아 프로젝트에 투입하고 단순화된 프로세스내에서 업무를 수행합니다.

애플의 경우, 프로젝트의 결과물을 검증하지 않는다고 합니다. 우리는 일반적으로 시장에 제품을 내놓기 전에 무수히 많은 시험을 했는데 말이죠. (물론, 제품의 퀄리티를 위한 품질 관리, 테스트는 하겠지요;;) 결과물을 검증하지 않는다는 말의 의도는 이렇습니다. 할 수 있는 일이 아니기 때문이기 때문입니다. 시장이 검증해야 한다는 의미지요.

이런 단순함이 고객에게도 영향을 미칠까요? 만약 고객에게 많은 선택권을 주면 고객이 좋아 할까요? 좋아하지 않는다고 합니다. 옵션이 많을 수록 잘 결정한 것인지에 대해 의문을 갖게 만든다고 합니다.

그럼에도 많은 기업들은 많은 옵션을 내놓고 있습니다. 시장의 심리를 파악하기가 어렵기에 많은 선택권을 주는 것이지요. 반면 애플은 라인업이 간단합니다.

단순하게 일한다는 것은 일을 대충한다는 의미는 아닙니다. "똑똑한 소수 정예"들을 통해 구체적으로 일한다는 의미입니다. 그리고 조직 문화도 단순하게 세팅이 되어야 하고요.

물론, 단순함을 추구한다는 것은 더 적은 인력을 효율적으로 일한다는 것을 의미하기에 구조조정을 겪기도 합니다. 하지만 맞는 사람들을 적절히 배치한다는 점에서 기업이 성공 확률이 높아진다고 생각됩니다.

당신은 단순한 조직에서 단순하게 일하고 있습니까?

10/30/2018

Netflix Vizceral

Vizceral은 Netflix Control Plain으로 유입되는 트래픽 상태에 대한 정보를 이해하는 방식을 변화 시켰다고 합니다.

Netflix의 경우 전체 시스템의 상태에 기반한 의사결정을 내리기를 원했고 이를 위해서 전체 시스템의 상태에 대해 직관적으로 이해할 수 있는 도구가 필요했습니다.

Netflix의 경우 데이터 구문 분석에 의존하는 대신 직관적인 방법을 적용하기로 했습니다. 장애로 인해 수백만명이 영향을 받는 시간을 최소화 하는 방안을 고려했고 이를 Intuition Engineering이라고 부르며 Vizceral이 그 대표적인 예입니다.

아래의 영상은 지역 간 트래픽 이동시 전체적인 모습을 시뮬레이션한 모습입니다.


Netflix의 트래픽 팀에서는 Intuition Engineering의 중요성을 입증 한 후 다양한 의견을 통해서 사회에 공헌 차원에서 오픈 소스 프로젝트로 유지 관리해야 한다는 결정을 했습니다. 그들이 공개한 소스는 아래와 같습니다.
  • vizceral: 그래프 데이터를 보고 상호 작용할 수 있는 기본 UI 구성 요소
  • vizceral-react: 시각화를 쉽게 할수 있는 Wrapper
  • vizceral-component: 웹 구성 요소를 사용하여 시각화를 돕는 Web Component Wrapper
  • vizceral-example: 예제 프로젝트
이외에 Netflix는 내부적으로 Atlas 및 Salp로 부터 데이터를 수집하는 서비스를 제공하고 있고 이 서비스는 vizceral 구성 요소에 필요한 형식으로 데이터를 변환하고 웹 소켓을 이용해 UI를 업데이트 합니다.

아래는 특정 지역에 대한 세부 트래픽을 보여주는 영상입니다.


특정 지역을 클릭하면 해당 지역에서 운영되는 마이크로 서비스의 확대 보기가 나타납니다. 보기 좋게 하기 위해 노드간 연결을 단일 차선으로 최소화 하였고 황색과 빨간색 점이 서비스간에 오류 응답을 표시합니다.

서비스를 더 자세히 보고 싶으면 노드위에 마우스를 오버하여 입력 및 출력을 표시할 수 있습니다.

enter image description here

노드를 클릭하면 컨텍스트 패널이 보여지며 관련 정보를 입력 할 수 있습니다.

enter image description here

vizceral을 이용하는 방법은 vizceral-example 프로젝트의 지침을 따르는 것이 가장 빠릅니다.

Source: https://medium.com/netflix-techblog/vizceral-open-source-acc0c32113fe

9/17/2018

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

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

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

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

enter image description here


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

위의 그림처럼 Monolithic 데이터베이스를 사용하는 설계는 서비스 변경 사항을 독립적으로 배포 할 수 없도록 상호간의 밀접한 결합 방식을 통해 무능력하게 만듭니다.

동일한 데이터베이스에 엑세스하는 여러 서비스가 있는 경우 모든 서비스간에 스키마 변경 사항을 조정해야 합니다.(어디서 어떤 데이터를 사용하는지 알 수 없기에…) 변경 사항을 적용 할 때 추가 작업에 대한 지연이 발생할 가능성이 큽니다.

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

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

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

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

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

enter image description here

마이크로 서비스의 설계 사상은 도메인 기반이어야 하며 한정된 컨텍스트를 가져야 합니다. 데이터 우선 접근 방식보다 코드 우선 접근 방식을 따라야 합니다. 따라서 가장 먼저 모델을 설계해야 합니다.

이 작업은 새로운 요구 사항이나 프로젝트를 시작할 때 데이터베이스 테이블을 먼저 설계하는 전통적인 사고 방식과는 근본적으로 다른 접근법입니다. 항상 비즈니스 모델의 무결성을 유지하려고 노력해야 합니다.

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

enter image description here

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

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

enter image description here

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

이는 서비스 간의 Loosely Coupled를 제공합니다.
Queue에 대한 메시지를 이벤트로 처리 될 수 있으며 Pub-Sub 모델을 사용할 수 있습니다.

enter image description here

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

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

8/29/2018

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

enter image description here
위의 아키텍처는 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의 주요 구성 요소를 나타낸다.
enter image description here
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로 구성된다.
enter image description here
단일 Client는 여러 서비스 인스턴스를 등록할 수 있다. 가상화된 환경에서 Network stack을 100% 신뢰할 수 없기 때문에 연결의 유효성을 결정하는데에 Heatbeat를 사용한다.

연결이 끊어지면 Write Cluster Registry의 등록 항목이 추출 대기열에 들어가고 궁극적으로 Registry에서 제거된다.

정상 동작인 Client는 연결을 해제하기 위해서는 항상 등록 취소 요청을 보내야 한다. 등록 후에 Client는 인스턴스 데이터를 변경하면서 원하는 수의 업데이트 요청을 전송 할 수 있다.

Registry Discovery

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

enter image description here

Service registry data model

Eureka 2.0은 서로 다른 클라우드 공급자 및 데이터 센터에서 작동하도록 설계되었고 현재 또는 미래의 배치를 수용할 수 있도록 기본 데이터 모델을 확장하도록 설계되었다. 기본 데이터 센터 모델 및 Amazon AWS / VPC 클라우드가 지원된다.
enter image description here
사전 정의 된 서비스 인스턴스 속성 세트는 메타 데이터 맵에 추가 할 수 있는 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

7/19/2018

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

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

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

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

메타데이터는 서비스에서 활용되며, 각 서비스마다 다른 형태로 사용됩니다. 사용자에게 콘텐츠 정보를 제공하는 Front-end 서비스는 이미지에 대한 링크가 필요하지만, 검색 및 추천 서비스는 Tag를 활용하여 사용자에게 추천할 영화를 검색합니다.

Netflix의 경우 이런 메타 데이터 자원들을 효율적으로 제공하기 위해서 VMS(Video Metadata Services) 플랫폼을 구성했습니다.

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

enter image description here

VMS를 구축하면서 해결해야 하는 몇 가지 요구사항이 존재했습니다.
  • 하루 1000억 건이 넘는 요청을 처리 해야 한다.
  • 20–30GB 사이즈의 대용량 데이터 처리, 모든 국가 및 디바이스 대상
  • 높은 복잡성을 지니고 있는 메타 데이터 처리 작업
  • Auto Scaling을 효율적으로 수행
초기에는 클라우드 배포를 아래의 방식으로 접근했습니다.
  • 기존 RDBMS와 상호 작용하는 서버를 구현, 주기적으로 데이터 스냅샷 생성 및 S3에 업로드
  • 특정 서버는 국가별 데이터를 처리하고 데이터 상관 관계를 평가하고 비즈니스 및 필터를 적용한 후 데이터 스냅샷을 생성하도록 구성
  • 클라이언트측의 Object Cache는 관련 스냅샷을 로드하고 메모리 객체에서 데이터를 사용할 수 있도록 지원
Cache는 VMS에서 생성되는 스냅샷을 기반으로 주기적으로 새로 고쳐집니다.

enter image description here

위의 아키텍처는 Netflix가 Global하게 확대되기전까지 매우 효과적이었습니다. 위 아키텍처에서는 서버 인스턴스를 구성하고 국가 또는 글로벌 여부에 관계없이 각 국가별 메타 데이터를 처리해야 했습니다.

예고편 데이터, 자막, 더빙, 언어 번역 및 현지화 그리고 계약 정보와 같은 메타 데이터는 국가에 따라 다르지만 장르, 배우, 감독등의 메타데이터는 같습니다.

처음에는 미국 기준으로 Catalog를 제공하고, 캐나다에 서비스를 하면서 두번째 서버를 추가했지만, 남미를 추가할 때 모든 지역마다 다른 콘텐츠를 제공해야 했습니다.

50개 서버의 운영 오버 헤드외에도 국가별로 데이터 중복이 있기 때문에 클라이언트의 Object Cache Footprint가 증가했습니다. 이런 점 때문에 클라이언트의 로드 시작이 길어지게 되었습니다. (중복 제거 작업을 해야 했기에…) 이러한 측면에서 Netflix는 확장할 수 있는 솔루션을 고민하게 되었습니다.
  • 국가 단위가 아닌 섬(유사한 특성을 가진 국가 컬렉션)을 중심으로 체계화 된 VMS 서버 간소화
  • NetflixGraph를 기반으로 적용된 메모리 최적화 기술로 메타 데이터 처리 및 중복 제거
  • 모든 데이터가 아닌 Application이 원하는 메타 데이터 기반으로 운영
위의 기능을 반영하였고, 아래 노란색으로 표시된 부분이 변경되었습니다.

enter image description here

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

Netflix Metadata Template — 한국어

7/13/2018

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

enter image description here
우리가 흔히 일상에서 접하는 음악의 장르는 보통 아래와 같이 분류한다.
음악에서의 장르란 광범위한 음악들을 형식적으로 카테고리화한 것이다.

음악을 좀 듣는 사람들은 처음 듣는 음악이라도 장르를 구분한다. 음악의 장르를 구분하는 AI 기술도 이미 존재한다. 대체로 음악의 장르 구분 기준은 듣는 사람의 감성과는 무관하다. 그리고 시간이 지남에 따라 음악은 엄청 많아졌다.

역설적으로 나의 감성/상황에 적합한 음악을 찾기가 어려워진것이다. 그래서 감성/상황 기반의 Playlist를 제공하고 있다. 부족한 부분을 보완한 분류체계인것이다.

Spotify, Youtube Music 등의 음악 서비스에서 기본적으로 제공하고 있고, 사용자가 Custom하게 만들고 공유할 수 있다.

이 기능 덕분에 누군가가 공유한 “운동할 때 듣는 음악", “여행 갈때 듣는 음악", “슬플때 듣는 음악"등등의 플레이리스트를 잘 활용하고 있다. 특정 사용자가 큐레이터가 되는 것이다.

enter image description here

이제 영화를 살펴보자. 영화 장르는 보통 아래와 같이 분류한다.
영화에서의 장르 역시 광범위한 영화들을 형식적으로 카테고리화한 것이다.

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

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

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

2014년에 소개한 Playlist 기능

저것만 가지고 부족하다고 생각한 것일까? 2016년에 Flixtape 서비스를 런칭한다.

flixtape 소개 동영상

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

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

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

Netflix Artwork의 개인화

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

Netflix 추천 시스템의 주요 목표는 사용자에게 맞는 콘텐츠를 추천하는 것이었습니다. 사용자가 콘텐츠에 흥미를 가지고 해당 콘텐츠가 가치가 있는지를 확인하는 방법이 무엇일지 많은 고민을 했습니다.

콘텐츠의 포스터가 관문 역할을 하며 사용자에게 콘텐츠에 대한 매력을 어필할 수 있다고 판단했습니다.

enter image description here

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

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

enter image description here

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

enter image description here

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

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

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

포스터를 개인별로 제공하기 위해서는 엔지니어링 관점에서 Challenge가 필요합니다. 사용자의 시각적 경험을 위해 많은 이미지를 포함한다는 점입니다.

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

Netflix의 추천엔진 대부분은 기계학습에 의해 동작됩니다. 사용자의 서비스 사용에 대한 데이터를 수집하고 그 데이터를 기반으로 알고리즘을 실행합니다.
그리고 A/B 테스트를 통해 새로운 알고리즘을 테스트 합니다. A/B 테스트는 새로운 알고리즘이 무작위로 구성된 사용자를 대상으로 진행하며, 현재 프로덕션 시스템보다 우수한지를 확인합니다.

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

enter image description here
enter image description here

Netflix는 이 실패를 해결하기 위해 Batch성 기계학습에서 벗어나 실시간 기계학습을 고려했습니다. Netflix가 사용하는 학습 알고리즘은 Contextual bandits입니다. (참조: https://medium.com/netflix-techblog/artwork-personalization-c589f074ad76)
이러한 접근 방식을 통해 Netflix는 사용자가 새로운 콘텐츠를 선택하는 방법에 대해 의미있는 개선을 했습니다. 대단합니다.

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

enter image description here

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

7/09/2018

Robot이 불러오는 변화들

enter image description here

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

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

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

enter link description here

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

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

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

첫째, “급변하는 트렌드에 발빠른 대응”
다른 신발 공장처럼 같은 소재, 디자인의 신발을 계속 만드는 것이 아니라 고객의 주문을 넣으면 원단 직조에서 마감까지 로봇이 처리하고 스타일, 깔창, 소재, 색깔 및 신발끈까지 고객의 요구 사항 그대로 맞춤형으로 생산된다.

둘째, “저임금 근로자에 대한 의존도 축소"
스피드 팩토리의 연간 생산량은 약 50만 켤레이다. 여기에 투입된 인력은 약 10명이다. 로봇없이 사람으로 50만 켤레를 생산하려면 약 600명의 근로자가 필요했다.

셋째, “재고 감소"
스피드 팩토리는 고객이 제품을 주문하면 생산하는 개념이다. 재고 관리에 대한 부담이 적어진다.

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

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

7/08/2018

GraphQL과 RESTful

enter image description here

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 APIv4의 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 구조를 원하는 방식으로 변경할 수 있습니다.
이 둘간의 차이점을 보여주는 그림입니다.

enter image description here

GraphQL을 사용하게되면 아래의 장점을 지니게 됩니다.
  • HTTP 요청 횟수를 줄일 수 있기 때문에, Network Latency가 감소됩니다.
  • HTTP 응답 Size가 줄게 됩니다.

결론

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

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