준비
조직의 높은 안정성 요구 사항을 충족하는 기존 아키텍처에 고유한 향상된 기능을 추가할 것입니다. 여기서는 연습을 성공적으로 진행하는 데 필요한 배경 컨텍스트에 대해 설명합니다.
문제 컨텍스트
Contoso Shoes는 트래픽이 크게 증가할 것으로 예상되는 다음 유명 제품 출시를 준비해야 합니다. 지난 2년 동안 웹 사이트가 반나절 동안 오프라인 상태가 되는 몇 가지 인시던트가 있었습니다. 시스템이 개발/테스트 환경에서 완전히 테스트되지 않았으며 일부 버그가 프로덕션 환경으로 전환되었습니다. 운영자가 근본 원인을 신속하게 식별할 수 없으므로 문제 해결 및 수정에 오랜 시간이 걸렸습니다.
특정 구성 요소를 사용할 수 없는 경우 몇 가지 문제가 있었습니다. 컴퓨팅에 대한 스케일 아웃 작업은 Azure Key Vault가 잘못 구성되었을 때 영향을 받았습니다. 또한 지역 가동 중단에 대한 전략은 없습니다. 최근 인시던트에서 서유럽 지역 전체가 무너졌습니다. 워크로드는 해당 지역에서만 실행 중이었기 때문에 회사는 지역이 백업될 때까지 재정적 손실을 감수해야 했습니다.
현재 아키텍처
이 과제를 완료하려면 Contoso Shoe의 현재 아키텍처를 잘 이해해야 합니다. API 계층에 집중해 보겠습니다.
구성 요소
이 아키텍처의 모든 구성 요소는 단일 지역에 배포됩니다.
Azure App Service 요금제의 표준 S2 SKU는 앱을 호스트하는 컴퓨팅 플랫폼을 제공합니다. 자동 스케일링을 사용할 수 있습니다. 개발 환경에서는 기본 B1 SKU를 사용합니다.
Azure App Service 컨테이너에서 API 코드를 실행하는 애플리케이션 플랫폼을 제공합니다. App Service 인증 기능은 권한 부여에 사용할 수 있습니다.
배포 슬롯: 배포를 스테이징한 다음, 프로덕션 배포로 교환할 수 있습니다. 프로덕션에서만 사용됩니다.
Azure Container Registry 컨테이너화된 API 코드를 저장한 뒤 워크로드 팀에서 만들고 관리하는 CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인을 통해 푸시됩니다. 프로덕션 환경과 개발/테스트 환경 모두 컨테이너 레지스트리를 사용합니다.
SQL API를 사용하는 Azure Cosmos DB는 워크로드와 관련된 모든 상태를 저장합니다. Cosmos DB 데이터베이스 계정에는 공유 처리량 모델의 몇 가지 컨테이너가 포함된 단일 데이터베이스가 있습니다. Azure Cosmos 계정은 서버리스 용량 모드를 사용합니다. 프로덕션용 인스턴스 하나와 개발/테스트용 인스턴스가 하나 있습니다.
Azure Key Vault는 API가 하나의 요청 흐름의 일부로 외부 타사 API에 HTTP POST를 호출하는 데 필요한 비밀을 저장합니다. 애플리케이션은 Azure App Service 앱 구성의 Key Vault 참조를 통해 비밀에 액세스합니다. 프로덕션에 대한 Key Vault 하나와 개발/테스트용으로 하나가 있습니다.
Azure Log Analytics는 솔루션에 사용되는 모든 구성 요소에 대한 모든 Azure Diagnostics 설정의 로그 및 메트릭을 저장하는 통합 싱크로 사용됩니다. 프로덕션용 작업 영역 하나와 개발/테스트용 작업 영역이 하나 있습니다.
Azure Application Insights는 API에서 원격 분석 및 로그를 캡처하는 데 사용됩니다. Application Insights는 전용 로그 분석 작업 영역에 쓰는 것이 아니라 자체 포함 모드를 사용합니다. 프로덕션 및 개발/테스트는 공통 인스턴스를 공유하지 않습니다.
Azure Pipelines는 사전 프로덕션 및 프로덕션 환경에서 워크로드를 빌드, 테스트 및 배포하는 CI/CD에 사용됩니다. 워크로드 팀은 파이프라인을 관리하며 솔루션의 모든 인프라도 관리합니다. Bicep은 IaC(Infrastructure-as-Code)에 대한 기술 선택입니다.
설계 선택
구성 요소 목록에서 배포 스탬프는 요청 처리에 참여하는 서비스로 구성됩니다. 이러한 서비스에는 App Services와 API 코드 및 Cosmos DB가 포함됩니다. 스탬프에는 비기능 구성 요소도 포함됩니다. Key Vault 및 Container Registry. 애플리케이션에는 성능 및 복원력 프레임워크에 대한 타사 종속성이 있습니다. 시스템 관리 ID는 스탬프의 구성 요소 간에 사용됩니다.
스탬프에서 App Services는 부하에 따라 자동으로 스케일링되도록 구성됩니다.
별도의 환경은 프로덕션 및 개발/테스트에 사용됩니다. 프로덕션 환경에서는 App Service 요금제의 표준 SKU를 사용합니다. 이 회사는 프로덕션에 배포하기 전에 애플리케이션을 슬롯에 미리 준비할 수 있도록 이 선택을 했습니다. 개발/테스트 환경은 비용 최적화를 위해 기본 SKU를 사용합니다. 두 환경에는 고유한 서비스 인스턴스가 있습니다. 환경은 Container Registry만 공유합니다.
컨테이너화된 API 코드는 App Service에서 실행되는 단일 컨테이너 이미지로 제공됩니다. API에는 읽기 및 쓰기 모두에 대해 다양한 프런트 엔드에서 사용되는 여러 HTTP 엔드포인트가 있습니다. 프런트 엔드는 이 모듈의 범위를 벗어났지만 이 상황의 중요 업무용 상태에 대한 큰 그림의 범위에 있습니다. 이 코드는 몇 가지 기본 원격 분석을 캡처하기 위해 Application Insights를 사용하여 계측되었습니다. 이 코드를 개발한 팀은 API 컨테이너 이미지 및 CI/CD 파이프라인에 대한 CI/CD 파이프라인도 관리합니다.
균형 유지
그러나 모든 것과 마찬가지로 현재 아키텍처에 비해 장단점이 있습니다. 비즈니스 요구 사항은 안정성 및 운영보다 비용 최적화를 우선 순위로 지정했습니다. 비용 한도 내에서 유지하기 위해 아키텍처는 진화하지 않았습니다. 플랫폼에서 제공하는 안정성 기능을 활용할 때 구성 요소가 부족합니다. 예를 들어 컴퓨팅용 SKU를 선택하면 워크로드가 가용성 영역을 사용할 수 없게 됩니다. 원격 분석의 경우 Log Analytics와 통합되지 않은 이전 버전의 Application Insights가 사용됩니다.
또한 워크로드에 대한 액세스가 지나치게 널리 퍼져 있습니다. 예를 들어 가상 네트워크 통합이 없으면 모든 Azure 서비스에 퍼블릭 인터넷을 통해 직접 연결할 수 있습니다.
솔루션이 개발되었을 때 앱 개발 팀은 단일 Azure 구독을 사용하여 DevOps 팀이 도구를 쉽게 사용할 수 있도록 동일한 구독에 개발/테스트 및 프로덕션을 공동 배치했습니다. 그러나 프로덕션 리소스와 개발/테스트 리소스는 완전히 격리되지 않습니다. 일부 리소스는 Contoso Shoes의 나머지 솔루션에서 격리된 구독을 얻었지만 두 환경 간에 공유됩니다.
또한 개발/테스트 환경은 개발 및 QA 팀의 모든 구성원 간에 공유되는 단일 환경입니다. 팀의 규모와 팀 간의 조정에 더 높은 수준의 격리가 필요하지 않다는 점을 감안하여 선택은 정당화되었습니다. 팀과 솔루션이 발전함에 따라 단일 개발/테스트 환경은 워크스트림 수명 주기가 충돌함에 따라 통합 복잡성을 점점 더 많이 발생시켰습니다. 변동과 안정성에 미치는 영향은 비용이 많이 들었습니다.
프로젝트 사양
회사는 예상되는 부하 증가를 처리할 수 있도록 솔루션 아키텍처에 기능을 추가하려고 합니다. 비즈니스 요구 사항은 다음과 같습니다.
- 아키텍처를 여러 지역으로 확장하여 지역 오류를 견딜 수 있는 기능 빌드
- 지리적으로 가까운 지역에서 클라이언트에게 더 빠르게 서비스를 제공하여 고객 경험 개선
- Azure 로드맵에 맞게 조정하고 Azure 서비스에서 제공하는 최신 안정성 기능 활용합니다.
- 전반적인 상태 모델을 빌드하여 문제를 조기에 파악하고 시스템에서 파급성 감지
이러한 요구 사항은 개선 계획의 우선 순위 목록일 뿐입니다. 애플리케이션 팀은 이 솔루션의 안정성을 중요 업무용 표준으로 끌어올리려면 모든 디자인 영역을 고려해야 한다는 것을 알고 있습니다. 향후 연습에서 다루는 측면을 지원하고 나면 이 팀은 솔루션 및 운영 개선을 멈추지 않을 것입니다.
팀에 오신 것을 환영합니다. Contoso Shoes는 여러분의 추천을 기대하고 있습니다.
설정
이 챌린지 프로젝트에서 여러분은 이전 섹션의 우선 순위가 지정된 항목부터 시작하여 Contoso Shoes가 안정성 결과를 달성하는 데 도움을 주는 설계자의 역할을 맡게 됩니다.
- 아키텍처 다이어그램 도구를 사용하여 아키텍처를 시각화하는 것이 좋습니다.
- 서비스 및 해당 기능에 익숙한 경우 이 문제에 대한 Azure 구독이 필요하지 않습니다.