설계 원칙 - AWS Well-Architected Framework

설계 원칙

클라우드에는 5가지 신뢰성 설계 원칙이 있습니다.

  • 장애 자동 복구: 워크로드의 KPI(핵심 성능 지표)를 모니터링하면 임계값이 위반될 때 자동화를 트리거할 수 있습니다. 이러한 KPI는 서비스 운영의 기술적 측면이 아닌 비즈니스 가치를 측정한 값이어야 합니다. KPI를 모니터링하면 장애 추적 및 자동 알림을 지원하고, 자동화된 복구 프로세스에 따라 장애 지점을 우회하거나 복구할 수 있습니다. 보다 정교한 자동화를 구현할 경우 장애가 발생하기 전에 예측하여 해결하는 것도 가능합니다.

  • 복구 절차 테스트: 온프레미스 환경에서 테스트는 워크로드가 특정 시나리오에서 작동하는 것을 증명하기 위해 시행됩니다. 일반적으로 복구 전략을 검증하기 위해 테스트하지는 않습니다. 클라우드에서는 워크로드의 장애 과정을 테스트하고 복구 절차를 검증할 수 있습니다. 자동화를 사용하여 다양한 장애를 시뮬레이션하거나 이전에 장애로 이어졌던 시나리오를 재현할 수 있습니다. 이 접근 방식은 장애 경로를 노출한 후 실제 장애 시나리오가 발생하기 전에 테스트하고 수정하여 위험을 줄일 수 있습니다.

  • 수평적 확장으로 워크로드 전체 가용성 증대: 단일의 큰 리소스를 다수의 작은 리소스로 대체하여 단일 장애가 전체 워크로드에 미치는 영향을 축소합니다. 요청을 더 작은 리소스 여러 개로 분산시키면 단일 장애 지점을 회피할 수 있습니다.

  • 용량 추정 불필요: 워크로드에 대한 수요가 해당 워크로드의 용량을 넘어서는 리소스 포화 상태는 온프레미스 워크로드에서 흔히 발생하는 장애의 원인입니다(서비스 거부 공격의 대상). 클라우드에서는 수요 및 워크로드 사용량을 모니터링하고 리소스 추가 또는 제거를 자동화함으로써 프로비저닝 과다 또는 부족 현상 없이 최적의 수준으로 수요를 충족할 수 있습니다. 클라우드에도 제한은 있지만 할당량을 어느 정도 제어하고 관리하는 것이 가능합니다(Service Quotas 및 제약 조건 관리 참조).

  • 자동화 변경 사항 관리: 인프라 변경은 자동화를 통해 수행되어야 합니다. 자동화 변경을 통하여 인프라를 관리해야 하며 이후에 이러한 변경을 추적하고 검토할 수 있습니다.