기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # API 라우팅 패턴 애자일 개발 환경에서는 자율적인 팀(예: 스쿼드 및 트라이브)이 여러 마이크로서비스를 포함하는 하나 이상의 서비스를 담당합니다. 팀은 소비자가 서비스 및 작업 그룹과 상호 작용할 수 있도록 이러한 서비스를 API로 노출합니다. 호스트 이름과 경로를 사용하여 업스트림 소비자에게 HTTP API를 노출하는 세 가지 주요 방법이 있습니다. | | | **메서드** | **설명** | **예시** | | --- |--- |--- | | [**호스트 이름 라우팅**](api-routing-hostname.md) | 각 서비스를 호스트 이름으로 노출합니다. | `billing.api.example.com` | | [**경로 라우팅**](api-routing-path.md) | 각 서비스를 경로로 노출합니다. | `api.example.com/billing` | | [**헤더 기반 라우팅**](api-routing-http.md) | 각 서비스를 HTTP 헤더로 노출합니다. | `x-example-action: something` | 이 섹션에서는 요구 사항 및 조직 구조에 가장 적합한 방법을 결정하는 데 도움이 되도록 이러한 세 가지 라우팅 방법의 일반적인 사용 사례와 장단점을 간략하게 설명합니다. # 호스트 이름 라우팅 패턴 호스트 이름별 라우팅은 각 API에 고유한 호스트 이름(예: `service-a.api.example.com` 또는 `service-a.example.com`)을 지정하여 API 서비스를 격리하는 메커니즘입니다. ## 일반적인 사용 사례 호스트 이름을 사용하여 라우팅하면 서비스 팀 간에 아무 것도 공유되지 않기 때문에 릴리스에서 발생하는 마찰이 줄어듭니다. 팀은 DNS 입력부터 프로덕션 환경의 서비스 운영에 이르기까지 모든 것을 관리할 책임이 있습니다. ![\[HTTP API를 업스트림 소비자에게 노출하는 호스트 이름 라우팅 패턴.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-1.png) ## 장점 호스트 이름 라우팅은 HTTP API 라우팅을 위한 가장 간단하고 확장성이 뛰어난 방법입니다. 관련 AWS 서비스를 사용하여 이 방법을 따르는 아키텍처를 구축할 수 있습니다. [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/), [Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/), [Amazon Elastic Compute Cloud(Amazon EC2)](https://aws.amazon.com/ec2/) 또는 기타 HTTP 호환 서비스를 사용하여 아키텍처를 생성할 수 있습니다. 팀은 호스트 이름 라우팅을 사용하여 하위 도메인을 완전히 소유할 수 있습니다. 또한 특정 AWS 리전 또는 버전(예: `region.service-a.api.example.com` 또는 `dev.region.service-a.api.example.com`)에 대한 배포를 보다 쉽게 분리, 테스트 및 오케스트레이션할 수 있습니다. ## 단점 호스트 이름 라우팅을 사용하는 경우 소비자는 노출하는 각 API와 상호 작용할 때 여러 호스트 이름을 기억해야 합니다. 클라이언트 SDK를 제공하여 이 문제를 해결할 수 있습니다. 하지만 클라이언트 SDK에는 고유한 문제가 있습니다. 일례로, 롤링 업데이트, 다국어, 버전 관리, 보안 문제 또는 버그 수정으로 인한 주요 변경 사항 전달, 설명서 등을 지원해야 합니다. 호스트 이름 라우팅을 사용하는 경우 새 서비스를 생성할 때마다 하위 도메인 또는 도메인을 등록해야 합니다. # 경로 라우팅 패턴 경로별 라우팅은 여러 API 또는 모든 API를 동일한 호스트 이름으로 그룹화하고 요청 URI를 사용하여 서비스를 격리하는 메커니즘입니다(예: `api.example.com/service-a` 또는 `api.example.com/service-b`). ## 일반적인 사용 사례 대부분의 팀은 아키텍처를 단순하게 유지하기 위해 이 방식을 선택합니다. 예를 들어 개발자는 HTTP API와 상호 작용할 때 `api.example.com`과 같은 URL을 하나만 기억하면 됩니다. API 설명서는 여러 포털이나 PDF로 분할되지 않고 함께 보관되는 경우가 많기 때문에 보통 이해하기가 더 쉽습니다. 경로 기반 라우팅은 HTTP API 공유를 위한 간단한 메커니즘으로 간주됩니다. 하지만 구성, 권한 부여, 통합, 다중 홉으로 인한 추가 지연 시간 등의 운영 오버헤드가 수반됩니다. 또한 잘못된 구성으로 인해 모든 서비스가 중단되지 않도록 하려면 완성도 높은 변경 관리 프로세스가 필요합니다. AWS에서는 여러 방법으로 API를 공유하고 올바른 서비스로 효과적으로 라우팅할 수 있습니다. 다음 섹션에서는 HTTP 서비스 역방향 프록시, API Gateway 및 Amazon CloudFront라는 세 가지 접근 방식에 대해 설명합니다. API 서비스를 통합하기 위한 방법으로 제안된 접근 방식 중 AWS에서 실행 중인 다운스트림 서비스에 의존하는 방식은 없습니다. 서비스는 HTTP와 호환되는 한 문제 없이 또는 어떤 기술로도 어디서든 실행될 수 있습니다. ## HTTP 서비스 역방향 프록시 [NGINX](https://www.f5.com/go/product/welcome-to-nginx)와 같은 HTTP 서버를 사용하여 동적 라우팅 구성을 생성할 수 있습니다. [Kubernetes](https://kubernetes.io/) 아키텍처에서는 경로를 서비스와 매칭하는 수신 규칙을 생성할 수도 있습니다. (이 가이드에서는 Kubernetes 수신에 대해 다루지 않습니다. 자세한 내용은 [Kubernetes 설명서](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource)를 참조하세요.) NGINX의 다음 구성은 `api.example.com/my-service/`의 HTTP 요청을 `my-service.internal.api.example.com`에 동적으로 매핑합니다. ``` server { listen 80; location (^/[\w-]+)/(.*) { proxy_pass $scheme://$1.internal.api.example.com/$2; } } ``` 다음 다이어그램은 HTTP 서비스 역방향 프록시 방법을 보여 줍니다. ![\[경로 라우팅에 HTTP 서비스 역방향 프록시 사용\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png) 요청 처리를 시작하는 데 추가 구성을 사용하지 않고 다운스트림 API가 지표와 로그를 수집할 수 있도록 하는 일부 사용 사례에는 이 접근 방식을 사용해도 충분할 수 있습니다. 운영 프로덕션 준비를 갖추려면 스택의 모든 수준에 관찰성을 추가하거나, 추가 구성을 추가하거나, 속도 제한 또는 사용량 토큰과 같은 고급 기능을 허용하도록 API 수신 지점을 사용자 지정하는 스크립트를 추가해야 합니다. ### 장점 HTTP 서비스 역방향 프록시 방식의 궁극적인 목표는 API를 단일 도메인으로 통합하여 모든 API 소비자에게 일관되게 보이도록 확장 가능하고 관리하기 쉬운 접근 방식을 만드는 것입니다. 또한 이 접근 방식을 통해 서비스 팀은 배포 후 오버헤드를 최소화하면서 자체 API를 배포하고 관리할 수 있습니다. [AWS X-Ray](https://aws.amazon.com/xray/), [AWS WAF](https://aws.amazon.com/waf/) 등 추적을 위한 AWS 관리형 서비스는 여기에도 적용됩니다. ### 단점 이 접근 방식의 가장 큰 단점은 필요한 인프라 구성 요소를 테스트하고 관리하는 작업 부담이 크다는 것이지만, 사이트 신뢰성 엔지니어링(SRE) 팀이 있으면 문제가 되지 않습니다. 이 방법에는 비용 한계점이 있습니다. 작은 볼륨에서 중간 볼륨까지는 이 가이드에서 설명하는 다른 방법보다 비용이 많이 듭니다. 하지만 큰 볼륨에서는 매우 비용 효율적입니다(초당 트랜잭션 약 10만 건 이상). ## API Gateway [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 서비스(REST API 및 HTTP API)는 HTTP 서비스 역방향 프록시 방법과 유사한 방식으로 트래픽을 라우팅할 수 있습니다. HTTP 프록시 모드에서 API Gateway를 사용하면 여러 서비스를 최상위 하위 도메인 `api.example.com`의 진입점으로 래핑한 다음 요청을 중첩 서비스로 프록시할 수 있는 간단한 방법이 제공됩니다(예: `billing.internal.api.example.com`). 루트 또는 코어 API Gateway에 있는 모든 서비스의 모든 경로를 매핑하여 지나치게 세분화하는 것은 바람직하지 않습니다. 대신 `/billing/*`과 같은 와일드카드 경로를 사용하여 요청을 결제 서비스에 전달합니다. 루트 또는 코어 API Gateway의 경로를 모두 매핑하지는 않으므로, API가 변경될 때마다 루트 API 게이트웨이를 업데이트할 필요가 없어 API의 유연성이 향상됩니다. ![\[API Gateway를 통한 경로 라우팅.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png) ### 장점 요청 속성 변경과 같은 더 복잡한 워크플로를 제어하기 위해 REST API는 Apache Velocity Template Language(VTL)를 노출하여 사용자가 요청 및 응답을 수정할 수 있도록 하고 있습니다. REST API는 다음과 같은 추가 이점을 제공할 수 있습니다. + [AWS Identity and Access Management(IAM)를 사용한 Auth N/Z](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html), [Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) 또는 [AWS Lambda 권한 부여자](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) + [추적을 위한 AWS X-Ray](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html) + [와의 통합AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) + [기본 속도 제한](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + 소비자를 여러 티어로 버킷팅하기 위한 사용량 토큰(API Gateway 설명서에서 [처리량 향상을 위해 API 요청 조절](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 참조) ### 단점 볼륨이 큰 경우 일부 사용자에게는 비용이 문제가 될 수 있습니다. ## CloudFront [Amazon CloudFront](https://aws.amazon.com/cloudfront/)의 [동적 오리진 선택 기능](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html)을 사용하여 요청을 전달할 오리진(서비스)을 조건부로 선택할 수 있습니다. 이 기능을 사용하면 `api.example.com`과 같은 단일 호스트 이름을 통해 여러 서비스를 라우팅할 수 있습니다. ### 일반적인 사용 사례 라우팅 로직은 Lambda@Edge 함수 내에 코드로 존재하므로, A/B 테스트, canary 릴리스, 기능 플래깅, 경로 재작성과 같은 고도로 맞춤화 가능한 라우팅 메커니즘을 지원합니다. 다음 다이어그램에 이 내용이 잘 설명되어 있습니다. ![\[CloudFront를 통한 경로 라우팅.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png) ### 장점 API 응답 캐싱이 필요한 경우 이 방법은 서비스 컬렉션을 단일 엔드포인트로 통합하는 좋은 방법이 됩니다. API 컬렉션을 통합하는 비용 효율적인 방법입니다. 또한 CloudFront는 [필드 레벨 암호화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html)는 물론, 기본 속도 제한 및 기본 ACL을 지원하기 위한 AWS WAF와의 통합을 지원합니다. ### 단점 이 방법은 통합 가능한 최대 250개의 오리진(서비스)을 지원합니다. 이 한도는 대부분의 배포 사례에서 충분하지만 서비스 포트폴리오를 확장함에 따라 많은 수의 API로 인해 문제가 발생할 수 있습니다. Lambda@Edge 함수를 업데이트하는 데 현재 몇 분 정도 걸립니다. 또한 CloudFront가 모든 접속 지점에 변경 사항을 모두 전파하는 데 최대 30분이 걸립니다. 따라서 업데이트가 완료될 때까지 추가 업데이트가 차단됩니다. # HTTP 헤더 라우팅 패턴 헤더 기반 라우팅을 사용하면 HTTP 요청에 HTTP 헤더를 지정하여 각 요청별로 적절한 서비스를 타겟팅할 수 있습니다. 예를 들어 `x-service-a-action: get-thing` 헤더를 보내면 `Service A`에서 `get thing`을 실행할 수 있습니다. 이 경우에도 요청 경로는 작업하려는 리소스에 대한 지침을 제공하기 때문에 중요합니다. 작업에 HTTP 헤더 라우팅을 사용하는 것 외에, 버전 라우팅, 기능 플래그 활성화, A/B 테스트 또는 이와 유사한 요구 사항을 위한 메커니즘으로 HTTP 헤더 라우팅을 사용할 수도 있습니다. 실제로는 강력한 API를 만들기 위해 헤더 라우팅을 다른 라우팅 방법 중 하나와 함께 사용하게 될 가능성이 높습니다. HTTP 헤더 라우팅 아키텍처에서는 일반적으로 다음 다이어그램과 같이 올바른 서비스로 라우팅하고 응답을 반환하는 마이크로서비스 앞에 단순한 라우팅 계층을 둡니다. 이 라우팅 계층은 모든 서비스를 포함하거나 버전 기반 라우팅과 같은 작업을 지원하는 일부 서비스만 포함할 수 있습니다. ![\[HTTP 헤더 라우팅.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/images/routing-5.png) ## 장점 구성 변경은 최소한의 작업으로 이루어지며 쉽게 자동화할 수 있습니다. 또한 이 방법은 유연하며 서비스에서 원하는 특정 작업만 노출할 수 있는 창의적인 방법을 지원합니다. ## 단점 호스트 이름 라우팅 방법과 마찬가지로, HTTP 헤더 라우팅은 사용자가 클라이언트를 완전히 제어할 수 있고 사용자 지정 HTTP 헤더를 조작할 수 있다고 가정합니다. 프록시, 콘텐츠 배포 네트워크(CDN), 로드 밸런서가 헤더 크기를 제한할 수 있습니다. 이 제한이 문제가 되는 경우는 드물지만, 추가하는 헤더와 쿠키의 수에 따라 문제가 될 수도 있습니다.