MSA(마이크로 서비스 아키텍처)에 대해서 생각해보기

 

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

아래는 가상 비디오 공유 플랫폼이 Monolithic 형태로 구현 된 후에 마이크로 서비스 형태로 구현되는 방식이다.

위의 시스템의 차이점은 하나의 큰 덩어리와 작은 단위라는 점이다.

• 독립 개발: 작고 독립적인 구성 요소는 그에 맞춰진 작고 독립적인 팀으로 구성할 수 있다.
• 독립 배포: 각 구성 요소는 독립적으로 확장 할 수 있다. 새로운 서비스가 출시 되면 모든 구성 요소를 배포하지 않고 해당 구성 요소만 배포가 가능하다.
• 재사용성: 구성 요소들은 작고 특정한 기능을 수행한다. 다른 서비스 또는 제품에 쉽게 적용할 가능성이 높다.

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

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

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

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

개발자의 복잡성 증가

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

운영자의 복잡성 증가

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

Devops 복잡성 증가

문제는 많은 조직이 여전히 분리된 개발 및 운영팀으로 운영되고 있다는 사실이다. 이런 조직은 마이크로 서비스 채택에 어려움을 겪을 가능성이 훨씬 높다는 것이다.

이런 단점을 극복하고자 Devops를 채택한 조직도 어렵긴 마찬가지다. 컨테이너 오케스트레이션 시스템 관점에서 진화하는 시스템을 이해하는 것은 매우 어렵다. 개발자와 운영자가 좋은 소프트웨어를 만드는 마음이 강하더라도 말이다.

전문 지식이 필요

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

이런 Skill set은 현재 시장에서 수요가 많기 때문에 찾기가 어려울 수 있다.

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

마이크로 서비스의 이점을 설명하기 위해 사용한 많은 자료에는 독립 구성 요소에 대한 이야기가 많다. 하지만 대부분의 경우 구성 요소들은 단순히 독립적이지 않다.

경계가 잘 정의되어 있지 않으면, 이론적인 관점에서 서비스를 독립적으로 배포 할 수 있다고 해도 서비스간의 상호 종속성으로 인해 결국 서비스 집합을 하나의 그룹에 배포해야 하는 상황이 발생한다.

즉, 새 기능을 배포하려면 여러 서비스를 동시에 배포해야 하기 때문에 실제로는 독립적으로 배포할 수 있는 시스템은 거의 없다.

의사 소통의 복잡성

서로에 의존하는 대규모 서비스를 구축할때에는 많은 서비스간 의사 소통이 발생 할 수 있다. 그리고 이로 인해서 몇 가지 문제가 발생한다.

첫째, 네트워크 호출이 실패 할 것을 예상해야 한다. 즉, 하나의 서비스가 다른 서비스를 호출 할때 최소한 여러번은 재시도를 해야하는 것을 의미한다. 이제는 서비스가 잠재적으로 많은 서비스를 호출해야 하기에 복잡한 상황에 처하게 된다.

사용자가 비디오 공유 서비스에서 비디오를 업로드한다고 가정하자. 업로드 서비슬르 실행하고, 데이터를 Transcode 서비스에 전달하고, Subscription을 업데이트하고, 권장 사항을 업데이트해야 할 수 있다. 이 모든 호출에는 일종의 Orchestration이 필요하다.

해당 작업이 실패하면 다시 시도해야 한다.

위의 재시도 논리는 관리하기가 어려울 수 있다. 동기적으로 일을 시도하는 것은 종종 끝나지 않고 많은 실패 지점이 존재하기 때문이다. 이 경우에 보다 안정적인 솔루션은 비동기 통신을 사용하여 통신을 처리하는 것이다. 비동기 패턴은 본질적으로 시스템을 stateful 상태로 만든다. 분산 처리에서 Stateful 시스템을 만드는 것은 어렵다.

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

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

분산 트랜잭션

트랜잭션 무결성이 필요한 상황에서 마이크로 서비스는 매우 고통스러울 수 있다.

분산 상태는 매우 다루기가 어렵기에 이 문제를 해결하기 위해서는 마이크로 서비스 모델에서 구현하는데 드는 비용이 매우 클 수 있다.

네트워킹 악몽

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

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

마이크로 서비스는 구성 요소의 또 다른 패턴 또는 구현일 뿐이며 그 이상은 아니다. 마이크로 서비스가 시스템에 존재한다고 해서 시스템의 아키텍처가 해결되었다는 것을 의미하지 않는다.

마이크로 서비스는 시스템 고유의 설계가 아니라 패키징 및 운영과 관련된 기술 프로세스와 관련이 있다. 구성 요소에 대한 적절한 경계는 시스템에서 가장 중요한 과제 중 하나이다.

