회로 차단기로 Lambda 함수에 복원력 추가

이 패턴은 굉장한circuitbreaker-lambda library

코드베이스 보기:
https://github.com/cdk-patterns/serverless/tree/master/the-lambda-circuit-breaker

복제하려면:

//TypeScript
npx cdkp init the-lambda-circuit-breaker
//Python
npx cdkp init the-lambda-circuit-breaker --lang=python

AWS Well-Architected 프레임워크는 다음의 장단점을 이해하는 데 도움이 됩니다.
AWS에서 시스템을 구축하는 동안 내리는 결정. 프레임워크를 사용하여 클라우드에서 안정적이고 안전하며 효율적이고 비용 효율적인 시스템을 설계하고 운영하기 위한 아키텍처 모범 사례를 배우게 됩니다. 모범 사례를 기준으로 아키텍처를 지속적으로 측정하고 개선이 필요한 영역을 식별할 수 있는 방법을 제공합니다.

우리는 잘 설계된 시스템을 갖추면 비즈니스 성공 가능성이 크게 높아진다고 믿습니다.

Serverless Lens Whitepaper

Well Architected Whitepaper

신뢰성의 기둥

참고 - 이 섹션의 내용은 Serverless Lens Whitepaper의 일부이며 약간의 조정이 있습니다.

reliability pillar에는 인프라 또는 서비스 중단으로부터 복구하고, 수요를 충족하기 위해 컴퓨팅 리소스를 동적으로 확보하고, 구성 오류 또는 일시적인 네트워크 문제와 같은 중단을 완화하는 시스템 기능이 포함됩니다.

REL 2: How are you building resiliency into your serverless application?

서버리스 및 비서버리스 리소스에 대한 확장 메커니즘을 평가하여 고객 요구 사항을 충족하고 종속성 전체에서 부분적 및 간헐적 장애를 견딜 수 있는 복원력을 구축합니다.

모범 사례:

1/트랜잭션, 부분 및 간헐적 오류 관리: 구성 요소의 부하가 높을 때 트랜잭션 오류가 발생할 수 있습니다. 일괄 처리 중에 부분적인 오류가 발생할 수 있지만 네트워크 또는 기타 일시적인 문제로 인해 간헐적인 오류가 발생할 수 있습니다.

이 패턴에는 무엇이 포함되어 있습니까?

이것은 DynamoDB를 사용하여 Lambda 함수가 호출하려는 웹 서비스가 지금 신뢰할 수 있는지 또는 사용해야 하는지 여부를 Lambda 함수에 알려주는 데 사용되는 사용자를 위해 데이터를 저장하고 검색하는 대신 간단한 웹 서비스 패턴만 구현한 것입니다. 폴백 기능.

이 동작을 시연하기 위해 Lambda 함수에는 실패를 시뮬레이션하는 몇 가지 논리가 있습니다. 아래 논리는 무작위로 실패합니다.

function unreliableFunction () {
  return new Promise((resolve, reject) => {
    if (Math.random() < 0.6) {
      resolve({ data: 'Success' })
      message = 'Success'
    } else {
      reject({ data: 'Failed' })
      message = 'Failed'
    }
  })
}

그런 다음 최근에 너무 많이 실패했을 때 대체 메커니즘으로 회로 차단기를 구성했습니다.

function fallbackFunction () {
  return new Promise((resolve, reject) => {
    resolve({ data: 'Expensive Fallback Successful' })
    message = 'Fallback'
  })
}

const options = {
  fallback: fallbackFunction,
  failureThreshold: 3,
  successThreshold: 2,
  timeout: 10000
}

exports.handler = async (event:any) => {
  const circuitBreaker = new CircuitBreaker(unreliableFunction, options)
  await circuitBreaker.fire()
  const response = {
    statusCode: 200,
    body: JSON.stringify({
      message: message
    })
  }
  return response
}

이 패턴을 사용하는 경우

외부 서비스와 통합하고 소비자에게 비용 효율적이고 탄력적인 서비스를 제공하려는 경우. 이 작업을 수행하지 않고 외부 서비스가 다운되면 전체 요청 시간 초과에 대한 람다 호출 비용을 지불하게 되고 소비자는 궁극적으로 실망스러운 경험을 기다립니다.

이 패턴을 테스트하는 방법

이 패턴을 배포한 후 브라우저에서 열면 다음 두 메시지 중 하나와 함께 JSON 페이로드를 다시 받는 API 게이트웨이에 대한 URL이 생깁니다.

// when the circuit is closed and the unreliable function worked
{
   "message": "Success"
}
// when the circuit is open
{
   "message": "Fallback"
}

따라서 브라우저를 몇 번 새로 고치면 메시지가 Fallback으로 전환되는 것을 볼 수 있습니다. 그런 다음 Lambda 함수에 대한 CloudWatch 로그를 열면 다시 눌렀을 때 회로 차단기가 상태를 변경하는 것을 볼 수 있어야 합니다.

다음과 같은 메시지가 표시됩니다.

정보 회로 차단기 상태: 열림

정보 회로 차단기 상태: HALF

정보 회로 차단기 상태: 닫힘

개방은 신뢰할 수 없는 기능에 대한 요청이 진행되지 않음을 의미하고, 절반은 신뢰할 수 없는 기능의 안정성을 테스트하기 위해 일부 요청을 허용함을 의미하며 폐쇄는 정상적으로 작동함을 의미합니다.