설계 원칙 및 고급 작업 적용

  • 아티클

처음 3개의 클라우드 관리 원칙은 관리 기준에 대해 설명합니다. 최소한 관리 기준에는 비즈니스 중단을 최소화하고 서비스가 중단된 경우 복구를 가속화하기 위한 표준 비즈니스 약속이 포함되어야 합니다. 대부분의 관리 기준에는 재고 및 가시성, 운영 규정 준수, 보호 및 복구 유지 관리에 대한 엄격한 초점이 포함됩니다.

관리 기준의 목적은 지원되는 모든 워크로드에 대한 최소 수준의 비즈니스 약정을 제공하는 일관된 제품을 만드는 것입니다. 이 공통적이고 반복 가능한 관리 제품에 대한 기준을 통해 팀은 편차를 최소화하면서 고도로 최적화된 운영 관리 수준을 제공할 수 있습니다. 그러나 그 표준 제품은 비즈니스에 대한 충분한 약속을 제공하지 않을 수 있습니다.

다음 섹션의 다이어그램은 관리 기준을 넘어서는 세 가지 방법을 보여 줍니다.

관리 기준은 포트폴리오에서 가장 낮은 중요도 워크로드의 80%에 필요한 최소 약속을 충족해야 합니다. 기준은 중요 업무용 워크로드에 적용되어서는 안 됩니다. 또한 워크로드 간에 공유되는 공통 플랫폼에도 적용해서는 안 됩니다. 이러한 워크로드에는 설계 원칙과 고급 작업에 중점을 두어야 합니다.

고급 작업 옵션

다음 다이어그램과 같이 관리 기준을 넘어 비즈니스 약속을 개선하기 위한 세 가지 제안된 경로가 있습니다.

고급 운영

향상된 관리 기준

Azure 관리 가이드에 설명된 대로 개선된 관리 기준은 클라우드 네이티브 도구를 사용하여 가동 시간을 개선하고 복구 시간을 단축합니다. 개선 사항은 중요하지만 워크로드 또는 플랫폼 전문화보다는 덜합니다. 향상된 관리 기준선의 장점은 비용과 구현 시간이 똑같이 크게 감소한다는 것입니다.

관리 전문화

워크로드 및 플랫폼 운영 측면에서 설계 및 아키텍처 원칙을 변경해야 할 수 있습니다. 이러한 변경에는 시간이 걸리고 운영 비용이 증가할 수 있습니다. 향상된 관리 기준은 이러한 투자가 필요한 워크로드 수를 줄이기 위해 비즈니스 약정을 충분히 개선할 수 있습니다.

비즈니스 약속을 충족하기 위해 더 많은 투자가 필요한 워크로드의 경우 운영의 전문화가 핵심입니다.

관리 전문 분야

두 가지 전문 분야가 있습니다.

  • 플랫폼 전문화: 공유 플랫폼의 지속적인 운영에 투자하여 여러 워크로드에 투자를 분산합니다.
  • 워크로드 전문화: 일반적으로 중요 업무용 워크로드를 위해 예약된 특정 워크로드의 지속적인 작업에 투자합니다.

중앙 IT 팀 또는 CCoE(Cloud Center of Excellence)

플랫폼 전문화와 워크로드 전문화 간의 결정은 각 워크로드의 중요도와 영향을 기반으로 합니다. 그러나 이러한 결정은 또한 중앙 IT 팀과 CCoE 조직 모델 간의 더 큰 문화적 결정을 나타냅니다.

워크로드 전문화는 종종 문화적 변화를 유발합니다. 기존 IT와 중앙 집중식 IT는 모두 대규모 지원을 제공할 수 있는 프로세스를 빌드합니다. 확장 지원은 관리 기준선, 향상된 기준선 또는 플랫폼 운영에서 발견되는 반복 가능한 서비스에 대해 더 달성 가능합니다. 워크로드 전문화는 확장되지 않는 경우가 많습니다. 이러한 규모의 부족으로 인해 중앙 집중식 IT 조직은 조직 규모의 한계에 도달하지 않고 필요한 지원을 제공하기 어렵습니다.

또는 클라우드 센터 오브 엑설런스 방법은 의도적인 책임 위임 및 선택적 중앙 집중화를 통해 확장됩니다. 워크로드 전문화는 CCoE의 위임된 책임 방법과 더 잘 일치하는 경향이 있습니다.

CCoE에서 역할의 자연스러운 정렬은 다음과 같이 요약됩니다.

  • 클라우드 플랫폼 팀은 여러 클라우드 채택 팀을 지원하는 공통 플랫폼을 빌드하는 데 도움을 줍니다.
  • 클라우드 자동화 팀은 이러한 플랫폼을 서비스 카탈로그의 배포 가능한 자산으로 확장합니다.
  • 클라우드 관리는 중앙에서 관리 기준을 제공하고 서비스 카탈로그 사용을 지원하는 데 도움이 됩니다.
  • 그러나 사업부(비즈니스 DevOps 팀 또는 클라우드 채택 팀 형태)는 워크로드, 파이프라인 또는 성능의 일상적인 운영에 대한 책임을 집니다.

관리 영역 조정과 관련하여 중앙 IT 팀과 CCoE 모델은 일반적으로 최소한의 문화적 변화로 플랫폼 전문화를 제공할 수 있습니다. 중앙 IT 팀의 경우 워크로드 전문화를 제공하는 것이 더 복잡할 수 있습니다.

관리 전문화 프로세스

