빠른 시작: Azure Portal에서 Azure Managed Instance for Apache Cassandra 클러스터 만들기

아티클
02/21/2024

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

이 빠른 시작에서는 Azure Portal을 사용하여 Apache Cassandra 클러스터용 Azure Managed Instance를 만드는 방법을 설명합니다.

필수 조건

Azure 구독이 없는 경우 시작하기 전에 체험 계정을 만듭니다.

관리되는 인스턴스 클러스터 만들기

Azure Portal에 로그인합니다.
검색 창에서 Apache Cassandra용 Managed Instance를 검색하고 결과를 선택합니다.
Apache Cassandra 클러스터용 Managed Instance 만들기 단추를 선택합니다.
Apache Cassandra용 Managed Instance 만들기 창에서 다음 세부 정보를 입력합니다.
- 구독 - 드롭다운에서 Azure 구독을 선택합니다.
- 리소스 그룹 - 새 리소스 그룹을 만들지 또는 기존 집합을 사용할지 여부를 지정합니다. 리소스 그룹은 Azure 솔루션과 관련된 리소스를 보관하는 컨테이너입니다. 자세한 내용은 Azure Resource Manager 개요 문서를 참조하세요.
- 클러스터 이름 - 클러스터의 이름을 입력합니다.
- 위치 - 클러스터가 배포되는 위치입니다.
- Cassandra 버전 - 배포될 Apache Cassandra 버전입니다.
- 확장 - Cassandra Lucene Index를 포함하여 추가될 확장입니다.
- 최초 Cassandra 관리자 암호 - 클러스터를 만드는 데 사용되는 암호입니다.
- Cassandra 관리자 암호 확인 - 암호를 다시 입력합니다.
- Virtual Network - Virtual Network 종료 및 서브넷을 선택하거나 새 서브넷을 만듭니다.
- 역할 할당 - 관리되는 Cassandra 클러스터를 배포할 수 있도록 하려면 Virtual Networks에 특별한 권한이 필요합니다. 새 Virtual Network를 만들거나 권한이 적용되지 않은 기존 Virtual Network를 사용하는 경우 이 확인란을 선택된 상태로 유지합니다. Azure SQL Managed Instance Cassandra 클러스터를 이미 배포한 가상 네트워크를 사용하는 경우 이 옵션을 선택 취소합니다.
팁

VPN을 사용하는 경우 다른 연결을 열 필요가 없습니다.
참고 항목

Azure Managed Instance for Apache Cassandra를 배포하려면 인터넷 액세스가 필요합니다. 인터넷 액세스가 제한되는 환경에서는 배포가 실패합니다. Managed Cassandra가 올바르게 작동하는 데 필요한 다음과 같은 중요한 Azure 서비스에 대한 VNet 내에서 액세스가 차단되어 있는지 확인합니다. 자세한 내용은 필수 아웃바운드 네트워크 규칙을 참조하세요.
- Azure Storage
- Azure KeyVault
- Azure Virtual Machine Scale Sets
- Azure 모니터링
- Microsoft Entra ID
- Azure Security
- 자동 복제 - 사용할 자동 복제 형식을 선택합니다. 자세한 정보
- 예약 이벤트 전략 - 예약된 이벤트에 대해 클러스터에서 사용할 전략입니다.
팁
- StopANY는 해당 노드에 대해 예정된 일정이 있을 때 모든 노드를 중지한다는 의미입니다.
- StopByRack은 특정 예약 이벤트에 대해 특정 랙의 노드만 중지하는 것을 의미합니다. 동시에 서로 다른 랙의 노드에 대해 두 개 이상의 이벤트가 예약된 경우 한 랙의 노드만 중지되고 다른 랙의 다른 노드는 지연됩니다.
다음으로, 데이터 센터 탭을 선택합니다.
다음 세부 정보를 입력합니다.
- 데이터 센터 이름 - 텍스트 필드에 데이터 센터 이름을 입력합니다.
- 가용성 영역 - 가용성 영역을 사용하도록 설정하려면 이 확인란을 선택합니다.
- SKU 크기 - 사용 가능한 가상 머신 SKU 크기 중에서 선택합니다.
참고 항목

