확장성 있는 클라우드 애플리케이션 및 SRE(사이트 안정성 엔지니어링)

클라우드 솔루션의 성공은 안정성에 달려 있습니다. 안정성은 시스템이 지정된 시간 내에 지정된 환경 조건에서 예상대로 작동할 확률로 광범위하게 정의할 수 있습니다. SRE(사이트 안정성 엔지니어링)은 확장성 있고 매우 안정적인 소프트웨어 시스템을 만들기 위한 일련의 원칙과 관행입니다. SRE는 디지털 서비스를 설계하는 동안 더 큰 안정성을 보장하기 위해 점점 더 많이 사용됩니다.

SRE 전략에 대한 자세한 내용은 AZ-400: SRE(사이트 안정성 엔지니어링) 전략 개발을 참조하세요.

잠재적인 사용 사례

이 문서의 개념은 다음에 적용됩니다.

• API 기반 클라우드 서비스.
• 공용 웹 애플리케이션.
• IoT 기반 또는 이벤트 기반 워크로드.

아키텍처

이 아키텍처의 PowerPoint 파일을 다운로드합니다.

여기에서 고려되는 아키텍처는 확장성 있는 API 플랫폼의 아키텍처입니다. 이 솔루션은 Dynamics 365 및 Microsoft 365와 같은 SaaS(Software as a Service) 솔루션을 포함하여 다양한 데이터베이스 및 스토리지 서비스를 사용하는 여러 마이크로 서비스로 구성됩니다.

이 문서에서는 다이어그램에 표시된 블록을 보여 주기 위해 상위 수준의 마켓플레이스 및 전자 상거래 사용 사례를 처리하는 솔루션을 고려합니다. 사용 사례는 다음과 같습니다.

• 제품 탐색.
• 등록 및 로그인.
• 뉴스 문서와 같은 콘텐츠 보기.
• 주문 및 구독 관리.

웹앱, 모바일 앱 및 서비스 애플리케이션과 같은 클라이언트 애플리케이션은 통합 액세스 경로 https://api.contoso.com를 통해 API 플랫폼 서비스를 사용합니다.

구성 요소

• Azure Front Door는 솔루션에 대한 모든 요청에 대해 안전하고 통합된 진입점을 제공합니다. 자세한 내용은 라우팅 아키텍처 개요를 참조하세요.
• Azure API Management는 게시된 모든 API 위에 거버넌스 계층을 제공합니다. Azure API Management 정책을 사용하여 액세스 제한, 캐싱 및 데이터 변환과 같은 추가 기능을 API 계층에 적용할 수 있습니다. API Management는 표준 및 프리미엄 계층에서 자동 크기 조정을 지원합니다.
• AKS(Azure Kubernetes Service)는 오픈 소스 Kubernetes 클러스터의 Azure 구현입니다. 호스팅되는 Kubernetes 서비스인 Azure는 상태 모니터링 및 유지 관리 같은 중요 작업을 처리합니다. Kubernetes 마스터는 Azure에서 관리되므로 에이전트 노드만 관리하고 유지 관리합니다. 이 아키텍처에서 모든 마이크로 서비스는 AKS에 배포됩니다.
• Azure Application Gateway는 애플리케이션 제공 컨트롤러 서비스입니다. 애플리케이션 계층인 계층 7에서 동작하며 다양한 부하 분산 기능을 가지고 있습니다. AGIC(Application Gateway 수신 컨트롤러)는 AKS(Azure Kubernetes Service) 고객이 Azure의 기본 Application Gateway L7 부하 분산 장치를 사용하여 클라우드 소프트웨어를 인터넷에 노출할 수 있도록 하는 Kubernetes 애플리케이션입니다. 자동 크기 조정 및 영역 중복성은 v2 SKU에서 지원됩니다.
• Azure Storage, Azure Data Lake Storage, Azure Cosmos DB 및 Azure SQL은 구조화된 콘텐츠와 구조화되지 않은 콘텐츠를 모두 저장할 수 있습니다. Azure Cosmos DB 컨테이너 및 데이터베이스는 자동 크기 조정 처리량으로 만들 수 있습니다.
• Microsoft Dynamics 365는 고객 서비스, 영업, 마케팅 및 재무를 위한 여러 비즈니스 애플리케이션을 제공하는 Microsoft의 SaaS(Software as a Service)입니다. 이 아키텍처에서 Dynamics 365는 주로 제품 카탈로그 관리 및 고객 서비스 관리에 사용됩니다. 배율 단위는 Dynamics 365 애플리케이션에 복원력을 제공합니다.
• Microsoft 365(이전의 Office 365)는 Office 365 SharePoint Online에 구축된 엔터프라이즈 콘텐츠 관리 시스템으로 사용됩니다. 미디어 자산 및 문서와 같은 콘텐츠를 만들기, 관리 및 게시하는 데 사용됩니다.

