Azure Well-Architected Framework 워크로드

Azure Well-Architected Framework의 컨텍스트에서 워크로드 라는 용어는 정의된 비즈니스 결과를 달성하기 위해 함께 작동하는 애플리케이션 리소스, 데이터 및 지원 인프라의 컬렉션을 나타냅니다. 워크로드는 구성 요소와 개발 및 운영 절차로 구성됩니다.

설계자는 워크로드를 설계하고 워크로드 팀은 워크로드를 구현합니다. 워크로드는 기능 및 비기능 비즈니스 요구 사항을 달성하기 위해 설계되고 구현됩니다. 워크로드는 여러 유형으로 분류할 수 있습니다.

워크로드 분류의 일반적인 기준은 다음과 같습니다.

• 웹 애플리케이션, 일괄 처리 및 실시간 분석과 같은 워크로드의 유틸리티, 특성 및 사용 패턴.

• 기술 플랫폼 또는 업계와의 연계와 같은 주요 영향력 있는 동인입니다.

• 의도된 대상 그룹입니다. 다양한 대상 그룹이 있는 솔루션의 예로는 기업 내의 내부 기간 업무 애플리케이션, 구매한 ISV(독립 소프트웨어 공급업체) 솔루션 또는 공용 사용을 위한 다중 테넌트 SaaS(Software as a Service) 솔루션이 있습니다.

동일한 클래스에 있는 워크로드는 대상 그룹, 규정 준수 요구 사항 및 기술 스택을 포함하여 유사성을 공유할 수 있습니다. Well-Architected Framework의 5가지 핵심 요소인 원칙, 검사 목록 및 장단점은 모든 워크로드 클래스와 관련이 있습니다.

Well-Architected Framework의 워크로드 지침은 특정 워크로드 클래스와 관련된 일반적인 우선 순위 및 장단점을 설명합니다. 워크로드 지침에서 핵심 지침은 워크로드의 우선 순위를 나타내는 기술 디자인 원칙 및 디자인 영역에 적용됩니다. 권장 사항에 따라 성공적인 워크로드를 설정하고 Well-Architected Framework에 맞게 조정합니다.

Well-Architected Framework 워크로드란?

모든 워크로드의 설계 및 운영은 안정성, 보안, 비용 최적화, 운영 우수성 및 성능 효율성의 다섯 가지 아키텍처 핵심 요소와 싸워야 합니다.

성공적인 워크로드를 만들려면 다음과 같은 이상을 기반으로 하는 Well-Architected Framework 원칙에 따라 워크로드를 개발합니다.

Well-Architected Framework 워크로드:

• 목표를 달성하기 위해 정의되고 우선 순위가 지정된 기능 및 비기능 요구 사항이 있습니다.
• 리소스를 사용하고 디자인 패턴과 절충을 통합하여 이러한 요구 사항을 달성할 수 있도록 설계되었습니다.
• 디자인 및 용도의 사양에 맞게 빌드되고 작동됩니다.
• 목적을 얼마나 적절하게 달성했는지에 따라 측정됩니다.
• 용도가 구체화되거나 변경될 때 적응할 수 있습니다.
• 필요한 만큼 안정적입니다.
• 필요한 만큼 안전합니다.
• 충분한 투자 수익을 제공합니다.
• 책임감 있게 개발 및 작동됩니다.
• 허용 가능한 기간 내에 목적을 달성합니다.

워크로드 팀과 organization 중앙 팀 간의 협업은 이전 특성을 가진 워크로드를 만들어야 합니다. 다음 섹션에서는 이러한 팀과 해당 기능에 대해 설명합니다.

워크로드 팀

다양한 기술 및 비즈니스 분야의 팀 구성원이 있는 워크로드 팀을 만듭니다. 모든 팀 구성원의 주요 초점은 워크로드의 성공이어야 합니다.

워크로드 팀 구성원의 예
애플리케이션 보안 엔지니어 비즈니스 관련자 클라우드 개발자 또는 소프트웨어 엔지니어 클라우드 솔루션 설계자 데이터 과학자 또는 분석가 데이터베이스 관리자	DevOps 엔지니어 인프라 엔지니어 제품 관리자 또는 소유자 QA(품질 보증) 엔지니어 지원 팀 구성원