Docker 컨테이너 여부 및 서비스 크기에 관계없이 항상 시스템을 함께 배치하는 방법에 대해 신중하게 생각해야 한다. 이에 대한 정답은 없으며 어려운 점을 해결하기 위한 많은 옵션은 존재한다.

Read More

Netflix 미디어 데이터베이스

Netflix의 목표는 전 세계 수백만 회원의 재생 시작 시간을 최소화하는 것이다. 이를 위해서 ISO BMFF의 Header 크기에 대한 통계량(최소값, 최대값, 중간값, 평균값등)을 수집해야 한다.

Netflix의 Transcoding Pipeline은 방대한 콘텐츠 카탈로그를 서비스하며 모든 콘텐츠에 대해 다양한 코덱+품질 조합을 생성한다.

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

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

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

의미있는 개인화 및 효율적인 스트리밍은 최종 사용자가 서비스를 정의하는 주요 요소이다.

이러한 경험을 제공하기 위해서는 복잡한 비즈니스 워크 플로우가 필요하다.

위 그림처럼 아트워크상의 이미지 및 타이틀은 사용자가 관련 영화를 찾는데 도움이 된다. Netflix에서는 콘텐츠를 처리하는 단계에서 디지털 상품 Asset을 합성하는데 도움이되는 시스템을 개발해야 하는 상황이 있었다. 예를 들어서 소스 비디오 Asset에서 자동으로 추출 된 의미 있는 원시적인 이미지 및 비디오 클립을 제공하는 부분이다. 이는 콘텐츠에서 매력적인 디지털 미디어 자산을 창출하는 출발점이 될 수 있다고 생각했다. 이런 기능을 제공하게되면 사용자가 관련 프로그램 및 영화를 찾는데 큰 도움이 될 수 있다.

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

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

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

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

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

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

미디어 데이터베이스는 다양한 형식의 미디어에 대한 분석 데이터가 들어있다. 여기에는 오디오, 비디오, 이미지 및 텍스트가 포함된다. 미디어 타임라인에서 임의의 쿼리를 처리할 때 사용된다. 예를 들어서 오디오 트랙의 타임라인에서 음악이 포함된 부분에 대한 시간 간격 또는 텍스트가 포함된 비디오의 비디오 프레임 목록 또는 자막 파일의 시간 간격 집합이 그것이다. 다음과 같은 사항이 미디어 데이터베이스의 중요한 특징이다.

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

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

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

References

• https://medium.com/netflix-techblog/the-netflix-media-database-nmdb-9bf8e6d0944d

Read More

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로 전환하였다. 

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

• https://medium.com/netflix-techblog/netflix-oss-and-spring-boot-coming-full-circle-4855947713a0

Read More

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

 

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

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

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

고객 및 이해 관계자를 행복하게 만드는 것은 중요한 행동이며 더 좋은 비즈니스 결과로 이어지게 됩니다. MSA(Microservice Architecture)는 즉각적인 영향을 줍니다. 마이크로서비스 구현시 ROI를 측정하는 가장 좋은 방법은 아래의 매개 변수를 고려해야 합니다.

1. 다국어 기술 환경 수용
2. 신속한 애자일 환경 제공 — 최단 시간내에 가장 빨리 기능을 전달
3. 빠르게 운영환경으로의 이동
4. 응용 어플리케이션의 크기 조정 — Heavy한 어플리케이션은 많은 양의 자원을 사용합니다.
5. 제품/기능/서비스가 복잡하거나 얽혀 있는 경우
6. Resilience/Fault Tolerance가 중요한지

마이크로서비스 아키텍처의 특징은 민첩한 방식의 지속적인 Deploy입니다.제품/서비스가 고객에게 다가 갈수록 피드백을 빨리 받을 수 있기 때문입니다.

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

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

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

Read More

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

 

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

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

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

계모임을 한다고 생각해보자. 계모임의 경우에는 돈을 관리하는 계주나 계원이 잠적하면 문제가 생긴다. 종종 뉴스에서 이런 사례가 보인다. 계모임은 인간관계를 바탕으로 신뢰를 얻기 때문이다. 여기서 논제를 약간 틀어서 계모임을 하는데 각자 입금하는 금액이 상이하다고 가정해보자. 그리고 입금한 금액은 장부에 기록한다고 치자. 그런데 장부를 기록하는 과정에서나 실제 기록한 이후에 다르게 바뀔 수 가 있다. 장부 관리자가 특정 계원과 기록을 허위로 작성하거나 기록된 내용을 변조할 수 있는 가능성이 있기 때문이다.

여기에 블록체인 기술을 적용해보자.

