애플리케이션을 확장성 있게 만들기
- 8분
이제 성장 준비의 기본 사항을 이해하고, 용량 계획에서 고려해야 할 요소들을 잘 알고 있으니, 애플리케이션을 최대한 확장성 있게 만드는 도전 과제를 맡을 수 있습니다.
건축 설계 검토
기억해야 할 핵심은 시스템에 대한 정기적인 아키텍처 검토를 수행해야 한다는 것입니다.
인프라와 같은 사례를 코드로 적용하여 클라우드 리소스를 배포하는 방법을 개선할 수 있습니다. 애플리케이션 코드를 정기적으로 업데이트하고 개선하면 기본 플랫폼 리소스에서 동일한 작업을 수행해야 합니다.
아키텍처 검토를 수행하면 개선이 필요한 영역을 식별하는 데 도움이 됩니다.
Azure 아키텍처 센터에는 클라우드에서 애플리케이션을 설계하는 데 도움이 되는 다양한 리소스가 있으며, 다음 링크의 애플리케이션 아키텍처 가이드에서 찾을 수 있는 많은 확장성 권장 사항이 있습니다.
시나리오: Tailwind Traders 아키텍처
첫 번째 단계는 아키텍처 및 애플리케이션의 평가를 수행하여 약점이 있는 위치를 결정할 뿐만 아니라 강점을 인식하는 것입니다. 그것에 대해 좋은 무엇입니까?
이전 단원에서 본 시나리오를 다시 살펴보세요. 다음은 조직의 아키텍처에 대한 다이어그램입니다.
애플리케이션을 더 작은 마이크로 서비스로 분해했으며, 이러한 서비스 중 일부는 Azure Kubernetes Service 컨테이너로 사용되거나 VM 또는 App Service에서 실행될 수 있습니다. 또한 Functions 및 Logic Apps와 같은 일부 본질적으로 확장 가능한 서비스를 사용하고 있습니다.
이 변경은 좋지만 애플리케이션의 확장성을 높일 수 있는 몇 가지 개선 사항이 있습니다. 예를 들어 이제 Products 서비스에 집중합니다. 다이어그램에서 제품 서비스는 Kubernetes에서 실행되고 있지만 이 설명은 Azure VM에서 실행되고 있다고 가정합니다. 약간 다른 구현을 사용하는 크기 조정 개념은 서버, App Service 또는 컨테이너에서 실행 중이든 애플리케이션에 적용할 수 있습니다.
제품은 현재 단일 Azure SQL 데이터베이스에 연결된 단일 VM에서 실행됩니다. 확장하려면 이 VM을 사용하도록 설정해야 합니다. 이 작업은 Azure 가상 머신 확장 집합을 사용하여 동일한 부하 분산 VM 그룹을 만들고 관리할 수 있습니다. 이제 둘 이상의 VM이 있으므로 VM 간에 트래픽을 분산하는 부하 분산 장치를 도입해야 합니다.
가상 머신 확장 집합
단일 VM에 가상 머신 확장 집합을 적용하면 다음과 같은 몇 가지 이점이 있습니다.
- 호스트 메트릭, 게스트 내 메트릭, 애플리케이션 인사이트 또는 일정에 따라 자동 크기 조정을 수행할 수 있습니다.
- 하나 이상의 데이터 센터로 구성된 Azure 지역 내에서 물리적으로 분리된 위치인 AZ(가용성 영역)를 사용할 수 있습니다. AZ 지원을 사용하면 여러 AZ에 VM을 분산할 수 있으므로 애플리케이션의 안정성이 향상되고 데이터 센터 오류로부터 보호할 수 있습니다. 확장 집합 내의 새 인스턴스는 자동으로 AZ에 균등하게 분산됩니다.
- 부하 분산 장치를 추가하는 것이 더 쉬워집니다. 가상 머신 확장 집합은 기본 계층 4 트래픽 분산에 Azure Load Balancer 사용을 지원합니다. 또한 고급 L7 트래픽 배포 및 SSL 종료에 대한 Azure Application Gateway 지원합니다.
확장 집합을 구현하기 전에 고려해야 할 몇 가지 중요한 요소가 있습니다. 특히:
- 클라이언트가 특정 백 엔드에 고정되지 않도록 인스턴스 고정을 방지합니다.
- VM에서 영구 데이터를 제거하고 Azure Storage 또는 데이터베이스와 같은 다른 위치에 저장합니다.
- 규모 축소를 위한 설계입니다. 애플리케이션을 쉽게 축소할 수 있는 것도 중요합니다. 트래픽을 처리하는 서버 풀에 더 많은 인스턴스가 추가될 뿐만 아니라 부하가 감소함에 따라 인스턴스의 갑작스러운 종료도 정상적으로 처리해야 합니다. 크기 조정의 축소 측면은 종종 간과됩니다.
분리
확장 집합을 사용하여 더 많은 VM을 추가했습니다. 스케일 아웃은 "크기를 조정해야 합니다"에 대한 일반적인 대답입니다. 그러나 단일 메트릭에서만 크기를 조정할 수 있으며 이 답변은 제품 서비스에서 수행하는 모든 작업과 관련이 없을 수 있습니다.
이 시나리오에서 제품 서비스에는 제품 이미지가 업로드될 때 해당 이미지를 트랜스코딩하고 썸네일, 카탈로그의 그림 등에 대해 여러 가지 크기로 저장합니다. 이미지 처리는 CPU를 많이 사용하지만 일반적인 사용량은 메모리를 많이 사용합니다.
이미지 처리는 백그라운드 작업으로 나눌 수 있는 비동기 작업입니다. 큐를 사용하여 이미지 처리 서비스를 분리하여 이 작업을 수행할 수 있습니다. 분리를 통해 메모리(제품 서비스)의 서비스 및 CPU 또는 큐 길이의 기타 서비스(이미지 처리 서비스)와 같은 두 가지 서비스를 독립적으로 스케일링하고 다른 확장 집합이 해당 메시지를 사용하고 이미지를 처리하도록 할 수 있습니다.
큐로 크기 조정
Azure의 두 가지 유형의 큐 서비스가 있습니다.
- Azure Service Bus 큐 더 광범위한 Azure Service Bus 제품의 일부인 고급 큐 제공으로, pub/sub 및 고급 통합 패턴을 제공합니다.
- Azure Storage 큐 Azure Storage 기반으로 빌드된 간단한 REST 기반 큐 인터페이스입니다. 안정적이고 지속적인 메시징을 제공합니다.
이 시나리오의 요구 사항은 간단하므로 Azure Storage 큐를 사용할 수 있습니다. 이 백그라운드 작업을 분리했기 때문에 제품 계층의 크기를 전혀 조정할 필요가 없습니다.
메모리 내 캐싱
애플리케이션의 성능을 향상시키는 또 다른 방법은 메모리 내 캐시를 구현하는 것입니다.
이제 성능이 정확히 확장성과 같지는 않지만 애플리케이션의 성능을 개선하면 다른 리소스에 대한 부하를 줄일 수 있습니다. 이 개선은 즉시 크기를 조정할 필요가 없다는 것을 의미합니다.
Azure Managed Redis(이전의 Azure Cache for Redis)는 관리되는 Redis 제품입니다. Redis는 여러 패턴 및 사용 사례에 사용할 수 있습니다. 이 시나리오에서 제품 서비스의 경우 캐시 배제 패턴을 구현할 가능성이 높습니다. 이 패턴에서는 필요에 따라 데이터베이스에서 캐시로 항목을 로드하여 애플리케이션의 성능을 향상시키고 데이터베이스에 대한 부하를 줄입니다.
Redis는 메시징 큐, 웹 콘텐츠 캐싱 또는 사용자 세션 캐싱에 사용할 수도 있습니다. 이러한 유형의 캐싱은 쿠키를 사용하는 대신 Redis에서 세션당 쇼핑 카트 데이터를 저장할 수 있는 쇼핑 카트 서비스와 같은 시스템의 다른 서비스에 더 적합할 수 있습니다.
데이터베이스 크기 조정
이제 컴퓨팅 리소스를 확장성 있게 만들었으므로 데이터베이스를 살펴보세요. 이 시나리오에서는 Azure 관리되는 SQL Server 제품인 Azure SQL Database 사용합니다.
관계형 데이터베이스는 비관계형 데이터베이스보다 스케일 아웃하기가 더 어렵습니다. 데이터베이스 크기를 조정하기 위해 가장 먼저 수행할 수 있는 작업은 데이터베이스 크기를 확장하는 것입니다. 이 크기 조정은 Azure SQL 간단한 API 호출을 사용하거나 포털에서 슬라이더를 사용하여 잠시 연결이 끊어지면 쉽게 수행할 수 있습니다.
이 크기 조정이 트래픽 특성에 따라 요구 사항을 충족하지 않는 경우 읽기를 데이터베이스로 확장하여 읽기 트래픽을 읽기 복제본으로 라우팅할 수 있도록 하는 것이 적합할 수 있습니다.
비고
Azure SQL의 읽기 스케일 아웃 기능은 기본적으로 프리미엄, 비즈니스 크리티컬, 하이퍼스케일 계층에서 사용할 수 있습니다. 하이퍼스케일의 경우 하나 이상의 보조 복제본을 구성해야 합니다. 기본 또는 표준 계층에서는 사용하도록 설정할 수 없습니다.
이 변경 내용은 코드에서 구현해야 합니다. 데이터베이스 연결 문자열 ApplicationIntent 특성을 설정하여 라우팅 의도를 지정합니다.
ReadOnly를 사용하여 복제본에 연결하거나 ReadWrite를 사용하여 주 복제본에 연결합니다.
권장되는 방법은 인증에 관리 ID를 사용하여 필요한 구성을 Azure Key Vault 저장하는 것입니다.
#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;
#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;
중요합니다
프로덕션 환경에서는 인증에 관리 ID를 사용합니다. 애플리케이션에 필요한 추가 비밀의 경우 코드 또는 구성 파일이 아닌 Azure Key Vault 저장합니다.
이 변경 내용은 코드에서 구현되어야 하므로 상황에 적합한 솔루션이 아닐 수 있습니다. 모든 단일 제품 서비스에 읽기 및 쓰기 기능이 필요한 경우 어떻게 해야 하나요?
이 경우 분할을 사용하여 Azure SQL Database 스케일 아웃하는 것을 볼 수 있습니다.
분할된 데이터베이스
읽기 복제본을 확장하거나 구현한 후에도 데이터베이스 리소스가 시스템의 요구 사항을 충족하지 못하는 경우 다음 옵션은 분할입니다.
분할은 많은 독립 데이터베이스에 동일한 구조화된 대량의 데이터를 분산하는 기술입니다. 분할은 많은 이유로 필요할 수 있습니다. 다음은 그 예입니다.
- 총 데이터 양이 너무 커서 개별 데이터베이스의 제약 조건에 맞지 않습니다.
- 전체 워크로드의 트랜잭션 처리량이 개별 데이터베이스의 기능을 초과합니다.
- 별도의 테넌트는 규정 준수를 위해 서로 다른 물리적 데이터베이스에 상주해야 합니다(이 요구 사항은 크기 조정에 대한 것이 아니라 분할이 사용되는 또 다른 상황임).
애플리케이션은 관련 분할된 데이터베이스에 관련 데이터를 추가하므로 개별 데이터베이스의 제약 조건을 초과하여 시스템을 확장할 수 있습니다.
Azure SQL Azure Elastic Database 도구를 제공합니다. 이러한 도구를 사용하면 애플리케이션 논리에서 Azure 분할된 SQL 데이터베이스를 만들고, 유지 관리하고, 쿼리할 수 있습니다.