프레임워크 적용 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

프레임워크 적용

복원력 분석 프레임워크를 적용하는 가장 좋은 방법은 장애패 범주별로 구성된 표준 질문 세트로 시작하여 분석 중인 사용자 스토리의 각 구성 요소에 대해 질문하는 것입니다. 워크로드의 모든 구성 요소에 일부 질문이 적용되지 않는 경우 가장 적합한 질문을 사용합니다.

다음 두 가지 관점에서 장애 모드에 대해 생각할 수 있습니다.

  • 장애가 사용자 스토리를 지원하는 구성 요소의 기능에 어떤 영향을 미치나요?

  • 장애가 다른 구성 요소와 구성 요소의 상호 작용에 어떤 영향을 미치나요?

예를 들어 데이터 저장소와 과도한 로드를 고려할 때 데이터베이스가 과도한 로드 상태이고 쿼리 제한 시간이 초과되는 장애 모드를 고려할 수 있습니다. 데이터베이스 클라이언트가 재시도로 데이터베이스를 압도하거나 데이터베이스 연결을 닫지 못하여 연결 풀이 소진될 수 있는 경우도 생각해 볼 수 있습니다. 또 다른 예는 인증 프로세스(여러 단계로 구성될 수 있음)가 있습니다. 다중 인증(MFA) 애플리케이션 또는 서드 파티 ID 제공업체(idP)의 장애가 이 인증 시스템의 사용자 스토리에 어떤 영향을 미칠 수 있는지 고려해야 합니다.

다음 질문에 답할 때 장애의 원인을 고려해야 합니다. 예를 들어 오버로드가 고객 급증 또는 유지 관리 활동 중에 너무 많은 노드를 서비스에서 해제한 인적 운영자에 의해 발생했나요? 각 질문에서 여러 장애 원인을 식별할 수 있으므로 다양한 완화 조치가 필요할 수 있습니다. 질문을 할 때 발견한 잠재적 장애 모드, 해당 장애가 적용되는 구성 요소, 각 장애의 원인을 기록해 둡니다.

단일 장애점

  • 구성 요소는 중복성을 위해 설계되었나요?

  • 구성 요소에서 장애가 발생하면 어떻게 되나요?

  • 애플리케이션이 단일 가용 영역의 부분 또는 전체 손실을 허용할 수 있나요?

과도한 지연 시간

  • 이 구성 요소에서 지연 시간이 증가하거나 상호 작용하는 구성 요소에서 지연 시간가 증가하면(또는 TCP 재설정과 같은 네트워크 중단) 어떻게 되나요?

  • 재시도 전략으로 제한 시간을 적절하게 구성했나요?

  • 빠른 실패인가요 아니면 느린 실패인가요? 빠르게 실패하기 때문에 장애가 발생한 리소스로 모든 트래픽을 실수로 전송하는 것과 같은 케스케이딩 효과가 있나요?

  • 이 구성 요소에 대해 비용이 가장 많이 드는 요청은 무엇인가요?

과도한 로드

  • 이 구성 요소를 압도할 수 있는 요소는 무엇인가요? 이 구성 요소가 다른 구성 요소를 어떻게 압도할 수 있나요?

  • 성공하지 못하는 작업에서 리소스 낭비를 방지하려면 어떻게 해야 하나요?

  • 구성 요소에 대해 구성된 회로 차단기가 있나요?

  • 무언가로 인해 심각한 수준의 백로그가 생성될 수 있나요?

  • 이 구성 요소는 어디에서 바이모달 동작을 경험할 수 있나요?

  • 어떤 제한 또는 서비스 할당량을 초과할 수 있나요(스토리지 용량 포함)?

  • 로드가 부과된 상태의 구성 요소는 어떻게 확장되나요?

잘못된 구성 및 버그

  • 잘못된 구성과 버그가 프로덕션에 배포되지 않도록 하려면 어떻게 해야 하나요?

  • 잘못된 배포를 자동으로 롤백하거나 업데이트 또는 변경 사항이 배포된 장애 컨테이너에서 트래픽을 이전할 수 있나요?

  • 운영자 오류를 방지하기 위해 어떤 가드레일이 마련되어 있나요?

  • 만료할 수 있는 항목(예: 자격 증명 또는 인증서)은 무엇인가요?

책임 공유

  • 장애 격리 경계는 어떠한가요?

  • 원박스 환경(결함 격리 경계 내 단일 인스턴스)과 같이, 배포 단위에 대한 변경 사항이 적어도 의도한 장애 격리 경계만큼 작지만, 이상적으로 더 작나요?

  • 이 구성 요소는 사용자 스토리 또는 다른 워크로드 사이에서 공유되나요?

  • 이 구성 요소에 긴밀하게 연결된 다른 구성 요소는 무엇인가요?

  • 이 구성 요소 또는 해당 종속성에 부분 또는 회색 장애가 발생하면 어떻게 되나요?

이러한 질문을 한 후 SEEMS를 사용하여 워크로드 및 각 구성 요소에 특정한 다른 질문을 개발할 수도 있습니다. SEEMS는 장애 모드에 대해 생각하는 체계적인 방법과 복원력 분석을 수행할 때 영감을 주는 소스로 가장 적합합니다. 이는 엄격한 분류가 아닙니다. 특정 장애 모드가 어떤 범주에 적합한지 걱정하는 데 시간을 할애하지 마세요. 이는 중요하지 않습니다. 중요한 것은 장애를 염두에 두고 기록한다는 점입니다. 잘못된 답변은 없습니다. 창의적이고 틀에 벗어난 사고가 좋습니다. 또한 장애 모드가 이미 완화되었다고 가정하지 말고 생각할 수 있는 모든 잠재적 장애 모드를 포함합니다.

첫 번째 연습에서 모든 잠재적 장애 모드를 예상할 가능성은 낮습니다. 프레임워크를 여러 번 반복하면 보다 완전한 모델을 생성하는 데 도움이 되므로 첫 번째 패스에서 모든 것을 시도하고 해결할 필요는 없습니다. 정기적으로(매주 또는 격주) 분석을 실행할 수 있습니다. 각 세션에서 특정 장애 모드 또는 구성 요소에 초점을 맞춥니다. 그러면 워크로드의 복원력을 개선하는 데 있어 안정적이고 점진적인 발전을 이룰 수 있습니다. 사용자 스토리에 대한 잠재적 장애 모드 목록을 수집한 후 이에 대해 수행할 작업을 결정할 수 있습니다.