[MSA] Micro Service Architecture: Outer - External Gateway


MSA의 Outer Architecture 중 External Gateway에 대해 알아보자.



MSA 개념 설명 읽어보기




External Gateway


  • 전체 서비스 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소
  • 사용자 인증 (Consumer Identity Provider)과 권한 정책관리(Policy Management)를 수행
  • API Gateway가 가장 핵심적인 역할



API Gateway


  • 서버 최앞단에 위치하여 모든 API 호출을 받음 (API 서버들의 endpoint 단일화를 해주는 또다른 서버)
  • API에 대한 인증과 인가 기능을 가지고 있음: 받은 API 호출을 인증한 후, 적절한 서비스들에 메세지를 전달(routing)
  • SOA의 핵심 인프라인 ESB(Enterprise Service Bus)에서 비롯됨
    • EBS는 SOAP/XML 기반의 무거운 기능
    • API Gateway는 REST/JSON 기반의 가벼운 기능



API Gateway의 주요 기능


  1. 인증 및 인가 (Authentication and Authorization)
    • MSA에서 각각의 서비스에 API호출에 대한 인증 및 인가를 한다는 것 = 같은 소스코드를 서비스 인스턴스들마다 심어줘야 함 = 소스의 중복이 심하여 유지 관리가 어렵고, 로깅 모니터링을 관리하는 것도 매우 어려워짐
    • 따라서 인증서 관리나 인증, SSL, 프로토콜 변환화 같은 기능들을 API Gateway에서 오프로드 -> 각각의 서비스 부담 줄이기 및 서비스 관리, 업그레이드가 용이함

      Authentication (인증) vs Authorization (인가)

      • Authentication: 유저가 누구인지 확인하는 절차
      • Authorizatoin: 어떠한 유저가 특정 자원에 접근하려 할 때, 그에 대한 접근 권한이 있는지 확인하는 절차
  2. 요청 절차의 단순화
    • API Gateway가 없을 시 클라이언트에 여러 서비스들에 대한 요청을 진행해야 함
    • API Gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하도록 만들어줌
    • 따라서 클라이언트와 백엔드 간 APU 통신량이 줄어 대기시간이 줄어줄이고 효율성을 높일 수 있음
  3. 라우팅 및 로드밸런싱
    • 클라이언트로부터 접수된 메시지에 따라, API 호출을 적절한 서비스에 라우팅
    • 서비스 인스턴스들에 대한 부하분산 가능
  4. 서비스 오케스트레이션
    • 오케스트레이션: 여러 개의 마이크로 서비스를 묶어 새로우 서비스를 만드는 개념
    • 과도한 오케스트레이션 로직: APU Gateway의 부담을 늘리는 것 = 성능 저하
  5. 서비스 디스커버리
    • API Gateway는 각 서비스 호출을 위해 서비스마다 IP주소 및 포트번호를 알고 있어야 함
    • lagacy 환경에서는 크게 문제될 점이 없지만, 클라우드 환경에서는 동적으로 배포되기 때문에 서비스 위치를 찾는 것이 어려움
      • 이러한 서비스의 위치를 찾는 것을 Service Discory
    • 서버 사이드나 클라이언트 사이드를 기준으로 서비스 디스커버리 구현 가능



API Gateway 적용 시 고려사항


  • API Gateway 계층이 추가적으로 만들어진다는 의미 = 그 만큼 네트워크 latency 증가

  • API Gateway의 Scale-out 적용이 유연하게 일어나지 않을 경우, API Gateway가 병목지점이 되어 어플리케이션의 성능저하가 일어날 수 있음

  • API Gateway의 가장 큰 단점은 API Gateway를 내부 마이크로서비스와 결합한다는 것
    -> 기존 SOA에서의 EBS(Enterprise Service Bus)에서 발생했던 문제점이 다시 발생할 수 있음

    2000년대 후반, 많은 SOA 프로젝트가 실패한 이유로 SOA의 핵심적인 요소 중 하나인 ESB가 꼽히는 경우가 많음.

    • 당시 EBS 내부 처리 로직을 XML 기반으로 했는데, XML의 파싱은 오버헤드가 큰 작업
    • EBS는 가벼운 연산 외에도 과도한 Orchestration 등 무거운 로직을 가짐. 대부분 ESB를 Gateway로의 특성이 아닌 시스템을 통합하기 위한 역할로 많이 구현했음

Author: Ruby Kim
Reprint policy: All articles in this blog are used except for special statements CC BY 4.0 reprint policy. If reproduced, please indicate source Ruby Kim !
Comments
  TOC