대안

이 솔루션은 확장성이 뛰어난 마이크로 서비스 기반 아키텍처를 사용하므로 컴퓨팅 평면에 대해 다음 대안을 고려합니다.

• 서버리스 API 서비스용 Azure Functions
• Java 기반 마이크로 서비스용 Azure Spring Apps

적절한 안정성

솔루션에 필요한 안정성의 정도는 비즈니스 컨텍스트에 따라 다릅니다. 14시간 동안 영업하며 해당 기간 내에 시스템 사용량이 최고조에 달하는 소매점 매장은 모든 시간에 주문을 수락하는 온라인 비즈니스와는 다른 요구 사항을 가지고 있습니다. SRE 사례는 적절한 수준의 안정성을 달성하도록 조정될 수 있습니다.

안정성은 서비스의 대상 안정성 수준을 정의하는 SLO(서비스 수준 대상)를 사용하여 정의 및 측정됩니다. 대상 수준을 달성하면 소비자가 만족하고 있다는 것을 의미합니다. SLO 목표는 비즈니스 요구 사항에 따라 발전하거나 변경될 수 있습니다. 그러나 서비스 소유자는 문제를 검색하고 정정 작업을 취하기 위해 SLO에 대한 안정성을 지속적으로 측정해야 합니다. SLO는 일반적으로 일정 기간 동안의 백분율 달성으로 정의됩니다.

주목해야 할 또 다른 중요한 용어는 SLO를 계산하는 데 사용되는 메트릭인 SLI(서비스 수준 표시기)입니다. SLI는 고객이 서비스를 소비할 때 캡처된 데이터에서 파생된 인사이트를 기반으로 합니다. SLI는 항상 고객의 관점에서 측정됩니다.

SLO와 SLI는 항상 함께 사용되며 일반적으로 반복적인 방식으로 정의됩니다. SLO는 주요 비즈니스 목표에 따라 구동되는 반면 SLI는 서비스를 구현하는 동안 측정할 수 있는 항목에 따라 구동됩니다.

모니터링되는 메트릭, SLI 및 SLO 간의 관계는 다음과 같습니다.

이는 SLI 메트릭을 정의하여 SLO 계산에 자세히 설명되어 있습니다.

모델링 규모 및 성능 기대치

소프트웨어 시스템의 경우 성능은 일반적으로 지정된 시간 내에 작업을 실행할 때 시스템의 전반적인 응답성을 나타내는 반면 확장성은 성능을 저하시키지 않으면서 증가된 사용자 로드를 처리할 수 있는 시스템의 기능입니다.

부하 증가를 지원하기 위해 기본 리소스를 동적으로 사용할 수 있는 경우 시스템은 확장성 있는 것으로 간주됩니다. 클라우드 애플리케이션은 규모에 맞게 설계되어야 하며 트래픽 양을 예측하기 어려운 경우가 있습니다. 계절별 급증은 특히 서비스가 여러 테넌트에 대한 요청을 처리할 때 확장 요구 사항을 증가시킬 수 있습니다.

부하를 충족하기 위해 필요에 따라 클라우드 리소스가 자동으로 스케일 업 및 스케일 다운되도록 애플리케이션을 설계하는 것이 좋습니다. 기본적으로 시스템은 수요를 충족하기 위해 증분 방식으로 리소스를 프로비저닝하거나 할당하여 워크로드 증가에 적응해야 합니다. 확장성은 컴퓨팅 인스턴스뿐만 아니라 데이터 스토리지 및 메시지 인프라와 같은 다른 요소에도 적용됩니다.

이 문서에서는 워크로드 시나리오의 규모 및 성능 모델링을 수행하고 결과를 사용하여 모니터, SLI 및 SLO를 정의하여 클라우드 애플리케이션에 대한 적절한 안정성을 보장할 수 있는 방법을 보여 줍니다.

고려 사항

확장성 있고 안정적인 애플리케이션 구축에 대한 지침은 Azure Well Architected Framework의 안정성 및 성능 효율성 요소를 참조하세요.

