빠른 시작 - Azure Managed Instance for Apache Cassandra를 사용하여 하이브리드 클러스터 구성

Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 또한 이 서비스를 사용하면 각 워크로드의 특정 요구 사항에 따라 구성을 재정의할 수 있으므로 필요한 경우 최대한의 유연성과 제어가 가능합니다.

이 빠른 시작에서는 Azure CLI 명령을 사용하여 하이브리드 클러스터를 구성하는 방법을 보여 줍니다. 온-프레미스 또는 자체 호스팅 환경에 기존 데이터 센터가 있는 경우 Azure Managed Instance for Apache Cassandra를 사용하여 해당 클러스터에 다른 데이터 센터를 추가하고 유지 관리할 수 있습니다.

필수 조건

• Azure Cloud Shell에서 Bash 환경을 사용합니다. 자세한 내용은 Azure Cloud Shell의 Bash에 대한 빠른 시작을 참조하세요.

  

• CLI 참조 명령을 로컬에서 실행하려면 Azure CLI를 설치합니다. Windows 또는 macOS에서 실행 중인 경우 Docker 컨테이너에서 Azure CLI를 실행하는 것이 좋습니다. 자세한 내용은 Docker 컨테이너에서 Azure CLI를 실행하는 방법을 참조하세요.

  • 로컬 설치를 사용하는 경우 az login 명령을 사용하여 Azure CLI에 로그인합니다. 인증 프로세스를 완료하려면 터미널에 표시되는 단계를 수행합니다. 다른 로그인 옵션은 Azure CLI를 사용하여 로그인을 참조하세요.

  • 메시지가 표시되면 처음 사용할 때 Azure CLI 확장을 설치합니다. 확장에 대한 자세한 내용은 Azure CLI에서 확장 사용을 참조하세요.

  • az version을 실행하여 설치된 버전과 종속 라이브러리를 찾습니다. 최신 버전으로 업그레이드하려면 az upgrade를 실행합니다.

• 이 문서를 진행하려면 Azure CLI 버전 2.30.0 이상이 필요합니다. Azure Cloud Shell을 사용하는 경우 최신 버전이 이미 설치되어 있습니다.

• 자체 호스팅 또는 온-프레미스 환경에 연결된 Azure Virtual Network. 온-프레미스 환경을 Azure에 연결하는 방법에 대한 자세한 내용은 Azure에 온-프레미스 네트워크 연결 문서를 참조하세요.

하이브리드 클러스터 구성

1. Azure Portal에 로그인하고 Virtual Network로 이동합니다.

2. 서브넷 탭을 열고 새 서브넷을 만듭니다. 서브넷 추가 양식의 필드에 대한 자세한 내용은 Virtual Network 문서를 참조하세요.

   

   참고 항목

   Azure Managed Instance for Apache Cassandra를 배포하려면 인터넷 액세스가 필요합니다. 인터넷 액세스가 제한되는 환경에서는 배포가 실패합니다. Managed Cassandra가 올바르게 작동하는 데 필요한 다음과 같은 중요한 Azure 서비스에 대한 VNet 내에서 액세스가 차단되어 있는지 확인합니다. 또한 여기에서 IP 주소 및 포트 의존성의 전체 목록을 확인할 수 있습니다.

   • Azure Storage
   • Azure KeyVault
   • Azure Virtual Machine Scale Sets
   • Azure 모니터링
   • Microsoft Entra ID
   • Azure Security

3. 이제 Azure CLI를 사용하여 Cassandra Managed Instance를 사용하는 데 필요한 몇 가지 특수 권한을 VNet 및 서브넷에 적용합니다. az role assignment create 명령을 사용하여 <subscriptionID>, <resourceGroupName> 및 <vnetName>을 적절한 값으로 바꿉니다.

   az role assignment create \
     --assignee a232010e-820c-4083-83bb-3ace5fc29d0b \
     --role 4d97b98b-1d4f-4787-a291-c67834d212e7 \
     --scope /subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>
   

   참고 항목

   이전 명령에서 assignee 및 role 값은 각각 고정된 서비스 주체 및 역할 식별자입니다.

