AWS Lambda(node.js 사용)에서 실행되는 "마이크로서비스"라고 부르는 것이 있습니다.
기본적으로 수백 메가바이트의 바이너리 blob에서 추출한 요약 요약을 제공합니다. 가능한 출력이 많고 모든 가능성을 미리 생성하는 것은 옵션이 아니며 매개변수를 허용하는 대화형 웹페이지에서 API 게이트웨이를 통해 액세스할 때 합리적으로 반응해야 합니다(최악의 경우 1초 미만). 빠르게 변화되길. 생성된 요약은 일반적으로 전체 데이터의 ~0.1-1%에만 액세스하지만 Blob의 액세스 패턴은 기본적으로 무작위입니다. 데이터 및 액세스 패턴은 데이터베이스에 데이터를 저장하는 것과 잘 호환되지 않습니다(아래 DynamoDB에 대한 언급 참조).
현재 접근 방식은 S3에서 큰 바이너리 blob을 호스팅하고 Lambda 핸들러가 Lambda 호출 사이에 로컬로 blob을 캐시하도록 하는 것입니다(javascript 코드의 버퍼와 마찬가지로 처리기 함수 외부 범위를 사용함). 분명히 Lambda의 메모리는 충분히 구성되어 있습니다. 크기가 큰). 핸들러 인스턴스는 일단 서버가 시작되어 실행되면 제대로 작동하고 응답성이 매우 높을 정도로 지속성이 있는 것 같습니다. 그러나 적어도 몇 가지 단점이 있습니다.
S3에서 데이터를 처음 가져오는 속도는 약 50-60MByte/s인 것 같습니다(내가 본 S3 대역폭에 대한 다른 보고서와 일치하는 것 같습니다). 따라서 첫 번째 액세스 시 몇 초의 지연이 발생할 수 있습니다.
이전 요점과 관련하여, 클라이언트가 매우 활동적이거나 사용자 로드가 증가하는 경우 더 많은 서버 인스턴스가 가동되고 사용자는 요청이 데이터 블롭을 가져올 때 중단된 인스턴스로 라우팅되어 성가신 결함이 발생할 수 있습니다. 그렇지 않으면 클라이언트가 원활하게 작동합니다.
나는 아마도 실제로 큰 덩어리의 상태(바이너리 blob)를 포함함으로써 "상태 비저장" 서비스를 의도한 것에서 너무 많은 것을 기대하고 있다는 것을 자유롭게 인정하지만, 어떤 조치를 취할 수 있는지 궁금합니다. 상황을 개선하십시오. 데이터는 특별히 압축 가능하지 않습니다. (1/3을 줄이는 것이 가능할 수도 있지만 이는 내가 찾고 있는 일종의 크기 순서가 아니거나 적어도 기껏해야 솔루션의 일부일 뿐입니다.) .
데이터를 Lambda로 더 빠르게 가져오는 방법에 대한 제안이 있으십니까? 내가 상상하는 종류는 다음과 같습니다.
Lambda의 대역폭이 훨씬 더 높은 다른 곳에서 데이터를 가져옵니다. 하지만 무엇을 해야 할까요? DynamoDB(필요한 만큼 400,000개의 바이너리 레코드로 분할)? 엘라스티캐시? AWS "메뉴"에서 내가 발견하지 못한 다른 것이 있습니다.
람다 인스턴스를 "미리 준비"하려면 몇 가지 교활한 트릭(무엇?)을 사용하십시오.
작업에 완전히 잘못된 도구를 사용하고 있습니다. 대신...을 사용하세요? (저는 Lambda 모델을 정말 좋아합니다. 인스턴스 프로비저닝 및 자동 확장에 대해 걱정할 필요 없이 기능에만 집중하세요.)
Google이나 Microsoft가 최근 발표한 Lambda와 유사한 제품(제가 아는 바는 거의 없음)에 이 사용 사례를 더 잘 지원하는 속성이 있다면 그것도 매우 흥미로운 정보가 될 것입니다.
내가 고려한 한 가지 옵션은 바이너리 데이터를 "배포 패키지"로 굽는 것이지만 이에 대한 250MByte 제한은 일부 예상 사용 사례에 비해 너무 낮습니다(BLOB이 압축된 경우에도).
답변1
바이너리 blob이 수백 메가바이트에 불과한 경우 함수에 "종속성"으로 포함하면 됩니다. 코드와 함께 파일로 추가하고 그에 따라 참조할 수 있습니다.
또 다른 옵션은 두 개의 람다 함수를 갖는 것입니다. 하나의 함수는 blob(함수와 함께 blob을 전송하여 위와 같이 생성)을 제공하는 것 외에는 아무것도 수행하지 않으며 타이머(기본적으로 cron)를 사용하여 매분마다 해당 기능을 "티클"하여 활성 상태를 유지할 수 있습니다. 그런 다음 두 번째 람다가 작업을 수행하고 시작 시 가장 먼저 수행하는 작업은 첫 번째 람다를 호출하여 얼룩을 가져오는 것입니다. 람다-람다 호출은 대역폭이 높으므로 시작 시간이 문제가 되지 않습니다.
이상적인 솔루션은 데이터를 요약하여 DynamoDB에 저장하는 방법을 찾는 것이지만, 해당 경로를 시도했지만 적합하지 않은 것 같습니다.