이 문서에서는 확장성 및 성능 모델링 기술을 적용하여 솔루션 아키텍처와 설계를 미세 조정하는 방법을 살펴봅니다. 이러한 기술은 최적의 사용자 환경을 위해 트랜잭션 흐름의 변경 내용을 식별합니다. 솔루션의 비기능적 요구 사항을 기반으로 기술 결정을 내리세요. 프로세스는.

• 확장성 요구 사항을 식별합니다.
• 예상 부하를 모델링합니다.
• 사용자 시나리오에 대한 SLI 및 SLO를 정의합니다.

확장성 요구 사항 캡처

다음과 같은 최대 로드 메트릭을 가정합니다.

• API 플랫폼을 사용하는 소비자 수: 150만
• 시간당 활성 소비자(150만 명 중 30%): 450,000명
• 각 작업에 대한 부하 비율:
  • 제품 탐색: 75%
  • 프로필 만들기 및 로그인을 포함한 등록: 10%
  • 주문 및 구독 관리: 10%
  • 콘텐츠 시청: 5%

로드는 플랫폼에서 호스팅하는 API에 대해 정상 최대치 로드에서 다음과 같은 확장 요구 사항을 생성합니다.

• 제품 마이크로 서비스: 초당 약 500개 요청(RPS)
• 프로필 마이크로 서비스: 약 100RPS
• 주문 및 결제 마이크로 서비스: 약 100RPS
• 콘텐츠 마이크로 서비스: 약 50RPS

이러한 규모 요구 사항은 계절 및 임의 최대치와 마케팅 프로모션과 같은 특별 이벤트 동안의 최대치를 고려하지 않습니다. 최대치 기간 동안 일부 사용자 작업에 대한 규모 요구 사항은 정상 최대치 로드의 최대 10배입니다. 마이크로 서비스를 설계할 때 이러한 제약 조건과 기대치를 염두에 두어야 합니다.

SLO 계산을 위한 SLI 메트릭 정의

SLI 메트릭은 서비스가 만족스러운 환경을 제공하는 정도를 나타내며 전체 이벤트에 대한 좋은 이벤트의 비율로 표현할 수 있습니다.

API 서비스의 경우 이벤트는 실행 중에 원격 분석 또는 처리된 데이터로 캡처되는 애플리케이션별 메트릭을 나타냅니다. 이 예에는 다음과 같은 SLI 메트릭이 있습니다.

다음은 SLI의 예입니다.

• (1,000ms 이내에 성공적으로 완료된 요청 수) / (요청 수)
• (카탈로그에 게시된 모든 제품을 3초 이내에 반환하는 검색 결과 수) / (검색 수)

SLI를 정의한 후 이를 측정하기 위해 캡처할 이벤트 또는 원격 분석을 결정합니다. 예를 들어 가용성을 측정하기 위해 API 서비스가 요청을 성공적으로 처리했는지 여부를 나타내는 이벤트를 캡처합니다. HTTP 기반 서비스의 경우 성공 또는 실패는 HTTP 상태 코드로 표시됩니다. API 설계 및 구현은 적절한 코드를 제공해야 합니다. 일반적으로 SLI 메트릭은 API 구현에 중요한 입력입니다.

클라우드 기반 시스템의 경우 리소스에 사용할 수 있는 진단 및 모니터링 지원을 사용하여 일부 메트릭을 얻을 수 있습니다. Azure Monitor는 클라우드 서비스에서 원격 분석을 수집, 분석 및 조치하기 위한 포괄적인 솔루션입니다. SLI 요구 사항에 따라 더 많은 모니터링 데이터를 캡처하여 메트릭을 계산할 수 있습니다.

백분위수 분포 사용

일부 SLI는 백분위수 분포 기술을 사용하여 계산됩니다. 평균 또는 중앙값 분포와 같은 다른 기술을 왜곡할 수 있는 이상값이 있는 경우 더 나은 결과를 제공합니다.

예를 들어 메트릭이 API 요청의 대기 시간이고 3초가 최적의 성능을 위한 임계값이라고 가정합니다. 1시간의 API 요청에 대해 정렬된 응답 시간은 3초 이상 걸리는 요청이 거의 없고 대부분이 임계값 제한 내에서 응답을 수신하는 것으로 나타났습니다. 이는 시스템의 예상된 동작입니다.

백분위수 분포는 일시적인 문제로 인한 이상값을 제외하기 위한 것입니다. 예를 들어 적절한 서비스 응답이 90번째 또는 95번째 백분위수에 있으면 SLO가 충족된 것으로 간주됩니다.

