[Youtube] 넷플릭스 마이크로 서비스 가이드 1,2
유투브 출처 : 넷플릭스 마이크로 서비스 가이드 - 혼돈의 제왕
강의 순서
1. Introductions 00:00 - 5:38
2. Microservice Basics 05:39 - 13:18
3. Challenges & Solutions 13:19 ~ 43:33
1) Dependency 13:19 ~ 25: 02
2) Scale 25:03 ~ 33:33
3) Varience 33:34 ~ 43:33
4) Chagne 43:33~ 45:45
4. Organization & Architecture 45:46 - 53:13
1. Introduction
넷플릭스 개요
인터넷 TV 서비스, 할리우드나 인디 또는 지역의 컨텐츠를 계약해서 공급
직접 만드는 오리지널 컨텐츠의 양도 굉장히 많아지고 있다.
오늘날 약 8600만명의 가입자, 전세계 사용자 숫자, 빠르게증가
190여개 국가에서 서비스 중이며
10개 이상의 언어로 제공되는 사용자 인터페이스, 그리고 자막이 서비스로 제공
1000여개에 이르는 장치에서 작동
그리고 모든 마이크로 서비스들은 AWS위에서 동작
2. Microservice Basics
1. 어떤게 마이크로 서비스가 아닌가?
2000년도 즈음에 넷플리스가 웹 기반의 DVD 사업을 하던 시절 사용자들은 큐에 원하는 DVD를 넣고, 우체통을 통해 주고 받을때이다.
구성도 설명
- 하드위에 기반의 로드 밸런서
- 고가의 하드웨어를 사용한 리눅스 서버들
- 이 서버에는 아파치 톰캣이나 리버스 프락시 같은 것들을 사용한 일반적 구성
- 여기에 한개의 자바 어플리케이션
- 고객이 접속해서 하는 모든 것들을 제공하는 자바 애플리케이션
- 이 자바 어플리케이션은 JDBC로 오라클 데이터 베이스에 직접 연결 되어 있고
- 그리고 데이터 베이스 링크로 다른 오라클 데이터 베이스와 연결되어 있다.
이 구조의 첫번째 문제는 바로 자바 어플리케이션 코드 베이스가 "모놀리틱"인 것이다. 매주 반복적으로 배포되는 애플리케이션의 코드 베이스에 모든 사람들이 한꺼번에 붙어서 작업을 해야했다. 이런 구조는 변경이 발생 할때마다 문제를 일으켰고 문제가 발생하면 분석이 엄청 어려웠다. 천천히 증가하는 메모리 누수를 찾는데 일주일 걸린적도 있었다. 문제를 찾기위해 코드를 변경하고, 다시 구동하고 분석을 시도하고, 다시 변경하는 과정에서 하나의 애플리케이션에 너무 많은 변경이 발생했기 때문에 분석에 필요한 시간이 점점 늘어났다.
데이터 베이스의 경우에는 더 심각한 모놀리틱 상태였다. 이건 거대한 하드웨어에서 동작하는 거대한 하나의 오라클 데이터베이스 였는데, '스토어 데이터베이스'라고 불렀다. 이게 다운되면 서비스 전체가 다운이었다. 그리고 매년 휴가철 피크 트래픽이 예상되는 시기가 돌아오면 부하로 인한 문제를 방지하기 위해 항상 더 좋은 하드웨어를 찾아 다녔다.
엔지니어링 측면에서 가장 심각한 문제는 모든게 서로 너무 깊게 연결되어 있기때문에 변경에 속도가 나지 않는다는 것이었다. 데이터베이스에 직접 연결하고, 테이블 스키마에 깊은 의존성을 가지는 어플리케이션들은 테이블에 컬럼을 추가하는 간단한 변경 요구가 여러개의 팀이 협업해야하는 프로젝트 규모가 되었다. 이런 모델이 오늘날 만들면 안되는 서비스의 전형적인 모습이다. 하지만 이런 모델은 90년대 초반부터 2000년대 초반까지 매우 일반적인 것이었다.
2. 그럼 마이크로 서비스는 무엇일까?
마이크로 서비스 아키텍쳐 스타일은 작은 서비스의 집합으로 하나의 어플리케이션을 구하는 것이며 각각의 작은 서비스들 자신만의 독립적인 프로세스를 가지고 있고 가벼운 구조를 가지는데, HTTP 기반의 API를 사용해 서로 연동한다.
위의 정의에 대해서는 아마 대부분 알고 있고, 또 기술적으로 맞는 이야기지만, 잘 와닿지는 않는다. 제 개인적인 느낌의 마이크로 서비스는 이전 2000년대 사용했던 모놀리틱 문제의 해결이 아닐까 합니다. 위험을 잘게 쪼개어 내는 것이 아마도 마이크로 서비스 전환의 가장 큰 부분이자 동기이며 모듈화 하고, 서비스에 필요한 데이터를 캡슐화 함으로써 전체 서비스를 덩어리로 고려하지 않아도 된다. 수평적 확장을 고려하고 있다면 아마도 올바른 접근일 것이다. 거대한 워크로드를 거대한 시스템이 아니라 여러개의 작은 부분으로 분리해서 처리하는 분산의 개념이 필요하다.
이런 마이크로 서비스가 잘 구현되려면 가상화 환경이 필요하다. 만약 이런 가상화된 환경이 없었다면, 마이크로 서비스를 운영하는 것은 아주 힘든일이 되었을것이다. 운영에 필요한 것들은 가능하면 최대한 자동화 해야하며 필요에 따라 리소르를 만들고 제거가 가능한건 마이크로 서비르를 구현할 때 매우 큰 장점이다.
# 넷플릭스 아키텍쳐
ELB 뒤에는 동적인 라우팅을 수행하는 Zuul로 구성된 프락시 계층이 있다. 또한 NCCP라 불리는 레거시 계층이 있는데, 이는 오래된 옛날 장치를 지원하고, 기본적인 영화 재싱 기능을 제공한다. 그리고 넷플릭스 API가 API 게이트웨어를 통해 제공 되는데 현재 넷플릭스 아키텍쳐의 핵심중의 하나로서 고객이 발생시키는 요청에 대한 응답을 처리하기 위해 다른 많은 서비스를 통신한다. 왼쪽 네모 박스 안의 서비스들은 '엣지' 서비스르 부르며, 여기에 도식화 되지 않으 DRM 같은 서비스도 엣지 서비스군에 속한다. 오른쪽에는 각종 기능을 하는 서비스들이 미들티어와 플랫폼이 합쳐진 형태로 구성되어 있다. 여기 속한 것들이 어떤 서비스들이 있는지 이해를 돕기 위해 좀더 깊이 살펴보자.
여기엔 A/B 테스트 인프라가 있고, 유입된 고객이 할당될 테스트용 A, B 서비스가 동작한다. 서브스크립션 서비스는 넷플릭스 고객에 대한 거의 모든 정보를 가지고 있는 서비스이다. 추천 시스템은 각 고객에게 맞는 적절한 영화를 제안하기 위한 기능을 수행하고 플랫폼 서비스들은 보다 기초적인 기능을 제공하기위해 존재한다. 라우팅 서비스는 마이크로 서비스들이 서로를 찾아 연결하는데 도움을 주고, 동적으로 설정 변경을 지원하는 서비스, 암호화 관련 서비스, 그리고 데이터를 영구 보존하기 위한 서비스들이 있다. 이것들은 애플리케이션의 오브젝트들처럼 전체 시스템의일부로 동작한다.
또한 마이크로 서비스 역시 일종의 추상화이다. 일반적으로 우린 마이크로 서비스를 매우 단순하게 이해하려는 경향이 있다. 수평적으로 잘 확장되는 마이크로 서비스들이 있으니 별 문제 없이 호출해서 접근 가능하겠지라고 말이다.
간단한 것 같지만 실제로는 절대 이렇게 간단하지 않다. 언젠가는 데이터베이스가 필요하다. 예를 들면 가입자에 대한 정보가 필요하거나 추천 정보와 같은 것들이 있다. 그런데 데이터는 대부분 '영구 보존 계층'에 위치한다. 이런 편의를 우선시하는 방법은 넷플릭스가 좋아하는 접근이다. 넷플릭스에서 정말 많이 사용된 방법인데 자바 기반의 클라이언트 라이브러리를 제공하고 이런 자바 라이브러리는 데이터 접근을 포함한 자주 사용되는 작업을 위해 만들어 사용했다.
그리고 어떤 시점에 분명 캐시가 필요한 순간이 있다. 왜냐하면 서비스와 데이터 베이스만으로는 성능이 충분하지 않기 때문이다. 그래서 캐시 접근을 위한 클라이언트도 필요하게 된다. 이제 우린 클라이언트 라이브러리간의 조율에 대해 고려해야한다. 캐시를 살펴보고 만약 데이터가 거기 없다면 서비스는 다시 데이터베이스를 호출한다. 요청에 대한 응답을 처리하고 나면 다음번의 동일한 요청을 더 빨리 처리하기 위해 캐시에 저장한다. 이렇게 구성된 클라이언트 라이브러리는 각각의 마이크로 서비스에 포함된다. 이 클라이언트 라이브러리 관점에서 살펴보다면 지금 설명한 전체의 복잡한 기술과 설정의 조합이 바로 마이크로 서비스이다. 이것이 'Statless' 같이 이론적으로 간단한 무엇이 아니라 실제로는 꽤나 복잡한 구조를 가지고 있는 구현이다.
관련글 모아보기