반응형
📝 API Gateway
클라이언트가 여러 백엔드 서비스를 직접 호출하지 않고 항상 게이트웨이를 통해서만 접근하게 만드는 패턴입니다.
특징
- 라우팅
- 내부 서비스 구조 은닉 가능
- 서비스들의 공통적인 문제를 한 곳에서 처리해준다. (횡단관심사문제 해결)
- 횡단관심사 : 인증 체크, 권한 체크, 로그 남기기, 트랜잭션 처리, 예외 처리, 모니터링, 속도 제한 등...
- MSA 의존성 제거
- 클라이언트에서 API 라우팅 변경시 클라이언트도 함께 수정 필요
- 게이트웨이에서 API 자체에서 장애 발생시 throttling 지원
- MSA를 철저히 지키면 Aggregation을 분리시키지만 대체로 API Gateway에 Aggregation을 같이 사용합니다.
- Aggregation을 사용함으로 클라이언트는 하나의 요청주소만 알게 되고 여러 조회를 합쳐서 내리기 때문에 클라이언트에서는 3개의 API를 호출해서 따로따로 다 바꿔줬어야하지만 1개만 호출하기 때문에 수정사항이 적어진다.
- heavy한 작업이면 하나로 다 호출하기에는 많은 시간이 소요되어서 페이지 로드가 느려질수도 있다.
📝 API Gateway Pattern
클라이언트가 여러 백엔드 서비스에 직접 접근하지 않고 하나의 중간 계층(API Gateway)을 통해서만 접근하도록 하는 설계 패턴으로 이 패턴 기반으로 만들어진 것이 API Gateway와 BFF가 있습니다.
📝 BFF (Backend for Frontend) (프론트 서버)
하나의 공통 백엔드를 여러 클라이언트에 쓰면 모바일은 필요한 데이터가 적은데 응답이 너무크거나 웹은 복잡한데 API 호출을 여러번해야하는 상황이 생깁니다. 이러한 문제를 해결하기 위해 Gateway같은 서버를 둬서 분리해서 호출해 사용합니다.
🔗 참고 및 출처
https://kir93.co.kr/entry/BFFBackend-For-Frontend
https://www.wallarm.com/what/the-concept-of-an-api-gateway
https://www.youtube.com/watch?v=Ci_DsTkzcRY
반응형