모든 클라우드 플랫폼에서 중요 업무용 애플리케이션을 설계하려면 신중한 엔지니어링 접근 방식이 필요합니다. 플랫폼의 기능을 이해하고, 올바른 서비스를 선택하고, 올바르게 구성하고, 효과적으로 운영하며, 진화하는 모범 사례 및 서비스 로드맵에 부합하는 복잡성이 있습니다.
이러한 복잡성을 탐색하려면 특히 가동 시간 및 복구와 관련하여 비즈니스 요구 사항에 부합하는 명확하고 간단한 디자인 방법을 설정합니다. 의사 결정이 어려워지거나 분석 마비에 갇혀 있는 경우 방법론을 참조 지점으로 되돌립니다. 선택 사항의 유효성을 검사하고, 디자인에 집중하며, 전반적인 목표와 일치하는지 확인하는 데 도움이 될 수 있습니다.
이 문서에서는 Azure에 배포된 수많은 중요 업무용 애플리케이션을 검토하여 얻은 인사이트를 통해 정보를 제공하는 디자인 방법론을 제안합니다.
안정성 목표를 위한 디자인
중요 업무가 모든 사람에게 동일한 의미는 아닙니다. 아키텍처는 워크로드의 비즈니스 요구 사항 및 허용 가능한 가동 중지 시간에 따라 달라집니다. 99.9% 및 99.999% 가용성과 같은 SLO(서비스 수준 목표)에서 정의되는 경우가 많습니다. 가용성 목표는 가동 시간 이상으로 간주합니다. 정상 애플리케이션 상태를 기준으로 일관된 서비스를 나타냅니다. 시작점으로 팀은 허용되는 가동 중지 시간을 정의해야 합니다. 가동 시간/가동 중지 시간 계산기를 사용하여 허용되는 가동 중지 시간을 결정합니다.
이 디자인 방법론은 목표가 설정된 후 아키텍처 결정 및 장단점의 시작점이 될 수 있습니다. 초안 대상 아키텍처가 구체화되고 비용과 복잡성이 명확해짐에 따라 대체 솔루션을 통해 초기 요구 사항을 다시 검토, 도전, 조정 또는 해결할 수 있습니다.
예를 들어 단일 지역, 다중 영역 설정은 많은 중요한 워크로드에 적합할 수 있지만 안정성이 높을수록 엔지니어링 노력과 복잡성이 높아질 수 있습니다. 강력한 요구 사항이 없는 한 활성-활성 다중 지역과 같은 복잡한 솔루션을 기본 선택으로 삼지 마세요.
RTO(복구 시간 목표) 및 RPO(복구 지점 목표)도 안정성 요구 사항을 정의하는 데 핵심적인 요소입니다. 예를 들어 1분 안에 애플리케이션을 복구하는 것이 목표인 경우 백업 기반 또는 활성-수동 전략은 충분히 빠르지 않을 수 있습니다.
엔드 투 엔드 자동화를 위해 노력
배포 및 지속적인 관리 활동을 모두 포괄하는 포괄적인 자동화 전략을 채택합니다. 이 방법론은 자동화 우선 원칙을 통해 일관성, 반복성 및 복원력을 강조합니다.
자동화의 일반적인 영역은 수동 작업 및 오류를 줄이기 위한 패치, 크기 조정 및 모니터링과 같은 일상적인 작업입니다. 템플릿이 실행 가능하지 않은 경우에만 스크립트를 사용하여 일관성과 명확성을 보장하기 위해 구성 및 배포를 위한 템플릿을 선호합니다.
자동화를 사용하도록 설정하기 위한 권장 사항 참조
가동 중지 시간 없는 배포를 위한 디자인
무정지 배포를 통해 사용자가 변경 중에 중단을 겪지 않도록 합니다.
이 방법론은 업데이트에서 결함, 취약성 또는 불안정성을 도입하지 않도록 엄격한 시험판 테스트를 요구합니다. 이를 지원하려면 배포 도구 및 프로세스를 고가용성 및 복원력이 있어야 합니다.
일관성이 핵심입니다. 수동 오류의 가능성을 제거하고 전반적인 위험을 줄이기 위해 모든 환경에서 동일한 아티팩트와 자동화된 프로세스를 사용해야 합니다. 엔드투엔드 자동화는 단순히 선호되는 것이 아닙니다. 신뢰할 수 있고 반복 가능하며 중단 없는 배포를 달성하려면 필수입니다.
빠른 오류 감지 및 복구를 위한 디자인
빠른 장애 감지는 잘 정의된 건강 모델로 시작합니다. 오류가 구성 요소 간에 연속되는 경우가 많기 때문에 워크로드 구성 요소 간의 조기 검색 및 명확한 종속성은 폭발 반경을 최소화하고 복구 속도를 높이기 위해 협상할 수 없습니다.
즉, 성능 및 가용성에 대한 실제 사용자 흐름 및 비즈니스 임계값을 기반으로 각 구성 요소에 대해 정상 및 비정상 상태의 모양을 명확하게 식별합니다. 이러한 정의는 모니터링하는 메트릭을 안내하고 문제를 근본 원인으로 다시 추적하는 데 도움이 됩니다.
Azure를 사용하여 진화
아키텍처를 모듈화되고 유연하게 설계하여 주요 변경 없이 새 기능을 더 쉽게 채택할 수 있습니다. Azure의 진화하는 서비스 및 기능을 최신 상태로 유지하기 위해 디자인을 정기적으로 검토합니다. 낮은 운영 오버헤드와 더 나은 통합을 위해 Azure 네이티브 관리 서비스의 우선 순위를 지정합니다. Azure는 자주 업데이트되므로 아키텍처를 로드맵에 맞게 조정하면 애플리케이션이 최적화되고 향후 준비 상태를 유지할 수 있습니다.
새 서비스 및 기능에 대한 최신 정보는 Azure 및 Azure 업데이트를 사용하여 진화를 참조하세요.
다음 단계
Well-Architected 프레임워크 기둥이 중요 업무용 워크로드 클래스에 적용되는 방식을 검토하여 디자인 과정을 시작합니다.
디자인 영역은 상호 연결되므로 한 영역의 변경 내용이 다른 영역에 영향을 미칠 수 있습니다. 비즈니스에 가장 중요한 영역부터 시작하고, 아키텍처 전체에서 선택이 어떻게 상쇄 효과를 일으키는지 이해하기 위해 고려 사항과 권장 사항을 검토합니다.
이 방법론에 따라 디자인 결정을 설명하는 이러한 참조 아키텍처를 참조하세요.