중앙 집중식 팀 및 관련자

중앙 집중식 팀은 종종 워크로드 팀을 지원합니다. 지원 기능을 제공하고 organization 내의 많은 또는 모든 클라우드 워크로드에 대한 거버넌스를 적용합니다. 중앙 집중식 팀은 조직의 성공에 초점을 맞추고 있으며, 이는 organization 워크로드의 성공에 의해 부분적으로 달성됩니다. 워크로드에 대한 서비스, 지침 및 가드 레일을 제공합니다.

중앙 집중식 팀 및 팀 구성원의 예
비즈니스 인텔리전스 분석가 비즈니스 관련자 CCoE(클라우드 우수 센터) 보드 클라우드 플랫폼 팀 사이버 보안 분석가 데이터베이스 관리자 엔터프라이즈 설계자	재무 분석가 인프라 엔지니어 법률 및 규정 준수 책임자 네트워크 엔지니어 조달 전문가 프로젝트 관리자

Well-Architected Framework 워크로드 팀은 워크로드 결과에 중점을 둡니다. 중앙 집중식 팀 구성원의 특수 지원을 통해 조정하고 혜택을 누릴 수 있습니다.

공동 책임 모델

가치를 제공하기 위해 워크로드를 배포하고 사용해야 합니다. 워크로드 팀의 일원으로서 organization 가치를 창출하는 방식으로 워크로드를 디자인, 구현 및 배포할 책임이 있습니다.

워크로드는 organization 컨텍스트 내에 있습니다. organization 종종 관리 및 권한 역할을 규제합니다. 워크로드 팀은 organization 기반 내에서 워크로드를 설계, 구현 및 배포할 책임이 있습니다.

Azure용 클라우드 채택 프레임워크 따라 워크로드의 클라우드 리소스를 표준화합니다. 표준화를 엄격하게 적용하여 워크로드 팀을 온보딩하는 데 도움이 되는 관리형 플랫폼을 제공합니다. organization 클라우드 운영 모델에 따라 이 거버넌스를 적용합니다.

Azure 랜딩 존을 사용하여 표준화를 수행할 수 있습니다. 플랫폼 랜딩 존 및 애플리케이션 랜딩 존은 Azure에서 사용할 수 있습니다. 애플리케이션 랜딩 존에 워크로드를 배포합니다.

organization 엄격하게 공식화되고 Azure 랜딩 존과 완벽하게 일치하는 클라우드 플랫폼 제품이 있을 수 있습니다. 또는 organization 채택 전략이 다르거나 구현이 없을 수 있습니다. 구현이 없는 경우 워크로드 팀은 거의 완전히 자율적인 엔터티입니다.

organization 사용하는 모든 플랫폼 및 거버넌스의 경우 워크로드에 Well-Architected Framework의 원칙을 적용해야 합니다. Well-Architected Framework는 Azure 랜딩 존을 참조하는 경우가 많지만 특정 플랫폼 구현에 종속되지는 않습니다. Well-Architected 프레임워크 핵심 요소, 원칙, 검사 목록 및 가이드는 모든 클라우드 플랫폼 및 대부분의 워크로드 유형에 대한 것입니다.

요구 사항 충족

핵심 핵심 요소 및 워크로드 지침과 같은 Well-Architected 프레임워크 전체에서 권장 사항은 워크로드의 의무와 일치합니다. 권장 사항은 일반적으로 팀 구성원 또는 팀이 이러한 의무를 용이하게 하는 것을 의미하지는 않습니다. 각 작업을 수행해야 하는 사용자를 결정할 수 있습니다. 워크로드 수준 매핑을 수행하여 토폴로지, 워크로드 유형 및 중요도와 관련된 팀의 역할 및 책임을 결정합니다.