4. 다음으로, 하이브리드 클러스터의 리소스를 구성합니다. 클러스터가 이미 있으므로 여기서는 기존 클러스터의 이름을 식별하는 논리적 리소스만 클러스터 이름이 됩니다. 다음 스크립트에서 clusterName 및 clusterNameOverride 변수를 정의할 때는 기존 클러스터의 이름을 사용해야 합니다.

   또한 기존 데이터 센터의 시드 노드와 노드 간 암호화에 필요한 가십 인증서가 최소한 필요합니다. Azure Managed Instance for Apache Cassandra에는 데이터 센터 간 통신을 위해 노드 간 암호화가 필요합니다. 기존 클러스터에서 노드 간 암호화를 구현하지 않은 경우 이를 구현해야 합니다. 여기에 있는 설명서를 참조하세요. 인증서의 위치에 대한 경로를 제공해야 합니다. 각 인증서는 PEM 형식이어야 합니다(예: -----BEGIN CERTIFICATE-----\n...PEM format 1...\n-----END CERTIFICATE-----). 일반적으로 인증서를 구현하는 방법에는 두 가지가 있습니다.

   1. 자체 서명된 인증서. 각 노드에 대한 프라이빗 및 공용(CA 없음) 인증서를 의미합니다. 이 경우 모든 공용 인증서가 필요합니다.

   2. CA 서명 인증서. 자체 서명 CA 또는 퍼블릭 CA일 수 있습니다. 이 경우 루트 CA 인증서(프로덕션용 SSL 인증서 준비 지침 참조) 및 모든 중간자(해당하는 경우)가 필요합니다.

   선택적으로 클라이언트-노드 인증서 인증 또는 mTLS(상호 전송 계층 보안)도 구현하려는 경우 하이브리드 클러스터를 만들 때와 동일한 형식으로 인증서를 제공해야 합니다. 아래 Azure CLI 샘플을 참조하세요. 인증서는 --client-certificates 매개 변수에 제공됩니다. 이렇게 하면 클라이언트 인증서가 Cassandra Managed Instance 클러스터의 신뢰 저장소에 업로드되고 적용됩니다(즉, cassandra.yaml 설정을 편집할 필요가 없음). 적용되면 클라이언트에서 연결할 때 클러스터는 Cassandra에서 인증서를 확인하도록 요구합니다(Cassandra client_encryption_options의 require_client_auth: true 참조).

   참고 항목

   아래에 제공할 delegatedManagementSubnetId 변수 값은 위의 명령에서 제공한 --scope 값과 정확히 동일합니다.

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster-legal-name'
   clusterNameOverride='cassandra-hybrid-cluster-illegal-name'
   location='eastus2'
   delegatedManagementSubnetId='/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>'
   
   # You can override the cluster name if the original name is not legal for an Azure resource:
   # overrideClusterName='ClusterNameIllegalForAzureResource'
   # the default cassandra version will be v3.11
   
   az managed-cassandra cluster create \
     --cluster-name $clusterName \
     --resource-group $resourceGroupName \
     --location $location \
     --delegated-management-subnet-id $delegatedManagementSubnetId \
     --external-seed-nodes 10.52.221.2 10.52.221.3 10.52.221.4 \
     --external-gossip-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/gossipKeyStore.crt_signed
     # optional - add your existing datacenter's client-to-node certificates (if implemented):
     # --client-certificates /usr/csuser/clouddrive/rootCa.pem /usr/csuser/clouddrive/nodeKeyStore.crt_signed
   

   참고 항목

   클러스터에 노드 간 및 클라이언트-노드 암호화가 이미 설정된 경우 기존 클라이언트 및/또는 가십 SSL 인증서가 유지되는 위치를 알아야 합니다. 잘 모르겠으면 keytool -list -keystore <keystore-path> -rfc -storepass <password>를 실행하여 인증서를 출력해야 합니다.

