유튜브에서 영상을 보다보니 노마드 코더 채널에서 위의 제목으로 영상이 올라온 것을 볼 수 있었다. 모르던 내용이기도 하고 흥미로워서 영상 내용 정리 및 추가적으로 정리한다. 영상링크
내용정리
넷플릭스의 백엔드는 초창기에 JAVA, Oracle 를 이용하여 그들의 데이터 센터에 호스팅되었다. 하드웨어를 직접 사서 관리했다는 의미이다. 이 구조의 문제는 너무 monolithic 했다는 점! monolithic 이란 하나의 거대한 백엔드 어플리케이션이 모든 것을 처리하는 경우를 말한다.
이러한 구조는 보통의 백엔드 구조라고 한다. 단점은 모든 것이 한 곳에 모여있기 때문에 어떠한 이유로 서버에 오류가 발생하면 전체 시스템이 같이 붕괴된다는 위험이 있다는 것이다. 예를 들어 영상 스트리밍에 에러가 발생하면 결제, 회원 가입 같은 전체 서비스가 같이 다운되게 된다. 또한 여러 팀에서 코드를 수정하거나 프로덕트를 배포하기 위해서는 전체 서버를 다시 시작해야하기 때문에 불편하다. 그리고 확장을 하게 될 경우 scale-up, 수직적으로 가능하다. 더 강력한 서버를 구매해야 한다는 의미이다. 따라서 탄력적이라고 보기는 힘들다. 갑자기 트래픽이 급증하면 대응할 수 없고, 반대로 메모리를 많이 구매했지만 유저가 줄어들면 쓸모없기 때문이다. 이러한 이유로 넷플릭스는 마이크로 서비스 아키텍쳐로 변경했다고 한다.
마이크로 서비스 아키텍쳐는 monolithic과 정반대 개념이다. 모두 작고, 독립적인 서비스로 나뉘어 있고 느슨히 결합되어 있고 상호의존적이지 않다. 서비스들이 각기 다른 서버에서 돌아갈 수도 있고 언어가 달라도 된다. 또한 일부 서비스에 에러가 발생해도 전체에 영향을 주지 않는다. 관리와 확장에도 용이하다. 수평적 확장이 가능하다.
그러나 실제로 도입하는 것이 쉽지 않다. 그래서 넷플릭스는 AWS로 이동했다.
회사들은 주로 모놀리식으로 시작해서 그들이 정말 필요성을 느낄 때만 마이크로 서비스로 이동한다고 한다.
비디오 스트리밍 핸들링
고해상도의 영상을 다양한 디바이스로 어떻게 빠르게 전달할까?
모든 영상을 담은 하나의 서버를 이용하게 되면 해당 서버에 문제가 발생할 경우 모두가 영상을 볼 수 없게 된다. 또한 서버의 위치에 따라 영상 로딩이 빠르거나 느릴 것이다. 따라서 CDN(Content Delivery Network)을 이용해서 컨텐츠를 전달했다. CDN은 전세계에 서버를 가지고 있는 회사 같은 것으로 결제를 하면 파일을 가져다 복사하고 전세계에 뿌리고 유저가 영상을 요청하면 가까운 서버에서 응답한다. 그러나 다른 회사의 서버를 최적화시키는 것은 어렵기 때문에 자체 시스템을 개발했다.
Netflix Open Connect
360TB의 영상과 시리즈로 채워서 인터넷 회사에 보내는 방식이다. 한국에서 킹덤을 볼 때 영상이 미국에서 오는 것이 아니라 우리의 인터넷 회사 데이터 센터에서 오는 것일 수 있다. 이렇기 때문에 VPN을 이용하면 해당 국가에서 볼 수 없는 컨텐츠도 볼 수 있게 된다. VPN을 쓰면 다른 ISP를 쓰기 때문에 다른 국가의 컨텐츠에 접속 가능한 것이다.
추가
monolithic architecture
장점
- 어떤 기능(서비스)이든지 개발되어있는 환경이 같아서 복잡하지않다.
- 쉽게 고가용성 서버 환경을 만들 수 있다. ( 같은 어플리케이션으로 하나더 만들면 됨)
- End-to-End 테스트가 용이하다. (MSA의 경우 테스트에 필요한 서비스들을 모두 동작시켜야함)
단점
- 한 프로젝트의 덩치가 너무 커져서 어플리케이션 구동시간이 늘어나고 빌드,배포 시간도 길어진다.
- 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포를 해야한다.
- 많은 양의 코드가 몰려있어 개발자가 모두를 이해 할 수 없고 유지보수도 힘들다.
- 일부분의 오류가 전체에 영향을 미친다.
- 기능별로 알맞는 기술, 언어, 프레임워크를 선택하기가 까다롭다.
microservice architecture
장점
- 기능별로 마이크로서비스를 개발하고, 작업 할당을 서비스 단위로 하면 개발자가 해당 부분을 온전히 이해할 수 있다.
- 새로 추가되거나 수정사항이 있는 마이크로서비스만 빠르게 빌드, 배포가 가능하다.
- 해당 기능에 맞는 기술, 언어 등을 선택하여 사용할 수 있다.
- 일부분의 오류가 있으면 해당 기능에만 오류가 발생하고 그 부분만 빠르게 고쳐서 정상화가 가능하다.
단점
- 무엇보다 관리가 힘들다. 작은 여러 서비스들이 분산되어있기 때문에 모니터링이 힘들다.
- 서로를 호출하여 전체 서비스가 이루어지기 때문에 무조건 다른 서비스를 호출하는 코드가 추가되는데 이부분이 모놀리식 아키텍쳐의 개발보다 조금 까다롭다.
- 통신관련 오류가 잦을 수 있다. 마이크로 서비스들 끼리 계속 서로 통신을 하다보니 모놀리식 아키텍쳐에 비해 통신관련 오류가 잦았다.
- 테스트가 불편하다. 예로 End-to-End 테스트를 위해 UI, Gateway 등등 여러개의 마이크로 서비스를 구동시켜야 했었다.
