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

프레임워크 적용

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

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

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

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

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

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

단일 장애점

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

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

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

과도한 지연 시간

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

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

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

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

과도한 로드

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

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

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

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

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

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

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

잘못된 구성 및 버그

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

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

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

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

책임 공유

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

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

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

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

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

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

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