L 시리즈 VM SKU를 활용하여 연속 쓰기 캐싱(공개 미리 보기)을 도입했습니다. 이 구현은 특히 읽기 집약적인 워크로드의 경우 비상 대기 시간을 최소화하고 읽기 성능을 향상시키는 것을 목표로 합니다. 이러한 특정 SKU에는 로컬로 연결된 디스크가 장착되어 있어 읽기 작업에 대한 IOPS가 크게 증가하고 비상 대기 시간이 단축됩니다.

Important

연속 쓰기 캐싱은 공개 미리 보기 상태입니다. 해당 기능은 별도의 Service Level Agreement(서비스 수준 규약) 없이 제공되며, 프로덕션 작업에는 사용하지 않는 것이 좋습니다. 자세한 내용은 Microsoft Azure Preview에 대한 추가 사용 약관을 참조하세요.
- 아니요. 디스크 수 - 각 Cassandra 노드에 연결할 p30 디스크의 수를 선택합니다.
- 아니요. 노드 수 - 이 데이터 센터에 배포할 Cassandra 노드의 수를 선택합니다.
Warning

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

참고 항목

클러스터를 만드는 데 최대 15분이 소요될 수 있습니다.
배포가 완료된 후 리소스 그룹을 확인하여 새로 만든 관리형 인스턴스 클러스터를 확인:
클러스터 노드를 찾아보려면 클러스터 리소스로 이동하고 데이터 센터 창을 열어서 확인합니다.

데이터 센터 크기 조정

이제 단일 데이터 센터가 있는 클러스터를 배포했으므로 데이터 센터를 강조 표시하고 Scale 단추를 선택하여 수평 또는 수직으로 크기 조정할 수 있습니다.

수평적 확장

노드를 스케일 아웃하려면 슬라이더를 원하는 숫자로 이동하거나 값을 편집합니다. 완료되면 Scale을 누릅니다.

수직적 확장

노드에 대해 보다 강력한 SKU 크기로 스케일 업하려면 Sku Size 드롭다운에서 선택합니다. 완료되면 Scale을 누릅니다.

참고 항목

크기 조정 작업에 소요되는 시간은 다양한 요인에 따라 다르며 몇 분 정도 걸릴 수 있습니다. Azure에서 크기 조정 작업이 완료되었다고 알리는 경우 모든 노드가 Cassandra 링에 조인되었음을 의미하지는 않습니다. 노드가 모두 '정상' 상태를 표시하고 데이터 센터 상태가 '성공'으로 표시되면 노드가 완전히 위임됩니다.

데이터 센터 추가

다른 데이터 센터를 추가하려면 데이터 센터 창에서 추가 단추를 클릭합니다.
Warning

데이터 센터를 다른 지역에 추가하는 경우 다른 가상 네트워크를 선택해야 합니다. 또한 이 가상 네트워크가 위에서 만든 주 지역의 가상 네트워크(및 관리되는 인스턴스 클러스터 내에서 데이터 센터를 호스트하는 다른 모든 가상 네트워크)에 연결되어 있는지 확인해야 합니다. 이 문서를 참조하여 Azure Portal을 사용하여 가상 네트워크를 피어링하는 방법을 알아봅니다. 또한 아래 CLI 명령을 사용하여 관리되는 인스턴스 클러스터를 배포하기 전에 적절한 역할을 가상 네트워크에 적용했는지 확인해야 합니다.
```
    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>
```
해당 필드를 채웁니다.
- 데이터 센터 이름 - 드롭다운에서 Azure 구독을 선택합니다.
- 가용성 영역 - 이 데이터 센터에서 가용성 영역을 사용하도록 설정하려면 이 확인란을 선택합니다.
- 위치 - 데이터 센터가 배포되는 위치입니다.
- SKU 크기 - 사용 가능한 가상 머신 SKU 크기 중에서 선택합니다.
- 아니요. 디스크 수 - 각 Cassandra 노드에 연결할 p30 디스크의 수를 선택합니다.
- 아니요. 노드 수 - 이 데이터 센터에 배포할 Cassandra 노드의 수를 선택합니다.
- Virtual Network - 기존 Virtual Network 및 서브넷을 선택합니다.
Warning

