Azure Well-Architected 프레임워크 핵심 요소

  • 10분

클라우드는 조직이 비즈니스 과제를 해결하는 방법과 애플리케이션 및 시스템이 설계되는 방식을 바꾸었습니다. 솔루션 설계자의 역할은 애플리케이션의 기능적 요구 사항을 통해 비즈니스 가치를 제공하는 것에 그치지 않으며, 확장성과 복원력이 있으며 효율적이고 안전한 방식으로 솔루션을 설계할 수도 있어야 합니다.

솔루션 아키텍처는 계획, 설계, 구현 및 기술 시스템의 지속적인 향상과 관련이 있습니다. 시스템의 아키텍처는 이러한 요구 사항을 실행하는 데 필요한 기술적 역량에 맞추어 비즈니스 요구 사항을 정렬하고 둘 사이의 균형을 유지해야 합니다. 완성된 아키텍처는 시스템 및 해당 구성 요소 전체에서 위험, 비용 및 기능의 균형을 유지합니다.

Azure Well-Architected 프레임워크

Azure Well-Architected 프레임워크는 Azure에서 고품질 솔루션을 빌드하는 방법을 안내하는 원칙 세트입니다. 아키텍처 설계에 보편적으로 적용할 수 있는 접근 방식은 없지만, 아키텍처, 기술 또는 클라우드 공급자에 관계없이 적용되는 몇 가지 보편적인 개념이 있습니다.

이 개념은 모두를 포괄하지는 않지만 이러한 개념에 집중하면 신뢰할 수 있고 안전하며 유연한 애플리케이션의 기반을 빌드하는 데 도움이 됩니다.

Azure Well-Architected 프레임워크는 다음 다섯 가지 핵심 요소로 구성됩니다.

  • 비용 최적화
  • 운영 우수성
  • 성능 효율성
  • 안정성
  • 보안

Azure Well-Architected 프레임워크의 핵심 요소를 보여주는 일러스트레이션.

비용 최적화

비용 효율적인 작업과 개발을 위한 클라우드 환경을 설계하려고 합니다. 자금을 가장 잘 활용할 수 있는 경우에만 지출하도록 하려면 클라우드 지출에서 비효율성 및 낭비를 식별해야 합니다.

유지 비용을 줄이면서도 품질, 속도 및 효율성을 높이는 것을 보여주는 일러스트레이션.

운영 우수성

DevOps와 같은 최신 개발 사례를 활용하여 더 빠른 개발 및 배포 주기를 사용하도록 설정할 수 있습니다. 오류와 문제가 발생하기 전에 또는 최소한 고객이 확인하기 전에 오류 및 문제를 감지할 수 있도록 올바른 모니터링 아키텍처를 마련해야 합니다. 자동화는 작업 민첩성을 높이는 동시에 분산 및 오류를 제거하는 이러한 핵심 요소의 중요한 측면입니다.

성능 효율성

아키텍처가 잘 작동하고 확장 가능하려면 리소스 용량과 수요를 적절히 일치시켜야 합니다. 전통적으로 클라우드 아키텍처는 애플리케이션의 작업을 기반으로 애플리케이션 크기를 동적으로 조정하여 이러한 균형을 유지합니다. 서비스에 대한 요구는 변경하므로, 아키텍처는 이러한 요구에 맞게 조정될 수 있어야 합니다. 성능 및 확장성을 염두에 두고 아키텍처를 설계함으로써 고객에게 비용 효율적이면서 뛰어난 환경을 제공할 수 있습니다.

수요에 따라 클라우드의 리소스 규모를 동적으로 스케일링하여 효율성을 높이는 방법을 보여 주는 일러스트레이션. 고정된 수준에서 리소스를 구현하면 수요가 적을 때에는 효율성이 떨어지고 수요가 많을 때에는 리소스가 부족하게 됩니다.

안정성

모든 설계자가 가장 두려워하는 것은 아키텍처가 어떠한 복구 방법도 없이 중단되는 것입니다. 성공적인 클라우드 환경은 모든 수준의 오류를 예측할 수 있는 방식으로 설계됩니다. 이러한 오류 예측의 일부는 관련자와 고객이 요구하는 시간 내에 오류를 복구할 수 있는 시스템을 설계하는 것입니다.

가상 네트워크의 가상 머신 두 대를 보여 주는 일러스트레이션. 머신 중 한 대는 오류가 있는 것으로 표시되고 다른 한 대는 서비스 고객 요청을 처리하는 것으로 표시됩니다.