적절한 측정 기간 선택

SLO를 정의하기 위한 측정 기간은 매우 중요합니다. 사용자 환경에 의미 있는 결과를 가져오려면 유휴 상태가 아닌 작업을 캡처해야 합니다. 이 기간은 SLI 메트릭을 모니터링하고 계산하는 방법에 따라 5분에서 24시간이 될 수 있습니다.

성과 거버넌스 프로세스 수립

API의 성능은 사용되지 않거나 사용 중지될 때까지 처음부터 관리해야 합니다. 성능 문제가 비즈니스에 영향을 미치는 주요 중단을 일으키기 전에 조기에 성능 문제를 검색하고 수정할 수 있도록 강력한 거버넌스 프로세스를 마련해야 합니다.

다음은 성과 거버넌스의 요소입니다.

• 성능 목표: 비즈니스 시나리오에 대한 야심 찬 성능 SLO를 정의합니다.
• 성능 모델링: 비즈니스에 중요한 워크플로 및 트랜잭션을 식별하고 모델링을 수행하여 성능 관련 영향을 이해합니다. 보다 정확한 예측을 위해 이 정보를 세부적인 수준에서 캡처합니다.
• 디자인 가이드라인: 성능 디자인 가이드라인을 준비하고 적절한 비즈니스 워크플로 수정을 권장합니다. 팀이 이러한 지침을 이해하도록 합니다.
• 구현 가이드라인: 메트릭 캡처를 위한 계측을 포함하여 솔루션 구성 요소에 대한 성능 설계 가이드라인을 구현합니다. 성능 설계 검토를 수행합니다. 서로 다른 팀의 아키텍처 백로그 항목을 사용하여 이 모든 것을 추적하는 것이 중요합니다.
• 성능 테스트: 부하 프로필 분포에 따라 부하 및 스트레스 테스트를 수행하여 플랫폼 상태와 관련된 메트릭을 캡처합니다. 제한된 부하에 대해 이러한 테스트를 수행하여 솔루션 인프라 요구 사항을 벤치마킹할 수도 있습니다.
• 병목 현상 분석: 코드 검사 및 코드 검토를 사용하여 다양한 구성 요소에서 성능 병목 현상을 식별, 분석 및 제거합니다. 최대 부하를 지원하는 데 필요한 수평 또는 수직 크기 조정 기능을 식별합니다.
• 지속적 모니터링: DevOps 프로세스의 일부로 지속적인 모니터링 및 경고 인프라를 구축합니다. 응답 시간이 벤치마크에 비해 현저히 저하되면 관련 팀에 이를 알립니다.
• 성과 거버넌스: 성능 SLO를 유지하기 위해 잘 정의된 프로세스와 팀으로 구성된 성능 거버넌스를 설정합니다. 빌드 업그레이드로 인한 성능 저하를 방지하기 위해 각 릴리스 후 규정 준수를 추적합니다. 정기적으로 검토를 수행하여 증가된 부하를 평가하여 솔루션 업그레이드를 식별합니다.

점진적인 정교화 프로세스의 일부로 솔루션 개발 과정에서 단계를 반복해야 합니다.

백로그에서 성과 목표 및 기대치 추적

달성할 수 있도록 성과 목표를 추적합니다. 추적할 세분화되고 상세한 사용자 스토리를 캡처합니다. 이렇게 하면 개발 팀이 성과 거버넌스 작업을 높은 우선 순위로 만드는 데 도움이 됩니다.

대상 솔루션에 대한 야심 찬 SLO 설정

다음은 고려 중인 API 플랫폼 솔루션에 대한 야심 찬 SLO 샘플입니다.

• 하루 동안 모든 READ 요청의 95%에 1초 이내에 응답합니다.
• 하루 동안 3초 이내에 모든 CREATE 및 UPDATE 요청의 95%에 응답합니다.
• 하루 동안 모든 요청의 99%에 오류 없이 5초 이내에 응답합니다.
• 하루 동안 모든 요청의 99.9%에 5분 이내에 성공적으로 응답합니다.
• 최대 1시간 창 오류 발생 동안 요청의 1% 미만.

SLO는 특정 애플리케이션 요구 사항에 맞게 조정할 수 있습니다. 그러나 안정성을 보장하기 위해 명확성을 갖도록 충분히 세분화하는 것이 중요합니다.

로그의 데이터를 기반으로 하는 초기 SLO 측정

API 서비스 사용 시 모니터링 로그가 자동으로 만들어집니다. 1주일 분량의 데이터에 다음이 표시된다고 가정합니다.