데이터 센터를 추가할 때는 새 가상 네트워크 만들기를 허용하지 않습니다. 기존 가상 네트워크를 선택해야 하며, 위에서 설명한 대로 데이터 센터가 배포될 대상 서브넷 간에 연결되어 있는지 확인해야 합니다. 또한 배포를 허용하려면 적절한 역할을 VNet에 적용해야 합니다(위 참조).
데이터 센터가 배포되면 데이터 센터 창에서 모든 데이터 센터 정보를 볼 수 있습니다.
데이터 센터 간 복제를 보장하려면 cqlsh에 연결하고 다음 CQL 쿼리를 사용하여 클러스터 전체의 모든 데이터 센터를 포함하도록 각 키스페이스의 복제 전략을 업데이트합니다(시스템 테이블은 자동으로 업데이트됩니다).
```
ALTER KEYSPACE "ks" WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc': 3, 'dc2': 3};
```
이미 데이터가 있는 클러스터에 데이터 센터를 추가하는 경우 rebuild를 실행하여 기록 데이터를 복제해야 합니다. Azure CLI에서 아래 명령을 실행하여 새 데이터 센터의 각 노드에서 nodetool rebuild를 실행하고, <new dc ip address>를 노드의 IP 주소로 바꾸고, <olddc>를 기존 데이터 센터의 이름으로 바꿉니다.
```
 az managed-cassandra cluster invoke-command \
   --resource-group $resourceGroupName \
   --cluster-name $clusterName \
   --host <new dc ip address> \
   --command-name nodetool --arguments rebuild="" "<olddc>"=""
```
Warning

키스페이스 복제 변경 내용을 적용할 때까지 애플리케이션 클라이언트가 새 데이터 센터에 쓰는 것을 허용해서는 안 됩니다. 그렇지 않으면 다시 빌드가 작동하지 않으며 Google 팀이 사용자를 대신하여 repair를 실행할 수 있도록 지원 요청을 빌드해야 합니다.

Cassandra 구성 업데이트

서비스를 사용하면 포털을 통하거나 CLI 명령을 사용하여 데이터 센터에서 Cassandra YAML 구성을 업데이트할 수 있습니다. 포털에서 설정을 업데이트하려면 다음을 수행합니다.

설정 아래에서 Cassandra Configuration을 찾습니다. 구성을 변경하려는 데이터 센터를 강조 표시하고 업데이트를 클릭합니다.
열리는 창에서 아래와 같이 필드 이름을 YAML 형식으로 입력합니다. 그런 다음, 업데이트를 클릭합니다.
업데이트가 완료되면 재정의된 값이 Cassandra Configuration 창에 표시됩니다.

참고 항목

재정의된 Cassandra 구성 값만 포털에 표시됩니다.
Important

제공한 Cassandra yaml 설정이 배포한 Cassandra 버전에 적합한지 확인합니다. Cassandra v3.11 설정은 여기를 참조하고 v4.0은 여기를 참조하세요. 다음 YAML 설정을 업데이트할 수 없습니다.
- cluster_name
- seed_provider
- initial_token
- autobootstrap
- client_encryption_options
- server_encryption_options
- transparent_data_encryption_options
- audit_logging_options
- authenticator
- authorizer
- role_manager
- storage_port
- ssl_storage_port
- native_transport_port
- native_transport_port_ssl
- listen_address
- listen_interface
- broadcast_address
- hints_directory
- data_file_directories
- commitlog_directory
- cdc_raw_directory
- saved_caches_directory
- endpoint_snitch
- partitioner
- rpc_address
- rpc_interface

Cassandra 버전 업데이트

Important

Cassandra 4.1, 5.0 및 턴키 버전 업데이트는 공개 미리 보기 상태입니다. 이 기능은 서비스 수준 계약 없이 제공되며, 프로덕션 워크로드에는 권장되지 않습니다. 자세한 내용은 Microsoft Azure Preview에 대한 추가 사용 약관을 참조하세요.

포털에서 직접 또는 Az CLI, Terraform 또는 ARM 템플릿을 통해 전체 주 버전 업그레이드를 수행할 수 있는 옵션이 있습니다.

개요 탭에서 Update 패널 찾기
드롭다운에서 Cassandra 버전을 선택합니다.

Warning

버전을 건너뛰지 마세요. 한 버전에서 다른 예 3.11에서 4.0, 4.0에서 4.1로만 업데이트하는 것이 좋습니다.
저장하려면 업데이트를 선택합니다.

턴키 복제

