마이크로서비스의 API 게이트웨이 패턴 이해: 간단한 가이드

단일 모놀리식 애플리케이션에서 마이크로서비스 아키텍처로 전환하면 많은 문제가 해결됩니다. 이를 통해 팀은 독립적으로 작업하고, 서비스를 별도로 배포하고, 필요에 따라 시스템 부분을 확장할 수 있습니다. 그러나 이는 또한 **클라이언트가 이러한 모든 독립적인 서비스와 어떻게 상호 작용합니까?**라는 새로운 과제를 제시합니다.

10개, 50개 또는 수백 개의 작은 마이크로서비스가 있는 경우 모바일 앱이나 웹페이지가 각 마이크로서비스에 직접 연결되어야 합니까?

이것이 바로 API 게이트웨이 패턴이 등장하는 곳입니다. 이 가이드에서는 API 게이트웨이가 무엇인지, 왜 필요한지, 간단한 단어와 실제 비유를 사용하여 마이크로서비스 시스템을 단순화하는 방법을 자세히 설명합니다.

실제 비유: 호텔 접수원

당신이 대형 고급 리조트 호텔에 체크인한다고 상상해 보십시오. 리조트에는 다양한 부서가 있습니다.

• 하우스키핑(깨끗한 시트의 경우)
• 룸서비스(음식)
• 컨시어지(투어 예약용)
• Billing (청구서 지불을 위해)

깨끗한 수건을 원한다면 하우스키핑 건물을 찾으려고 리조트를 돌아다니지 마세요. 저녁을 먹고 싶다면 부엌 문을 두드리지 마세요. 대신 프런트 데스크 접수원에게 전화하세요.

접수원은 고객님의 요청을 듣고 어느 부서에서 해결할 수 있는지 판단한 후 연결해 주거나 처리해 드립니다.

이 시나리오에서는:

• 귀하는 클라이언트(모바일 앱 또는 브라우저)입니다.
• 접수원은 API 게이트웨이입니다.
• 부서(하우스키핑, 룸서비스, 청구)는 마이크로서비스입니다.

문제: 클라이언트-서비스 직접 통신

게이트웨이가 어떻게 작동하는지 살펴보기 전에 게이트웨이를 사용하지 않으면 어떤 일이 일어나는지 살펴보겠습니다.

전자 상거래 애플리케이션에 세 가지 별도의 마이크로서비스가 있다고 가정해 보겠습니다.

1. 사용자 서비스(프로필 관리)
2. 제품 서비스(카탈로그 관리)
3. 주문 서비스 (결제 관리)

API 게이트웨이가 없으면 클라이언트 앱은 각 서비스의 개별 주소(IP 또는 URL)에 직접 별도의 요청을 보내야 합니다.

이러한 직접 연결 접근 방식은 몇 가지 주요 골칫거리를 야기합니다.

• 엔드포인트가 너무 많음: 클라이언트 앱은 세 개의 개별 URL을 기억해야 합니다. 서비스를 분할하거나 주소를 변경하는 경우 클라이언트 애플리케이션을 업데이트해야 합니다.
• 보안 악몽: 각 마이크로서비스는 인증(로그인 토큰 확인), SSL 인증서 및 방화벽 규칙을 별도로 구현해야 합니다.
• 네트워크 오버헤드: 클라이언트는 단일 페이지를 로드하기 위해 느린 모바일 네트워크를 통해 세 가지 별도의 네트워크 요청을 수행해야 할 수 있습니다(예: 프로필 가져오기, 제품 세부 정보 가져오기, 주문 내역 가져오기).
• 프로토콜 차이점: 클라이언트 앱은 HTTP/JSON과 같은 표준 웹 프로토콜을 사용하는 것을 선호할 수 있지만 내부 서비스는 gRPC 또는 AMQP와 같은 특수 프로토콜을 사용하여 더 빠르게 통신할 수 있습니다.

솔루션: API 게이트웨이 패턴

API 게이트웨이는 클라이언트 애플리케이션과 내부 마이크로서비스 사이에 위치하는 도우미 서버입니다. 이는 들어오는 모든 요청에 ​​대한 단일 진입점 역할을 합니다.

