안정성 디자인 원칙

중단 및 오작동은 모든 워크로드에 심각한 문제입니다. 신뢰할 수 있는 워크로드는 이러한 이벤트에서 살아남고 의도한 기능을 지속적으로 제공해야 합니다. 허용되는 기간 내에 오류를 감지, 견뎌, 복구할 수 있도록 복원력이 있어야 합니다. 또한 사용자가 약속된 품질 수준에서 약속된 기간 동안 워크로드에 액세스할 수 있도록 사용할 수 있어야 합니다.

특히 워크로드가 분산 시스템에서 실행되도록 빌드된 경우 오류가 발생하지 않는다고 가정하는 것은 현실적이지 않습니다. 일부 구성 요소는 실패하고 다른 구성 요소는 계속 작동할 수 있습니다. 어떤 시점에서 사용자 환경이 영향을 받을 수 있으므로 비즈니스 목표가 손상될 수 있습니다.

워크로드 아키텍처는 애플리케이션 코드, 인프라 및 운영에서 안정성을 보증해야 합니다. 디자인 선택은 비즈니스 요구 사항에 따라 지정된 의도를 변경해서는 안 됩니다. 이러한 변화는 상당한 절충안으로 간주되어야 합니다.

디자인 원칙은 개발 수명 주기 전반에 걸쳐 고려해야 하는 안정성 측면에 대한 지침을 제공하기 위한 것입니다. 권장 접근 방식부터 시작하여 일련의 요구 사항에 대한 이점을 정당화합니다. 전략을 설정한 후 안정성 검사 목록을 사용하여 작업을 수행합니다.

이러한 원칙을 디자인에 적용하지 않으면 워크로드가 프로덕션의 문제를 예상하거나 처리할 준비가 되지 않을 가능성이 큽니다. 결과는 재정적 손실로 이어지는 서비스 중단일 수 있습니다. 중요한 워크로드의 경우 이러한 원칙을 적용하지 못하면 안전이 위태로워질 수 있습니다.

비즈니스 요구 사항을 고려한 디자인

워크로드의 의도된 유틸리티에 중점을 두고 비즈니스 요구 사항을 수집합니다.

요구 사항은 사용자 환경, 데이터, 워크플로 및 워크로드에 고유한 특성을 포함해야 합니다. 요구 사항 프로세스의 결과는 기대치를 명확하게 명시해야 합니다. 지정된 투자를 감안할 때 목표를 달성하고 팀과 협상해야 합니다. 기술 선택, 구현 및 운영을 추진하려면 문서화해야 합니다.

접근 방식	혜택
개별 구성 요소, 시스템 흐름 및 시스템 전체에 대한 지표에서 대상을 설정하여 성공을 정량화합니다. 이러한 대상이 사용자 흐름을 보다 안정적으로 만들 수 있나요?	메트릭은 기대치를 정량화합니다. 복잡성을 이해하고 이러한 복잡성 의 다운스트림 비용이 투자 한도 내에 있는지 여부를 확인할 수 있습니다. 대상 값은 이상적인 상태를 나타냅니다. 값을 테스트 임계값으로 사용하여 해당 상태의 편차 와 대상 상태로 돌아가는 데 걸리는 시간을 검색할 수 있습니다. 규정 준수 요구 사항에는 scope 흐름에 대한 예측 가능한 결과도 있어야 합니다. 이러한 흐름의 우선 순위를 지정 하면 가장 중요한 영역에 주의를 기울입니다.
플랫폼 약정을 이해합니다. 서비스에 대한 제한, 할당량, 지역 및 용량 제약 조건을 고려합니다.	SLA(서비스 수준 계약)는 서비스에 따라 다릅니다. 모든 서비스와 기능이 동일하게 적용되는 것은 아닙니다. 모든 지역에서 모든 서비스 또는 기능을 사용할 수 있는 것은 아닙니다. 대부분의 구독 리소스 제한은 지역당입니다. 범위 및 제한을 잘 이해하면 드리프트를 감지하고 복원력 및 복구 메커니즘을 빌드하는 데 도움이 될 수 있습니다.
종속성과 해당 종속성이 복원력에 미치는 영향을 결정합니다.	다른 팀 또는 타사에서 개발한 종속 인프라, 서비스, API 및 기능을 추적하면 이러한 종속성이 없는 경우 워크로드가 작동할 수 있는지 여부를 결정하는 데 도움이 됩니다. 또한 연속 오류를 이해하고다운스트림 작업을 개선하는 데 도움이 됩니다. 개발자는 오류에 취약할 수 있는 외부 서비스를 사용할 때 잠재적인 오류를 처리하기 위해 복원력 있는 디자인 패턴을 구현 할 수 있습니다.

