이 참조 아키텍처에서는 데이터 계층에 대해 Linux에서 Apache Cassandra를 사용하여 N 계층 애플리케이션을 위해 구성되는 VM(가상 머신) 및 가상 네트워크를 배포하는 방법을 보여 줍니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
이 아키텍처의 구성 요소는 다음과 같습니다.
일반
리소스 그룹. 리소스 그룹은 리소스를 수명, 소유자를 비롯한 기준으로 관리할 수 있도록 Azure 리소스를 그룹화하는 데 사용됩니다.
가용성 영역. 가용성 영역은 Azure 지역 내의 물리적 위치입니다. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다. VM을 여러 영역에 배치하면 애플리케이션의 한 영역 내에서 오류가 발생할 경우 복원력이 향상됩니다.
네트워킹 및 부하 분산
가상 네트워크 및 서브넷. 모든 Azure VM은 가상 네트워크에 배포되어 서브넷으로 분할될 수 있습니다. 각 계층에 대해 별도의 서브넷을 만듭니다.
Application Gateway Application Gateway는 계층 7 부하 분산 장치입니다. 이 아키텍처에서 HTTP 요청을 웹 프런트 엔드로 라우팅합니다. 또한 application Gateway는 일반적인 악용 및 취약점으로부터 애플리케이션을 보호하는 WAF(웹 애플리케이션 방화벽)을 제공합니다.
Load Balancer Azure Standard Load Balancer를 사용하여 웹 계층에서 비즈니스 계층으로 네트워크 트래픽을 분산합니다.
NSG(네트워크 보안 그룹). NSG를 사용하여 가상 네트워크 내에서 네트워크 트래픽을 제한합니다. 예를 들어 여기에 표시된 3계층 아키텍처에서 데이터베이스 계층은 비즈니스 계층 및 관리 서브넷뿐 아니라 웹 프론트 엔드의 트래픽을 허용하지 않습니다.
DDoS Protection Azure 플랫폼이 DDoS(분산 서비스 거부) 공격에 대한 기본 보호를 제공하지만 Azure DDoS 네트워크 보호를 사용하는 것이 좋습니다. 그러면 DDoS 완화를 강화하게 됩니다. 보안 고려사항을 참조하세요.
Azure DNS. Azure DNS는 DNS 도메인에 대한 호스팅 서비스입니다. 이 서비스는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공합니다. Azure에 도메인을 호스트하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다.
가상 머신
Apache Cassandra 데이터베이스. 복제 및 장애 조치(failover)를 사용하여 데이터 계층에서 높은 가용성을 제공합니다.
OpsCenter. DataStax OpsCenter와 같은 모니터링 솔루션을 배포하여 Cassandra 클러스터를 모니터링합니다.
Jumpbox. 요새 호스트라고도 합니다. 관리자가 다른 VM에 연결할 때 사용하는 네트워크의 보안 VM입니다. jumpbox는 안전 목록에 있는 공용 IP 주소의 원격 트래픽만 허용하는 NSG를 사용합니다. NSG는 RDP(원격 데스크톱) 트래픽을 허용해야 합니다.
권장 사항
개발자의 요구 사항이 여기에 설명된 아키텍처와 다를 수 있습니다. 여기서 추천하는 권장 사항을 단지 시작점으로 활용하세요.
가상 머신
VM 구성 권장 사항은 Azure에서 Linux VM 실행을 참조하세요.
가상 네트워크
가상 네트워크를 만들 때 각 서브넷에 포함된 리소스에 몇 개의 IP 주소가 필요한지 결정합니다. CIDR 표기법을 사용하여 필요한 IP 주소를 충족하는 서브넷 마스크와 네트워크 주소 범위를 지정합니다. 표준 개인 IP 주소 블록(10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16)에 해당하는 주소 공간을 사용합니다.
나중에 VNet과 온-프레미스 네트워크 사이에 게이트웨이를 설정해야 할 경우에 대비하여 온-프레미스 네트워크와 중복되지 않는 주소 범위를 선택합니다. VNet을 만든 뒤에는 주소 범위를 변경할 수 없습니다.
기능 및 보안 요구 사항을 염두에 두고 서브넷을 구성합니다. 동일한 계층이나 역할에 속한 모든 VM은 동일한 서브넷에 속해야 합니다. 이때 서브넷은 보안 경계가 될 수 있습니다. VNet 및 서브넷 디자인에 대한 자세한 내용은 Azure Virtual Networks 계획 및 디자인을 참조하세요.
Application Gateway
Application Gateway를 구성하는 방법에 대한 내용은 Application Gateway 구성 개요를 참조하세요.
부하 분산 장치
인터넷에 직접 VM을 노출하지 않습니다. 대신 각 VM에 개인 IP 주소를 제공합니다. 클라이언트는 Application Gateway와 연결된 IP 주소를 통해 연결합니다.
네트워크 트래픽이 VM으로 전달되도록 부하 분산 장치 규칙을 정의합니다. 예를 들어 HTTP 트래픽을 허용하려면 프론트 엔드 구성의 포트 80을 백엔드 주소 풀의 포트 80으로 매핑하는 규칙을 만듭니다. 클라이언트가 포트 80으로 HTTP 요청을 전송하면 부하 분산 장치가 소스 IP 주소를 포함하는 해싱 알고리즘을 사용하여 백엔드 IP 주소를 선택합니다. 클라이언트 요청은 모든 VM에 걸쳐 분산됩니다.
네트워크 보안 그룹
NSG 규칙을 사용하여 계층 사이의 트래픽을 제한합니다. 위에 표시된 3계층 아키텍처에서 웹 계층은 데이터베이스 계층과 직접 통신하지 않습니다. 이를 위해서는 데이터베이스 계층에서 웹 계층 서브넷으로부터 수신되는 트래픽을 차단해야 합니다.
- VNet의 모든 인바운드 트래픽을 거부합니다. (규칙에
VIRTUAL_NETWORK태그를 사용합니다.) - 비즈니스 계층 서브넷의 인바운드 트래픽을 허용합니다.
- 데이터베이스 계층 서브넷 자체의 인바운드 트래픽을 허용합니다. 이 규칙은 데이터베이스 복제와 장애 조치에 필요한 데이터베이스 VM 간 통신을 허용합니다.
- jumpbox 서브넷에서 ssh 트래픽(22 포트)을 허용합니다. 관리자는 이 규칙을 사용하여 jumpbox에서 데이터베이스 계층에 연결할 수 있습니다.
첫 번째 규칙보다 우선 순위가 높은 2 – 4 규칙을 만들어 재정의합니다.
Cassandra
프로덕션 사용의 경우 DataStax Enterprise를 권장하나, 이러한 권장 사항은 모든 Cassandra 버전에 적용됩니다. Azure에서 DataStax 실행에 관한 자세한 내용은 Azure용 DataStax Enterprise 배포 가이드를 참조하세요.
노드를 랙 인식 모드로 구성합니다. 오류 도메인을 cassandra-rackdc.properties 파일의 랙에 매핑합니다.
클러스터 앞에 부하 분산 장치가 필요하지 않습니다. 클라이언트는 클러스터의 노드에 직접 연결합니다.
이 아키텍처의 배포 스크립트는 이름 확인을 사용하여 클러스터 내 통신(가십)에 대한 시드 노드를 초기화합니다. 이름 확인을 사용하도록 설정하기 위해 배포는 Cassandra 노드에 대한 A 레코드를 사용하여 Azure 프라이빗 DNS 영역을 만듭니다. 초기화 스크립트에 따라 고정 IP 주소를 대신 사용할 수 있습니다.
참고
Azure 프라이빗 DNS는 현재 공개 미리 보기로 제공됩니다.
Jumpbox
공용 인터넷에서 애플리케이션 워크로드를 실행하는 VM으로의 SSH 액세스를 허용하지 않습니다. 대신, 이러한 VM에 대한 모든 ssh 액세스는 jumpbox를 통해 이루어져야 합니다. 관리자는 jumpbox에 로그인한 다음, jumpbox에서 다른 VM에 로그인하게 됩니다. jumpbox는 인터넷으로부터의 ssh 트래픽을 허용하지만, 알려진 안전한 IP 주소만 허용됩니다.
jumpbox에는 최소 성능 요구 사항이 있으므로 작은 VM 크기를 선택합니다. jumpbox에 대한 공용 IP 주소를 만듭니다. jumpbox를 다른 VM과 동일한 VNet 안에 배치하되 별도의 관리 서브넷에 배치합니다.
jumpbox를 보호하려면 안전한 공용 IP 주소 집합의 ssh 연결만 허용하는 NSG 규칙을 추가합니다. 관리 서브넷에서 ssh 트래픽을 허용하도록 다른 서브넷에 대한 NSG를 구성합니다.
고려 사항
확장성
확장 집합
웹 및 비즈니스 계층의 경우 가용성 집합에 별도 VM을 배포하는 대신 Virtual Machine Scale Sets를 사용하는 것이 좋습니다. 확장 집합을 통해 동일한 VM 집합을 쉽게 배포하고 관리하며, 성능 메트릭에 따라 VM의 크기를 자동으로 조정할 수 있습니다. VM들의 부하가 늘어나면 부하 분산 장치에 VM이 자동으로 추가됩니다.
확장 집합에 배포된 VM을 구성하는 방법에는 두 가지가 있습니다.
VM이 배포된 후에 확장명을 사용하여 VM을 구성합니다. 이렇게 하면 확장명이 없는 VM보다 새 VM 인스턴스를 시작하는 데 시간이 더 오래 걸릴 수 있습니다.
사용자 지정 디스크 이미지를 사용하여 관리 디스크를 배포합니다. 이 옵션을 사용하면 배포 시간이 단축될 수 있습니다. 하지만 그러러면 이미지를 최신 상태로 유지해야 합니다.
자세한 내용은 확장 집합 디자인 고려 사항을 참조하세요.
팁
자동 확장 솔루션을 사용할 때는 사전에 미리 프로덕션 수준 워크로드로 테스트해야 합니다.
구독 제한
각 Azure 구독에는 지역당 최대 VM 개수를 비롯해 기본적인 제한이 적용됩니다. 지원 요청을 제출하여 제한을 늘릴 수 있습니다. 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.
Application Gateway
Application Gateway는 고정 용량 모드 또는 자동 크기 조정 모드를 지원합니다. 고정 용량 모드는 워크로드가 일관적이고 예측 가능한 시나리오에 유용합니다. 가변 트래픽이 있는 워크로드에 자동 크기 조정 모드를 사용하는 것이 좋습니다. 자세한 내용은 자동 스케일링 및 영역 중복 Application Gateway v2를 참조하세요.
성능 효율성
Azure VM의 Cassandra에서 최상의 성능을 얻으려면 Azure VM에서 Apache Cassandra 실행의 권장 사항을 참조하세요.
가용성
가용성 영역은 단일 지역 내에서 최상의 복원력을 제공합니다. 더 높은 가용성이 필요한 경우 두 지역에 걸쳐 애플리케이션을 복제하는 것이 좋습니다.
모든 지역에서 가용성 영역을 지원하는 것은 아니며 모든 VM 크기가 모든 영역에서 지원되는 것도 아닙니다. 다음 Azure CLI 명령을 실행하여 지역 내의 각 VM 크기에 대해 지원되는 영역을 찾습니다.
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
가용성 영역을 지원하지 않는 지역에 이 아키텍처를 배포하는 경우 각 계층에 대한 VM을 가용성 집합 내에 배치합니다. 동일한 가용성 내의 VM은 중복성을 위해 여러 물리적 서버, 컴퓨팅 랙, 스토리지 단위 및 네트워크 스위치 간에 배포됩니다. 확장 집합은 자동으로 배치 그룹을 사용합니다. 이 기능은 암시적인 가용성 집합으로 작동합니다.
가용성 영역에 배포할 때 Azure Load Balancer의 표준 SKU 및 Application Gateway의 v2 SKU를 사용합니다. 이러한 SKU는 영역 간 중복성을 지원합니다. 자세한 내용은 다음을 참조하세요.
- 표준 Load Balancer 및 가용성 영역
- 자동 크기 조정 및 영역 중복 Application Gateway v2
- Application Gateway는 고가용성과 확장성을 어떤 방식으로 지원하나요?
단일 Application Gateway 배포는 게이트웨이의 여러 인스턴스를 실행할 수 있습니다. 프로덕션 워크로드의 경우 두 개 이상의 인스턴스를 실행합니다.
Cassandra 클러스터
Cassandra 클러스터의 경우 장애 조치(failover) 시나리오는 애플리케이션에서 사용된 일관성 수준 및 복제 수에 따라 달라집니다. Cassandra의 일관성 수준 및 사용량은 데이터 일관성 구성 및 Cassandra: Quorum과 통신하는 노드 수를 참조하세요. Cassandra의 데이터 가용성은 애플리케이션 및 복제 메커니즘에서 사용하는 일관성 수준에 따라 결정됩니다. Cassandra의 복제에 대해서는 Data Replication in NoSQL Databases Explained(NoSQL 데이터베이스의 데이터 복제 설명)를 참조하세요.
상태 프로브
Application Gateway 및 Load Balancer 둘 다 상태 프로브를 사용하여 VM 인스턴스의 가용성을 모니터링합니다.
- Application Gateway는 항상 HTTP 프로브를 사용합니다.
- Load Balancer는 HTTP와 TCP를 모두 테스트할 수 있습니다. 일반적으로 VM이 HTTP 서버를 실행하는 경우 HTTP 프로브를 사용합니다. 그렇지 않으면 TCP를 사용합니다.
프로브가 시간 제한 내에 인스턴스에 도달하지 못할 경우 게이트웨이 또는 부하 분산 장치는 해당 VM으로 전달되는 트래픽을 차단합니다. 프로브는 계속 확인하고 VM을 다시 사용할 수 있게 되면 VM을 백 엔드 풀로 반환합니다.
HTTP 프로브는 지정된 경로에 HTTP GET 요청을 보내고 HTTP 200 응답을 수신 대기합니다. 이 경로는 루트 경로("/")일 수도 있고, 애플리케이션의 상태를 확인하는 일부 사용자 지정 로직을 구현하는 상태 모니터링 엔드포인트일 수도 있습니다. 엔드포인트는 익명의 HTTP 요청을 허용해야 합니다.
상태 프로브에 대한 자세한 내용은 다음을 참조하세요.
상태 프로브 엔드포인트 디자인에 대한 고려 사항은 상태 엔드포인트 모니터링 패턴을 참조하세요.
비용 최적화
Azure 가격 책정 계산기를 사용하여 비용을 예측합니다. 기타 고려 사항은 다음과 같습니다.
가상 머신 크기 집합
가상 머신 확장 집합은 모든 Linux VM 크기에서 사용할 수 있습니다. 배포하는 Azure VM과 스토리지 및 네트워킹과 같이 사용된 추가 기본 인프라 리소스에 대해서만 요금이 청구됩니다. Virtual Machine Scale Sets 서비스 자체에 대한 증분 요금은 없습니다.
단일 VM 가격 책정 옵션은 Linux VM 가격 책정을 참조하세요.
부하 분산 장치
구성된 부하 분산 및 아웃바운드 규칙 수에 대해서만 요금이 청구됩니다. 인바운드 NAT 규칙은 무료입니다. 규칙이 구성되지 않은 경우 표준 Load Balancer에 대한 시간당 요금은 없습니다.
자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.
보안
가상 네트워크는 Azure의 트래픽 격리 경계입니다. 하나의 VNet에 속한 VM은 다른 VNet에 속한 VM과 직접 통신할 수 없습니다. 하나의 VNet에 속한 여러 VM은 사용자가 트래픽을 제한하기 위해 NSG(네트워크 보안 그룹)를 만들지 않은 이상 서로 통신할 수 있습니다. 자세한 내용은 Microsoft 클라우드 서비스 및 네트워크 보안을 참조하세요.
수신되는 인터넷 트래픽의 경우 부하 분산 장치의 규칙이 어느 트래픽이 백엔드에 도달할 수 있는지 정의합니다. 단, 부하 분산 장치의 규칙은 IP 안전 목록을 지원하지 않으므로 안전 목록에 특정 공용 IP 주소를 추가하려면 서브넷에 NSG를 추가해야 합니다.
DMZ NVA(네트워크 가상 어플라이언스)를 추가하여 인터넷과 Azure 가상 네트워크 사이에 DMZ를 만드는 것도 좋은 방법입니다. NVA는 방화벽, 패킷 조사, 감사, 사용자 지정 라우팅과 같은 네트워크 관련 작업을 수행하는 가상 어플라이언스를 통칭하는 용어입니다. 자세한 내용은 Azure와 인터넷 사이에 DMZ 구현을 참조하세요.
암호화. 중요한 미사용 데이터를 암호화하고 Azure Key Vault를 사용하여 데이터베이스 암호화 키를 관리합니다. Key Vault는 암호화 키를 HSM(하드웨어 보안 모듈)에 저장합니다. 또한 Key Vault에 데이터베이스 연결 문자열과 같은 애플리케이션 비밀을 저장하는 것이 좋습니다.
DDoS 보호 Azure 플랫폼은 기본적으로 기본 DDoS 보호를 제공합니다. 이 기본 보호는 전체 Azure 인프라를 보호할 대상으로 지정합니다. 기본 DDoS 보호가 자동으로 설정되지만 Azure DDoS 네트워크 보호를 사용하는 것이 좋습니다. 네트워크 보호는 애플리케이션의 네트워크 트래픽 패턴을 기반으로 적응형 조정을 사용하여 위협을 검색합니다. 그러면 인프라 수준의 DDoS 정책에 의해 알려지지 않을 수 있는 DDoS 공격에 대한 완화를 적용할 수 있습니다. 네트워크 보호는 Azure Monitor를 통해 경고, 원격 분석 및 분석도 제공합니다. 자세한 내용은 Azure DDoS Protection: 모범 사례 및 참조 아키텍처를 참조하세요.
운영 우수성
모든 주요 리소스와 해당 종속성은 이 아키텍처의 동일한 가상 네트워크에 있으므로 동일한 기본 워크로드에서 격리됩니다. 이를 통해 팀이 해당 리소스의 모든 측면을 독립적으로 관리할 수 있도록 워크로드의 특정 리소스를 DevOps 팀과 쉽게 연결하도록 해줍니다. 이러한 격리를 통해 DevOps 팀 및 서비스는 CI/CD(연속 통합 및 지속적인 업데이트)를 수행할 수 있습니다.
또한 다양한 배포 템플릿을 사용하고 Azure DevOps Services와 통합하여 몇 분 안에 다양한 환경을 프로비저닝할 수 있습니다. 예를 들어, 필요한 경우에만 프로덕션 유사 시나리오를 복제하거나 테스트 환경을 로드하여 비용을 절감할 수 있습니다.
이 시나리오에서는 가상 머신이 Apache Cassandra와 같은 특정 추가 소프트웨어를 설치할 수 있으므로 Virtual Machine 확장을 사용하여 구성됩니다. 특히 사용자 지정 스크립트 확장을 사용하면 Virtual Machine에서 임의의 코드를 다운로드하고 실행할 수 있으므로 Azure VM 운영 체제를 무제한으로 사용자 지정할 수 있습니다. VM 확장은 VM을 만들 때만 설치되고 실행됩니다. 즉, 운영 체제가 이후 스테이지에서 잘못 구성된 경우 올바른 상태로 다시 전환하려면 수동 개입이 필요합니다. 구성 관리 도구를 사용하여 이 문제를 해결할 수 있습니다.
Azure Monitor를 사용하여 인프라의 성능을 분석 및 최적화하고 가상 머신에 로그인하지 않고 네트워킹 문제를 모니터링 및 진단하는 것이 좋습니다. Application Insights는 실제로 전체 Azure 환경의 상태를 확인하기 위한 풍부한 메트릭과 로그를 제공하는 Azure Monitor의 구성 요소 중 하나입니다. Azure Monitor는 인프라의 상태를 따르는 데 도움이 됩니다.
애플리케이션 데이터 계층의 낮은 성능은 심각한 결과를 초래할 수 있으므로 애플리케이션 코드를 지원하는 컴퓨팅 요소뿐 아니라 특정 데이터베이스에서 데이터 플랫폼도 모니터링해야 합니다.
애플리케이션이 실행되는 Azure 환경을 테스트하기 위해서는 애플리케이션 코드와 동일한 메커니즘을 통해 버전이 제어되고 배포되어야 하므로 DevOps 테스트 패러다임을 사용해 테스트하고 유효성을 검사할 수도 있습니다.
자세한 내용은 Microsoft Azure Well-Architecture Framework의 운영 효율성 섹션을 참조하세요.