각 전문 분야 내에서 다음 4단계 프로세스가 규칙적이고 반복적인 방법으로 제공됩니다. 이 방법을 사용하려면 실행 가능하고 정보에 입각한 피드백 루프를 만들기 위해 클라우드 채택, 클라우드 플랫폼, 클라우드 자동화 및 클라우드 관리 전문가 간의 파트너십이 필요합니다.

  • 시스템 설계 개선: 일반적인 시스템(플랫폼) 또는 특정 워크로드의 설계를 개선하여 중단을 효과적으로 최소화합니다.
  • 수정 자동화: 일부 개선 사항은 비용 효율적이지 않습니다. 이러한 경우 문제 해결을 자동화하고 중단의 영향을 줄이는 것이 더 합리적일 수 있습니다.
  • 솔루션 확장: 시스템 설계 및 자동화된 수정이 개선됨에 따라 서비스 카탈로그를 통해 환경 전반에 걸쳐 이러한 변경 내용을 확장할 수 있습니다.
  • 지속적인 개선: 다양한 모니터링 도구를 사용하여 시스템 설계, 자동화 및 확장의 다음 단계에서 해결할 점진적 개선 사항을 찾을 수 있습니다.

시스템 디자인 개선

시스템 디자인 개선은 일반 플랫폼의 운영을 개선하는 가장 효과적인 접근법입니다. 시스템 설계 개선은 안정성을 높이고 비즈니스 중단을 줄이는 데 도움이 될 수 있습니다. 개별 시스템의 디자인은 클라우드 도입 프레임워크에서 수행되는 환경 보기의 범위를 벗어납니다.

이 프레임워크의 보완 요소인 Microsoft Azure Well-Architected Framework는 플랫폼 또는 특정 워크로드의 품질을 개선하기 위한 지침을 제공합니다. 프레임워크는 다음 아키텍처 핵심 요소의 5가지 기능에 대한 개선에 중점을 둡니다.

  • 비용 최적화: 비용을 관리하여 제공되는 가치를 극대화합니다.
  • 뛰어난 운영: 프로덕션에서 시스템을 실행하는 작업 프로세스를 따릅니다.
  • 성능 효율성: 부하의 변화에 맞게 시스템 크기를 조정합니다.
  • 안정성: 오류를 복구하여 계속 작동하도록 시스템을 디자인합니다.
  • 보안: 위협으로부터 애플리케이션 및 데이터를 보호합니다.

대부분의 비즈니스 중단은 특정 형태의 기술적인 문제 또는 아키텍처의 결함에 해당합니다. 기존 배포의 경우 시스템 디자인 개선을 기존의 기술적인 문제에 대한 보답으로 볼 수 있습니다. 신규 배포의 경우 시스템 디자인 개선을 기술적인 문제에 대한 예방책으로 볼 수 있습니다. 다음 섹션에서는 처리할 수 없거나 처리해서는 안 되는 기술적인 문제를 처리하는 방법을 보여 줍니다.

시스템 디자인을 개선하려면 Microsoft Azure Well-Architected 프레임워크에 대해 자세히 알아봅니다. 시스템 설계가 개선되면 이 문서로 돌아와 환경 전반에 걸쳐 개선 사항을 개선하고 확장할 수 있는 새로운 기회를 찾습니다.

자동화된 수정

일부 기술적인 문제는 해결될 수 없거나 해결되어서는 안 됩니다. 해결하는 데 비용이 너무 많이 들 수 있습니다. 계획할 수는 있지만 프로젝트 기간이 길 수 있습니다. 비즈니스 중단은 비즈니스에 심각한 영향을 미치지 않을 수 있습니다. 또는 비즈니스 우선 순위는 복원력에 투자하는 대신 신속하게 복구하는 것입니다.

기술적인 문제를 확인하는 것이 바람직한 경로가 아닌 경우 일반적으로 자동 재구성이 바람직한 다음 단계입니다. Azure Automation 및 Azure Monitor를 사용하여 추세를 검색하고 자동 재구성 기능을 제공하는 것은 자동 재구성에 대한 가장 일반적인 접근법입니다.

자동 재구성에 대한 지침은 Azure Automation 및 경고를 참조하세요.

서비스 카탈로그를 사용하여 솔루션 크기 조정

플랫폼 전문화 및 플랫폼 작업의 초석은 잘 관리되는 서비스 카탈로그입니다. 이는 시스템 디자인 및 재구성에 대한 개선 사항이 환경 전체에 확장되는 방법입니다. 클라우드 플랫폼 팀과 클라우드 자동화 팀은 함께 협력하여 모든 환경의 가장 일반적인 플랫폼에 대한 반복 가능한 솔루션을 만듭니다. 그러나 이러한 솔루션이 일관되게 적용되지 않는 경우 클라우드 관리는 기본 제품 이상을 제공할 수 없습니다.

최적화된 플랫폼의 채택을 최대화하고 유지 관리 오버헤드를 최소화하려면 플랫폼을 서비스 카탈로그에 추가해야 합니다. 카탈로그의 각 애플리케이션을 서비스 카탈로그를 통해 내부에서 사용하도록 배포하거나 외부 사용자를 위한 Marketplace 제품으로 배포할 수 있습니다.

서비스 카탈로그에 게시하는 방법에 대한 자세한 내용은 서비스 카탈로그에 게시에 대한 시리즈를 참조하세요.

지속적인 향상

플랫폼 전문화 및 플랫폼 작업은 모두 도입, 플랫폼, 자동화 및 관리 팀 간의 강력한 피드백 루프에 의존합니다. 이러한 피드백 루프를 데이터에 접지하면 각 팀이 현명한 결정을 내릴 수 있습니다. 플랫폼 운영이 장기적인 비즈니스 약속을 달성하려면 중앙 집중식 플랫폼에 특정한 인사이트를 활용하는 것이 중요합니다. 컨테이너와 SQL Server는 가장 일반적인 두 가지 중앙 관리 플랫폼이므로 다음 문서를 검토하여 지속적인 개선 데이터 컬렉션을 시작하는 것이 좋습니다.