우리는 S3에 파일을 업로드하는 .NET 클라이언트 응용 프로그램이 있습니다. 버킷에 등록되어 Lambda가 파일을 처리하도록 트리거하는 이벤트 알림이 있습니다. 유지 관리가 필요한 경우 이벤트 통지를 제거하고 처리를 재개 할 준비가되었을 때 나중에 다시 추가하여 처리를 일시 중단합니다.람다 + 키네시스 비용 제어
이벤트 통지가 비활성화 된 기간 동안 S3에서 대기중인 파일의 백 로그를 처리하기 위해 S3 키가있는 키네시 스 스트림에 각 파일에 레코드를 쓰고 람다 각 운동 기록을 소비하십시오. 스트림의 조각 수를 제어하여 커다란 백 로그를 처리 할 때 동시성을 제어 할 수 있기 때문에 이것이 효과적입니다. 우리는 원래 SNS를 사용했지만 재 처리해야 할 파일이 수천 개에 달했을 때 SNS는 동시 실행 임계 값을 초과 할 때까지 Lambda를 계속 시작했습니다. 이것이 Kinesis로 전환 한 이유입니다.
우리가 지금 직면하고있는 문제는 키네 시스의 비용이 간신히 그것을 사용하더라도, 우리를 죽이고 있다는 것입니다. 분당 150 ~ 200 개의 파일이 업로드되며, 람다는 각 파일을 처리하는 데 약 15 초가 걸립니다. 몇 시간 동안 처리를 일시 중단하면 수천 개의 파일이 처리됩니다. 128 샤드 스트림을 사용하여 쉽게 재 처리 할 수 있지만, 한 달에 1,400 달러의 비용이 듭니다. 매달 우리 람다를 운영하기위한 현재 비용은 300 달러 미만입니다. 복구 시나리오에서 동시성 수준을 제어하기 위해서는 매출 원가를 400 % 증가시켜야합니다.
큰 크기의 백 로그를 다시 처리하기 전에 기본적으로 스트림 크기를 작게 유지 한 다음 크기를 조정할 수 있지만 1 개의 샤드에서 128까지 스트림의 크기를 조정하면 엄청난 시간이 걸릴 수 있습니다. 예기치 않은 정전 사태에서 복구를 시도한다면 우리는 스트림을 사용하기 전에 스트림 크기를 기다릴 필요가 없습니다. 그래서 내 질문은 :
사람은 큐를 배출 동시 람다의 수에 상한을 제어 할 수있는 대한 운동성 파편을 사용하는 대신 패턴을 추천 할 수 있습니까?
우리가 Kinesis를 더 효율적으로 사용할 수있게 해주는 뭔가가 빠졌습니까?