cf) MSA
ㅡ 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크
ㅡ 마이크로서비스는 완전히 독립적으로 배포가 가능
ㅡ 다른 기술 스택(개발 언어, 데이터베이스 등)이 사용 가능한 단일 사업 영역에 초점을 둠
API Gateway를 한 마디로 정의하자면 사용자 요청을 적절한 서비스로 프록시 혹은 라우팅하는 MSA의 컴포넌트인 것
단순히 API Gateway만을 알기보다 사례를 통한 등장 배경을 아는게 더 도움이 되었다.
(이 이상 설명을 더 잘할 수 없어서, 들어가서 읽는게 좋다.)
https://www.samsungsds.com/kr/insights/msa_and_netflix.html
넷플릭스로 알아보는 MSA
넷플릭스로 알아보는 MSA
www.samsungsds.com
정리하자면,
- 2007년 심각한 데이터베이스 손상으로 3일간 서비스 장애를 겪은 넷플릭스
- 신뢰성 높고 수평 확장이 가능한 클라우드 시스템으로 이전할 필요성을 느낌
-> 고가용성, 유연한 스케일링, 빠르고 쉬운 배포를 위해 MSA 선택
MSA 전환을 위한 기술들을 도입하여 무려 7년에 걸쳐 클라우드 환경으로 이전
- 넷플릭스 OSS는 MSA를 도입하려는 많은 사람에게 좋은 선택지가 되어짐
cf) OOS = Open Source Software
- 자동 확장이란 특정 서비스에 트래픽이나 부하가 증가할 경우 인스턴스를 추가로 생성하고, 반대로 트래픽과 부하가 감소할 경우 불필요한 인스턴스를 서비스에서 제거하는 것
-> 서비스 단위로 자동 확장이 가능해 시스템 자원 활용을 최적화할 수 있지만 구현하기 위해서는 고려해야 할 것들이 많음
ex) 동적으로 추가하는 인스턴스 정보를 다른 서비스로 전달할 방법이 필요, 신규 추가된 인스턴스 간의 로드 밸런싱을 처리, 장애대응 방법 마련 etc .... 서비스의 확장과 축소가 빈번하고 서버들의 물리적 환경이 다르다면 고민은 더 커질 것
- Zuul은 넷플릭스가 개발한 Spring Cloud Netflix에 특화된 API 게이트웨이
cf) 주의 : Zuul 외에 API Gateway는 이밖에도 있음. 넷플릭스만의 것이 아니라 지금 필요성을 알아보기 위해 넷플릭스 사례를 본 것
edge microservice
어떤 사람들은 정의를 이렇게 내리기도 함. "backed for frontend pattern"
Q. 사용자에게 API Gateway만 노출하고 다른 마이크로서비스의 edge들은 숨기는 이유는?
-> MSA 환경은 하나의 서비스에 여러 개의 서버가 존재할 수 있어서 사용자에게 다수의 진입점(End Point)이 생김.
진입점은 인증과 보안, 잘못된 요청 등을 처리하는데 일부 진입점에 변경이 생길 경우 전체가 영향을 받기 때문에 관리가 까다로움.
-> 이때 API Gateway를 활용해 도메인을 하나로 통합하고 단일 진입점으로 사용한다면 관리가 수월해짐
- web, mobile 다르게 두기도
(1) Monolithic Architecture
* 출처 *
https://www.youtube.com/watch?v=1vjOv_f9L8I
https://www.nginx.com/blog/introduction-to-microservices/ (튜토리얼)
https://wikidocs.net/155744 (사진)
https://www.samsungsds.com/kr/insights/msa_and_netflix.html (넷플릭스 이야기)
https://wooaoe.tistory.com/m/57 (Monolithic)
ESLlint (1) | 2022.01.24 |
---|---|
도커 실행 (0) | 2022.01.18 |
Vim (0) | 2022.01.13 |
[JS] 구조분해 할당 (0) | 2022.01.06 |
[JS] Shorthand property names (0) | 2022.01.06 |