• 요청: 123,456
• 성공한 요청: 123,204
• 90번째 백분위수 대기 시간: 497ms
• 95번째 백분위수 대기 시간: 870ms
• 99번째 백분위수 대기 시간: 1,024ms

이 데이터는 다음과 같은 초기 SLI를 생성합니다.

• 가용성 = (123,204 / 123,456) = 99.8%
• 대기 시간 = 최소 90%의 요청이 500ms 이내에 처리됨
• 대기 시간 = 요청의 약 98%가 1000ms 이내에 처리되었습니다.

계획하는 동안 야심 차게 목표로 하는 대기 시간 SLO 대상은 요청의 90%가 500ms 이내에 처리되고 1주일 동안 99%의 성공률을 나타내는 것이라고 가정합니다. 로그 데이터를 통해 SLO 대상 달성 여부를 쉽게 식별할 수 있습니다. 몇 주 동안 이러한 유형의 분석을 수행하면 SLO 준수와 관련된 추세를 볼 수 있습니다.

기술적 위험 완화를 위한 지침

확장성 및 성능 위험을 완화하려면 다음 권장 사례 검사 목록을 사용합니다.

• 규모와 성능을 고려한 설계.
  • 계절성 및 최대치를 포함하여 모든 사용자 시나리오 및 워크로드에 대한 확장 요구 사항을 캡처해야 합니다.
  • 성능 모델링을 수행하여 시스템 제약 조건 및 병목 현상 식별
• 기술적인 문제를 관리합니다.
  • 성능 메트릭을 광범위하게 추적합니다.
  • 예를 들어 사용자 로드가 50~100RPS인 개발 스테이징 환경에서 스크립트를 사용하여 K6.io, Karate 및 JMeter와 같은 도구를 실행하는 것을 고려합니다. 이렇게 하면 설계 및 구현 문제를 검색하기 위한 정보가 로그에 제공됩니다.
  • 자동화된 테스트 스크립트를 CD(지속적인 배포) 프로세스의 일부로 통합하여 빌드 중단을 검색합니다.
• 프로덕션 마인드를 가지고 있습니다.
  • 상태 통계에 표시된 대로 자동 크기 조정 임계값을 조정합니다.
  • 수직보다 수평 크기 조정 기술을 기본 설정합니다.
  • 계절성을 처리하기 위해 사전에 크기 조정합니다.
  • 링 기반 배포를 선호합니다.
  • 오류 예산을 사용하여 실험합니다.

가격 책정

안정성, 성능 효율성 및 비용 최적화는 함께 진행됩니다. 아키텍처에 사용되는 Azure 서비스는 변화하는 사용자 부하를 수용하도록 자동 크기 조정되기 때문에 비용을 줄이는 데 도움이 됩니다.

AKS의 경우 처음에는 노드 풀의 표준 크기 VM으로 시작할 수 있습니다. 그런 다음 개발 또는 프로덕션 사용 중에 리소스 요구 사항을 모니터링하고 그에 따라 조정할 수 있습니다.

비용 최적화는 Microsoft Azure Well-Architected Framework의 핵심입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요. Azure 제품 및 구성의 비용을 예상하려면 가격 계산기를 사용합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Subhajit Chatterjee | 주요 소프트웨어 엔지니어

다음 단계

• Azure 설명서
• Microsoft Azure Well-Architected Framework
• 마이크로 서비스 아키텍처 스타일
• 규모 확장을 위한 디자인
• 애플리케이션에 사용할 Azure 컴퓨팅 서비스 선택
• 디자인 및 구현 패턴
• Azure Kubernetes Service의 마이크로 서비스 아키텍처
• Azure Front Door란?
• API Management 정보
• Application Gateway 수신 컨트롤러란?
• Azure Kubernetes Service
• 자동 크기 조정 및 영역 중복 Application Gateway v2
• AKS(Azure Kubernetes Service)에서 애플리케이션 수요에 맞게 클러스터 크기를 자동으로 조정
• 자동 스케일링 처리량을 사용하여 Azure Cosmos 컨테이너 및 데이터베이스 만들기
• Microsoft Dynamics 365 설명서
• Microsoft 365 설명서
• 사이트 안정성 엔지니어링 문서
• AZ-400: SRE(사이트 안정성 엔지니어링) 전략 개발

관련 참고 자료

• 영역 중복이 있는 기준 웹 애플리케이션
• Azure에서 웹 애플리케이션 모니터링