기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
API 게이트웨이 패턴
여러 클라이언트 애플리케이션이 포함된 복잡하거나 대규모 마이크로서비스 기반 애플리케이션을 설계하고 구축하려는 경우 API 게이트웨이 패턴을 사용하는 것이 좋습니다. 이 패턴은 객체 지향 설계의 파사드 패턴
이 패턴은 요청을 내부 마이크로서비스 엔드포인트로 리디렉션하거나 라우팅하기 위한 역방향 프록시를 제공합니다. API 게이트웨이는 클라이언트 애플리케이션을 위한 단일 엔드포인트 또는 URL을 제공하고 요청을 내부적으로 내부 마이크로서비스에 매핑합니다. 추상화 계층은 특정 구현 세부 정보(예: Lambda 함수 이름 및 버전)를 숨김으로써 제공되며, 응답 및 요청 변환, 엔드포인트 액세스 권한 또는 추적과 같은 추가 기능을 백엔드 서비스 위에 추가할 수도 있습니다.
다음과 같은 경우 API 게이트웨이 패턴을 사용하는 것이 좋습니다.
-
마이크로서비스의 종속성 수는 관리할 수 있으며 시간이 지나도 증가하지 않습니다.
-
호출 시스템에는 마이크로서비스의 동기 응답이 필요합니다.
-
짧은 지연 시간이 요구됩니다.
-
API 하나를 노출하여 여러 마이크로서비스에서 데이터를 수집해야 합니다.
사용 사례
이 사용 사례에서 고객은 Lambda 함수로 배포된 4개의 마이크로서비스(‘고객‘, ‘커뮤니케이션‘, ‘결제‘, ‘판매‘)로 구성된 보험 시스템에서 정기적으로 월별 결제를 합니다. ‘고객’ 마이크로서비스는 월별 결제 세부 정보로 고객 데이터베이스를 업데이트합니다. ‘판매’ 마이크로서비스는 영업 팀이 교차 판매 기회를 찾기 위해 고객에게 후속 조치를 취하는 데 도움이 되는 관련 정보로 판매 데이터베이스를 업데이트합니다. ‘커뮤니케이션’ 마이크로서비스는 결제가 성공적으로 처리된 후 고객에게 확인 이메일을 보냅니다. 마지막으로, ‘결제’ 마이크로서비스는 고객이 월별 결제를 위해 사용하는 전체 시스템입니다. 이 패턴은 웹 서비스를 사용하여 ‘고객‘, ‘판매‘ 및 ‘커뮤니케이션‘ 하위 시스템을 ‘결제‘ 마이크로서비스와 통합합니다.
이 사용 사례에서 이 패턴을 사용하는 데에는 세 가지 문제가 있습니다.
다운스트림 시스템에 동기 호출이 이루어지므로 이러한 하위 시스템으로 인한 대기 시간이 전체 응답 시간에 영향을 미칩니다.
‘결제’ 시스템이 호출 시스템에 응답하기 전에 다른 마이크로서비스의 응답을 기다리기 때문에 운영 비용이 더 많이 듭니다. 따라서 총 실행 시간은 비동기 시스템에 비해 상대적으로 더 깁니다.
오류 처리 및 재시도는 개별 마이크로서비스가 아닌 ‘결제’ 시스템 내의 각 마이크로서비스에 대해 개별적으로 처리됩니다.
다음 두 예제는 API 게이트웨이 패턴을 사용하여 여러 API 게이트웨이 또는 하나의 API 게이트웨이를 사용하여 마이크로서비스를 통합하는 방법을 간략하게 설명합니다.
다중 API 게이트웨이
다음 그림에서 각 마이크로서비스에는 자체 API 게이트웨이가 있습니다. ‘결제‘ 마이크로서비스는 개별 시스템을 호출하고 API 게이트웨이 패턴을 구현합니다.
단일 API 게이트웨이
다음 그림에서 각 마이크로서비스는 Lambda 함수로 배포되지만 모든 마이크로서비스는 동일한 API 게이트웨이를 통해 연결됩니다.
