1. 외부 api 설계 이슈
마이크로 서비스의 경우, 모노리식과는 다르게 서비스에 직접 접근하여 api 를 호출하는 것은 여러가지 문제가 될 수 있다.
모놀리식인 경우에는 하나의 서비스에 api 를 호출하면 되지만, 마이크로 서비스는 데이터가 여러 서비스에 분산되어있다.
따라서 마이크로 서비스 아키텍처를 채택하는 경우, 기존 모놀리식에서 제공하는 데이터를 제공하기 위해 여러 서비스가 사용된다.
하지만 마이크로 서비스 아키텍처가 장점만 있는 것은 아니다.
아래와 같은 문제점들이 있을 수 있다.
- 인터넷은 느리다.
- 인터넷은 느리기 때문에, 직렬로 api 를 호출할 수 밖에 없으면 여러 서비스를 호출시 더 오랜 시간이 걸릴 수 있다.
- 클라이언트 마다 다르지만, 일부 클라이언트에 따라 변경이 어렵다.
- 모바일 애플리케이션의 경우, 강제 업데이트를 하지 않으면 기존의 api 를 호출하기 때문에 변경이 어려워진다.
- api 조합을 클라이언트 개발자가 해야한다.
- 기존 api 엔드포인트 하나에서, 여러 api 를 호출해서 데이터를 조합해야함.
- 여러 서비스의 각 백엔드 개발자 입장에서 하위 호환성을 지속적으로 지켜야함.
2. api gateway pattern
일종의 퍼사드와 비슷한 구조.
클라이언트는 api gateway 를 통해서, 서비스를 간접적으로 호출한다. 리버스 프록시와 비슷한 역할을 한다.
api gateway 의 책임
- routing
- 뒤의 서버(서비스)들로 라우팅을 할 수 있다.
- api 조합
- 단순히 라우팅하는 것 뿐만 아니라 뒤의 서버들을 조합해서 처리해줄 수 있음. → 인터넷을 통하는 것 보다 빠르다.
- 프로토콜 변환
- 내부 서비스가 http 프로토콜이 아니어도, api gateway가 변환해서 http로 서빙해줄 수 있음.
- 클라이언트마다 적합한 api 제공
- 모바일, 서드파티 등 각기 다른 api 가 필요한데, api gateway 가 이를 제공할 수 있음.
- 그 외 부가 기능들
- 인증
- 인가
- 로깅 등
api gateway 아키텍처
BFF (Backend For Frontend)
https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html
api gateway 를 클라이언트마다 분리하는 방식. 그리고 해당 클라이언트 팀 마다 api gateway를 소유한다.
⇒ 격리
격리를 함으로써 얻는 장점
- 개발시 의도치 않은 참조나 배포가 꼬이거나 하는 문제가 없어짐.
- 하나의 api gateway 가 장애가 나도, 다른 클라이언트는 죽지 않음.
- api gateway 마다 독립적으로 확장 가능.
- 별도의 프로세스로 동작해서 관측성이 좋아짐.
넷플릭스 팔코
https://netflix.github.io/falcor/
api gateway 장단
장점 : 다른 서비스들이 캡슐화된다.
단점 : 고가용성 컴포넌트 (api gateway) 를 관리해야 한다. 풀어서 설명하자면, api gateway 는 수많은 클라이언트의 진입점이 된다. 따라서 요청량이 매우 많기 때문에 가용성이 높아야한다.
api gateway 설계 이슈
api gateway 는 일반적으로 부하가 크다. 따라서 가용성이 높아야함.
아래 방식이 고려되어야 함.
동기 I/O vs NIO
- 동기 I/O
- OS 스레드 할당 → 스레드 개수 제약 → 동시 접속 제한
- NIO
- 이벤트 루프 스레드
- jvm 네티, 언더토우 등
- nodejs
- 라우팅에서는 성능 향상. cpu 집약에서는 별 차이 x
- 이벤트 루프 스레드
리액티브 프로그래밍
- 동시 호출
부분 실패처리
- 타임아웃 처리
- 일부 서비스 장애 → 서킷 브레이커
'아키텍처' 카테고리의 다른 글
DDD - Entity 인가 아닌가? (0) | 2024.09.04 |
---|---|
DDD - Entity의 개념 (0) | 2024.08.31 |
설계 원칙 (0) | 2023.09.03 |
Yagni (You aren’t gonna need it) (feat. 클린 아키텍처) (0) | 2023.07.02 |