Cassandra 5.0은 다중 지역 클러스터 배포를 위한 간소화된 방식을 도입하여 향상된 편의성과 효율성을 제공합니다. 턴키 복제 기능을 사용하면 다중 지역 클러스터 설정 및 관리에 대한 액세스성이 향상되어 분산 환경 전반에 걸쳐 보다 원활한 통합 및 운영이 가능해졌습니다. 이 업데이트는 다중 지역 구성 배포 및 유지 관리와 관련된 전통적 복잡성을 크게 줄여 사용자가 Cassandra의 기능을 더욱 쉽고 효과적으로 사용할 수 있도록 해줍니다.

팁

없음: 자동 복제가 없음으로 설정됩니다.
SystemKeyspaces: 모든 시스템 키스페이스(system_auth, system_traces, system_auth)를 자동 복제합니다.
AllKeyspaces: 모든 키스페이스를 자동 복제하고 새 키스페이스가 만들어졌는지 모니터링한 다음 자동 복제 설정을 자동으로 적용합니다.

자동 복제 시나리오

새 데이터 센터를 추가할 때 Cassandra의 자동 복제 기능은 nodetool rebuild를 원활하게 실행하여 추가된 데이터 센터 전체에서 데이터가 성공적으로 복제되도록 합니다.
데이터 센터를 제거하면 키스페이스에서 특정 데이터 센터가 자동으로 제거됩니다.

온-프레미스에서 호스트되는 것과 같은 외부 데이터 센터의 경우 외부 데이터 센터 속성을 활용하여 키스페이스에 포함될 수 있습니다. 이를 통해 Cassandra는 이러한 외부 데이터 센터를 다시 빌드 프로세스의 원본으로 통합할 수 있습니다.

Warning

자동 복제를 AllKeyspaces로 설정하면 키스페이스 복제가 다음을 포함하도록 변경됩니다. WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'on-prem-datacenter-1' : 3, 'mi-datacenter-1': 3 } 원하는 토폴로지가 아닌 경우 SystemKeyspaces를 사용하여 직접 조정하고 Azure Managed Instance for Apache Cassandra 클러스터에서 nodetool rebuild를 수동으로 실행해야 합니다.

클러스터 할당 취소

비프로덕션 환경의 경우 요금이 청구되지 않도록 클러스터의 리소스를 일시 중지/할당 취소할 수 있습니다(스토리지 요금은 계속 청구됨). 먼저 클러스터 유형을 NonProduction으로 변경한 다음 deallocate로 변경합니다.

Warning

할당 취소 중에는 스키마 또는 쓰기 작업을 실행하지 마세요. 이로 인해 데이터가 손실될 수 있으며 드물지만 지원 팀의 수동 개입이 필요한 스키마 손상이 발생할 수 있습니다.

문제 해결

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

참고 항목

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

클러스터에 연결

Apache Cassandra용 Azure Managed Instance는 공용 IP 주소가 포함된 노드를 만들지 않으므로 새로 만든 Cassandra 클러스터에 연결하려면 VNet 내에 다른 리소스를 만들어야 합니다. 애플리케이션이나 Apache의 오픈 소스 쿼리 도구인 CQLSH가 포함된 가상 머신이 설치될 수 있습니다. 템플릿을 사용하여 Ubuntu 가상 머신을 배포할 수 있습니다.

CQLSH에서 연결

가상 머신이 배포되면 SSH를 사용하여 해당 머신에 연결하고 아래 명령을 사용하여 CQLSH를 설치합니다.

# Install default-jre and default-jdk
sudo apt update
sudo apt install openjdk-8-jdk openjdk-8-jre

# Install the Cassandra libraries in order to get CQLSH:
echo "deb http://archive.apache.org/dist/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add -
sudo apt-get update
sudo apt-get install cassandra

# Export the SSL variables:
export SSL_VERSION=TLSv1_2
export SSL_VALIDATE=false

# Connect to CQLSH (replace <IP> with the private IP addresses of a node in your Datacenter):
host=("<IP>")
initial_admin_password="Password provided when creating the cluster"
cqlsh $host 9042 -u cassandra -p $initial_admin_password --ssl

애플리케이션에서 연결

CQLSH와 마찬가지로 지원되는 Apache Cassandra 클라이언트 드라이버 중 하나를 사용하여 애플리케이션에서 연결하려면 SSL 암호화를 사용하도록 설정하고 인증 확인을 사용하지 않도록 설정해야 합니다. Java, .NET, Node.js 및 Python을 사용하여 Azure Managed Instance for Apache Cassandra에 연결하는 샘플을 참조하세요.