보안

데이터는 조직의 기술적 공간에서 가장 중요한 부분입니다. 이 핵심 요소에서는 인증을 통해 아키텍처에 대한 액세스를 보호하고, 네트워크 취약성으로부터 애플리케이션 및 데이터를 보호하는 것에 집중하게 됩니다. 암호화 같은 도구를 사용하여 데이터의 무결성도 보호해야 합니다.

디자인 및 구현에서부터 배포 및 작업까지 애플리케이션의 전체 수명 주기 동안 보안을 고려해야 합니다. 클라우드는 네트워크 침입 및 DDoS 공격과 같은 다양한 위협에 대한 보호를 제공합니다. 그러나 애플리케이션, 프로세스 및 조직 문화에도 보안을 구축해야 합니다.

클라우드의 데이터에 영향을 줄 수 있는 보안 위협 및 공격 유형을 보여주는 일러스트레이션.

일반 설계 원칙

이러한 각 핵심 요소뿐 아니라 아키텍처 전체에서 고려해야 할 몇 가지 일관된 설계 원칙이 있습니다.

  • 아키텍처 발전 활성화: 고정적인 아키텍처는 없습니다. 새 서비스, 도구 및 기술을 사용할 수 있는 경우 이를 활용하여 아키텍처를 발전시킬 수 있습니다.

  • 데이터를 사용하여 결정: 데이터를 수집하고 분석하여 아키텍처에 대한 결정을 내리는 데 사용합니다. 비용 데이터, 성능, 사용자 로드 등 데이터를 사용하면 사용자 환경에서 적절한 선택을 할 수 있습니다.

  • 교육 및 활성화: 클라우드 기술은 빠르게 발전합니다. 적절한 결정을 내리고 비즈니스 문제를 해결하는 솔루션을 구축할 수 있도록 개발, 운영 및 비즈니스 팀을 교육하세요. 조직 내에서 구성, 결정 사항 및 모범 사례를 문서화하고 공유해야 합니다.

  • 자동화: 수동 작업을 자동화하면 운영 비용이 줄어들고 수동 단계에서 발생하는 오류를 최소화할 수 있으며 여러 환경 간에 일관성을 가질 수 있습니다.

공동 책임

클라우드로 이동하면 공동 책임 모델이 도입됩니다. 이 모델에서 클라우드 공급자는 애플리케이션의 특정 측면을 관리하고 나머지 책임은 사용자에게 맡깁니다.

온-프레미스 환경에서는 모든 항목을 사용자가 담당합니다. IaaS(Infrastructure as a Service)로 이동한 다음, PaaS(platform as a service) 및 SaaS(Software as a Service)로 전환하면 클라우드 공급자는 더 많은 책임을 맡게 됩니다.

이러한 공동 책임은 비용, 보안과 애플리케이션의 기술 및 운영적 기능에 영향을 줄 수 있으므로 아키텍처 결정에 중요한 역할을 합니다. 이러한 책임을 공급자에게 맡기게 되면 비즈니스에 가치를 부여하는 데 집중하고 핵심 비즈니스 기능이 아닌 활동에서 벗어날 수 있습니다.

각 클라우드 서비스 모델 유형의 공동 책임 수준을 보여 주는 일러스트레이션

설계 선택

이상적인 아키텍처라면 가급적 가장 안정적이고 고성능 및 고가용성의 효율적인 환경을 빌드하게 될 것입니다. 그러나 모든 경우와 마찬가지로 여기에도 단점이 있습니다.

이러한 모든 핵심 요소 중 가장 높은 수준으로 환경을 구축하려면 비용이 발생합니다. 해당 비용은 금액, 전달 시간 또는 운영의 민첩성에 해당할 수 있습니다. 모든 조직마다 각 핵심 요소에서 결정한 설계 선택에 영향을 미치는 우선 순위는 다릅니다. 아키텍처를 설계할 때 허용하거나 허용할 수 없는 단점을 결정해야 합니다.

Azure 아키텍처를 빌드할 때는 많은 고려 사항을 염두에 두어야 합니다. 아키텍처가 안전하며 확장성이 있고 사용 및 복구 가능하기를 원한다고 가정하겠습니다. 이를 가능하게 하려면 비용, 조직의 우선 순위 및 위험에 따라 결정해야 합니다.