Amazon MSK 서버리스 클러스터 유형입니다. Apache Kafka 용 Amazon Managed Streaming (Amazon MSK)를 사용하면 클러스터 용량을 관리하고 확장할 필요 없이 Apache Kafka를 쉽게 실행할 수 있습니다. MSK 서버리스는 컴퓨팅 및 스토리지 리소스를 자동으로 프로비저닝하고 확장합니다. MSK 서버리스를 사용하면 필요에 따라 Apache Kafka를 사용할 수 있으며 스트리밍하고 보관하는 데이터에 대해 사용량에 따라 비용을 지불할 수 있습니다.
여러 VPC와 여러 계정에 걸쳐 인프라를 배포하는 것이 모범 사례로 간주되어 격리 경계를 유지하면서 확장성을 촉진합니다. 다중 계정 환경에서 Kafka 생산자와 소비자는 동일한 VPC 내에 존재할 수 있습니다. 그러나 이들은 종종 서로 다른 VPC에 위치하며 때로는 동일한 계정, 다른 계정 또는 여러 다른 계정에 위치합니다. MSK 서버리스 클러스터에 대한 액세스를 동일한 AWS 계정 및 여러 AWS 계정 내 여러 VPC의 생산자와 소비자로 확장할 수 있는 솔루션이 필요합니다. 솔루션은 확장 가능하고 유지 관리가 간단해야 합니다.
이 게시물에서는 MSK 서버리스 교차 VPC 및 교차 계정 액세스 연결 옵션을 다루는 여러 솔루션 접근 방식을 안내하고 각 접근 방식의 장점과 제한 사항에 대해 논의합니다.
MSK 서버리스 연결 및 인증
MSK 서버리스 클러스터가 생성되면 AWS는 사용자를 대신하여 클러스터 인프라를 관리하고 다음에서 제공하는 VPC 엔드포인트를 통해 프라이빗 연결을 VPC로 다시 확장합니다. AWS 프라이빗링크. 모든 기본 브로커의 기록을 보유하는 부트스트랩 서버를 통해 클러스터에 대한 연결을 부트스트랩합니다.
생성 시 FQDN(정규화된 도메인 이름)이 클러스터 부트스트랩 서버에 할당됩니다. 부트스트랩 서버 FQDN의 일반 형식은 다음과 같습니다. boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, 클러스터 브로커는 다음 형식을 따릅니다. bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, 어디에 ClusterUniqueID.xx 클러스터에 고유하며 bxxxx 동적 브로커 범위입니다(b0001, b0037 및 b0523은 특정 시점에 할당된 브로커 중 일부일 수 있음). 클러스터에 할당된 브로커는 동적이며 시간이 지남에 따라 변경되지만 부트스트랩 주소는 클러스터에 대해 동일하게 유지된다는 점에 주목할 가치가 있습니다. 클러스터와의 모든 통신은 필요할 때 활성 브로커 목록으로 응답할 수 있는 부트스트랩 서버에서 시작됩니다. 적절한 Kafka 통신을 위해서는 MSK 클라이언트가 부트스트랩 서버와 모든 브로커의 도메인 이름을 확인할 수 있어야 합니다.
클러스터 생성 시 클러스터와 통신할 VPC를 지정합니다(클러스터와 동일한 계정에 최대 5개의 VPC). 클러스터 생성 중에 지정된 각 VPC에 대해 클러스터 VPC 엔드포인트가 부트스트랩 서버 목록과 최신 상태로 유지되는 모든 동적 브로커 목록을 포함하는 프라이빗 호스팅 영역과 함께 생성됩니다. 프라이빗 호스팅 영역을 사용하면 클러스터 생성 중에 정의된 연결된 VPC 내에서 각 VPC 엔드포인트까지 부트스트랩 서버 및 브로커의 FQDN을 쉽게 확인할 수 있습니다.
교차 계정 액세스
Kafka 생산자 및 소비자의 개인 연결을 MSK 서버리스 클러스터로 확장하려면 개인 연결, 인증 및 권한 부여, DNS 확인이라는 세 가지 주요 측면을 고려해야 합니다.
다음 다이어그램은 가능한 연결 옵션을 강조합니다. 다이어그램에는 데모 목적으로 여기에 모두 표시되어 있지만 대부분의 경우 아키텍처에 따라 이러한 옵션 중 하나 이상을 사용하며 동일한 설정에서 모두 사용할 필요는 없습니다.
이 섹션에서는 다양한 연결 옵션과 그 장단점을 논의합니다. 또한 관련 연결 옵션과 관련된 인증 및 DNS 확인 측면도 다룹니다.
비공개 연결 계층
이것이 기본 개인 네트워크 연결입니다. VPC 피어링을 사용하여 이 연결을 달성할 수 있습니다. AWS 전송 게이트웨이, 또는 PrivateLink(위 다이어그램에 표시된 대로)입니다. VPC 피어링 설정을 단순화하지만 전이적 라우팅에 대한 지원이 부족합니다. 대부분의 경우 피어링은 VPC 수가 제한되어 있거나 일반적으로 VPC가 측면 연결이나 전이적 라우팅 없이 제한된 수의 핵심 서비스 VPC와 통신하는 경우에 사용됩니다. 반면, AWS Transit Gateway는 전이적 라우팅을 촉진하고 VPC 수가 많을 때, 특히 측면 연결이 필요할 때 아키텍처를 단순화할 수 있습니다. PrivateLink는 전체 VPC 간 연결을 노출하지 않고 VPC 또는 계정 전체에서 단방향으로 특정 리소스에 대한 연결을 확장하여 격리 계층을 추가하는 데 더 적합합니다. PrivateLink는 Transit Gateway 또는 VPC 피어링에서 지원되지 않는 CIDR이 겹치는 경우에 유용합니다. PrivateLink는 연결된 당사자가 별도로 관리되는 경우와 단방향 연결 및 격리가 필요한 경우에도 유용합니다.
연결 옵션으로 PrivateLink를 선택하는 경우 네트워크 로드 밸런서 (NLB) 등록된 대상이 있는 IP 유형 대상 그룹이 MSK 서버리스 클러스터의 영역 엔드포인트 IP 주소로 설정되어 있습니다.
클러스터 인증 및 승인
생산자와 소비자가 클러스터에 액세스할 수 있으려면 비공개 연결을 갖고 부트스트랩 서버 및 브로커 도메인 이름을 확인할 수 있는 것 외에도 적절한 자격 증명으로 클라이언트를 구성해야 합니다. MSK 서버리스 지원 AWS 자격 증명 및 액세스 관리 (IAM) 인증 및 권한 부여. 교차 계정 액세스의 경우 MSK 클라이언트는 클러스터에 액세스하기 위한 적절한 자격 증명이 있는 역할을 맡아야 합니다. 이 게시물은 주로 계정 간 연결 및 이름 확인 측면에 중점을 둡니다. 교차 계정 인증 및 권한 부여에 대한 자세한 내용은 다음을 참조하세요. GitHub 레포.
DNS 확인
조직 전체의 계정에 있는 Kafka 생산자와 소비자가 중앙 집중식 MSK 서버리스 클러스터에서 생산하고 소비할 수 있으려면 클러스터 부트스트랩 서버와 각 클러스터 브로커의 FQDN을 확인할 수 있어야 합니다. 브로커 할당의 동적 특성을 이해하면 솔루션은 이러한 요구 사항을 수용해야 합니다. 다음 섹션에서는 요구 사항의 이 부분을 충족할 수 있는 방법을 설명합니다.
클러스터 교차 계정 DNS 확인
이제 MSK 서버리스의 작동 방식, 개인 연결 확장 방식, 인증 및 권한 부여 요구 사항에 대해 논의했으므로 클러스터에서 DNS 확인이 작동하는 방식에 대해 논의하겠습니다.
클러스터 생성 중 클러스터와 연결된 모든 VPC에 대해 VPC 엔드포인트가 다음과 함께 생성됩니다. 프라이빗 호스팅 영역. 프라이빗 호스팅 영역을 사용하면 각 해당 VPC 내에서 클러스터 부트스트랩 서버 및 동적으로 할당된 브로커의 FQDN에 대한 이름 확인이 가능합니다. 이는 클러스터 생성 중에 추가된 VPC 내에서 요청이 들어오는 경우에 잘 작동합니다. 왜냐하면 필요한 VPC 엔드포인트와 관련 프라이빗 호스팅 영역이 이미 있기 때문입니다.
클러스터 생성 중에 포함되지 않은 동일한 계정 내의 다른 VPC와 다른 계정에 있을 수 있는 다른 VPC로 이름 확인을 확장할 수 있는 방법에 대해 논의해 보겠습니다.
VPC 피어링, PrivateLink, Transit Gateway 등 아키텍처 요구 사항에 가장 적합한 프라이빗 연결 옵션을 이미 선택하셨습니다. 클러스터 액세스를 용이하게 하기 위해 올바른 IAM 자격 증명이 있는 역할을 맡도록 MSK 클라이언트도 구성했다고 가정하면 이제 연결의 이름 확인 측면을 해결해야 합니다. VPC 피어링, Transit Gateway 및 PrivateLink를 사용하여 다양한 연결 옵션을 나열했지만 대부분의 경우 이러한 연결 옵션 중 하나 또는 두 개만 존재한다는 점은 주목할 가치가 있습니다. 반드시 모두 가질 필요는 없습니다. 옵션을 보여주기 위해 여기에 나열되어 있으며 아키텍처와 요구 사항에 가장 적합한 옵션을 자유롭게 선택할 수 있습니다.
다음 섹션에서는 DNS 확인을 해결하는 두 가지 방법을 설명합니다. 각 방법에는 장점과 제한 사항이 있습니다.
프라이빗 호스팅 영역
다음 다이어그램에서는 솔루션 아키텍처와 해당 구성 요소를 강조합니다. 다이어그램을 단순화하고 이 섹션에 필요한 보다 관련성 있는 세부 정보를 위한 공간을 확보하기 위해 일부 연결 옵션을 제거했습니다.
솔루션은 프라이빗 호스팅 영역을 생성하는 것부터 시작하고 이어서 VPC 연결을 생성합니다.
프라이빗 호스팅 영역 생성
이름 확인을 위한 프라이빗 호스팅 영역을 생성하는 것부터 시작합니다. 솔루션을 확장 가능하고 유지 관리하기 쉽게 만들기 위해 동일한 MSK 서버리스 클러스터 계정에 이 프라이빗 호스팅 영역을 생성하도록 선택할 수 있습니다. 어떤 경우에는 중앙 집중식 네트워킹 계정에서 프라이빗 호스팅 영역을 생성하는 것이 선호됩니다. MSK 서버리스 클러스터 계정에 프라이빗 호스팅 영역을 생성하면 MSK 클러스터와 함께 프라이빗 호스팅 영역을 중앙 집중식으로 관리할 수 있습니다. 그런 다음 중앙 집중식 프라이빗 호스팅 영역을 동일한 계정 내 또는 다른 다른 계정의 VPC와 연결할 수 있습니다. 네트워킹 계정에서 프라이빗 호스팅 영역을 중앙 집중화하도록 선택하는 것도 고려해야 할 실행 가능한 솔루션이 될 수 있습니다.
프라이빗 호스팅 영역의 목적은 부트스트랩 서버뿐만 아니라 동적으로 할당된 모든 클러스터 연결 브로커의 FQDN을 확인할 수 있도록 하는 것입니다. 앞에서 설명한 대로 부트스트랩 서버 FQDN 형식은 다음과 같습니다. boot-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com, 클러스터 브로커는 다음 형식을 사용합니다. bxxxx-ClusterUniqueID.xx.kafka-serverless.Region.amazonaws.com과 bxxxx 브로커 ID입니다. 기본 도메인이 다음과 같이 설정된 새 프라이빗 호스팅 영역을 생성해야 합니다. kafka-serverless.Region.amazonaws.com, A-Alias 레코드를 사용하여 *.kafka-serverless.Region.amazonaws.com MSK 클러스터 VPC에 있는 MSK 서버리스 클러스터의 지역 VPC 엔드포인트를 가리킵니다. 이는 클러스터를 대상으로 하는 모든 트래픽을 프라이빗 호스팅 영역에 지정한 기본 클러스터 VPC 엔드포인트로 전달하기에 충분해야 합니다.
이제 프라이빗 호스팅 영역을 생성했으므로 이름 확인이 작동하려면 MSK 클러스터(생산자 또는 소비자)용 클라이언트가 있는 모든 VPC와 프라이빗 호스팅 영역을 연결해야 합니다.
프라이빗 호스팅 영역을 동일한 계정의 VPC와 연결
MSK 클러스터와 동일한 계정에 있고 클러스터 생성 중 구성에 포함되지 않은 VPC의 경우 다음을 사용하여 생성된 프라이빗 호스팅 영역에 연결할 수 있습니다. AWS 관리 콘솔 프라이빗 호스팅 영역 설정을 편집하고 해당 VPC를 추가합니다. 자세한 내용은 다음을 참조하세요. 프라이빗 호스팅 영역에 더 많은 VPC 연결.
교차 계정 VPC에서 프라이빗 호스팅 영역 연결
MSK 클러스터 계정이 아닌 다른 계정에 있는 VPC의 경우 다음을 참조하세요. Amazon VPC와 다른 AWS 계정으로 생성한 프라이빗 호스팅 영역 연결. 주요 단계는 다음과 같습니다.
- VPC 연결 승인 생성 프라이빗 호스팅 영역이 생성된 계정(이 경우 MSK 서버리스 클러스터 계정과 동일한 계정)에서 호스팅 영역과 연결할 원격 VPC에 권한을 부여합니다.
- VPC를 프라이빗 호스팅 영역과 연결 MSK 클라이언트가 있는 VPC가 있는 계정(원격 계정)에서 이전에 생성한 연결 권한을 참조합니다.
- VPC 승인 삭제 VPC를 호스팅 영역과 연결하려면:
권한 부여를 삭제해도 연결에는 영향을 주지 않으며 나중에 VPC를 호스팅 영역과 다시 연결하지 못하게 될 뿐입니다. VPC를 호스팅 영역과 다시 연결하려면 이 절차의 1단계와 2단계를 반복해야 합니다.
VPC에는 다음이 있어야 합니다. enableDnsSupport 과 enableDnsHostnames 이것이 작동하려면 DNS 속성이 활성화됩니다. 이 두 가지 설정은 VPC DNS 설정에서 구성할 수 있습니다. 자세한 내용은 다음을 참조하세요. VPC의 DNS 속성.
이러한 절차는 VPC 피어링 또는 Transit Gateway를 사용하여 연결을 확장하는 경우 모든 원격 계정에 적합합니다. 연결 옵션이 PrivateLink를 사용하는 경우 대신 원격 계정(PrivateLink VPC 엔드포인트가 있는 계정)에서 프라이빗 호스팅 영역을 생성해야 합니다. 또한 이전 다이어그램에 표시된 대로 MSK 클러스터 엔드포인트 대신 PrivateLink 엔드포인트로 확인되는 A-별칭 레코드를 생성해야 합니다. 이렇게 하면 PrivateLink 끝점에 대한 이름 확인이 쉬워집니다. 다른 VPC가 동일한 PrivateLink 설정을 통해 클러스터에 액세스해야 하는 경우 앞서 설명한 것과 동일한 프라이빗 호스팅 영역 연결 절차를 따르고 다른 VPC를 PrivateLink VPC용으로 생성된 프라이빗 호스팅 영역과 연결해야 합니다.
제한 사항
프라이빗 호스팅 영역 솔루션에는 몇 가지 주요 제한 사항이 있습니다.
첫째, 개인 호스팅 영역의 기본 도메인으로 kafka-serverless.Region.amazonaws.com을 사용하고 있고 A-Alias 레코드는 다음을 사용하기 때문입니다. *.kafka-serverless.Region.amazonaws.com, 이 프라이빗 호스팅 영역과 연결된 모든 VPC에서 시작되는 MSK 서버리스 서비스에 대한 모든 트래픽은 호스팅 영역 A-별칭 레코드에 지정한 하나의 특정 클러스터 VPC 지역 엔드포인트로 전달됩니다.
이 솔루션은 중앙 집중식 서비스 VPC에 MSK 서버리스 클러스터가 하나 있는 경우에 유효합니다. 여러 MSK 서버리스 클러스터에 대한 액세스를 제공해야 하는 경우 동일한 솔루션을 사용할 수 있지만 중앙 집중식 접근 방식이 아닌 분산형 프라이빗 호스팅 영역 접근 방식을 채택할 수 있습니다. 분산 프라이빗 호스팅 영역 접근 방식에서는 각 프라이빗 호스팅 영역이 특정 클러스터를 가리킬 수 있습니다. 특정 프라이빗 호스팅 영역과 연결된 VPC는 특정 프라이빗 호스팅 영역 아래에 나열된 각 클러스터하고만 통신합니다.
또한 *.kafka-serverless.Region.amazonaws.com을 확인하는 프라이빗 호스팅 영역과 VPC 연결을 설정한 후에는 해당 VPC는 해당 특정 프라이빗 호스팅 영역에 정의된 클러스터하고만 통신할 수 있으며 다른 클러스터는 통신할 수 없습니다. . 이 규칙의 예외는 동일한 클라이언트 VPC 내에 로컬 클러스터가 생성되는 경우입니다. 이 경우 VPC 내의 클라이언트는 로컬 클러스터하고만 통신할 수 있습니다.
또한 PrivateLink를 사용하면 클러스터당 PrivateLink와 프라이빗 호스팅 영역을 생성하고 앞서 설명한 구성 단계를 복제하여 여러 클러스터를 수용할 수 있습니다.
분산 프라이빗 호스팅 영역 또는 PrivateLink를 사용하는 두 솔루션 모두 각 클라이언트 VPC에 대해 연결된 프라이빗 호스팅 영역이 구성된 하나의 MSK 서버리스 클러스터와만 통신할 수 있다는 제한 사항이 여전히 적용됩니다.
다음 섹션에서는 또 다른 가능한 솔루션에 대해 논의합니다.
해석기 규칙 및 AWS Resource Access Manager
다음 다이어그램은 다음을 사용하여 솔루션에 대한 높은 수준의 개요를 보여줍니다. 아마존 경로 53 리졸버 규칙 과 AWS 리소스 액세스 관리자.
솔루션은 만드는 것부터 시작됩니다. Route 53 인바운드 및 아웃바운드 확인자 엔드포인트, MSK 클러스터 VPC와 연결되어 있습니다. 그런 다음 어떤 VPC와도 연결되지 않은 MSK 계정에서 해석기 전달 규칙을 생성합니다. 다음으로 Resource Access Manager를 사용하여 계정 간에 확인자 규칙을 공유합니다. 이름 확인을 확장해야 하는 원격 계정에서 리소스 공유를 수락하고 확인자 규칙을 원격 계정(MSK 클라이언트가 있는 계정)에 있는 대상 VPC와 연결해야 합니다.
이 접근 방식에 대한 자세한 내용은 다음의 세 번째 사용 사례를 참조하세요. Route 53 Resolver를 사용하여 다중 계정 환경에서 DNS 관리를 단순화하세요.
이 솔루션은 보다 확장 가능하고 유연한 접근 방식으로 여러 중앙 집중식 MSK 서버리스 클러스터를 수용합니다. 따라서 솔루션은 MSK 클러스터가 있는 VPC에서 DNS 요청을 해결하도록 지시하는 것에 의존합니다. 여러 MSK 서버리스 클러스터가 공존할 수 있으며, 특정 VPC의 클라이언트는 동시에 하나 이상의 클러스터와 통신할 수 있습니다. 이 옵션은 프라이빗 호스팅 영역 솔루션 접근 방식에서는 지원되지 않습니다.
제한 사항
이 솔루션에는 장점이 있지만 몇 가지 제한 사항도 있습니다.
첫째, 특정 대상 소비자 또는 생산자 계정의 경우 모든 MSK 서버리스 클러스터는 MSK 계정의 동일한 핵심 서비스 VPC에 있어야 합니다. 이는 해석기 규칙이 계정 수준에서 설정되고 .kafka-serverless.Region.amazonaws.com을 기본 도메인으로 사용하여 해당 서비스 VPC 내의 하나의 특정 VPC 해석기 엔드포인트 인바운드/아웃바운드 쌍으로 해석을 지시하기 때문입니다. . 서로 다른 VPC에 별도의 클러스터가 필요한 경우 별도의 계정을 생성하는 것이 좋습니다.
두 번째 제한 사항은 모든 클라이언트 VPC가 핵심 MSK 서버리스 VPC와 동일한 리전에 있어야 한다는 것입니다. 이러한 제한의 이유는 확인자 끝점 쌍(실제로는 인바운드 끝점으로 루프하는 아웃바운드 끝점을 가리킴)을 가리키는 확인자 규칙이 확인자 규칙과 동일한 지역에 있어야 하고 Resource Access Manager가 확장된다는 것입니다. 동일한 지역 내에서만 공유됩니다. 그러나 이 솔루션은 동일한 코어 VPC에 여러 MSK 클러스터가 있고 원격 클라이언트가 다른 VPC 및 계정에 있더라도 여전히 동일한 리전 내에 있는 경우에 유용합니다. 이 제한에 대한 해결 방법은 두 번째 지역에서 해석기 규칙 및 아웃바운드 해석기 엔드포인트 생성을 복제하는 것입니다. 여기서 아웃바운드 엔드포인트는 MSK 서버리스 클러스터 VPC와 연결된 원래의 첫 번째 지역 인바운드 해석기 엔드포인트를 통해 루프백됩니다(IP 연결이 용이하다고 가정). . 그러면 두 번째 지역 내에서 Resource Access Manager를 사용하여 이 두 번째 지역 해석기 규칙을 공유할 수 있습니다.
결론
프라이빗 호스팅 영역 또는 Route 53 해석기 규칙을 사용하여 다중 계정 환경에서 MSK 서버리스 교차 VPC 및 교차 계정 액세스를 구성할 수 있습니다. 이 게시물에서 설명하는 솔루션을 사용하면 구성을 중앙 집중화하는 동시에 계정 간 액세스를 확장하여 확장 가능하고 유지 관리가 간편한 솔루션을 만들 수 있습니다. 당신은 할 수 있습니다 MSK 서버리스 클러스터 생성 생산자와 소비자를 위한 교차 계정 액세스를 통해 비즈니스 결과에 계속 집중하고 Kafka 인프라의 규모를 적절하게 조정하고 관리하지 않고도 조직 전체의 데이터 소스에서 통찰력을 얻을 수 있습니다.
저자에 관하여
테이머 솔리만 AWS의 수석 솔루션 아키텍트입니다. 그는 ISV(독립 소프트웨어 공급업체) 고객이 AWS에서 혁신, 구축 및 확장할 수 있도록 돕습니다. 그는 20년 이상의 업계 경험을 보유하고 있으며 3개의 특허를 취득한 발명가입니다. 그의 경험은 통신, 네트워킹, 애플리케이션 통합, 데이터 분석, AI/ML, 클라우드 배포 등 다양한 기술 영역에 걸쳐 있습니다. 그는 AWS 네트워킹을 전문으로 하며 기계 학습, AI 및 생성 AI에 대한 깊은 열정을 가지고 있습니다.
- SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
- PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
- PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
- 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
- PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
- 출처: https://aws.amazon.com/blogs/big-data/secure-connectivity-patterns-for-amazon-msk-serverless-cross-account-access/