직접 워크로드 팀은 대부분의 워크로드 요구 사항을 처리합니다. 일부 요구 사항은 중앙 집중식 팀과 공동 작업으로 처리됩니다. 예를 들어 구현 선택은 중앙 집중식 팀이 설정하는 가드 레일을 기반으로 할 수 있습니다. 또는 중앙 집중식 팀이 구현 선택 사항을 독점적으로 처리할 수 있습니다.

워크로드 팀은 워크로드 목표를 코드 조각화할 수 있도록 다른 팀과 작업 관계를 구축해야 합니다. 구성 요소 또는 책임을 아웃소싱하는 경우 해당 의무를 성공적으로 이행해야 합니다.

제약 조건 알아보기

중앙 집중식 팀은 팀의 핵심 기능 및 핵심 인프라를 기반으로 다양한 워크로드를 지원합니다. 조직 규모에서 이러한 지원을 제공하기 위해 중앙 집중식 팀은 제공된 서비스 또는 인프라에 대한 균일성 및 제약 조건을 구현할 수 있습니다. 워크로드를 설계할 때 이러한 제약 조건을 이해하고 가능한 경우 이러한 제약 조건을 알고 있는 엔터프라이즈 설계자와 협력하는 것이 중요합니다. 가능한 한 이전 구현에서 알아봅니다.

모든 플랫폼 거버넌스 구현은 다르지만 다음과 같은 제약 조건은 많은 워크로드에서 일반적입니다.

• 클라우드 리소스에 대한 허용 목록
• 클라우드 리소스에 대한 구성 의무
• 클라우드 리소스 및 프레미스 간 연결 가용성에 대한 지역 허용 목록
• 업무 시간 외에 플랫폼 지원이 제한되거나 지원되지 않음
• 패치 요구 사항
• DNS(도메인 이름 시스템) 및 프라이빗 엔드포인트 구현을 구동하는 특정 허브-스포크 구현
• 공급망 제어 요구 사항

요구 사항을 명시적으로 전달

워크로드 요구 사항이 핵심 기능 또는 인프라 제품을 명확하게 정의하지 않는 제약 조건 또는 SLA(서비스 수준 계약)에 직면한 경우 해당 상황을 위험으로 처리합니다. 이러한 위험을 해결하려면 워크로드 팀은 문제가 워크로드에 미치는 영향에 대해 다른 팀에 명확성을 제공해야 합니다. 워크로드 요구 사항, 디자인 또는 구현을 변경하거나 인프라 제품을 변경해야 할 수 있습니다.

조직 지침 및 워크로드 팀의 의무와 관련된 플랫폼 팀의 의무를 이해하면 현실적인 기대와 권장 사항으로 워크로드 요구 사항을 전달할 수 있습니다.

일반적인 워크로드 요구 사항 전달

모든 플랫폼 파트너십은 다르지만 다음 영역은 공동 책임 대화에서 일반적인 topics.

• 규정 준수 및 법적 요구 사항
• 정적 수신 또는 송신 IP 주소의 필요성과 같은 네트워킹 관련 사항
• 효과적인 라이브 사이트 심사를 제공하기 위한 가시성 요구 사항
• 네트워크 처리량, 클라우드 리소스의 가용성 또는 지역 가용성과 같은 성능 요구 사항
• 송신 및 수신 관점에서 공용 인터넷 액세스에 대한 기대
• 워크로드 사용자에게 제공되는 SLO(서비스 수준 목표) 또는 SLA
• 기술 지원의 가용성

통합 승리 찾기

공동의 책임은 단지 절충, 제약 조건 및 타협에 관한 것이 아닙니다. 플랫폼 팀에는 개별 워크로드 팀이 유지할 수 있는 것 이상으로 보강할 수 있는 고도로 전문화된 기술과 전용 예산이 있는 경우가 많습니다. 다음 예제를 고려해 보세요.

보안 전문가. 워크로드에 보안 개발 수명 주기가 있을 수 있습니다. 중앙 집중식 보안 팀이 organization 전체에서 대규모로 보안 개발 작업을 수행하므로, 그 이상의 노력을 통해 일상적인 침투 테스트를 수행할 수 있습니다. 인시던트 대응 전략을 계획하고 수행하는 데도 도움이 될 수 있습니다.

