[MSA] #4 API Gateway

MSA는 각각의 서비스를 API 형태로 제공한다는 것을 알게 되었습니다. 그러면서 몇 가지 이슈가 생겨나게 됩니다. 예를 들면 서비스마다 주소가 다르다는 점과 로깅, 모니터링, CORS처럼 서비스 간의 공통된 로직의 관리가 있습니다. 차근차근 API Gateway가 어떤 식으로 이를 해결하는지 알아보겠습니다.

API Gateway란? API 서버 앞단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 녀석.

기능

1. API 요청을 한 곳에서 받아서 해당 서비스로 라우팅(이동)을 시켜줍니다.  

예를 들어 다음과 같은 환경에 서비스가 구동한다고 가정하겠습니다.

   유저 주문
주소 1.1.1.1 2.2.2.2 3.3.3.3

백엔드 팀은 3가지의 서비스를 완벽하게 구현을 하였고, 프론트엔드 팀 또는 앱 팀과의 협업을 위해 API 문서를 잘 정리한 후 전달을 하면 잠시 후 해당 팀에서  “왜 각각의 서비스마다 호출해야 될 주소가 달라요?”라며 물을 겁니다. 지금이야 서비스가 3개지만 프로덕션는 점점 커갈 것이고, 종국에는 수십, 수백 개의 서비스마다 주소를 구별해야 하게 되면 큰 이슈로 남을 것입니다. API Gateway는 간단하게 모든 서비스의 요청을 받은 후 해당 서비스로 라우팅(이동)을 시켜줍니다.

<API Gateway 없는 구조>

<API Gateway>

2. 보안을 강화해줍니다.

API Gateway는 외부에서 접근할 수 있도록 public으로 열어두고 각 서비스들은 내부 IP에서만 접근할 수 있게 private으로 구축해두게 되면 보안적으로 이점이 있습니다.

3. 각 서비스의 공통된 로직을 처리해줍니다.

대표적으로는 로깅, CORS(Cross-Origin Resource Sharing), 보안 및 인증, 모니터링 등이 있습니다.

온라인 서점을 예로 들면 유저, 책, 서비스를 이용하기 위해서 A라는 인증 방법을 사용하고 있습니다. 다시 말해서 A라는 로직을 통과해야 유저정보를 보거나 책을 주문할 수 있는 거죠. 그런데 만약 서비스를 하고 있다가 A로직의 치명적인 이슈가 발생하여 B라는 로직으로 변경을 하기 위해서는 모든 서비스의 인증 로직을 변경해야 됩니다. 이는 프로젝트 간의 중복 코드가 생겨났고 악취를 풍긴다는 걸 의미합니다. 이러한 이슈를 API Gateway의 필터 기능을 통해 해결할 수 있습니다.

이 이외에도 API Gateway 제품에 따라 스트레스 테스트, 로드밸런싱 등 다양한 기능을 제공합니다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

WordPress.com 제공.

위로 ↑

%d 블로거가 이것을 좋아합니다: