API Gateway를 배포하기 전에 생각해봐야 할 것들

개념으로서의 Microservices는 본질적으로 Cloud-Native 애플리케이션과 거의 동의어입니다. 즉, 작은 구성 요소가 있고 함께 네트워크로 연결된 다음 느슨하게 연결된 서비스로 배포됩니다.

API는 수십 년 동안 사용되어 왔으며 API Gateway는 새로운 개념이 아닙니다. 그러나 모놀리식에서 마이크로서비스 기반 앱으로 전환하는 과정에서 업계는 XML로 인코딩된 페이로드(payload)가 있는 SOAP API에서 JSON으로 인코딩된 페이로드(payload)가 있는 REST API로 크게 이동했습니다. 기본 기술과 데이터 형식이 변경되었을 뿐만 아니라 API 구축 방식과 API에서 사용하는 메시징 및 상호 작용 스타일도 변경되었습니다.

목차

1. 마이크로서비스 및 API 관리
2. API Gateway를 배포할 때 물어볼 질문
3. API Gateway 및 Service Mesh
4. API Gateway와 하이드리드 클라우드
  4-1. 표준 클라우드 인프라의 API Gateway
  4-2. REST vs API용 메시징(Messaging)
5. 결론

1. 마이크로서비스 및 API 관리

개별 개발자가 소유하는 수백 개의 API가 있는 대규모로 분산된 환경은 그 규모와 분산된 특성으로 인해 본질적으로 문제를 야기합니다. 여러 API Gateway가 있을 수 있습니다. 각 API에 대해 하나씩, API를 구축하는 각 팀에 대해 하나씩 등입니다. API가 프로덕션에서 노출됨에 따라 보안이 중요해집니다. 예를 들어 TLS가 종단 간(end to end)으로 구성된 경우 종단 간(end to end) 트래픽이 안전한지 확인해야 합니다. 또 다른 문제는 애플리케이션 및 보안 팀의 우선 순위가 상충한다는 점입니다. DevOps는 속도를 중시하는 반면, NetOps는 조직의 자산을 보호하는 정책 준수를 위해 변경 사항을 신중하게 테스트해야 합니다.

더 빠르고 더 자주 배포하는 것은 효율적인 CI/CD 파이프라인이 있는 경우에만 작동할 수 있습니다. API Gateway가 이 파이프라인에 있을 수 있지만 API를 업데이트하고 API Gateway에 트래픽을 처리하거나 이러한 Endpoint에 대한 인증 및 액세스 제어를 수행해야 한다고 알릴 수 있습니까? 게이트웨이는 자체 API를 통해 구성해야 할 수 있습니다. 이상적으로는 API Gateway가 올바른 방식으로 업데이트될 수 있도록 전용 중앙 시스템을 통해 이러한 API 호출을 수행해야 합니다.

NGINX가 NGINX Controller와 함께 사용하는 한 가지 접근 방식은 API 인터페이스를 제공하여 API를 업데이트하고 새 API를 게시할 수 있도록 하여 애플리케이션 팀이 빠르게 이동하고 고유한 CI/CD 파이프라인을 구축할 수 있는 인터페이스를 제공하는 것입니다. 동시에 API 관리는 올바른 보안 정책이 적용될 수 있도록 중앙 위치에서 발생해야 하지만 모든 것이 느려지지는 않습니다.

2. API Gateway를 배포할 때 물어볼 질문

클라우드 공급업체는 API Gateway를 쉽게 배포할 수 있도록 합니다. 워크로드를 클라우드로 이동한 다음 인증, 속도 제한 및 라우팅을 위한 API Gateway를 설정할 수 있지만 복잡성에 대해 생각해야 합니다.

API Endpoint에는 적절한 인프라가 있을 수 있지만 지금부터 6~12개월 후에는 몇 개의 API를 갖게 될까요? 확장하거나 축소할 준비가 되어 있어야 합니다. 얼마나 많은 팀이 API를 배포하거나 변경하고 있습니까? 역할 기반 액세스 제어와 적절한 권한이 필요할 수 있습니다. API는 내부 또는 외부 사용을 위한 것입니까? 일반적으로 API가 외부에 많을수록 퍼블릭 클라우드에 배포하는 것이 더 매력적입니다.

오케스트레이션 및 컨테이너화를 위해 Kubernetes에 API를 배포할 때 질문이 바뀝니다. 그런 다음 어떤 API Gateway를 사용할 것이며 어디에 사용할 것인지 묻기 시작합니다. 클러스터 앞에 있거나 클러스터 내부에서 실행되는 서비스의 일부일 수 있습니다. Ingress Controller가 필요합니까? Ingress Controller는 불필요한 홉(hops) 및 단일 실패 지점(single points of failure)을 피할 수 있는 API Gateway가 될 수 있습니다.

3. API Gateway 및 Service Mesh

Service Mesh는 주로 마이크로서비스 기반 애플리케이션 전체의 관리 및 가시성을 향상시키는 측면에서 상당히 뜨거운 주제입니다.

Kubernetes에서 north-south 트래픽은 일반적으로 Client에서 Endpoint로의 API 호출로 구성됩니다.

그러나 초기 API 호출에 응답하려면 다른 API를 호출해야 할 수 있으며 이제 Service Mesh가 들어오는 서비스 간 통신(east-west 트래픽)이 있습니다.

