클라우드 네이티브 솔루션은 새 워크로드(애플리케이션)를 빌드하거나 기존 워크로드에 새 기능을 추가하여 새로운 비즈니스 가치를 만듭니다. 새로운 애플리케이션을 개발하든 기존 시스템에 새로운 기능을 추가하든 클라우드 네이티브 개발은 워크로드 계획, 빌드, 배포 및 최적화를 통해 진행됩니다. 이 프레임워크는 클라우드 네이티브 애플리케이션이 비즈니스 목표에 부합하고, 잘 설계되었으며, 최소한의 위험으로 제공되도록 하기 위한 엔드 투 엔드 지침을 제공합니다.
필수 조건:Azure 랜딩 존
클라우드 네이티브 솔루션에 대한 비즈니스 목표 정의
명확한 비즈니스 목표부터 시작합니다. 새 디지털 제품 사용, 새 시장 진출, 고객 환경 개선 또는 운영 비용 절감 등 클라우드 네이티브 솔루션이 달성해야 하는 특정 결과를 정의합니다. 수익 증가, 시장 출시 시간 감소 또는 지원 티켓 볼륨과 같은 측정 가능한 지표를 사용하여 성공을 정량화합니다. 새로운 기능의 경우 고객 환경 개선, 운영 비용 절감 또는 시스템 확장성 증가와 같은 목표를 정의합니다.
제약 조건 및 성공 조건을 식별합니다. 예산, 규정 준수 또는 배달 타임라인과 같은 비즈니스 제약 조건을 문서화합니다. 각 목표에 대한 성공의 모양을 정의합니다. 예를 들어 "4분기까지 새 고객 포털을 시작" 또는 "체크 아웃 대기 시간을 40%줄입니다." 이러한 기준은 우선 순위를 안내하고 계획 중에 장단을 평가하는 데 도움이 됩니다.
관련자 정렬을 확인합니다. 모든 이해 관계자(비즈니스 및 기술)가 목표, 제약 조건 및 성공에 동의하는지 확인합니다. 이 맞춤에는 워크샵 또는 공식 사인오프가 포함될 수 있습니다. 조기 맞춤은 나중에 잘못된 의사 소통을 방지하고 비용이 많이 드는 재작업을 방지하여 모든 사람이 처음부터 동일한 기대를 공유하도록 합니다.
클라우드 네이티브 솔루션에 대한 요구 사항 정의
기능 요구 사항을 문서화합니다. 사용자 요구를 충족하기 위해 시스템에서 제공해야 하는 기능과 기능을 문서화합니다. 각 요구 사항은 비즈니스 목표에 다시 연결하여 개발 노력이 원하는 결과를 직접 지원하도록 해야 합니다. 관련자 인터뷰 및 비즈니스 전략 문서를 사용하여 고부가가치 결과를 식별합니다. 비즈니스 가치 및 기술 타당성에 따라 기능의 우선 순위를 지정합니다. 각 요구 사항을 측정 가능한 비즈니스 목표에 따라 추적하여 포함을 정당화합니다.
비기능적 요구 사항을 설정합니다. 비기능적 요구 사항은 기능 요구 사항 및 거버넌스를 충족하기 위한 기술 요구 사항을 정의합니다. 이러한 기능을 지원하는 데 필요한 품질 특성 및 기술 목표를 설정합니다. 가동 시간, RPO(복구 지점 목표) 및 RTO(복구 시간 목표)에 대한 SLO(서비스 수준 목표)와 같은 대상 안정성 메트릭 을 정의합니다. 보안 기준을 설정합니다. 비용 모델을 만듭니다. 성능 목표를 설정합니다.
클라우드 네이티브 솔루션의 범위를 제어합니다. 초기 릴리스의 범위 내 및 범위를 벗어난 항목을 명확하게 정의합니다. 더 많은 "좋은" 기능을 포함하려는 유혹이 있지만 범위 크리프는 타임라인과 예산을 위태롭게 할 수 있습니다. 솔루션의 경계를 문서화하고 새 요청에 대한 변경 제어 프로세스를 구현합니다. 정의된 목표를 직접 지원하고 일정이나 예산을 훼손하지 않고 제공할 수 있는 변경 내용만 승인합니다. 우선순위가 낮은 아이디어를 향후 백로그에 추가합니다. 엄격하게 범위를 관리하면 팀은 제약 조건 내에서 가장 중요한 기능을 먼저 제공하는 데 집중할 수 있습니다.
클라우드 네이티브 아키텍처 계획
잘 계획된 아키텍처는 목표와 요구 사항을 충족하는 데 중요합니다. 모든 주요 아키텍처 결정에는 확장성, 복잡성, 비용 및 민첩성의 장단분이 포함됩니다. 다음 단계와 의사 결정 사항은 모범 사례에 맞게 클라우드 네이티브 디자인을 만드는 데 도움이 됩니다.
유효성이 검사된 클라우드 네이티브 아키텍처 살펴보기
아키텍처 기본 사항 및 모범 사례를 검토합니다. 아키텍처를 처음부터 새로 만들기 전에 Azure 아키텍처 센터에서 유효성이 검사된 참조 아키텍처 및 기본 사항을 검토합니다. 친숙한 아키텍처 스타일에는 일반적인 워크로드에 대한 유효성이 검사된 참조 아키텍처를 탐색하는 것이 포함됩니다. 이러한 아키텍처는 설계 결정을 가속화하고 위험을 줄이는 데 도움이 됩니다.
적절한 아키텍처 스타일을 선택합니다. 워크로드의 특성 및 팀 기능에 따라 아키텍처 스타일을 선택합니다. 아키텍처 스타일에는 N 계층(모놀리식), 마이크로 서비스, 이벤트 기반(메시지 기반), 웹 큐 작업자가 포함됩니다. 예를 들어 비교적 간단한 애플리케이션에 대해 신속한 개발이 필요한 경우 잘 구성된 N 계층 모놀리스로 충분할 수 있습니다. 고유한 도메인을 사용하는 대규모 또는 빠르게 진화하는 애플리케이션의 경우 마이크로 서비스 또는 이벤트 기반 접근 방식은 복잡성을 희생하면서 유연성을 제공합니다. 실제로 많은 시스템은 하이브리드 스타일로 끝납니다. 예를 들어 일부 공유 서비스 또는 이벤트 기반 하위 시스템이 있는 마이크로 서비스 코어가 있습니다. 핵심은 각 스타일의 장차를 이해하고 확장성, 복원력 및 민첩성 요구 사항을 가장 잘 충족하는 방법을 선택하는 것입니다.
디자인 모범 사례를 적용합니다. 어떤 스타일을 선택하든 클라우드 아키텍처 기본 사항 및 모범 사례를 준수합니다. Azure 아키텍처 센터는 분산 워크로드의 일반적인 문제를 해결하는 클라우드 디자인 패턴 카탈로그(재시도, 회로 차단기, CQRS)를 제공합니다. 이러한 패턴을 디자인에 통합하면 안정성과 성능이 향상될 수 있습니다.
5가지 핵심 요소를 디자인 결정에 통합합니다. Well-Architected Framework를 사용하여 안정성, 보안, 성능 효율성, 비용 최적화 및 운영 우수성에 대한 의사 결정을 안내합니다. 이 다섯 가지 핵심 요소는 모든 디자인 결정을 알려야 합니다. 예를 들어 데이터베이스를 선택할 때 안정성(중복성, 백업), 성능 및 비용을 함께 고려하여 적절한 균형을 맞추십시오. 성능 향상을 위한 더 많은 비용과 같이 핵심 요소 간의 장차를 만드는 위치를 문서화합니다. 이러한 참고 사항은 향후 거버넌스 및 검토에 중요합니다.
기존 시스템과의 통합 계획
모든 종속 시스템 및 서비스를 인벤토리로 작성합니다. 초기 단계의 스타트업이 아닌 경우, 새로운 클라우드 네이티브 솔루션은 격리된 상태로 거의 작동하지 않습니다. 새 워크로드 또는 기능이 환경에 어떻게 적합한지 고려합니다. 데이터 흐름을 매핑하고 표준과의 호환성을 보장합니다. 워크로드가 상호 작용하는 모든 시스템의 포괄적인 목록을 만듭니다. 이 목록에는 내부 API, 데이터베이스, ID 공급자(Microsoft Entra ID), 모니터링 도구, CI/CD 파이프라인 및 VPN 또는 ExpressRoute를 통해 액세스되는 온-프레미스 시스템이 포함됩니다. 아키텍처 다이어그램 및 종속성 맵을 사용하여 이러한 관계를 시각화합니다.
통합 유형 및 프로토콜을 분류합니다. 각 통합 지점을 유형(인증, 데이터 교환, 메시징) 및 프로토콜(REST, gRPC, ODBC, SAML, OAuth2)으로 분류합니다. 이 분류는 호환성 요구 사항 및 잠재적인 병목 상태를 식별하는 데 도움이 됩니다.
ID의 유효성을 검사하고 통합에 액세스합니다. 솔루션이 조직의 ID 공급자와 통합되는지 확인합니다. 예를 들어 새 ID 시스템을 도입하는 대신 인증 및 권한 부여에 Microsoft Entra ID를 사용합니다. SSO(Single Sign-On), RBAC(역할 기반 액세스 제어) 및 조건부 액세스 정책에 대한 지원을 확인합니다.
네트워크 연결 및 보안을 평가합니다. 워크로드가 다른 시스템에 연결하는 방법을 검토합니다. 방화벽 규칙, DNS 확인 및 라우팅 경로의 유효성을 검사합니다. 하이브리드 시나리오의 경우 ExpressRoute 또는 VPN 구성이 준비되고 테스트되는지 확인합니다. Azure Network Watcher를 사용하여 연결을 모니터링하고 문제를 해결합니다.
데이터 흐름 호환성 및 규정 준수를 보장합니다. 시스템 간의 데이터 흐름을 매핑합니다. 데이터 형식, 스키마 및 변환 요구 사항을 확인합니다. 데이터 상주, 암호화 및 보존 정책을 준수합니다.
통합 지점을 조기에 지속적으로 테스트합니다. 초기 개발 단계에서 통합 테스트를 수행합니다. 사용할 수 없는 시스템에는 모의 객체 또는 스텁을 사용하십시오. Azure DevOps 또는 GitHub Actions와 같은 도구를 사용하여 CI/CD 파이프라인에서 이러한 테스트를 자동화합니다. 대기 시간, 처리량 및 오류 비율을 모니터링합니다. 예를 들어, 앱이 의존하는 API가 필요한 부하를 지원하지 않는 상황이나 네트워크 방화벽이 서비스를 차단하는 상황을 피하고자 합니다.
통합 계약 및 SLA를 문서화합니다. 각 통합 지점의 예상 동작, 가용성 및 성능을 정의하고 문서화합니다. 재시도 논리, 시간 제한 설정 및 대체 메커니즘을 포함합니다. 종속 시스템의 SLA(서비스 수준 계약)에 맞춥니다.
적절한 Azure 서비스 및 서비스 계층 선택
의사 결정 가이드를 사용하여 워크로드 요구 사항과 일치하는 서비스를 선택합니다. Azure는 각각 장단점이 있는 애플리케이션 코드를 실행하는 여러 옵션을 제공합니다. 기술 선택 개요를 검토하여 기능 및 비기능적 요구 사항에 맞는 서비스를 식별합니다. 이러한 서비스는 인프라 관리, 패치 및 크기 조정을 자동으로 처리하여 운영 오버헤드를 줄이기 때문에 PaaS(Platform-as-a-Service) 옵션의 우선 순위를 지정합니다.
서비스 계층을 선택하기 위한 사용 패턴 및 성능 요구 사항을 정의합니다. 서비스 계층 선택은 비용과 기능 모두에 영향을 줍니다. 예상 트랜잭션 볼륨, 동시 사용자 로드, 스토리지 요구 사항 및 응답 시간 및 처리량과 같은 성능 목표를 문서화합니다. 이러한 메트릭을 사용하여 상당한 오버 프로비저닝 없이 기준 요구 사항을 충족하는 초기 SKU(서비스 계층)를 선택합니다. 배포 후 실제 사용 패턴에 따라 계층을 조정하도록 계획합니다.
선택한 서비스 계층에서 기능 호환성의 유효성을 검사합니다. 고급 보안 기능, 고가용성 옵션 또는 통합 API와 같은 중요한 기능은 서비스 계층에 따라 다릅니다. 필요한 기능을 사용 가능한 SKU에 매핑하는 기능 매트릭스를 만듭니다. 선택한 계층이 나중에 비용이 많이 드는 마이그레이션 또는 아키텍처 변경을 방지하기 위해 필요한 모든 기능을 지원하는지 확인합니다. 서비스별 설명서를 참조하여 기능 가용성 및 제한 사항을 확인합니다.
사용할 지역 수 선택
다중 지역 배포의 장차를 평가합니다. 단일 지역 아키텍처는 더 간단하고 저렴하지만 지역 가동 중단으로 앱이 중단됩니다. 다중 지역 배포는 더 높은 가용성을 달성할 수 있으며(한 지역이 실패하고 사용자가 다른 지역에서 제공됨) 가장 가까운 지역의 사용자에게 서비스를 제공하여 성능을 향상시킬 수도 있습니다. 배포 및 데이터 동기화의 복잡성이 증가합니다. 잠재적 일관성 문제, 글로벌 트래픽 라우팅 및 더 높은 비용으로 지역 간 데이터 복제를 처리해야 합니다. 신뢰성 요구 사항에 따라 이 결정을 내리십시오.
안정성 목표를 사용하여 지역 전략을 안내합니다. SLO(서비스 수준 목표), RPO(복구 지점 목표) 및 RTO(복구 시간 목표)를 정의하여 지역 요구 사항을 결정합니다.
데이터 보존 규정 준수를 확인합니다. 법률 및 규정 준수 팀과 협력하여 지역 선택이 규정 의무를 충족하는지 확인합니다.
문서 아키텍처
자세한 아키텍처 다이어그램 및 디자인 문서를 만듭니다. 설명서는 구현, 검토 및 향후 유지 관리를 지원합니다. 선택한 Azure 서비스, SKU, 데이터 흐름 및 사용자 상호 작용을 포함합니다. 다이어그램이 구현 및 검토를 지원하기 위해 아키텍처의 명확한 시각적 표현을 제공하는지 확인합니다.
주요 디자인 결정 및 절충을 기록합니다. 안정성, 보안 및 성능과 같은 비기능 요구 사항을 포함하여 아키텍처 선택에 대한 근거를 문서화합니다. 경쟁 우선 순위의 균형을 맞추기 위해 이루어진 타협사항을 강조합니다.
클라우드 네이티브 배포 전략 계획
클라우드 네이티브 솔루션을 프로덕션에 배포하는 경우 임시 푸시가 아닌 계획된 전략을 따릅니다. 견고한 배포 계획은 사용자에게 미치는 영향을 최소화하고 문제가 발생할 경우 복구하는 방법을 제공합니다.
개발 및 배포 방안 계획
개발 및 배포 사례는 환경 전체에서 일관된 전달 및 운영 준비를 보장합니다. 이러한 사례는 배포 위험을 줄이고 팀 조정을 개선합니다.
배포 자동화를 위한 DevOps 사례를 설정합니다. DevOps 사례는 자동화, 버전 제어 및 CI/CD 파이프라인을 통해 개발 및 운영 팀을 조정합니다. Azure DevOps 또는 GitHub Actions와 같은 도구를 사용하여 빌드, 테스트 및 배포 워크플로를 자동화합니다. 이 방법은 수동 오류를 줄이고, 릴리스 주기를 가속화하며, 환경 전반에 걸쳐 일관된 배포 프로세스를 제공합니다.
배포 활동을 지원하기 위한 운영 준비 상태를 계획합니다. 운영 준비에는 배포 시나리오에 대한 모니터링, 경고 및 인시던트 대응 절차가 포함됩니다. 롤백 절차, 상태 검사 및 문제 해결 단계를 다루는 배포 Runbook 및 자동화 스크립트를 문서화합니다. 배포 작업 중에 접근성을 보장하기 위해 이러한 리소스를 Azure DevOps Wiki 또는 GitHub와 같은 중앙 위치에 저장합니다.
신뢰할 수 있는 배포 를 지원하는 개발 사례를 정의합니다. 코딩 표준, 피어 검토 및 자동화된 테스트를 사용하여 코드 품질 및 배포 준비 상태를 보장합니다. 이러한 사례를 CI/CD 파이프라인에 통합하여 배포 전에 품질 게이트를 적용합니다. 통합 테스트, 스모크 테스트 및 성능 유효성 검사와 같은 배포별 테스트를 포함하여 프로덕션에 대한 시스템 준비 상태를 확인합니다.
새 워크로드에 대한 배포 계획
점진적 노출을 사용하여 영향을 제한합니다. 기존 사용자가 없는 새 애플리케이션(greenfield)의 경우 소프트 시작을 수행해야 합니다. 프로덕션 환경에 배포하지만 처음에는 내부 사용자 또는 파일럿 그룹에만 노출합니다. 이 접근 방식은 새로운 워크로드를 위한 카나리아 배포 전략입니다. 완전히 새롭고 격리된 경우 전체 프로덕션에 한 번만 배포하는 것이 가능하지만, 문제가 발생하지 않도록 제어된 방식으로 점진적으로 노출하는 것이 권장됩니다. 실제 환경에서의 유효성 검사를 먼저 수행하지 않고 첫날부터 시스템을 100% 사용자에게 배포하지 마세요. 자세한 내용은 WAF - 점진적 노출 모델 채택을 참조하세요.
작업 절차 및 에스컬레이션 경로를 문서화합니다. 서비스 다시 시작, 로그 액세스, 일반적인 문제 처리 및 인시던트 에스컬레이션에 대한 명확한 설명서를 만듭니다. 이 설명서를 SharePoint 또는 GitHub와 같은 공유 리포지토리에 저장하여 지원 팀의 가용성을 보장합니다.
새 기능에 대한 배포 계획
변경 관리를 사용하여 새 기능 통합을 계획합니다. 조직의 변경 관리 프로세스에 따라 프로덕션 변경 내용을 제어하고 문서화합니다. 애플리케이션 버전 되돌리기 또는 데이터베이스 백업 복원과 같은 롤백 절차를 정의합니다. 배포 전에 관련자 승인을 보호하여 비즈니스 목표와 일치하도록 합니다. 자세한 내용은 CAF의 변경 관리를 참조하세요.
사소하거나 이전 버전과 호환되는 변경에 대한 현재 위치 업데이트를 사용합니다. 롤링 업데이트 또는 기능 플래그를 사용하여 프로덕션 환경에 직접 업데이트를 배포합니다. 소수의 사용자 또는 인스턴스로 시작합니다. 전체 출시 전에 시스템 메트릭 및 로그를 모니터링하여 안정성의 유효성을 검사합니다.
주요 또는 위험 수준이 높은 변경에 병렬(파란색-녹색) 배포를 사용합니다. 별도의 환경에서 새 버전을 배포합니다. 라이브 트래픽의 작은 부분을 새 버전으로 라우팅하여 동작의 유효성을 검사합니다. 성공하면 모든 트래픽을 새 버전으로 이동합니다. 문제가 발생하면 트래픽을 원래 버전으로 되돌려 연속성을 보장합니다.
새 워크로드에 대한 운영 인계를 계획합니다. 배포 후 솔루션 운영 및 지원을 담당하는 팀을 식별합니다. 지원 모델(24/7 전화 또는 업무 시간 지원)을 정의하고 모든 이해 관계자가 자신의 역할을 이해하도록 합니다.
소유권 및 지원 책임을 정의합니다. 운영 팀이 새 기능을 지원할 준비가 되어 있는지 확인합니다. 설명서 및 에스컬레이션 경로를 업데이트하여 새로운 책임을 반영하고 신속한 인시던트 대응을 보장합니다.
클라우드 네이티브 솔루션에 대한 롤백 계획 정의
롤백 계획을 사용하면 배포가 실패하거나 위험이 발생할 때 팀이 변경 내용을 신속하게 되돌릴 수 있습니다. 잘 정의된 계획은 가동 중지 시간을 최소화하고, 비즈니스 영향을 제한하며, 시스템 안정성을 유지합니다. 마이그레이션 또는 배포를 시작하기 전에 항상 롤백 조건 및 절차를 설정합니다.
실패한 배포를 정의합니다. 비즈니스 관련자, 워크로드 소유자 및 운영 팀과 협력하여 실패한 배포로 간주되는 사항을 결정합니다. 예를 들어 실패한 상태 검사, 성능 저하, 보안 문제 또는 충족되지 않은 성공 메트릭이 있습니다. 이 정의는 롤백 결정이 조직의 위험 허용 오차와 일치하도록 보장합니다. CPU 사용량 제한, 응답 시간 임계값 또는 오류 속도와 같은 배포 계획에서 롤백을 트리거하는 특정 조건을 포함합니다. 이 평가는 인시던트 중에 롤백 결정을 명확하고 일관되게 만듭니다.
CI/CD 파이프라인에서 롤백 단계를 자동화합니다. Azure Pipelines 또는 GitHub Actions와 같은 도구를 사용하여 롤백 프로세스를 자동화합니다. 예를 들어 상태 검사가 실패하는 경우 이전 버전을 다시 배포하도록 파이프라인을 구성합니다.
워크로드별 롤백 지침을 만듭니다. 워크로드 유형, 환경 및 배포 방법과 일치하는 롤백 단계를 개발합니다. 예를 들어 코드 기반 인프라 배포에는 이전 템플릿을 다시 적용해야 합니다. 애플리케이션 롤백에는 이전 컨테이너 이미지를 다시 배포하는 작업이 포함됩니다. 롤백 스크립트, 구성 스냅샷 및 코드로서의 인프라 템플릿을 롤백 계획에 연결합니다. 이러한 자산은 신속한 실행을 가능하게 하고 수동 개입에 대한 의존도를 줄입니다.
테스트 롤백 절차. 사전 프로덕션 환경에서 배포 실패를 시뮬레이션하여 롤백 효율성의 유효성을 검사합니다. 자동화, 권한 또는 종속성에서의 격차를 식별하고 해결합니다. 롤백이 시스템을 안정적이고 정상 상태로 복원하는지 확인합니다.
롤백 전략 개선 각 배포 또는 롤백 이벤트 후에는 회고전을 수행하여 무엇이 작동하고 무엇이 작동하지 않았는지 평가합니다. 학습된 교훈, 아키텍처 변경 또는 새 도구에 따라 롤백 조건, 프로시저 및 자동화를 업데이트합니다. 롤백 전략이 최신 상태이고 효과적으로 유지되도록 설명서를 유지합니다.