컨퍼런스(Conference, Session)/우아콘(WOOWACON)

[2022 우아콘] API Gateway 패턴에는 API Gateway가 없다

Chann._.y 2022. 10. 27.

728x90

1. 세션 시청 배경

MSA 아키텍처 상 API Gateway 서버가 필연적이라는 생각을 하고 있었음
API Gateway 패턴에 대한 호기심

2. 세션 주제

1. MSA 아키텍처에서 필수적인 API Gateway Pattern이 API gateway Framework와 무관한 이유
2. API Gateway Pattern이란?
3. MSA의 API 애플리케이션 역할 구분
4. 하나씩 알아보는 API Gateway Framework을 사용하면 안되는 이유들
5. 그래도 API Gateway Framework를 사용해도 되는 경우들

3. 세션 내용

키워드 정리
1. API Gateway Pattern
  1. 클라이언트의 요청을 받아서 내부 마이크로서비스를 호출하는 로직을 직접 작 성하고 응답 내용도 취사 선택하여 필요한 것만 내보내는 것
2. API gateway Framework
  1. 외부에 API를 제공하기 위한 API Gateway Pattern 은 Spring Cloud Gateway 나 Netflix Zuul
3. BFF - Backend For Frontend
  1. API Gateway Pattern 과 유사하게 직접 구현하는 로직을 작성하는 방법과
    API Gateway 애플리케이션을 클라이언트 기기 단위로 구분하고 소유권을 정하는 방식 조합
주의 사항
1. 인증과 권한 기능을 붙였는지 여부와 무관하게 외부에 API를 제공해줄 용도로 API Gateway Framework 를 사용한 요청/응답 Routing 은 하면 안됨
  1. API Gateway Framework 를 통해 단순 Gateway Routing Pattern 으로 내부 서비 스 API를 외부로 노출 시키는 경우에는 필터/인터셉터 역할만 하기 때문에 컨트롤러/퍼 사드가 존재하지 않는 상태가 되어 많은 문제를 일으킴
  2. Presentation 계층 구성은 꼭 컨트롤러와 퍼사드 코드를 직접 개발자가 작성하는 API Gateway Pattern을 따라야 함
  3. 비즈니스 계층 마이크로서비스 API들을 Presentation 계층으로 변환하는 용도로 API Gateway Framewor를 사용해서는 안되며 반대로 Filter/Interceptor/AOP 같은 횡단 관심사를 처리하는 데는 API Gateway Framework를 사용할 수 있다는 의미지만 추천하지는 않음

3. API Gateway Framework Gateway Routing 방식의 문제점

보안 취약성
1. IDOR(Insecure Direct Object Reference) 중 "수평적 권한 상승"
Client 개발자 혹은 특정 Micro Service에게 Business 로직 전가
1. 단순 라우팅을 하게 되면 Facade가 필요한 경우에 엉뚱한 로직을 전가하게 됨
  1. Cliendp 구현 전가 : 클라이언트가 직접 비즈니스 계층이 로직을 조합해서 호출
    1. 클라이언트 개발자가 UI 처리에 집중하지 못하게 됨
    2. 버그가 존재할 경우 Mobile App은 각종 앱스토어 인증 절차에 걸리는 시간과 사용자들이 자발적으로 앱을 업데이트 할 때까지의 시간동안 버그 해결이 불가능해짐
  2. 각 마이크로서비스에 전가 : 서비스가 엉뚱하게 타 서비스를 호출해서 클라이언트 요청에 필요한 정보를 조합해 반환하는 것처럼 본인 비즈니스가 아닌것에 대해 구현하고 의존하게 됨
    1. 특정 서비스 개발자들은 알지 못하는 로직 구현 책임 맡게 됨
    2. 불필요한 복잡도, 결합도 증가 -> 장애 여파 증가
Business 계층과 Client 간의 강결합과 그로인한 보안 취약성
1. Business 계층 개발자는 항상 Clinet의 변경사항을 주시해야 함
2. 단순 요청/응답 라우팅은 어떠한 경우에도 사용하지 말고
  항상 응답 내용을 프리젠테이션 계층에서 Client에 필요한 것만 정제해서 내보내기!!
성능 저하
1. 여러 API 호출을 조합해야 하므로 network 호출이 여러번 일어나게 되고 불필요한 데이터들을 포함하고 있거나, 필요한 데이터가 없어서 추가 API 호출 시 Overhead 발생
2. API Gateway Pattern을 Non Blocking IO / Reactive하게 구현하여 성능 향상 추천(Spring WebFlux 등)
3. GraphQL로 이 문제를 해소 가능하지만, 비즈니스 계층 Microservice 에 GraphQL을 구축하고 이를 그대로 프리젠테이션 계층까지 노출하면 앞서 말했던 보안 문제들이 그대로 발생함. GraphQL 도 API Gateway Pattern에 따라 프리젠테이션 계층 서 버 애플리케이션으로 적절한 보안 처리를 해서 별도 구축
내부 Service들 간의 Protocol 자유도 하락
1. AGF로 프레젠테이션 계층을 구현한다는 것은 비즈니스 계층 서비스 모두 HTTP API(REST?로 고정된다는 의미
2. 내부 비즈니스 계층을 밖으로 한 번 노출하면 프로토콜 변경 어려워짐
3. gRPC, Message Queue, HTTP API, 기타 등등 자유도 포기 금지
계층형 아키텍처의 일반적인 원칙 위반 사례

7. 횡단 관심사 처리 관점에서도 사용하지 않아야 하는 이유

Single Point Of Failure
성능 저하 : 불필요한 서버 관리 부담 늘어나고 비용 증가
관리 부담 : Client가 하나의 end point만 바라본다고 해서 좋아질 것은 크게 없음
1. Client가 하나의 end point만 바라본다고 해서 좋아질 것은 크게 없음
2. Service.메소드수천개() : ???
문서화
1. 필요한 API를 빠르게 찾아볼 수 있게 문서들 잘 모아두기

4. API Gateway Framework를 사용할 만한 경우

-> 다양한 게이트웨이 라우팅 패턴 문제 해결 가능하고 AGF를 사용해서 얻는 이득이 문제점으로 인한 손해보다 크거나 감당 가능할 경우 AGF 사용해도 무관

4. 느낀점

기존에 본인이 알고 있던 API Gateway는 하나의 프레임워크였고 디자인 패턴으로서의 API Gateway Pattern은 결국 Gateway측에서 자체 로직으로 내부와 외부의 경계 사이에서 통제타워 역할을 한다는 것을 깨달았다.
스프링 유레카나 줄을 사용할 때 실익이 있는지 고려해봐야 겠다.

출처
2022 우아콘 - API Gateway Framework는 사실 그리 많이 필요하지 않아요
: https://woowacon.com/ko/detailVideo/18