복원력을 위한 디자인

워크로드는 전체 또는 축소된 기능으로 계속 작동해야 합니다.

구성 요소 오작동, 플랫폼 중단, 성능 저하, 제한된 리소스 가용성 및 기타 오류가 발생할 것으로 예상해야 합니다. 내결함성이 있고 정상적으로 저하할 수 있도록 시스템에서 복원력을 구축합니다.

접근 방식	혜택
중요한 경로에 있는 구성 요소를 저하된 상태에서 작동할 수 있는 구성 요소와 구분합니다.	워크로드의 모든 구성 요소가 똑같이 신뢰할 필요는 없습니다. 중요도를 결정하면 각 구성 요소의 중요도에 따라 디자인하는 데 도움이 됩니다. 실패할 경우 종단 간 문제를 일으킬 수 있는 구성 요소와 달리 사용자 환경을 약간 저하시킬 수 있는 구성 요소에 대한 복원력을 지나치게 강화하지 않습니다. 디자인은 중요한 구성 요소에 리소스를 할당하는 데 효율적일 수 있습니다. 오류 격리 전략을 구현하여 비임계 구성 요소가 실패하거나 성능이 저하된 상태로 진입하는 경우 연속 오류를 방지하기 위해 격리할 수 있습니다.
특히 중요한 구성 요소에 대한 시스템의 잠재적 오류 지점을 식별하고 사용자 흐름에 미치는 영향을 결정합니다.	오류 사례, 폭발 반경 및 오류 강도(전체 또는 부분 중단)를 분석할 수 있습니다. 이 분석은 구성 요소 수준에서 오류 처리 기능의 디자인에 영향을 줍니다.
디자인 패턴을 올바르게 사용하고 디자인을 모듈화하여 오류를 격리하여 자체 보존 기능을 빌드합니다.	시스템은 문제가 다운스트림 구성 요소에 영향을 주지 않도록 방지할 수 있습니다. 시스템은 일시적 및 영구적 오류, 성능 병목 상태 및 안정성에 영향을 줄 수 있는 기타 문제를 완화할 수 있습니다. 또한 폭발 반경을 최소화할 수 있습니다.
지원되는 지역에서 서비스의 용량 제약 조건을 고려하여 중요한 구성 요소(애플리케이션 및 인프라)를 스케일 아웃하는 기능을 추가합니다.	워크로드는 가변 용량 급증 및 변동을 처리할 수 있습니다. 이 기능은 시스템에 예기치 않은 부하가 있을 때(예: 유효한 사용량 급증) 매우 중요합니다. 워크로드가 여러 지역에 걸쳐 스케일 아웃되도록 설계된 경우 단일 지역에 영향을 미치는 잠재적인 임시 리소스 용량 제약 조건 또는 기타 문제를 극복할 수도 있습니다.
계층에서 중복성을 구축하고 다양한 애플리케이션 계층에서 복원력을 구축합니다. 물리적 유틸리티의 중복성과 즉각적인 데이터 복제를 목표로 합니다. 또한 서비스, 운영 및 인력을 포함하는 기능 계층의 중복성을 목표로 합니다.	중복성은 단일 실패 지점을 최소화하는 데 도움이 됩니다. 예를 들어 구성 요소, 영역 또는 지역 중단이 있는 경우 중복 배포(활성-활성 또는 활성-수동)를 사용하면 가동 시간 목표를 충족할 수 있습니다. 중간자를 추가하면 구성 요소 간의 직접적인 종속성이 방지되고 버퍼링이 향상됩니다. 이러한 이점은 모두 시스템의 복원력을 강화합니다.
중복 인스턴스의 개별 오류를 즉시 완화하고 런어웨이 리소스 소비에 대해 버퍼링하기 위한 오버프로비전.	과잉 프로비전에 대한 투자가 증가하면 복원력이 향상됩니다. 크기 조정 작업이 오류를 수정하기 전에도 시스템이 활성 실패 시 전체 유틸리티에서 계속 작동합니다. 마찬가지로 시스템 오류 또는 공격적인 크기 조정이 발생하기 전에 계획된 버퍼를 클레임하는 예기치 않은 런어웨이 리소스 소비의 위험을 줄이고 중요한 심사 시간을 얻을 수 있습니다.

