Azure 플랫폼 복원력

클라우드에서 신뢰할 수 있는 애플리케이션을 구축하는 것은 기존 온-프레미스 애플리케이션 개발과는 다릅니다. 과거에는 스케일 업을 위해 고급 하드웨어를 구입했지만 클라우드 환경에서는 스케일 아웃합니다. 오류를 예방하는 대신 그 영향을 최소화하고 시스템을 안정적으로 유지하는 것이 목표입니다.

즉, 안정적인 클라우드 애플리케이션은 다음과 같은 고유한 특성을 나타냅니다.

• 복원력이 있고, 문제로부터 정상적으로 복구되며, 계속 작동합니다.
• 고가용성(HA)을 유지하고 심각한 가동 중지 없이 정상 상태에서 설계한 대로 실행됩니다.

이러한 특성이 함께 작동하는 방법과 비용에 영향을 미치는 방식을 이해하는 것은 신뢰할 수 있는 클라우드 네이티브 애플리케이션을 구축하는 데 반드시 필요합니다. 다음으로 Azure 클라우드의 기능을 활용하여 클라우드 네이티브 애플리케이션에 복원력과 가용성을 빌드할 수 있는 방법을 살펴보겠습니다.

복원력 있는 설계

복원력을 통해 애플리케이션이 오류에 대응하고 계속 작동할 수 있습니다. Azure의 복원력 백서는 Azure 플랫폼에서 복원력을 달성하기 위한 지침을 제공합니다. 다음은 몇 가지 주요 권장 사항입니다.

• 하드웨어 오류. 여러 장애 도메인에 구성 요소를 배포하여 애플리케이션에 중복성을 빌드합니다. 예를 들어 가용성 집합을 사용하여 Azure VM이 다른 랙에 배치되었는지 확인합니다.

• 데이터 센터 오류. 데이터 센터에서 장애 격리 영역을 사용하여 애플리케이션에 중복성을 빌드합니다. 예를 들어 Azure 가용성 영역을 사용하여 Azure VM이 서로 다른 장애 격리 데이터 센터에 배치되었는지 확인합니다.

• 지역 오류. 애플리케이션을 신속하게 복구할 수 있도록 데이터와 구성 요소를 다른 지역에 복제합니다. 예를 들어 Azure Site Recovery를 사용하여 Azure VM을 다른 Azure 지역에 복제합니다.

• 과부하. 사용량 급증을 처리하기 위해 인스턴스 간에 부하 분산합니다. 예를 들어 부하 분산 장치 뒤에 둘 이상의 Azure VM을 배치하여 모든 VM에 트래픽을 분산합니다.

• 실수로 인한 데이터 삭제 또는 손상. 삭제 또는 손상이 있는 경우 복원할 수 있도록 데이터를 백업합니다. 예를 들어 Azure Backup을 사용하여 Azure VM을 주기적으로 백업합니다.

중복성을 포함한 설계

오류는 영향 범위가 다릅니다. 디스크 오류와 같은 하드웨어 오류는 클러스터의 단일 노드에 영향을 줄 수 있습니다. 실패한 네트워크 스위치는 전체 서버 랙에 영향을 줄 수 있습니다. 정전과 같은 덜 일반적인 오류는 전체 데이터 센터를 중단시킬 수 있습니다. 드물게 전체 지역을 사용할 수 없게 됩니다.

중복성은 애플리케이션 복원력을 제공하는 한 가지 방법입니다. 필요한 이중화의 정확한 수준은 비즈니스 요구 사항에 따라 다르며 시스템의 비용과 복잡성 모두에 영향을 미칩니다. 예를 들어 다중 지역 배포는 단일 지역 배포보다 비용이 많이 들고 관리하기 더 복잡합니다. 장애 조치(failover) 및 장애 복구를 관리하려면 운영 절차가 필요합니다. 추가 비용과 복잡성은 일부 비즈니스 시나리오에서 정당화될 수 있지만 다른 시나리오에서는 정당화되지 않을 수 있습니다.

중복성을 설계하려면 애플리케이션의 주요 경로를 식별한 다음 경로의 각 지점에 중복성이 있는지 확인해야 합니다. 하위 시스템에 오류가 발생하면 애플리케이션이 장애 조치(Failover)되나요? 마지막으로, 중복성 요구 사항을 충족하기 위해 활용할 수 있는 Azure 클라우드 플랫폼에 빌드된 기능에 대한 명확한 이해가 필요합니다. 다음은 중복성 설계에 대한 권장 사항입니다.

• 서비스의 여러 인스턴스를 배포합니다. 애플리케이션이 서비스의 단일 인스턴스에 종속된 경우 단일 실패 지점이 생깁니다. 여러 인스턴스를 프로비전하면 복원력 및 확장성이 모두 개선됩니다. Azure Kubernetes Service에서 호스팅할 때 Kubernetes 매니페스트 파일에서 중복 인스턴스(복제본 세트)를 선언적으로 구성할 수 있습니다. 복제본 수 값은 프로그래밍 방식으로, 포털에서 또는 자동 크기 조정 기능을 통해 관리할 수 있습니다.