5. 클러스터 리소스가 생성되면 다음 명령을 실행하여 클러스터 설정 세부 정보를 가져옵니다.

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster'
   
   az managed-cassandra cluster show \
      --cluster-name $clusterName \
      --resource-group $resourceGroupName \
   

6. 이전 명령은 관리형 인스턴스 환경에 대한 정보를 반환합니다. 기존 데이터 센터의 노드에 대한 신뢰 저장소에 이를 설치할 수 있도록 가십 인증서가 필요합니다. 다음 스크린샷에서는 이전 명령의 출력과 인증서 형식을 보여 줍니다.

   

   참고 항목

   위의 명령에서 반환된 인증서에는 텍스트로 표현되는 줄바꿈(예: \r\n)이 포함되어 있습니다. 기존 데이터 센터의 신뢰 저장소로 가져오기 전에 각 인증서를 파일에 복사하고 형식을 지정해야 합니다.

   팁

   위의 스크린샷에 표시된 gossipCertificates 배열 값을 파일에 복사하고, 다음 bash 스크립트(플랫폼용 jq를 다운로드하고 설치해야 하는 경우)를 사용하여 인증서의 형식을 지정하고 각각에 대해 별도의 pem 파일을 만듭니다.

   readarray -t cert_array < <(jq -c '.[]' gossipCertificates.txt)
   # iterate through the certs array, format each cert, write to a numbered file.
   num=0
   filename=""
   for item in "${cert_array[@]}"; do
     let num=num+1
     filename="cert$num.pem"
     cert=$(jq '.pem' <<< $item)
     echo -e $cert >> $filename
     sed -e 's/^"//' -e 's/"$//' -i $filename
   done
   

7. 다음으로, 하이브리드 클러스터에 새 데이터 센터를 만듭니다. 변수 값을 클러스터 세부 정보로 바꾸어야 합니다.

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster'
   dataCenterName='dc1'
   dataCenterLocation='eastus2'
   virtualMachineSKU='Standard_D8s_v4'
   noOfDisksPerNode=4
   
   az managed-cassandra datacenter create \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName \
     --data-center-name $dataCenterName \
     --data-center-location $dataCenterLocation \
     --delegated-subnet-id $delegatedManagementSubnetId \
     --node-count 9
     --sku $virtualMachineSKU \
     --disk-capacity $noOfDisksPerNode \
     --availability-zone false
   

   참고 항목

   --sku의 값은 다음과 같은 사용 가능한 SKU에서 선택할 수 있습니다.

   • Standard_E8s_v4
   • Standard_E16s_v4
   • Standard_E20s_v4
   • Standard_E32s_v4
   • Standard_DS13_v2
   • Standard_DS14_v2
   • Standard_D8s_v4
   • Standard_D16s_v4
   • Standard_D32s_v4

   또한 --availability-zone은 false로 설정됩니다. 가용성 영역을 사용하도록 설정하려면 이를 true로 설정합니다. 가용성 영역은 서비스의 가용성 SLA를 늘립니다. 자세한 내용은 여기에서 전체 SLA 세부 정보를 검토하세요.

   Warning

   모든 하위 지역에서 가용성 영역이 지원되지 않습니다. 가용성 영역이 지원되지 않는 하위 지역을 선택하면 배포에 실패합니다. 여기에서 지원되는 지역을 참조하세요. 또한 가용성 영역을 성공적으로 배포하는 경우 지정된 하위 지역의 모든 영역에서 컴퓨팅 리소스를 사용할 수 있습니다. 선택한 SKU 또는 용량을 모든 영역에서 사용할 수 없는 경우 배포가 실패할 수 있습니다.

8. 이제 새 데이터 센터가 생성되었으므로 데이터 센터 표시 명령을 실행하여 세부 정보를 확인합니다.

   resourceGroupName='MyResourceGroup'
   clusterName='cassandra-hybrid-cluster'
   dataCenterName='dc1'
   
   az managed-cassandra datacenter show \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName \
     --data-center-name $dataCenterName
   