복구를 위한 디자인

워크로드는 사용자 환경 및 비즈니스 목표에 대한 중단을 최소화하면서 모든 규모의 대부분의 실패를 예측하고 복구할 수 있어야 합니다.

복원력이 뛰어난 시스템조차도 아키텍처 설계 및 워크로드 작업 모두에서 재해 대비 접근 방식이 필요합니다. 데이터 계층에는 손상 시 워크로드 상태를 복구할 수 있는 전략이 있어야 합니다.

접근 방식	혜택
협상된 복구 목표와 일치하는 구조화, 테스트 및 문서화된 복구 계획이 있습니다. 계획은 시스템 전체뿐만 아니라 모든 구성 요소를 포함해야 합니다.	잘 정의된 프로세스는 비즈니스의 재정 및 평판에 부정적인 영향을 미칠 수 있는 빠른 복구 로 이어집니다. 정기적인 복구 훈련을 수행하면 시스템 구성 요소, 데이터 및 장애 조치(failover) 및 장애 복구 단계를 복구하는 프로세스를 테스트하여 시간 및 데이터 무결성이 성공의 주요 측정값인 경우 혼동을 방지합니다 .
복구 대상 내의 모든 상태 저장 구성 요소의 데이터를 복구 할 수 있는지 확인합니다.	백업은 마지막으로 알려진 양수 상태와 같은 신뢰할 수 있는 복구 지점을 사용하여 시스템을 다시 작동 상태로 되돌리는 데 필수적입니다. 변경할 수 없고 트랜잭션적으로 일관된 백업은 데이터를 변경할 수 없고 복원된 데이터가 손상되지 않도록 합니다.
디자인에서 자동화된 자가 복구 기능을 구현합니다 .	이 자동화는 사람의 개입과 같은 외부 요인으로 인한 위험을 줄이고 중단 수정 주기를 단축합니다.
상태 비저장 구성 요소를 변경할 수 없는 임시 단위로 바꿉니다.	요청 시 스핀업 및 삭제할 수 있는 임시 단위를 빌드하면 반복성과 일관성을 제공합니다. 병렬 배포 모델을 사용하여 새 단위로 증분 전환하여 중단을 최소화합니다.

운영을 위한 디자인

작업에서 왼쪽으로 이동하여 실패 조건을 예상합니다.

개발 수명 주기 초기에 자주 실패를 테스트하고 성능이 안정성에 미치는 영향을 확인합니다. 근본 원인 분석 및 사후 분석을 위해서는 팀 전체에서 종속성 상태 및 지속적인 실패에 대한 공유 가시성이 있어야 합니다. 관찰 가능한 시스템의 인사이트, 진단 및 경고는 효과적인 인시던트 관리 및 지속적인 개선의 기본 사항입니다.

