[Youtube] 넷플릭스 마이크로 서비스 가이드 4

유투브 출처 :  넷플릭스 마이크로 서비스 가이드 - 혼돈의 제왕

강의 순서
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 46:46~53:13

 

---

 

4. Organization & Architecture

 

 아주 오래전에 "일레트로닉 딜리버리"라 불리는 팀이 있었다. "스트리밍"이라는 단어가 없을때 스트리밍을 했던 서비스 이름이다. 실제로는 하드 드라이브와 같은 장치로 다운로드를 제공하는 것이다.

일렉트로닉 딜리버리 아키텍쳐

초기 고객 장치에서 동작하는 넷플릭스는 이런 모양이었다. 네트워킹과 같은 기본 기능을 포함하고 보안과 등록, 재생을 하는 기능, 그리고 사용자 인터페이스로 구성되었다. 사용자 인터페이스는 당시에 아주 간단했다. 웹 사이트에서 원하는 영화를 선택하면 "큐 리더" 라는 도구에 등로고디고, 장치를 켜면 영화가 재생되는 방식이었다. 이런 기능을 하나의 조직에서 개발할때는 잘 동작했다. "일렉트로닉 딜러버리"라고 불리는 기능은 서버와 클라이언트 모두 하나의 조직에서 일했기 때문에 매우 긴밀하게 협조하면서 업무를 수행 했었다. 시스템의 디자인은 XML 기반이었고, XML안에 독자적으로 만들어진 응답을 제공했으며, 펌웨어를 버전별로 릴리즈 했는데, 배포 주기가 꽤 길었다. 

 

 

이후에는 넷플릭스 API가 개발되었는데, DVD 사업과 관련된 외부 애플리케이션이 더 많이 더 쉽게 접근하도록 하기 위한 것이었다. 이부분에서 큰 성공을 거두었으면 하는 마음으로 "1000개의 꽃이 만발하게 하자!"라고 외쳤다. 넷플릭스에 엄청난 가치를 주지는 못했기 때문에 사실 그다지 성공하지는 못했지만, 당시 만든 넷플릭스 API는 넷플릭스 UI를 혁신하는 촉매가 되었다. 이 넷플릭스 API라는 것은 컨텐츠에 대한 메타데이터를 제공하거나 서비스되고 있는 영화의 리스트를 생성하거나 하는 기능을 일반화된 REST API, JSON 스키마, HTTP 응답 코드 기반, 여기서 이야기 하는 것들은 대부분 현대의 아키텍쳐들이죠? 그리고 외부 인증을 지원하기 위한 OAuth 보안 모델이 제공 되었다.

 

 

근데 클라이언트 장치 측면에서 발생했던 문제는 넷플릭스가 API가 생겨남으로 인해 지원해야 할 포인트가 늘어났다는 점이다. 2개의 완전히 다른 형태로 구성된 엣지 서비스가 생겼고, 하나는 REST, JSON OAuth, 다른 하나는 RPC, XML, 그리고 토큰 지원을 위한 커스텀 보안 모델의 서비스 였다. 그리고 이 두개 서비스 사이에는 방화벽이 있었는데, 새로운 API 서비스는 기존의 NCCP보다 당시 빈번하 장애로 API 서비스로 인해 발생한 문제가 NCCP팀에 연락이 가는등의 문제로 서비스를 운용하는데 조직간의 마찰이 발생했다. 이 두개의 완전히 다른 서비스, 프로토콜, 스키마, 보안 모델은 다양한 이유로 클라이언트 입장에서 두개 모두를 완벽히 지원해야 할 필요가 있었다. 몇가지 기능 때문에 두가지 서비스 모두 필요했는데, 예를 들면 영화의 리스트에 재생시간을 제한하는 라이센스를 포함해서 사용자 인터페이스로 전달하고 그래서 리스트된 영화중 하나를 클릭하면 DRM을 호출하고, 즉시 재생이 되어야 했기 때문이다. 

 

두개로 나누어졌기 때문에 발생한 문제를 해결하기 위해 당시 넷플릭스에 근무하던 시니어 엔지니어에게 질문을 했다. "장기적 관점에서 어떤게 올바른 아키텍쳐일까? "라고 물었을때, 대답은 "조직간의 문제도 함께 고려고 있나요?"라고 되물었다. 만약 두서비스를 합치거나 두 서비스를 쪼개면 조직에 무슨일 생길까요?사실 이건 "콘웨이의 법칙"과 매우 깊은 관련이 있다. "시스템은 시스템을 디자인하는 조직의 커뮤니케이션 구조를 반영 한다." 아주 추상적이다. "소프트웨어는 그걸 만든 조직의 구조를 닮는다.", "컴파일러는 만드는 조직이 4개면 4개의 단계를 가지는 컴파일러가 만들어진다" 는 의미이다. 결과적으로 우리는 "블레이드 러너"라고 불리는 아키텍쳐를 적용했다. 왜냐하면 우리는 지금 "엣지" 서비스를 살펴보는 중이기 때문이다. NCCP의 기능은 결국 분리되어 Zuul 프락시 또는 API 게이트웨이, 그리고 다른 세분화된 아주 작은 새로운 마이크로 서비스들로 분화 되었는데, 이들은 기본적인 보안 기능, 재생을 위주로한 기능, 지원, 자막, 메타데이터 제공등의 역할을 한다. 

 

결국 우리가 배운것은 두개의 서비스를 통합하는 방법은 넷플릭스에게 장기적으로 높은 수준의 성능과 개선 속도를 제공함으로써 더 강력한 클라이언트 개발에 집중할 수 있었기 때문이다. 제가 관리하는 모든 조직을 결국 넷플릭스 API팀으로 병합하는 방식으로 조직의 리팩토링을 했고, 그 후에 다시 오퍼레이션 엔지니어링으로 옮겼다. 이건 사업을 위한 올바른 행동이었다. 배운 것은 해법을 찾고 팀은 그다음이다. 그리고 조직의 변화를 두려워 하면 안된다는 것이다. 

 

 

강의를 마치며

 

마이크로 서비스 아키텍쳐는 인간의 장기와 마찬가지로 복잡하다. 그리고 서비스는 지속적으로, 그리고 정기적으로 카오스 상태를 테스트함으로서 더 강력해 질 수 있다.

 

 

의존성에 있어서 서킷 브레이커와 fallback ,그리고 카오스 적용을 고려해라. 클라이언트를 단순화 하고, 최종 일관성을 적용하라. 멀티 리전 복구 전략을 고려하라.

확장에 있어선 오토 스케일링을 꼭 써라. 간단하지만 큰 장점이 있다. 단일 장애 포인트를 없애야 한다. 업무를 분리해야 하며, 요청 캐시에 대한 예처럼 실패에 기반해서 디자인 하라 

부하 상태에서 카오스를 만드는 기법을 통해 예상 동작을 확인하라. 

변경 관리에 있어선, 가급적이면 최대한 자동화를 구현하라. 아키텍쳐 다양성을 구현하고 유지하는 비용에 대한 이해와, 중앙에서 관리하는 지원 조직이 있다면 지원에 우선순위를 고려하라. 서비스 영향도에 기반한 우선순위 설정은 더 효율적인 지원이 가능하도록 만들어 줄 것이다. 

변화에 있어서는 자동화된 배포와 경험을 지속적으로 반영하도록 하라. 다시한번, 해법이 먼저고 팀이 나중이다.