각자의 내역을 쪽지에 적어 나머지 사람에게 전달하고 나머지 사람은 자기 기록을 포함해 각각 다른 사람의 내용을 기록한 쪽지를 갖게 된다. 이 내용을 근거로 1장의 장부를 각각 만든다. 그리고 참여하는 사람이 합계를 각각 산출한다. 이 과정에서 가장 먼저 합계를 산출한 사람이 손을 들고 사본을 만들어 나머지 사람들에게 배포한다. 사본을 전달 받은 사람들은 합계가 맞는지 일치하는지 점검하고 이상이 없다면 보관한다. 만약 내용이 틀리면 잘못되었음을 알리고 다른 누구가 정확한 자료를 만들때까지 작업을 계속한다.

위의 방식으로 처리하기 때문에 기술적 특성에서 생긴 처리 속도의 제한적 문제가 발생한다. 모든 참여자가 데이터를 기록하고 관리하는 방식의 한계이기도 하다. 이를 해결하는 방안을 “Consensus 알고리즘”이라고 한다. 속도 문제를 해결하기 위해 여러가지 다양한 Consensus 알고리즘이 나타났고., 최초의 블록체인이 추구하던 개념과는 거리가 먼 알고리즘도 생겨났다. 블록체인은 개방형과 폐쇄형으로 나뉘게 된다. 개방형은 요건을 갖추면 누구나 참여할 수 있고, 폐쇄형은 특정 조건의 참가자만 참여가 가능하다.

초반에는 블록체인이 기존 비즈니스에 혁신을 가져다 줄 것이라는 기대가 많았다. 특히 중개 거래상에서 투명성을 제공하고 거래 비용을 낮춰줄꺼라는 기대가 많았다. 하지만 현실은 녹녹치 않은 상황이다. 이미 중앙화된 시스템에서 신뢰가 확보된 분야에서는 블록체인으로 인해 투명성과 신뢰도를 제공한다고 해서 기존 대비 큰 가치를 제공하지 못한다면 굳이 도입할 이유가 없다. 이미 잘 운영되고 있는 분야에 적용하는 것은 어렵지 않을까?

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

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

Read More

[독서] 지지 않는다는 말

 

다이어리 정리를 하다가 얼마전 읽은 지지 않는다는 말에 나온 글귀를 적은 페이지를 발견하고 여기에 옮겨 적는다.

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

Read More

GraphQL 채택 후 Netflix가 배운 것들

Netflix에서는 콘텐츠 인기도 파악과 같은 다양한 데이터 및 집계 데이터를 활용하여 관련성이 높은 광고를 제공한다. Netflix의 목표는 모든 외부 채널에 대해 광고가 사용자와 잘 어우러지게 만드는 것이다. Netflix는 보다 효율적으로 하기 위해 끊임없는 실험을 하고 있다.

Monet의 React UI는 Apache Tomcat에 의해 구동되고 REST API에 Access를 했다. 시간이 지나고 어플리케이션이 발전함에 따라서 사용 사례가 복잡해지기 시작했다. Simple page는 다양한 소스의 데이터를 가져와야 한다. 이 데이터를 클라이언트에서 효과적으로 로드하기 위해서 Backend 데이터를 비정규화 하는 노력을 시도했다. 그 이유는 모든 페이지가 모든 데이터를 필요로 하지 않기 때문에 유지하기가 어려워지기 때문이다. Network 병목 현상에 발생했다.

Backend에서 클라이언트에게 보내는 field의 수를 줄이는 방법은 모든 페이지에 대해서 endpoint를 만드는 것이었지만, 효율적이지 못했다. 대신 GraphQL을 Middleware로 선택했다. 이미 개발되어 사용중이던 Falcor도 훌륭한 솔루션이었지만 GraphQL의 Eco시스템을 이용하기 위해 Falcor가 아닌 GraphQL을 사용했다. 데이터 구조가 점차 그래프 지향적으로 변경됨에 따라 Network 병목도 해결했고, 기능을 더 빨리 추가 할 수 있게 되었다.

장점

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를 수용할 수 있게 된다.

Chaining Type Systems

GraphQL에서 Entitiy를 정의하고 나면 자동 코드 Generater 도구를 사용하여 Client 어플리케이션의 TypeScript 유형을 생성한다. 이러한 유형과 Query는 서버 Schema에 대해서도 유효성이 검사 되기에 서버에서 발생한 모든 변경 사항은 데이터를 사용하는 Client가 알게 된다. GraphQL과 함께 여러 서비스를 묶고 이러한 검사를 Build Process에 연결하면 잘못된 코드를 배포하기 전에 더 많은 문제를 파악할 수 있다.

개발 단순화

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 프로세스를 최적하는 방법에 대해 고민하지 않고도 필요한 모든 데이터를 요청 할 수 있다.

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

Read More