넷플릭스 OSS 구조 파헤치기

서버 사이드 로드밸런싱

• 주로 L4스위치를 사용
• 4계층의 포트를 사용해 트래픽을 분산함
• 하드웨어가 필요함
• 비용과 유연성의 부담
• 트래픽을 분산할 서버 1~3개의 주소가 필요
• 제한적

위의 단점을 해결하기 위해 클라이언트 사이드 로드밸런싱이 필요하다.

클라이언트 사이드 로드밸런싱(리본)

• L4 스위치를 클라이언트 소프트웨어로 대체함
• Ribbon은 분산처리방법으로 여러 서버를 라운드 로빈 방식으로 부하 분산 기능을 제공함 (NginX랑 유사함)

Eureka

• 로드 밸런싱과 failover를 위해 만들어진 rest 서비스
• 로드 밸런싱을 위해 유레카 클라이언트 목록을 제공하고, failover를 위해 유레카 클라이언트의 상태를 체크한다.

스프링 클라우드 넷플릭스

• 넷플릭스에서 MSA를 자사 서비스에 적용하기 위해 만들어낸 서킷 브레이커(Hystrix), 클라이언트 사이드 로드밸런싱(Ribbon), tjqltm eltmzjqjfl(Eureka), 인텔리전트 라우팅(Zuul) 등의 넷플릭스 OSS에 대한 통합 지원
• Spring cloud는 클라우드 환경에 특화된 프레임워크
• MSA 구축에 특화된 라이브러리들의 집합

MSA

• 개발될 기능을 어떻게 만들면 에러 상황에 탄력성있게 잘 대처할지, 빠른 배포가 가능하고, 서비스 부하에 능동적으로 잘 대처하도록 만들지에 대한 관점

MSA 도입시 고려사항

• 자동확장 (특정 서비스에 트래픽이나 부하가 증가할 때 추가 인스턴스를 생성
• 반대로 트래픽과 부하가 감소할 경우 불필요한 인스턴스를 서비스에서 제거
• 동적으로 추가되는 인스턴스 정보를 다른 서비스로 전달할 방법
• 신규 추가된 인스턴스들 간의 로드 밸런싱을 처리/장애 대응방법 마련

서비스 디스커버리 서버 (유레카)

• MSA 구조에서 서비스들은 동적으로 확장되고 축소되기도 하는데 이때마다 운영자가 일일이 인스턴스 정보를 수정/관리하기가 어려움
• 인스턴스의 상태를 동적으로 관리하는 서버가 필요한데 이를 서비스 디스커버리 서버로 명하고 넥플릭스는 유레카라고 공개했다.
• 새로운 인스턴스는 시작시 Eureka 서버에 IP, 호스트 주소, 포트 정보등을 전송함
• 받은 정보를 일정 간격으로 상태를 체크하며 해당 인스턴스를 관리
• 인스턴스가 새로 실행될 때마다 정보를 서버에 동적 등록하기 때문에 서비스 수평확장시 IP정보를 신경쓰지 않아도 됨. (수평확장은 부하가 걸린 서비스의 인스턴스를 늘려 처리량을 높임)
• 운영자는 설정 파일에 Eureka 서버 정보만 입력하고, 서비스들은 다른 서비스 호출시 Eureka서버에 등록된 인스턴스를 조회하면 됨

유레카의 필요성

• MSA는 주로 클라우드 환경에서 이루어지고, 클라우드는 수시로 서버가 늘어나거나 줄어들가나 한다.
• 로드 밸런싱을 위해 LB가 IP, Port 정보를 가져야하는데 서버의 수가 달라질때마다 수동으로 기록하는건 무리임
• 유레카는 등록과 해지, fetch 개념을 구체화하여 이를 자동화 시킴

Gateway Pattern

• MSA 핵심구성요소 -> API Gateway 패턴

API Gateway 패턴

• Restful하게 작성된 API를 손쉽게 관리, 인증을 통한 자원의 효율적인 분배 (인증서버)
• API 모든 요청에 대한 로깅
• 모든 클라이언트의 요청이 하나의 서버로 들어와 해당 서버에서 요청이 정제되거나 조작되어 각자 목적에 맞는 서비스를 찾아가도록 함
• 각 서버에서 로직 수행후 발생한 응답을 모아 사용자에게 분배해줌

API Gateway의 고려사항

• 병목현상
• 네트워크 latency