• 부하 분산 장치를 활용합니다. 부하 분산은 애플리케이션의 요청을 정상 서비스 인스턴스에 분산하고 비정상 인스턴스를 윤번에서 자동으로 제거합니다. Kubernetes에 배포할 때 부하 분산은 서비스 섹션의 Kubernetes 매니페스트 파일에서 지정할 수 있습니다.

• 다중 지역 배포 계획 작성. 단일 지역에 애플리케이션을 배포하고 해당 지역을 사용할 수 없게 되면 애플리케이션도 사용할 수 없게 됩니다. 이는 애플리케이션의 서비스 수준 계약 약관에 따라 허용되지 않을 수 있습니다. 대신 여러 지역에 애플리케이션과 해당 서비스를 배포하는 것이 좋습니다. 예를 들어 AKS(Azure Kubernetes Service) 클러스터는 단일 지역에 배포됩니다. 지역별 오류로부터 시스템을 보호하기 위해 애플리케이션을 여러 지역의 여러 AKS 클러스터에 배포하고 쌍을 이루는 지역 기능을 사용하여 플랫폼 업데이트를 조정하고 복구 작업의 우선 순위를 지정할 수 있습니다.

• 지리적 복제 활성. Azure SQL Database 및 Cosmos DB와 같은 서비스에 대한 지역 복제는 여러 지역에 걸쳐 데이터의 보조 복제본을 만듭니다. 두 서비스 모두 동일한 지역 내에서 데이터를 자동으로 복제하지만 지역 복제는 보조 지역으로 장애 조치(failover)할 수 있도록 하여 지역 중단으로부터 사용자를 보호합니다. 지역 복제에 대한 또 다른 모범 사례는 컨테이너 이미지 저장을 중심으로 합니다. AKS에 서비스를 배포하려면 리포지토리에서 이미지를 저장하고 가져와야 합니다. Azure Container Registry는 AKS와 통합되어 컨테이너 이미지를 안전하게 저장할 수 있습니다. 성능과 가용성을 개선하려면 AKS 클러스터가 있는 각 지역의 레지스트리에 이미지를 지역 복제하는 것이 좋습니다. 그런 다음 각 AKS 클러스터는 그림 6-4와 같이 해당 지역의 로컬 컨테이너 레지스트리에서 컨테이너 이미지를 가져옵니다.

그림 6-4 지역 간 복제된 리소스

• DNS 트래픽 부하 분산 장치를 구현합니다.Azure Traffic Manager는 DNS 수준에서 부하 분산을 통해 중요한 애플리케이션에 대한 고가용성을 제공합니다. 지리적 위치, 클러스터 응답 시간 및 애플리케이션 엔드포인트 상태에 따라 트래픽을 다른 지역으로 라우팅할 수 있습니다. 예를 들어 Azure Traffic Manager는 고객을 가장 가까운 AKS 클러스터 및 애플리케이션 인스턴스로 보낼 수 있습니다. 서로 다른 지역에 여러 AKS 클러스터가 있는 경우 Traffic Manager를 사용하여 각 클러스터에서 실행되는 애플리케이션으로 트래픽이 흐르는 방식을 제어합니다. 그림 6-5는 이 시나리오를 보여 줍니다.

그림 6-5 AKS 및 Azure Traffic Manager

확장성을 위한 디자인

클라우드는 크기 조정에 성공합니다. 시스템 부하 증가/감소 문제를 해결하기 위해 시스템 리소스를 늘리거나 줄이는 기능은 Azure 클라우드의 핵심 요소입니다. 그러나 애플리케이션의 크기를 효과적으로 조정하려면 애플리케이션에 포함하는 각 Azure 서비스의 크기 조정 기능을 이해해야 합니다. 시스템에서 크기 조정을 효과적으로 구현하기 위한 권장 사항은 다음과 같습니다.

• 크기 조정을 고려한 디자인. 크기 조정을 고려하여 애플리케이션을 설계해야 합니다. 시작하려면 요청이 모든 인스턴스로 라우팅될 수 있도록 서비스가 상태 비저장이어야 합니다. 상태 비저장 서비스가 있다는 것은 인스턴스를 추가하거나 제거해도 현재 사용자에게 부정적인 영향을 미치지 않는다는 의미이기도 합니다.

• 파티션 워크로드. 도메인을 독립적인 자체 포함 마이크로 서비스로 분해하면 각 서비스 규모를 다른 서비스와 독립적으로 조정할 수 있습니다. 일반적으로 서비스에는 다양한 확장성 요구 사항과 요구 사항이 있습니다. 분할을 사용하면 전체 애플리케이션을 크기 조정하는 데 드는 불필요한 비용 없이 필요한 부분만 조정할 수 있습니다.

