앞선 글
API 게이트웨이의 개념에 대해서는 어느 정도 알고 있었지만 정확이 어떤 개념으로, 어떤 방식으로 구현되고 어떤 구조로 설계되는지 실제 개발에 앞서 먼저 알아보고자 이 글을 작성합니다.
이 글은 다음 글을 번역한 글입니다: The Concept Of An API Gateway
해당 글을 통해 좀 더 자세한 정보를 이해 한 뒤 Ocelot을 사용해 API 게이트웨이를 구현하는 글까지 작성할 예정입니다.
서론
일반적으로 게이트웨이는 두 개의 컴포넌트가 특정 기능을 수행할 수 있도록 하는 커넥터 역할을 하는 통로입니다. API 게이트웨이도 크게 다르지 않습니다. 이것은 우리들이 이해해야 할 중요한 주제입니다.
API 게이트웨이가 무엇인지 빠르게 알아보기.
API 게이트웨이는 API와 다양한 백엔드 서비스 사이에 배치된 가상의 통로와 같습니다. 요청과 호출 처리에 적합한 스테이션이나 서비스와 매치시키고 대상 리소스로 다시 요청을 보냅니다.
기업과 데이터를 중심으로 하는 조직을 위한 API에는 추가 보안 계층, 액세스 모니터링, 사용량 제한과 같은 기능이 필요합니다. 게이트웨이는 요청 횟수, 데이터 사용량, 요청 소스 유효성 검사, 액세스 및 사용자 인증을 처리해 추가 기능을 제공합니다.
API 게이트웨이의 아이디어는 규칙 지향적인 리소스 표준을 중심으로 여러 개의 비조정 서비스가 중앙 집중식 통신 생태계를 공유할 수 있도록 합니다.
왜 API 게이트웨이를 사용할까?
초보자에게는 API 호출을 적절하게 감동하는 이상적인 수단으로만 보일 수 있습니다. 하지만 API 게이트웨이는 더 많은 기능을 수행합니다.
- 인증, 속도 제한과 같은 기능으로 API 남용을 검사하는데 도움을 줍니다.
- 개발자가 API가 사용되는 방법에 대한 다양한 시나리오를 찾는데 도움을 줍니다.
- 수익을 창출하는 설루션의 경우 백엔드 프로세스와 청구 시스템 간의 원활한 관계를 구성하도록 합니다.
- 마이크로 서비스 배포의 경우 다양한 애플리케이션에 대한 특성 요청을 구성하도록 합니다.
- 업데이트가 발생하는 경우에도 API 유지 관리, 업그레이드, 현대화에 필요한 모든 리소스를 확보하는데 도움이 됩니다.
- API 게이트웨이는 API에 발생하는 모든 것을 관찰할 수 있으므로 여러 개의 API 처리에 도움을 줍니다.
API 게이트웨이는 어떻게 동작할까?
애플리케이션 테스팅과 사용에는 수많은 데이터 교환 작업이 포함됩니다. 이러한 유형의 통신에는 사전 준비가 필요합니다. 문제들을 분류하기 위해서 API 게이트웨이는 다양한 요청을 수신할 수 있는 중앙 플랫폼으로써의 역할을 수행합니다.
이 과정에서 여러 API 호출이 모이고 인증되어 적절한 API로 리디렉션 됩니다.
마이크로 서비스 생태계에서 특정 마이크로 서비스의 요청에 대한 적절한 진입을 만들어 냅니다. 또한 접근성과 수행 기준을 설정합니다.
게다가 API 게이트웨이는 서비스 검색, API 프로토콜 변환, 비즈니스 로직 처리, 캐시 관리, 네트워크 트래픽 지원, API 모니터링과 같은 기능을 다룹니다.
전체 API 관리에서 게이트웨이의 중요성.
API 호출을 처리하고 담당하는 곳으로 분산시킬 수 있다는 것은 API 게이트웨이를 API 관리에서 없어서는 안 될 존재로 만듭니다. 여기에서 비율 제한, 알림, 분석, 인증, 정책, 비용 계산, 안정성과 같은 기능을 수행합니다.
마이크로 서비스 아키텍처를 위한 API 게이트웨이.
수많은 작은 컴포넌트들이 마이크로 서비스를 구성합니다. 이러한 접근 방식은 개발자가 사용자 경험을 향상하는데 도움이 됩니다. 여기에는 API 게이트웨이가 반드시 필요합니다. 결국 API 게이트웨이는 이러한 컴포넌트에 대한 번역기와 같은 역할을 하여 신속하고 오류 없는 API 구현을 보장합니다.
일반적으로 게이트웨이는 최대한의 클라이언트 요청을 처리하고 모든 요청을 중앙 집중식으로 유지하고 결합할 수 있습니다. 이렇게 하면 클라이언트와 응용프로그램 간의 통신에 소요되는 시간이 줄어들어 운영 비용도 절감할 수 있게 됩니다.
API 게이트웨이를 사용하여 얻는 이점.
게이트웨이를 배치하는 것은 API 개발에서부터 관리, 운영 비용에 이르기까지 모든 것이 한 번에 처리되므로 엔드유저, 애플리케이션, API, 설루션 개발자 모두에게 좋습니다.
효율적인 API 개발.
API게이트웨이는 특정 API의 다양한 버전을 실행하고 가능한 한 최소한의 노력으로 API를 테스트, 반복, 업데이트할 수 있는 기능을 개발자에게 제공합니다. API 개발은 빠르고 똑같이 효율적이 됩니다. API 게이트웨이는 API 호출과 데이터 전송에 대해서만 책임을 지므로 이행해야 하는 최소한의 책무는 없습니다.
모든 규모에 대한 생산성.
API 게이트웨이는 개발자가 최소한의 지연시간으로 작업을 가능하게 하여 엔드 유저에게 더 나은 경험을 제공할 수 있도록 지원합니다. 또한 트래픽 제한과 API 요청에 대한 인증 기능을 가능하게 합니다. 이 두 기능은 백엔드 API 개발 팀이 트래픽 급증을 처리하고 지속적인 API 성능을 보장하는데 도움이 됩니다.
간편한 모니터링.
API 게이트웨이는 모든 것을 통합된 지점으로 가져오고 API 호출 정보, 오류, 지연과 관련된 세부 정보와 같은 데이터 통합에 대한 가시성을 제공해 줍니다. 모든 측정 항목에 즉시 접근할 수 있으므로 개발자는 모든 단계에서 API 성능을 추적하고 숨겨진 경고를 찾을 수 있습니다.
모든 규모에 대한 비용 절감.
API 게이트웨이는 여러 구독 옵션과 함께 제공되며 API 요청에 따라 패키지를 자유롭게 선택할 수 있습니다. 일반적으로 0.9 달러의 비용으로 백만 개의 API 요청을 처리할 수 있습니다. 이러한 유연한 가격 정책으로 API 개발 비용을 통제할 수 있게 합니다.
API 게이트웨이 사용의 문제점.
안전성.
API 호출에서 보안 관행을 구현하고 성능을 추적하는 것은 어렵습니다. 이 작업에는 처리해야 할 다양한 작은 요청이 존재하므로 마이크로 서비스 생태계의 탭이 됩니다. 또한 내부와 외부 API에 대한 다양한 안전 관행을 생각해야 합니다. 이것은 훨씬 더 많은 작업을 의미합니다.
지속 가능성과 신뢰성.
API 게이트웨이가 여러 요청을 결합하게 되므로 만약 게이트웨이가 동작하지 않으면 전체 API 인프라가 붕괴됩니다.
복잡성을 유발하는 높은 수준의 종속성.
효과적인 작업을 위해서는 모든 마이크로 서비스를 추가해 API 게이트 업데이트를 유지 관리하는 것이 중요합니다. 단일 애플리케이션이 수백만 개의 마이크로 서비스로 바뀌면 너무나 많은 일이 발생합니다. 이러한 시나리오에서 게이트웨이를 업데이트하는 것은 끝나지 않는 작업이 될 수도 있습니다.
Service Mash vs. API 게이트웨이
제어의 중앙 집중화를 촉진하는 API 게이트웨이와 달리 서비스 매쉬는 다양한 마이크로 서비스를 이용해 애플리케이션에서 고유한 기능을 수행하도록 합니다. 서비스 매쉬에서 마이크로 서비스 간의 교환을 중재하기 위해 API 게이트웨이를 사용하면 보안 수준과 작업 실행 속도가 개선될 수 있습니다.
목적
API 게이트웨이는 조직, DB, 외부의 호출이나 요청을 안전하게 라우팅하고 서비스 매쉬는 마이크로 서비스를 사용해 조직 네트워크 내에서 플랫폼 독립성을 향상합니다.
동작
API 게이트웨이는 외부 네트워크와 상호작용하고 조직 네트워크에서 요청을 전달할 수 있습니다. 서비스 매쉬는 조직 내 네트워크 내부에서 동작합니다.
책임.
API 게이트웨이는 네트워크 API의 관리와 안전에 대한 책임을 갖습니다. 서비스 매쉬는 시스템과 네트워크의 성능과 휴대성을 향상하며 서비스 매쉬에서 API는 외부로부터 서비스 매쉬를 숨기고 보호합니다.
보안 메서드.
API 게이트웨이에서는 자동화와 정책을 사용할 수 있습니다. 서비스 매쉬에서는 보안 전략을 수동으로 구현해야 합니다.
맺는 글
이상으로 간단하게 API 게이트웨이가 무엇인지, 어떻게 구성되는지, 이점이 무엇인지에 대해 알아보았습니다. 이 글이 API 게이트웨이의 개념을 이해하는데 도움이 되셨길 바랍니다.
'Programming' 카테고리의 다른 글
[RabbitMQ] VirtualHost란? (0) | 2023.03.07 |
---|---|
[Mac] xcrun: error: invalid active developer path (0) | 2022.12.12 |
Blazor Server vs Blazer WebAssembly: Blazor 호스팅 모델의 차이점 (0) | 2022.09.22 |
Blazor vs React (0) | 2022.09.21 |
[FTP] vsftpd TLS 설정 (0) | 2022.09.15 |