엔터프라이즈 아키텍처 지침. 팀이 이미 프로세스를 간소화했기 때문에 엔터프라이즈 아키텍처 팀의 패턴과 관행에 부합하는 경우 시간과 노력을 절약할 수 있습니다. 협상 없이 파트너 관계 내에서 솔루션이 불가능한 경우 재작업을 방지할 수도 있습니다.

큰 티켓 지출. 플랫폼 팀은 개별 워크로드 팀에 대해 너무 비싸거나 너무 광범위하게 관리되는 구성 요소 또는 서비스를 호스트하는 경우가 많습니다. 플랫폼 팀은 워크로드 간에 비용을 나누기 때문에 이러한 구성 요소와 서비스를 감당할 수 있습니다.

종종 이러한 서비스 또는 중앙 집중식 플랫폼은 단순한 쇼백으로 제공되므로 워크로드 비용을 최적화하는 데 도움이 됩니다. 그리고 그들은 차지백으로 제공 될 때, 그들은 종종 때문에 규모와 중앙 집중화의 경제 저렴.

플랫폼 팀은 다양한 활동을 위해 워크로드 팀에 셀프 서비스 옵션을 제공하는 경우가 많습니다. 예:

• 자체 교육용 설명서 리포지토리 제공
• 특정 리소스 태그 지정을 통해 비용 관리에 온보딩
• 공식 구독 자동 판매 프로세스를 통해 구독 제공

워크로드에 적합할 수 있는 셀프 서비스 옵션을 탐색합니다.

성공 및 과제 공유

다른 팀과 공동의 책임은 워크로드의 성공과 과제를 공유하는 것을 의미합니다. 워크로드가 의무를 충족하고 의도한 가치를 얻는 경우 이를 파트너 팀과 공유합니다. 워크로드의 성공에 어떻게 기여했는지 알려주세요. 워크로드가 의무를 충족하지 않는 경우 작동하지 않는 작업을 공유하고 협업하고 다시 조정하여 다시 궤도에 오를 수 있습니다.

플랫폼 팀에는 의무와 성공 기준도 있습니다. 파트너가 워크로드가 제품과 잘 작동하는지 또는 시끄러운 이웃이 될 위험이 있는지 알려줄 것으로 예상해야 합니다.

지속적인 개선을 위해 노력

모든 Well-Architected 프레임워크 핵심 요소의 테마는 지속적으로 개선됩니다. 진보적인 사고방식을 채택합니다. 기존 문제에 대한 새로운 접근 방식을 처리하거나, 새로운 기술을 채택하거나, 새로운 요구 사항을 해결하거나, 새로운 제약 조건에서 작동할 수 있습니다. 시간이 지남에 따라 워크로드가 개선됨에 따라 파트너 팀의 동일한 사고방식을 기대합니다. 그러나 모든 개선 기회도 변화를 의미하며 적절한 관리 프로세스에서 지원되어야 합니다.

워크로드 팀은 플랫폼 팀의 서비스에 영향을 미칠 수 있는 워크로드 요구 사항에 대한 제안된 변경 사항에 대해 플랫폼 팀과 통신할 의무가 있습니다. 마찬가지로 플랫폼 팀은 워크로드 파트너를 변경 제어 프로세스에 포함하고 영향력 있는 플랫폼 변경 내용을 명확하게 전달할 의무가 있습니다. 파트너와의 정기적인 커뮤니케이션 주기를 설정하여 제품이 어떻게 발전하는지 알아보고 공유합니다.

성공적인 결과 달성

워크로드는 사용자, 주주, 규제 기관, 직원, 우수성의 중심 및 최고 경험 책임자로부터 많은 기대를 가지고 있습니다. 기대는 방향 나침반 회전을 설정할 수 있습니다. Well-Architected Framework는 성공적인 결과를 얻기 위해 아키텍처 결정에 대한 명시적 합리화를 제공하여 디자인 및 구현과 관련된 명확성을 제공합니다. 성공적인 워크로드를 개발하고 해당 성공을 organization 공유합니다.