[Youtube] 넷플릭스 마이크로 서비스 가이드 3-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

 

---

 

3. Challenges & Solutions

 

지난 7년간 넷플릭스의 해법과 해법 철학으로 4가지 접근방법이 있다. 

.

1) Dependency

2) Scale

3) Variance, 다양한 아키텍쳐의 수용

4) Change, 변화를 어떻게 처리할지

 

 

 

4) Change

 

지금 우리가 하는건 변화를 위해 무언가 바꾸고 부수고 새로 만든느 일을 "업무 시간"에 하는 것이다. 아래 있는 것은 주중 장애 그래프 이다. 주말 보다 주중에 더 많은도록 노력하는 중이다.

 

아래는 매우 흥미로운 시간별 장애 그래프이다. 아침 9시에 뭔가 반영하고 "붐", 바로 넷플릭스를 변화 시키고, 부술 시간인 것이다. 우리는 이런일(변경으로 발생하는 장애)이 발생한다는 것을 다 알고 있다. 

그래서 우리는 "어떻게 가능한 빠르게, 그리고 뭔가 잘못되지 않을거라는 자신감을 가지고 변경을 적용할 수 있는가?"를 질문을 하게 된다. 여기에 대한 답변으로, 우린 "spinnaker"새로운 배포 플랫폼을 만들었다. 오랫동안 사용했던 Asgard를 대체하고, 넷플릭스의 새로운 글로벌 클라우드 관리 플랫폼이다. 자동화 된 배포를 수행하는 시스템이다. Spinnaker는 그간의 다양한 경험을 바탕으로 발생하는 변경사항을 프로덕션에 적절히 배포할 수 있도록 디자인된 도구이다.  이에 2가지 분석을 볼수 있는데 하나는 자동화된 카나리 분석이고, 이것은 새로운 버전의 애플리케이션이 배포될때 라비으 시스템에서 유입되는 트래픽으 일부를 "자동으로" 새버전으로 흐르게 한다. 이를 통해 기존의 코드와 새로운 코드 중에 어떤게 나은지 알아낼 수 있다. 다른 하나는 스테이징 배포이다. 우리가 확실히 하고 싶었던 것은 하나의 배포를 하나의 리전에만 수행하고 싶었다. 뭔가 크게 고장나더라도 다른 리전들로 트래픽을 분배할 수 있기 때문이다. 그 외에도 많은 기능이 있다. 장기적인 관점에서 이전에 이야기 했던 "프로덕션 배포 확인 리스트"와 같이 다양성을 반영하기 위한 도구들은 모두 배포 파이프라인에 언젠가는 적용 되어야 한다.