접근 방식	혜택
원격 분석의 상관 관계를 지정할 수 있는 관찰 가능한 시스템을 빌드합니다.	모니터링 및 진단 중요한 작업입니다. 오류가 발생하면 실패한 경우, 실패한 경우 및 실패한 이유를 알아야 합니다. 구성 요소 수준의 가시성은 기본적이지만 구성 요소 및 상관 관계가 있는 사용자 흐름의 집계된 가시성은 상태 상태 대한 전체적인 보기를 제공합니다. 이 데이터는 사이트 안정성 엔지니어가 수정 작업의 우선 순위를 지정할 수 있도록 하는 데 필요합니다.
잠재적인 오작동 및 비정상적인 동작을 예측합니다. 우선 순위가 지정되고 실행 가능한 경고를 사용하여 활성 안정성 오류를 표시합니다. 더 빠른 심사로 이어지는 신뢰할 수 있는 프로세스 및 인프라에 투자합니다.	사이트 안정성 엔지니어는 지속적인 라이브 사이트 인시 던트가 완화되고 실시간 인시던트가 되기 전에 예측 경고로 식별된 잠재적인 오류를 사전에 완화할 수 있도록 즉시 알림을 받을 수 있습니다.
프로덕션 및 사전 프로덕션 환경에서 오류를 시뮬레이션하고 테스트를 실행합니다.	복구에 대한 현실적인 기대치를 설정할 수 있도록 프로덕션에서 오류를 경험하는 것이 좋습니다. 이렇게 하면 오류에 정상적으로 대응하는 디자인을 선택할 수 있습니다. 또한 비즈니스 메트릭에 대해 설정한 임계값을 테스트할 수 있습니다.
자동화를 염두에 두고 구성 요소를 빌드하고 가능한 한 자동화합니다.	자동화 는 사용자 오류 가능성을 최소화하여 테스트, 배포 및 작업에 일관성 을 제공합니다.
일상적인 작업과 시스템의 안정성에 미치는 영향을 고려합니다.	워크로드에는 애플리케이션 수정, 보안 및 규정 준수 감사, 구성 요소 업그레이드 및 백업 프로세스와 같은 지속적인 작업이 적용될 수 있습니다. 이러한 변경 내용을 면밀히 조사하면 시스템의 안정성이 보장됩니다.
프로덕션의 인시던트에서 지속적으로 학습합니다.	인시던트에 따라 사전 프로덕션에서 눈에 띄지 않을 수 있는 설계 및 작업의 영향과 감독을 확인할 수 있습니다. 궁극적으로 실제 인시던트에 따라 개선 사항을 추진 할 수 있습니다.

단순하게 유지

아키텍처 디자인, 애플리케이션 코드 및 작업을 과도하게 사용하지 마세요.

가장 신뢰할 수 있는 솔루션으로 이어지는 추가 항목이 아니라 제거하는 경우가 많습니다. 단순성은 제어를 위한 노출 영역을 줄여 비효율성과 잠재적인 잘못된 구성 또는 예기치 않은 상호 작용을 최소화합니다. 반면에 지나치게 단순화하면 단일 실패 지점이 발생할 수 있습니다. 균형 잡힌 접근 방식을 유지합니다.

접근 방식	혜택
대상 비즈니스 값을 달성하는 데 도움이 되는 경우에만 구성 요소를 아키텍처에 추가합니다. 중요한 경로를 간결하게 유지합니다.	비즈니스 요구 사항을 설계하면 쉽게 구현하고 관리할 수 있는 간단한 솔루션이 될 수 있습니다. 각 구성 요소는 중요한 실패 지점이므로 너무 많은 중요한 구성 요소가 없으면 안 됩니다.
코드 구현, 배포 및 프로세스에서 표준을 설정하고 문서화합니다. 자동화된 유효성 검사를 사용하여 이러한 표준을 적용할 기회를 식별합니다.	표준은 일관성을 제공하고 사용자 오류를 최소화합니다. 표준 명명 규칙 및 코드 스타일 가이드와 같은 접근 방식을 사용하면 품질을 유지하고 문제 해결 중에 자산을 쉽게 식별할 수 있습니다.
이론적 접근 방식이 사용 사례에 적용되는 실용적인 디자인 으로 변환되는지 여부를 평가합니다.	너무 세분화된 애플리케이션 코드는 불필요한 상호 의존성, 추가 작업 및 어려운 유지 관리로 이어질 수 있습니다.
충분한 코드를 개발합니다.	예기치 않은 리소스 사용, 사용자 또는 데이터 흐름 오류 및 코드 버그와 같은 비효율적인 구현의 결과로 발생하는 문제를 방지할 수 있습니다. 반대로 안정성 문제로 인해 코드가 문제를 처리할 수 있을 만큼 복원력이 있는지 확인하기 위해 코드 검토가 이뤄져야 합니다.
비즈니스 목표를 효과적으로 충족하는 데 도움이 될 수 있는 플랫폼 제공 기능 및 미리 빌드된 자산을 활용합니다.	이 방법은 개발 시간을 최소화합니다. 또한 유사한 워크로드와 함께 사용된 시도되고 테스트된 사례에 의존 할 수 있습니다.

다음 단계

안정성 검사 목록