기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
서버리스 환경에 대한 클라이언트 드라이버 연결 최적화
원하는 기존 Apache Cassandra 클라이언트 드라이버를 사용하여 Amazon Keyspaces와 통신할 수 있습니다. Amazon Keyspaces는 서버리스 서비스이므로 애플리케이션의 처리량 요구 사항에 맞게 클라이언트 드라이버의 연결 구성을 최적화하는 것이 좋습니다. 이 주제에서는 애플리케이션에 필요한 연결 수를 계산하는 방법과 연결 모니터링 및 오류 처리를 비롯한 모범 사례를 소개합니다.
주제
Amazon Keyspaces에서의 연결 작동 방식
이 섹션에서는 Amazon Keyspaces에서 클라이언트 드라이버 연결이 작동하는 방식에 대한 개요를 제공합니다. Cassandra 클라이언트 드라이버를 잘못 구성하면 Amazon Keyspaces에서 PerConnectionRequestExceeded
이벤트가 발생할 수 있으므로 이러한 연결 오류를 방지하려면 클라이언트 드라이버 구성에서 적절한 양의 연결을 구성해야 합니다.
Amazon Keyspace에 연결할 때 드라이버에는 초기 연결을 설정하기 위한 시드 엔드포인트가 필요합니다. Amazon Keyspaces는 DNS를 사용하여 초기 연결을 사용 가능한 여러 엔드포인트 중 하나로 라우팅합니다. 엔드포인트는 네트워크 로드 밸런서에 연결되며, 네트워크 로드 밸런서는 플릿의 요청 핸들러 중 하나로의 연결을 설정합니다. 초기 연결이 설정되면 클라이언트 드라이버는 system.peers
테이블에서 사용 가능한 모든 엔드포인트에 대한 정보를 수집합니다. 이 정보를 사용하여 클라이언트 드라이버는 나열된 엔드포인트에 대한 추가 연결을 생성할 수 있습니다. 클라이언트 드라이버가 만들 수 있는 연결 수는 클라이언트 드라이버 설정에 지정된 로컬 연결 수에 따라 제한됩니다. 기본적으로 대부분의 클라이언트 드라이버는 엔드포인트당 하나의 연결을 설정하고, Cassandra에 대한 연결 풀을 설정하고, 연결 풀 전체에 걸쳐 쿼리를 로드 밸런싱합니다. 동일한 엔드포인트에 여러 연결을 설정할 수 있지만 네트워크 로드 밸런서 뒤에서는 여러 개의 다른 요청 핸들러에 연결될 수 있습니다. 퍼블릭 엔드포인트를 통해 연결하는 경우 system.peers
테이블에 나열된 9개 엔드포인트 각각에 하나씩 연결을 설정하면 서로 다른 요청 핸들러에 9개의 연결이 생성됩니다.
Amazon Keyspaces에서 연결을 구성하는 방법
Amazon Keyspaces는 초당 TCP 연결당 최대 3,000개의 CQL 쿼리를 지원합니다. 드라이버가 설정할 수 있는 연결 수에는 제한이 없으므로 오버헤드, 트래픽 버스트 및 더 나은 로드 밸런싱을 위해 연결당 초당 500개의 CQL 요청만 대상으로 지정하는 것이 좋습니다. 다음 단계에 따라 드라이버 연결이 애플리케이션의 요구 사항에 맞게 올바르게 구성되었는지 확인하세요.
드라이버가 연결 풀에서 유지 관리하는 IP 주소당 연결 수를 늘리십시오.
-
대부분의 Cassandra 드라이버는 Cassandra에 연결 풀을 설정하고 연결 풀 전체에 걸쳐 쿼리를 로드 밸런싱합니다. 대부분의 드라이버의 기본 동작은 각 엔드포인트마다 하나의 연결을 설정하는 것입니다. Amazon Keyspaces는 드라이버에 9개의 피어 IP 주소를 노출하므로 대부분의 드라이버의 기본 동작을 기준으로 하면 연결 수가 9개입니다. Amazon Keyspaces는 초당 TCP 연결당 최대 3,000개의 CQL 쿼리를 지원하므로 기본 설정을 사용하는 드라이버의 최대 CQL 쿼리 처리량은 초당 27,000개의 CQL 쿼리입니다. 드라이버의 기본 설정을 사용하는 경우 단일 연결에서 초당 최대 CQL 쿼리 처리량인 3,000개 이상의 CQL 쿼리를 처리해야 할 수 있습니다. 이로 인해
PerConnectionRequestExceeded
이벤트가 발생할 수 있습니다. PerConnectionRequestExceeded
이벤트를 방지하려면 엔드포인트별로 추가 연결을 생성하여 처리량을 분산하도록 드라이버를 구성해야 합니다.Amazon Keyspaces의 모범 사례로 각 연결이 초당 500개의 CQL 쿼리를 지원할 수 있다고 가정합니다.
즉, 사용 가능한 9개의 엔드포인트에 걸쳐 초당 27,000개의 CQL 쿼리를 지원해야 하는 프로덕션 애플리케이션의 경우 엔드포인트당 6개의 연결을 구성해야 합니다. 이렇게 하면 각 연결에서 초당 500개 이하의 요청을 처리할 수 있습니다.
애플리케이션의 요구 사항에 따라 드라이버에 대해 구성해야 하는 IP 주소당 연결 수를 계산하십시오.
애플리케이션에 엔드포인트별로 구성해야 하는 연결 수를 결정하려면 다음 예제를 고려해 보십시오. 10,000, 5,000 INSERT
및 5,000개의 DELETE
작업으로 구성된 초당 20SELECT
,000개의 CQL 쿼리를 지원해야 하는 애플리케이션이 있습니다. Java 애플리케이션은 Amazon Elastic Container Service(Amazon ECS)의 세 인스턴스에서 실행되며, 각 인스턴스는 Amazon Keyspaces에 대한 단일 세션을 설정합니다. 드라이버에 구성해야 하는 연결 수를 추정하는 데 사용할 수 있는 계산에 사용되는 입력은 다음과 같습니다.
애플리케이션이 지원해야 하는 초당 요청 수.
사용 가능한 인스턴스 수에서 유지 관리 또는 장애 발생을 고려하여 하나를 뺀 수.
사용 가능한 엔드포인트 수. 퍼블릭 엔드포인트를 통해 연결하는 경우 사용 가능한 엔드포인트는 9개입니다. VPC 엔드포인트를 사용하는 경우 리전에 따라 2~5개의 엔드포인트를 사용할 수 있습니다.
Amazon Keyspaces에 대한 모범 사례로 연결당 초당 500개의 CQL 쿼리를 사용합니다.
결과를 반올림합니다.
이 예제의 공식은 다음과 같습니다.
20,000 CQL queries / (3 instances - 1 failure) / 9 public endpoints / 500 CQL queries per second = ROUND(2.22) = 3
이 계산에 따라 드라이버 구성에서 엔드포인트당 로컬 연결 3개를 지정해야 합니다. 원격 연결의 경우 엔드포인트당 하나의 연결만 구성합니다.
Amazon Keyspaces에서 연결에 대한 재시도 정책을 구성하는 방법
Amazon Keyspaces에 연결하기 위해 재시도 정책을 구성할 때는 Amazon Keyspaces 재시도 정책 을 구현하는 것이 좋습니다AmazonKeyspacesExponentialRetryPolicy
. 이 재시도 정책은 드라이버의 보다는 Amazon Keyspaces에 대한 다양한 연결에서 재시도하는 데 더 적합합니다DefaultRetryPolicy
.
를 사용하면 필요에 맞는 연결에 대한 재시도 횟수를 구성할 AmazonKeyspacesExponentialRetryPolicy
수 있습니다. 기본적으로 에 대한 재시도 횟수AmazonKeyspacesExponentialRetryPolicy
는 3으로 설정됩니다.
또 다른 장점은 Amazon Keyspaces 재시도 정책이 서비스에서 반환한 원래 예외를 반환한다는 것입니다. 이는 요청 시도가 실패한 이유를 나타냅니다. 기본 재시도 정책은 요청 실패에 대한 인사이트를 숨길 수 NoHostAvailableException
있는 일반 만 반환합니다.
를 사용하여 요청 재시도 정책을 구성하려면 적은 수의 재시도를 구성하고 애플리케이션 코드에서 반환된 예외를 처리하는 것이 AmazonKeyspacesExponentialRetryPolicy
좋습니다.
재시도 정책을 구현하는 코드 예제는 Github의 Amazon Keyspaces 재시도 정책을
Amazon Keyspaces에서 VPC 엔드포인트를 통한 연결을 구성하는 방법
프라이빗 VPC 엔드포인트를 통해 연결할 때 3개의 엔드포인트를 사용할 수 있을 가능성이 높습니다. VPC 엔드포인트 수는 가용 영역 수와 할당된 의 서브넷 수에 따라 리전별로 다를 수 있습니다VPC. 미국 동부(버지니아 북부) 지역에는 5개의 가용 영역이 있으며 Amazon Keyspaces 엔드포인트를 최대 5개까지 보유할 수 있습니다. 미국 서부(캘리포니아 북부) 지역에는 2개의 가용 영역이 있으며 Amazon Keyspaces 엔드포인트를 최대 2개까지 보유할 수 있습니다. 엔드포인트 수에 따라 규모가 달라지지는 않지만 드라이버 구성에서 설정해야 하는 연결 수가 늘어납니다. 다음 예제를 살펴보세요. 애플리케이션은 20,000개의 CQL 쿼리를 지원해야 하며 각 인스턴스ECS가 Amazon Keyspaces에 대한 단일 세션을 설정하는 Amazon의 세 인스턴스에서 실행됩니다. 유일한 차이점은 서로 다른 에서 사용할 수 있는 엔드포인트 수입니다 AWS 리전.
미국 동부(버지니아 북부) 리전에서 필요한 연결:
20,000 CQL queries / (3 instances - 1 failure) / 5 private VPC endpoints / 500 CQL queries per second = 4 local connections
미국 서부(캘리포니아 북부) 리전에서 필요한 연결:
20,000 CQL queries / (3 instances - 1 failure) / 2 private VPC endpoints / 500 CQL queries per second = 10 local connections
중요
프라이빗 VPC 엔드포인트를 사용하는 경우 Amazon Keyspaces가 사용 가능한 VPC 엔드포인트를 동적으로 검색하고 system.peers
테이블을 채우려면 추가 권한이 필요합니다. 자세한 내용은 인터페이스 VPC 엔드포인트 정보로 system.peers 테이블 항목 채우기 단원을 참조하십시오.
다른 를 사용하여 프라이빗 VPC 엔드포인트를 통해 Amazon Keyspaces에 액세스할 때 단일 Amazon Keyspaces 엔드포인트만 표시될 AWS 계정수 있습니다. 다시 말하지만 이는 Amazon Keyspaces에 대한 가능한 처리량 규모에는 영향을 미치지 않지만 드라이버 구성의 연결 수를 늘려야 할 수도 있습니다. 이 예제는 사용 가능한 단일 엔드포인트에 대한 동일한 계산을 보여줍니다.
20,000 CQL queries / (3 instances - 1 failure) / 1 private VPC endpoints / 500 CQL queries per second = 20 local connections
공유 를 사용하여 Amazon Keyspaces에 대한 교차 계정 액세스에 대해 자세히 알아보려면 섹션을 VPC참조하세요공유의 엔드포인트를 VPC 사용하여 Amazon Keyspace에 대한 계정 간 액세스를 구성합니다. VPC .
Amazon Keyspaces에서의 연결 모니터링 방식
애플리케이션이 연결된 엔드포인트 수를 식별할 수 있도록 system.peers
테이블에 검색된 피어 수를 기록할 수 있습니다. 다음 예제는 연결이 설정된 후 피어 수를 인쇄하는 Java 코드의 예제입니다.
ResultSet result = session.execute(new SimpleStatement("SELECT * FROM system.peers")); logger.info("number of Amazon Keyspaces endpoints:" + result.all().stream().count());
참고
CQL 콘솔 또는 AWS 콘솔은 내에 배포되지 VPC 않으므로 퍼블릭 엔드포인트를 사용합니다. 따라서 외부에 있는 애플리케이션에서 system.peers
쿼리를 실행하면 피어가 9개씩 발생하는 경우가 VPCE 많습니다. 각 피어의 IP 주소를 인쇄하는 것도 유용할 수 있습니다.
VPCE Amazon CloudWatch 지표를 설정하여 VPC 엔드포인트를 사용할 때 피어 수를 관찰할 수도 있습니다. 에서는 VPC 엔드포인트에 설정된 연결 수를 확인할 CloudWatch수 있습니다. Cassandra 드라이버는 각 엔드포인트에 대한 연결을 설정하여 CQL 쿼리를 보내고 제어 연결을 설정하여 시스템 테이블 정보를 수집합니다. 아래 이미지는 드라이버 설정에 1개의 연결이 구성된 Amazon Keyspaces에 연결한 후의 VPC 엔드포인트 CloudWatch 지표를 보여줍니다. 이 지표는 제어 연결 1개와 연결 5개(여러 가용 영역에 걸쳐 엔드포인트당 1개)로 구성된 6개의 활성 연결을 보여줍니다.
CloudWatch 그래프를 사용하여 연결 수 모니터링을 시작하려면 Amazon Keyspaces AWS CloudFormation 템플릿 리포지토리에서 에서 GitHub 사용할 수 있는 이 템플릿을 배포할 수 있습니다. https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates
Amazon Keyspaces의 연결 오류를 처리하는 방법
연결 할당량당 요청 3,000개를 초과하는 경우 Amazon Keyspaces는 PerConnectionRequestExceeded
이벤트를 반환하고 Cassandra 드라이버는 WriteTimeout
또는 ReadTimeout
예외를 수신합니다. Cassandra 재시도 정책 또는 애플리케이션에서 지수 백오프를 적용하여 이 예외를 재시도해야 합니다. 추가 요청을 보내지 않으려면 지수 백오프를 제공해야 합니다.
기본 재시도 정책은 쿼리 계획에서 try next host
을(를) 시도합니다. 엔드포인트에 연결할 때 Amazon Keyspaces에 1~3개의 사용 가능한 VPC 엔드포인트가 있을 수 있으므로 애플리케이션 로그에 WriteTimeout
및 ReadTimeout
예외 NoHostAvailableException
외에도 이 표시될 수 있습니다. Amazon Keyspaces에서 제공하는 재시도 정책을 사용할 수 있습니다. 이 정책은 여러 연결에 걸친 동일한 엔드포인트에서 재시도합니다.
Amazon Keyspaces Java 코드 예제 리포지토리에서 의 GitHub Java에 대한 지수 재시도 정책의 예를 찾을 수 있습니다. https://github.com/aws-samples/amazon-keyspaces-java-driver-helpers/blob/main/src/main/java/com/aws/ssa/keyspaces/retry/AmazonKeyspacesExponentialRetryPolicy.java