세 가지 다른 서비스를 호출하는 대신 클라이언트는 API 게이트웨이를 한 번 호출합니다. 그런 다음 게이트웨이는 요청을 올바른 내부 서비스로 전달하고 결과를 수집하여 클라이언트로 다시 보냅니다.

API 게이트웨이의 주요 책임

API 게이트웨이는 직접적인 트래픽 이상의 기능을 수행합니다. 모든 마이크로서비스가 다음에 대한 코드를 작성해야 하는 작업인 “교차적 문제"를 처리합니다.

1. 라우팅: 게이트웨이는 수신 URL(예: /api/v1/orders)을 가져와 이를 올바른 내부 서비스 주소에 매핑합니다.
2. 인증 및 승인: 게이트웨이는 출입문에서 보안 토큰(예: JWT)의 유효성을 검사합니다. 요청이 유효하지 않으면 즉시 거부되므로 인증되지 않은 요청으로 인해 마이크로서비스가 CPU 주기를 낭비하지 않게 됩니다.
3. 속도 제한: 사용자가 분당 보낼 수 있는 요청 수를 제한하여 악의적인 봇이나 버그가 있는 클라이언트가 시스템에 스팸을 보내는 것을 방지합니다.
4. 로드 밸런싱: 게이트웨이는 들어오는 트래픽을 마이크로 서비스의 여러 인스턴스에 균등하게 분산하여 단일 서버의 과부하를 방지할 수 있습니다.
5. 프로토콜 번역: 사용자 대상 JSON 요청을 고성능 내부 gRPC 메시지로 변환하여 서비스가 선호하는 언어로 서로 통신할 수 있도록 합니다.

간단한 구현: 코드 예

라우팅이 얼마나 쉬운지 알아보기 위해 API 게이트웨이를 설정하는 두 가지 일반적인 방법을 살펴보겠습니다.

1. 선언적 라우팅(Spring Cloud Gateway YAML)

엔터프라이즈 Java 시스템에서는 간단한 구성 파일을 사용하여 라우팅을 구성하는 경우가 많습니다. 게이트웨이는 다음 규칙에 따라 자동으로 요청을 전달합니다.

spring:
  cloud:
    gateway:
      routes:
        - id: user_service_route
          uri: http://internal-user-service:8081
          predicates:
            - Path=/api/users/**
        - id: product_service_route
          uri: http://internal-product-service:8082
          predicates:
            - Path=/api/products/**

2. 프로그래밍 방식 라우팅(Node.js 게이트웨이 목업)

Express를 사용하여 Javascript로 경량 API 게이트웨이를 구축하려는 경우 다음과 같습니다.

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;

// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
    const token = req.headers['authorization'];
    if (token === 'secret-handshake-token') {
        next(); // Token is valid, proceed
    } else {
        res.status(401).json({ error: 'Unauthorized Access!' });
    }
};

// Apply auth check to all incoming gateway requests
app.use(authenticate);

// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));

app.listen(PORT, () => {
    console.log(`API Gateway running smoothly on port ${PORT}`);
});

API 게이트웨이 패턴의 장점과 단점

모든 아키텍처 결정과 마찬가지로 API 게이트웨이 사용에는 다음과 같은 장단점이 있습니다.

결론

API 게이트웨이 패턴은 최신 마이크로서비스 아키텍처의 초석입니다. 단일 스마트 진입점 역할을 함으로써 내부 서비스 설정의 복잡성으로부터 클라이언트 애플리케이션을 보호합니다. 클라이언트 측 코드를 단순화하고 보안을 중앙 집중화하며 트래픽 관리를 효율적으로 처리합니다.

소규모 네트워크 홉을 도입하고 프로덕션에서 고가용성을 설정해야 하지만 더 깨끗하고 안전하며 관리하기 쉬운 코드베이스의 이점으로 인해 성장하는 모든 분산 시스템에 적극 권장되는 패턴입니다.

Ghaznix 블로그에서 더 많은 소프트웨어 개발 및 백엔드 엔지니어링 통찰력을 살펴보세요 →