• 스케일 아웃을 선호합니다. 클라우드 기반 애플리케이션은 스케일 업하는 대신 리소스 스케일 아웃을 선호합니다. 스케일 아웃(수평 크기 조정이라고도 함)에는 원하는 수준의 성능을 충족하고 공유하기 위해 기존 시스템에 더 많은 서비스 리소스를 추가하는 작업이 포함됩니다. 스케일 업(수직 확장이라고도 함)에는 기존 리소스를 더 강력한 하드웨어(더 많은 디스크, 메모리 및 처리 코어)로 바꾸는 작업이 포함됩니다. 일부 Azure 클라우드 리소스에서 사용할 수 있는 자동 크기 조정 기능을 사용하여 수평 확장을 자동으로 호출할 수 있습니다. 여러 리소스에 걸쳐 스케일 아웃하면 전체 시스템에 중복성이 추가됩니다. 마지막으로 단일 리소스를 스케일 업하는 것은 일반적으로 많은 소규모 리소스에서 스케일 아웃하는 것보다 비용이 많이 듭니다. 그림 6-6은 두 가지 방법을 보여 줍니다.

그림 6-6 스케일 업 및 스케일 아웃

• 비례적으로 크기 조정합니다. 서비스 크기를 조정하는 경우 리소스 집합을 고려해야 합니다. 특정 서비스를 대폭 스케일 아웃하는 경우 백 엔드 데이터 저장소, 캐시 및 종속 서비스에 어떤 영향을 미치나요? Cosmos DB와 같은 일부 리소스는 비례적으로 스케일 아웃할 수 있지만 다른 리소스는 스케일 아웃할 수 없습니다. 연결된 다른 리소스가 모두 소모되는 지점까지 리소스를 스케일 아웃하지 않도록 해야 합니다.

• 선호도를 방지합니다. 고정 세션이라고도 하는 로컬 선호도가 필요하지 않도록 하는 것이 가장 좋습니다. 요청은 모든 인스턴스로 라우팅할 수 있어야 합니다. 상태를 유지해야 하는 경우 Azure Redis 캐시와 같은 분산 캐시에 저장해야 합니다.

• 플랫폼 자동 크기 조정 기능 활용. 가능한 경우 사용자 지정 또는 타사 메커니즘 대신 기본 제공 자동 크기 조정 기능을 사용합니다. 가능한 경우 예약된 크기 조정 규칙을 사용하여 시작 지연 없이 리소스를 사용할 수 있도록 하되, 예기치 않은 수요 변화에 대처하기 위해 적절한 경우 규칙에 반응적 자동 크기 조정을 추가하세요. 자세한 내용은 자동 크기 조정 지침을 참조하세요.

• 공격적으로 스케일 아웃합니다. 마지막 방법은 비즈니스 손실 없이 즉각적인 트래픽 급증에 신속하게 대처할 수 있도록 적극적으로 스케일 아웃하는 것입니다. 그런 다음 시스템을 안정적으로 유지하기 위해 보수적으로 스케일 인(즉, 불필요한 인스턴스를 제거)합니다. 이를 구현하는 간단한 방법은 조정 작업 사이에 대기하는 시간인 휴지 기간을 리소스 추가에 5분, 인스턴스 제거에 최대 15분으로 설정하는 것입니다.

서비스에 다시 시도 기본 제공

이전 섹션에서 프로그래밍 방식 다시 시도 작업을 구현하는 모범 사례를 권장했습니다. 많은 Azure 서비스 및 해당 클라이언트 SDK에는 다시 시도 메커니즘도 포함되어 있습니다. 다음 목록에는 이 책에서 설명하는 여러 Azure 서비스의 다시 시도 기능이 요약되어 있습니다.

• Azure Cosmos DB 클라이언트 API의 DocumentClient 클래스는 실패한 시도를 자동으로 다시 시도합니다. 다시 시도 횟수와 최대 대기 시간을 구성할 수 있습니다. 클라이언트 API에서 throw되는 예외는 다시 시도 정책을 초과하는 요청이거나 일시적이지 않은 오류입니다.

• Azure Redis Cache. Redis StackExchange 클라이언트는 실패한 시도에 대한 다시 시도를 포함하는 연결 관리자 클래스를 사용합니다. 다시 시도 횟수, 특정 다시 시도 정책 및 대기 시간을 모두 구성할 수 있습니다.

• Azure Service Bus. Service Bus 클라이언트는 백오프 간격, 다시 시도 횟수 및 작업이 수행할 수 있는 최대 시간을 지정하는 로 구성할 수 있는 TerminationTimeBuffer를 노출합니다. 기본 정책의 최대 다시 시도 횟수는 9번이며 시도 사이에 백오프 기간은 30초입니다.

• Azure SQL Database. 재시도 지원은 Entity Framework Core 라이브러리를 사용할 때 제공됩니다.

• Azure Storage. 스토리지 클라이언트 라이브러리는 다시 시도 작업을 지원합니다. 전략은 Azure Storage 테이블, Blob 및 큐에 따라 다릅니다. 또한 지역 중복 기능이 사용하도록 설정된 경우 대체 다시 시도는 기본 및 보조 스토리지 서비스 위치 간에 전환합니다.

• Azure Event Hubs - 이벤트 허브 클라이언트 라이브러리에는 구성 가능한 지수 백오프 기능이 포함된 RetryPolicy 속성이 있습니다.