9. 이전 명령은 새 데이터 센터의 시드 노드를 출력합니다.

   

10. 이제 새 데이터 센터의 시드 노드를 cassandra.yaml 파일 내에 있는 기존 데이터 센터의 시드 노드 구성에 추가합니다. 그리고 각 인증서에 대해 keytool 명령을 사용하여 기존 클러스터의 각 노드에 대한 신뢰 저장소에 이전에 수집한 관리형 인스턴스 가십 인증서를 설치합니다.

    keytool -importcert -keystore generic-server-truststore.jks -alias CassandraMI -file cert1.pem -noprompt -keypass myPass -storepass truststorePass
    

    참고 항목

    데이터 센터를 더 추가하려는 경우 시드 노드만 있으면 위의 단계를 반복할 수 있습니다.

    Important

    기존 Apache Cassandra 클러스터에 단일 데이터 센터만 있고 데이터 센터가 처음 추가되는 경우 cassandra.yaml의 endpoint_snitch 매개 변수가 GossipingPropertyFileSnitch로 설정되었는지 확인합니다.

    Important

    기존 애플리케이션 코드가 일관성을 위해 QUORUM을 사용하는 경우 아래 단계에서 복제 설정을 변경하기 전에 기존 애플리케이션 코드가 LOCAL_QUORUM을 사용하여 기존 클러스터에 연결하는지 확인해야 합니다. 그렇지 않으면 아래 단계에서 복제 설정을 변경한 후 라이브 업데이트가 실패합니다. 복제 전략이 변경되면 원하는 경우 QUORUM으로 되돌릴 수 있습니다.

11. 마지막으로, 다음 CQL 쿼리를 사용하여 클러스터의 모든 데이터 센터를 포함하도록 각 키스페이스에서 복제 전략을 업데이트합니다.

    ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3};
    

    또한 여러 시스템 테이블을 업데이트해야 합니다.

    ALTER KEYSPACE "system_auth" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    ALTER KEYSPACE "system_distributed" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    ALTER KEYSPACE "system_traces" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'on-premise-dc': 3, 'managed-instance-dc': 3}
    

    Important

    기존 클러스터의 데이터 센터가 클라이언트-노드 암호화(SSL)를 적용하지 않고 애플리케이션 코드가 Cassandra Managed Instance에 직접 연결하려는 경우 애플리케이션 코드에서 SSL도 사용하도록 설정해야 합니다.

실시간 마이그레이션에 하이브리드 클러스터 사용

위 지침은 하이브리드 클러스터 구성에 대한 지침을 제공합니다. 그러나 이는 가동 중지 시간이 없는 완벽한 마이그레이션을 달성하는 좋은 방법이기도 합니다. 온-프레미스 또는 기타 Cassandra 환경에서 작동 중지 시간 없이 서비스를 해제하고 Azure Managed Instance for Apache Cassandra에서 워크로드를 실행하려는 경우 다음 단계를 이 순서대로 완료해야 합니다.

1. 하이브리드 클러스터 구성 - 위의 지침을 따릅니다.

2. 마이그레이션 기간 동안 Azure Managed Instance for Apache Cassandra에서 자동 복구를 일시적으로 사용하지 않도록 설정합니다.

   az managed-cassandra cluster update \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName --repair-enabled false
   

