brunch

라이킷 1 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 에디의 기술블로그 Apr 10. 2018

API Gateway Pattern

- and Backend for Front-End Pattern

API Gateway Pattern

개념 및 문제점

클라이언트가 여러 서비스를 이용하는 경우, 특히 마이크로서비스 아키텍처 같은 분산형 아키텍처에서는 경우에는 클라이언트에서 각 엔드포인트를 관리하는 것이 어려울 수 있다. 예를 들어서 보안 기능을 공통으로 적용하기 위해서는 각 서비스에서 이러한 기능을 일관되게 구현해야 한다. 표준화된 프레임워크(라이브러리)를 사용할 수 있지만, 공통 프레임워크에 기능이 추가되면 할수록 모든 서비스를 다시 컴파일하여 배포해야 하기 때문에 의존성이 너무 높아진다.

해결 방법

각 서비스 앞에 API Gateway를 적용하고, 클라이언트는 적용된 API Gateway 의 단일 Url(End-Point)만 알고 통신하면 된다. Back-End 서비스에서의 변경이 되어도 클라이언트는 변경 없이 서비스를 유지할 수 있고, 클라이언트에서의 모든 호출은 API Gateway를 통해서 전송이 된다. 비록 API Gateway를 통과하기 때문에 네트워크 비용이 추가되지만 서비스에는 거의 영향을 미치지 않는 수준일 것이다. 오히려 단일 왕복으로 여러 서비스에서 데이터를 검색할 수 있기 때문에, Request(요청) 횟수는 줄어들 것이다. 요청 횟수가 줄어들면 자연스럽게 클라이언트 브라우저에서의 서비스 품질도 높아질 것이다.

고려해야 할 사항

언제나 고가용성을 유지해야 한다.

불필요한 메모리 저장을 하지 않는다.

복잡성이 증가하지 않도록 설계를 잘 해야 한다.

샘플 소스

생략

참고자료

http://microservices.io/patterns/apigateway.html

https://docs.microsoft.com/ko-kr/azure/architecture/patterns/gateway-routing

https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d

지극히 개인적인 생각이지만, API Gateway 에 대한 필요성보다는 고려해야 할 사항이 더 크게 느껴진다. 시스템에 성급하게 도입하는 것은 신중해야 한다. API Gateway 가 장애가 발생을 하면 어떻게 되는지에 대해서 우리는 심각하게 고민하고 도입해야 한다. 즉, API Gateway를 호출하는 모든 클라이언트 서비스에 방어 로직이 설계가 잘 되어야 할 것이다.

Backend for Front-End Pattern

개념 및 문제점

PC와 모바일 디바이스는 화면 크기, 디스플레이 등 다른 점이 있다. 같은 API에서 이런 요구사항을 모두 만족할 수 있을까? 만약 완벽하게 동일한 로직을 사용한다면 API에서 동일한 비즈니스 로직으로 요구사항을 모두 전달할 수 있다고 생각이 되지만, 필자는 분리하는게 좋다는 의견이다. 내 생각과 비슷한 글은 [Building Microservices - 샘 뉴먼 - 한빛미디어] 라는 책에서, 115page부터 읽어보면 Backend for Front-End Pattern에 대해서 참고할 수 있다.