클러스터 노드의 IP 주소를 적절한 도메인에 매핑하지 않으면 인증서 확인이 작동하지 않으므로 인증서 확인을 사용하지 않도록 설정하는 것이 좋습니다. 애플리케이션에 대해 SSL 인증서 확인을 수행하도록 하는 내부 정책이 있는 경우 10.0.1.5 host1.managedcassandra.cosmos.azure.com와 같은 항목을 각 노드에 대한 호스트 파일에 추가하여 이를 용이하게 할 수 있습니다. 이 접근 방식을 사용하는 경우 노드를 스케일 업할 때마다 새 항목을 추가해야 합니다.

Java의 경우 애플리케이션이 비상 대기 시간에 중요한 경우 투기적 실행 정책을 사용하도록 설정하는 것이 좋습니다. 이 작동 방식과 정책을 사용하도록 설정하는 방법을 보여 주는 데모는 여기서 찾을 수 있습니다.

참고 항목

대부분의 경우 Azure Managed Instance for Apache Cassandra에 연결하기 위해 인증서(rootCA, 노드 또는 클라이언트, 신뢰 저장소 등)를 구성하거나 설치할 필요가 없습니다. Azure Managed Instance for Apache Cassandra 인증서는 해당 환경에서 신뢰되기 때문에 클라이언트가 사용하는 런타임의 기본 신뢰 저장소와 암호를 사용하여 SSL 암호화를 사용하도록 설정할 수 있습니다(Java, .NET, Node.js 및 Python 샘플 참조). 드문 경우지만 인증서를 신뢰할 수 없으면 인증서를 신뢰 저장소에 추가해야 할 수도 있습니다.

클라이언트 인증서 구성(선택 사항)

클라이언트 인증서 구성은 선택 사항입니다. 위 단계를 수행했다면 클라이언트 애플리케이션은 Azure Managed Instance for Apache Cassandra에 연결할 수 있습니다. 그러나 원하는 경우 인증을 위한 클라이언트 인증서를 추가로 만들고 구성할 수도 있습니다. 일반적으로 인증서를 만드는 다음 두 가지 방법이 있습니다.

자체 서명된 인증서. 각 노드에 대한 프라이빗 및 공용(CA 없음) 인증서를 의미합니다. 이 경우 모든 공용 인증서가 필요합니다.
CA 서명 인증서. 자체 서명 CA 또는 퍼블릭 CA일 수 있습니다. 이 경우 루트 CA 인증서(프로덕션용 SSL 인증서 준비 지침 참조) 및 모든 중간자(해당하는 경우)가 필요합니다.

클라이언트-노드 인증서 인증 또는 mTLS(상호 전송 계층 보안)를 구현하려면 Azure CLI를 통해 인증서를 제공해야 합니다. 아래 명령은 클라이언트 인증서를 Cassandra Managed Instance 클러스터의 신뢰 스토리지에 업로드하고 적용합니다(즉, cassandra.yaml 설정을 편집할 필요가 없음). 적용되면 클라이언트에서 연결할 때 클러스터는 Cassandra에서 인증서를 확인하도록 요구합니다(Cassandra client_encryption_options의 require_client_auth: true 참조).

resourceGroupName='<Resource_Group_Name>'
clusterName='<Cluster Name>'

az managed-cassandra cluster update \
  --resource-group $resourceGroupName \
  --cluster-name $clusterName \
  --client-certificates /usr/csuser/clouddrive/rootCert.pem /usr/csuser/clouddrive/intermediateCert.pem

리소스 정리

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

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

다음 단계

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

Azure Databricks를 사용하여 관리형 Apache Spark 클러스터 배포

빠른 시작: Azure Portal에서 Azure Managed Instance for Apache Cassandra 클러스터 만들기

필수 조건

관리되는 인스턴스 클러스터 만들기

데이터 센터 크기 조정

수평적 확장

수직적 확장

데이터 센터 추가

Cassandra 구성 업데이트

Cassandra 버전 업데이트

턴키 복제

자동 복제 시나리오

클러스터 할당 취소

문제 해결

클러스터에 연결

CQLSH에서 연결

애플리케이션에서 연결

클라이언트 인증서 구성(선택 사항)

리소스 정리

다음 단계

추가 리소스