3. Azure CLI에서 아래 명령을 실행하여 새 Azure Managed Instance for Apache Cassandra 데이터 센터의 각 노드에서 nodetool rebuild를 실행합니다. 이를 통해 <ip address>를 노드의 IP 주소로 바꾸고 <sourcedc>를 기존 데이터 센터(마이그레이션하려는 데이터 센터)의 이름으로 바꿉니다.

   az managed-cassandra cluster invoke-command \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName \
     --host <ip address> \
     --command-name nodetool --arguments rebuild="" "<sourcedc>"=""
   

   이전 단계를 모두 수행한 후에만 이 작업을 실행해야 합니다. 이렇게 하면 모든 기록 데이터가 Azure Managed Instance for Apache Cassandra의 새 데이터 센터에 복제됩니다. 동시에 하나 이상의 노드에서 다시 빌드를 실행할 수 있습니다. 한 번에 하나의 노드에서 실행하여 기존 클러스터에 미치는 영향을 줄입니다. 클러스터가 추가 I/O 및 네트워크 압력을 처리할 수 있는 경우 여러 노드에서 실행합니다. 대부분의 설치에서 클러스터에 과부하가 걸리지 않도록 한두 개만 병렬로 실행할 수 있습니다.

   Warning

   nodetool rebuild를 실행할 때 원본 데이터 센터를 지정해야 합니다. 첫 번째 시도에서 데이터 센터를 잘못 제공하면 비시스템 테이블에 대한 데이터가 복사되지 않고 토큰 범위가 복사됩니다. 데이터 센터를 올바르게 제공하더라도 후속 시도는 실패합니다. 대상 Cassandra MI 데이터 센터의 cqlsh 쿼리 도구를 통해 system.available_ranges의 각 비시스템 키스페이스에 대한 항목을 삭제하여 이 문제를 해결할 수 있습니다.

   delete from system.available_ranges where keyspace_name = 'myKeyspace';
   

4. Azure Managed Instance for Apache Cassandra 데이터 센터의 시드 노드를 가리키도록 애플리케이션 코드를 잘라냅니다.

   Important

   하이브리드 설정 지침에서도 언급한 바와 같이 기존 클러스터의 데이터 센터가 클라이언트-노드 암호화(SSL)를 적용하지 않는 경우 애플리케이션 코드에서 이를 사용하도록 설정해야 합니다. 이는 Cassandra Managed Instance가 이를 적용하기 때문입니다.

5. 이전과 동일한 방식으로 각 키스페이스에 대해 ALTER KEYSPACE를 실행하지만 이제 이전 데이터 센터를 제거합니다.

6. 각 이전 데이터 센터 노드에 대해 nodetool decommission을 실행합니다.

7. 애플리케이션 코드를 다시 쿼럼으로 전환합니다(필요한 경우/기본 설정하는 경우).

8. 자동 복구를 다시 사용하도록 설정합니다.

   az managed-cassandra cluster update \
     --resource-group $resourceGroupName \
     --cluster-name $clusterName --repair-enabled true
   

문제 해결

Azure CLI를 사용하여 Virtual Network에 권한을 적용할 때 'e5007d2c-4b13-4a74-9b6a-605d99f03501'에 대한 그래프 데이터베이스에서 사용자 또는 서비스 주체를 찾을 수 없음과 같은 오류가 발생하는 경우 Azure Portal에서 동일한 권한을 수동으로 적용할 수 있습니다. 여기에서 이 작업을 수행하는 방법을 알아봅니다.

참고 항목

Azure Cosmos DB 역할 할당은 배포 목적으로만 사용됩니다. Azure Managed Instanced for Apache Cassandra에는 Azure Cosmos DB에 대한 백 엔드 종속성이 없습니다.

리소스 정리

이 관리형 인스턴스 클러스터를 더 이상 사용하지 않으려면 다음 단계에 따라 삭제합니다.

1. Azure Portal의 왼쪽 메뉴에서 리소스 그룹을 선택합니다.
2. 목록에서 이 빠른 시작에서 만든 리소스 그룹을 선택합니다.
3. 리소스 그룹 개요 창에서 리소스 그룹 삭제를 선택합니다.
4. 새 창에서 삭제할 리소스 그룹의 이름을 입력한 다음, 삭제를 선택합니다.

다음 단계

이 빠른 시작에서는 Azure CLI 및 Apache Cassandra용 Azure Managed Instance를 사용하여 하이브리드 클러스터를 만드는 방법을 알아보았습니다. 이제 클러스터 사용을 시작할 수 있습니다.

Azure CLI를 사용하여 Apache Cassandra용 Azure Managed Instance 리소스 관리