Service Mesh의 목표는 더 나은 가시성을 제공하는 것입니다. east-west 트래픽, 더 많은 보안 제어(예: 상호 TLS[mTLS] 사용) 및 제어 평면으로 이를 관리하는 기능. 트래픽이 east-west 방향일 때 API Endpoint에는 API Gateway가 될 수도 있는 사이드카 프록시(Sidecar Proxy)가 있을 수 있습니다.

Sidecar Proxy는 API Gateway가 될 수 있지만 east-west를 처리하는 Sidecar Proxy와 별도로 API Gateway가 north-south 트래픽을 처리하도록 하는 것이 가장 좋습니다. Service Mesh를 사용하면 Sidecar Proxy는 본질적으로 자율적이고 보이지 않습니다. 어떤 서비스가 다른 서비스와 통신하는지 구성할 때입니다. 클라이언트는 Microservices 또는 Service Mesh가 있는지 알지 못하므로 일반적으로 API Gateway를 외부에 게시 및 공개하고 Service Mesh가 보안을 처리하고 서비스가 서로 통신하는 방식을 제어하도록 하는 방법으로 API Gateway를 남겨두는 것이 가장 좋습니다. 서비스 간 관점에서 진행 상황에 대한 가시성을 제공합니다.

4. API Gateway와 하이드리드 클라우드

여기에서 API 관리와 API Gateway의 차이점을 이해하는 것이 중요합니다. API Gateway는 클라이언트와 API Endpoint 사이에 위치하며 라우팅, 정책 및 보안을 담당하는 Data Plane입니다. 하이브리드 클라우드를 사용하면 서로 동기화해야 하는 API Gateway가 많이 있을 수 있습니다. 정책을 정의하고 구성을 푸시하고 보고하고 모든 API Gateway에 대한 가시성을 확보하려면 API 관리 Control Plane이 필요합니다. API 관리 플랫폼은 이상적으로는 인프라에 구애받지 않으므로 적절한 인프라에 API Gateway를 자유롭게 배포할 수 있습니다.

4-1. 표준 클라우드 인프라의 API Gateway

DevOps 환경에서는 API Gateway 구성을 CI/CD 파이프라인에 통합하여 게이트웨이가 게시 중인 API를 제공할 준비가 되도록 하는 것이 중요합니다. 게이트웨이를 올바르게 구성하고 배포하려면 일반적으로 조건부 논리와 사용자 지정 처리가 필요합니다. CI/CD 스크립트에서 논리를 캡처하는 대신 중앙 집중식 API 관리 시스템을 사용하여 이를 처리하십시오. 그러나 API 정의, 배포 위치, 정책 등을 API 관리 플랫폼 자체가 아니라 소스 제어 저장소에 저장하고 싶습니다. 그러면 CI/CD 파이프라인 스크립트가 리포지토리에서 정보를 가져옵니다.

4-2. REST vs API용 메시징(Messaging)

JSON REST API가 대중적으로 SOAP XML API를 추월한 지 거의 10년이 되었습니다. 동기(예: JSON REST API)와 비동기(예: Pub/Sub 메시징) 통신을 결합하는 좋은 사례가 있습니다. gRPC를 사용하면 메시지 이벤트 스트림 및 RPC 호출과 같은 양방향 스트리밍을 통해 비동기 및 동기를 모두 수행할 수 있습니다.

API Gateway는 동기 및 비동기 프로토콜을 혼합할 때 매우 중요합니다. 메시징 스타일에 관계없이 API 클라이언트가 호출을 보내는 일관된 단일 진입점(entry point)입니다. 이것은 API Client의 삶을 더 쉽게 만듭니다. 어떤 스타일을 거쳐도 소비할 수 있습니다.

5. 결론

마이크로서비스 기반 환경에서 API를 성공적으로 사용하려면 CI/CD 파이프라인의 일부로 이상적으로는 자동화된 방식으로 개발자가 API를 설계, 구현 및 게시할 수 있는 도구를 제공해야 합니다. 목표는 보안에 높은 초점을 두고 반복하는 것입니다.

현대 건축은 빠른 속도로 변화하고 있습니다. API는 여러 클라우드, 컨테이너, Kubernetes 등의 플랫폼에서 관리할 수 있습니다. API Gateway를 통해 트래픽을 제어하고 라우팅하는 새로운 접근 방식이 많이 있습니다. 하나는 컨테이너 클러스터 내에서 API를 관리하고 보호할 때 더 많은 가시성을 제공하는 Service Mesh 기능을 제공하는 Sidecar Gateway(또는 Proxy)입니다.

JSON 기반 REST 및 RPC와 같은 다양한 통신 스타일이 있으며 이러한 형식은 시간이 지남에 따라 변경될 것으로 예상합니다. 이것들은 개발자들에게 좋은 서비스를 제공하므로 API Gateway는 동기 또는 비동기, 내부 또는 외부 등 여러 언어를 지원해야 합니다.

API 또는 여러 클라우드에 걸쳐 있는 API Gateway를 처리할 때 인프라에 구애받지 않는 API 관리 플랫폼을 사용하여 API가 성장함에 따라 원활하게 이러한 API를 관리, 배포 및 보호하는 방법이 필요합니다.