Mejores prácticas de flujo de trabajo sin servidor + cálculo de funciones para el procesamiento por lotes de archivos OSS masivos

Introducción de antecedentes

La interfaz simple de OSS y su excelente escalabilidad permiten que las aplicaciones en diferentes escenarios almacenen fácilmente entre miles y miles de millones de archivos de objetos por día. La estructura simple de acceso a datos de clave / valor simplifica enormemente la carga y lectura de datos. Sin embargo, además de cargar y leer, se generaron rápidamente una serie de nuevos escenarios de aplicación alrededor de OSS. Aquí hay algunos ejemplos:

• Copia masiva de archivos OSS (dentro o entre cubetas), cambie el tipo de almacenamiento (estándar-> archivo) para ahorrar costos
• Gran archivo OSS concurrente que se descongela (restaura) para restaurar el archivo de copia de seguridad para su uso
• El evento desencadena la descompresión de archivos muy grandes, paquetes comprimidos a nivel de GB, los archivos que contienen más de 100,000 niveles deben descomprimirse automáticamente en una nueva ruta OSS después de cargarlos

Los tres escenarios anteriores tienen algunos desafíos comunes:

1. Tiempo de procesamiento total prolongado : procesamiento de cientos de millones de archivos OSS Incluso con un alto acceso simultáneo a OSS, el tiempo total que se tarda es días o incluso más
2. Manejo de excepciones que puede ser causado por una gran cantidad de llamadas remotas : dado que la API OSS básicamente opera en un solo archivo, procesar de millones a decenas de millones de archivos significa un orden igual de llamadas remotas. En un sistema distribuido, estas fallas de llamadas remotas deben ser manejadas.
3. Persistencia de estado : se necesita un mecanismo similar a un punto de control para reducir todo el reprocesamiento en el caso de fallas parciales y evitar la pérdida de tiempo (como el procesamiento por lotes puede omitir los primeros 10 millones de claves que se han procesado).

En este artículo presentaremos una solución de mejores prácticas sin servidor basada en el flujo de trabajo sin servidor y la computación de funciones (FC) para los tres escenarios mencionados anteriormente.

Copia masiva de archivos OSS + archivo

La copia de seguridad de archivos OSS suena como una simple lista y copia del programa principal que se puede resolver, hay muchos problemas en la realidad que deben considerarse: por ejemplo, si la máquina está inactiva o el proceso sale anormalmente durante el programa principal, cómo ¿Recuperación (logrando alta disponibilidad usted mismo)? ¿Cómo procesar rápidamente los archivos que se han procesado después de la recuperación (escriba usted mismo el estado de mantenimiento de la base de datos)? ¿Cómo coordinar los procesos activos y en espera (implementando el descubrimiento del servicio usted mismo)? ¿Cómo acortar el tiempo de replicación? (Implemente la llamada y administración paralelas usted mismo) ¿Cómo elegir entre el costo de mantenimiento y el costo económico y la confiabilidad de la infraestructura? Frente a cientos de millones de objetos OSS, un simple programa principal de lista y copia de un solo subproceso no ha podido satisfacer de manera confiable tales necesidades.

Suponga que el usuario tiene cientos de millones de archivos OSS en un depósito que deben copiarse en diferentes depósitos en la misma región, y el tipo de almacenamiento estándar debe convertirse en almacenamiento de archivo. En este ejemplo oss-batch-copy , proporcionamos una plantilla de aplicación de flujo de trabajo para llamar a todas las funciones en el archivo de índice proporcionado por el usuario a su vez para calcular la operación OSS CopyObject para lograr la copia de seguridad. El archivo de índice contiene el meta del objeto OSS que debe procesarse. Los ejemplos son los siguientes:

archivo de índice también son cientos de millones de OSS cien nivel de GB, es necesario leer una página rango de lectura utilizando el archivo de índice, y cada archivo de procesamiento de parte OSS necesita un semejante while hasMore {}lógica de control para asegurar que todo el archivo de índice se procesa de principio a fin. La lógica de implementación del uso del flujo de trabajo sin servidor es la siguiente:

1. copy_files Pasos de la tarea: lea la longitud del archivo de entrada desde la posición del archivo de índice de entrada (desplazamiento), extraiga el archivo que se procesará a partir de él y llame a la función FC para llamar a OSS CopyObject
2. has_more_files Paso de selección: después de procesar con éxito un lote de archivos, determine si el archivo de índice actual se ha procesado por comparación de condiciones. En caso afirmativo, ingrese el paso exitoso. De lo contrario, transfiera la página siguiente (desplazamiento, tamaño) a copy_files para la ejecución del bucle.
3. start_sub_flow_executionPaso de la tarea: dado que la ejecución de un solo flujo de trabajo tiene un límite en el número de eventos del historial, el paso de selección también se juzgará en función de la ID del evento del flujo de trabajo actual. Si el número actual de eventos ha excedido un umbral, se activará un nuevo proceso idéntico Ejecución, el proceso continuará después del final del subproceso. Un subproceso también puede desencadenar sus subprocesos, de modo que las capas de recursión aseguran que, sin importar cuántos archivos OSS, se pueda procesar todo el proceso.

El uso del flujo de trabajo para implementar el procesamiento por lotes proporciona las siguientes garantías:

1. El tiempo de procesamiento individual puede ser de casi cualquier longitud, cualquier número de archivos : el flujo de trabajo admite hasta 1 año de ejecución
2. Sin operación y mantenimiento, sin necesidad de lograr una alta disponibilidad : el flujo de trabajo y el cálculo de funciones son servicios en la nube sin servidor de alta disponibilidad
3. No es necesario implementar una lógica como el punto de control y el mantenimiento del estado : si el proceso falla por algún motivo, puede comenzar de nuevo desde el desplazamiento exitoso más reciente. No es necesario utilizar ninguna base de datos o cola en este proceso.
4. Configuración de reintento de fallas : la configuración de retroceso exponencial puede manejar la mayoría de los errores de llamadas remotas transitorias.

Descongelación por lotes altamente concurrente de archivos OSS

El artículo presenta una solución para descongelar de manera eficiente y confiable una gran cantidad de archivos OSS basados ​​en el flujo de trabajo sin servidor y la alta descongelación por lotes concurrente de archivos OSS . Este escenario tiene desafíos similares a la copia de archivos, pero también tiene sus particularidades:

1. A diferencia de CopyObject, la operación de restauración es asíncrona, es decir, el estado del objeto debe sondearse después de activarse para garantizar que se complete la descongelación
2. El tiempo de descongelación de un solo objeto es del orden de minutos, que puede cambiar con el tamaño del objeto. Esto requiere una mayor concurrencia de todo el proceso para garantizar que la descongelación se complete dentro del tiempo especificado.

Lógica similar a oss-batch-copy, este ejemplo restaura OSS en lotes a través de ListObjects, donde cada lote de deshielo es un subproceso . Utilice un paso de bucle paralelo foreach en cada proceso para descongelar objetos OSS con alta concurrencia (hasta 100 concurrencias). Como la interfaz de restauración es una operación asincrónica, debe sondear el estado del objeto después de cada restauración hasta que se complete el deshielo. La descongelación y el sondeo se realizan en la misma rama concurrente.

Use la función de flujo de trabajo + para calcular las características de descongelación por lotes:

1. Naturalmente, admite el deshielo de alta concurrencia, acorta el tiempo total que consume
2. El sondeo con estado y confiable garantiza que todos los objetos se descongelen al final del proceso

Descompresión controlada por eventos de archivos OSS de gran tamaño

Una función importante de OSS es hacer un almacenamiento compartido de archivos, por ejemplo, una parte carga el contenido procesado para las aplicaciones posteriores. Dado que cargar múltiples archivos requiere llamar a la interfaz PutObject varias veces con una alta probabilidad de error y no es fácil de implementar, muchos servicios ascendentes usan paquetes comprimidos para completar la carga con una llamada de interfaz. Aunque esto simplifica el cargador, los usuarios intermedios desean ver la estructura original del archivo para el consumo. El requisito aquí es descomprimir automáticamente un paquete comprimido y almacenarlo en otra ruta OSS en respuesta a un evento de carga de archivos OSS. Hoy en día, ya hay una función en la consola que activa el cálculo de la función para realizar la descompresión. Sin embargo, la solución actual puramente basada en funciones tiene algunos problemas:

1. Límite de tiempo de ejecución de 10 minutos para una sola función : para paquetes comprimidos a nivel de GB, o escenarios donde hay una gran cantidad de archivos pequeños en el paquete comprimido, es fácil ejecutar el tiempo de espera y causar fallas de descompresión
2. Baja tolerancia a fallas : cálculo de la función de llamada asíncrona OSS, existe la posibilidad de una falla instantánea para acceder al OSS dentro de la función, la llamada asincrónica FC volverá a intentarlo como máximo 3 veces cuando la llamada de función falle, después de exceder el número de veces, el mensaje se descartará y la descompresión fallará.
3. Flexibilidad insuficiente : varios usuarios han propuesto que necesiten enviar notificaciones, mensajes de texto y eliminar paquetes comprimidos originales después de la descompresión, que no es fácil de implementar en función de una sola función.

Para resolver el problema de la ejecución prolongada y el reintento personalizado, presentamos el cálculo de la función de orquestación del flujo de trabajo sin servidor en esta aplicación de muestra . Después de calcular la función de activación de eventos OSS, se inicia la ejecución del flujo de trabajo. El flujo de trabajo se leerá, descomprimirá y cargará en la ruta de destino OSS a través de los metadatos del paquete ZIP. Después de que el tiempo de ejecución de cada función exceda un cierto umbral, se devuelve el marcador actual. El flujo de trabajo determinará si el marcador actual indica que se completó todo el procesamiento del archivo y, de ser así, finalizará la ejecución del proceso, de lo contrario, continuará la descompresión de flujo desde el marcador actual hasta el final.

La adición de flujo de trabajo rompe el límite de 10 minutos de llamadas a funciones y viene con administración de estado y reintentos personalizados. Incluso si es un tamaño de nivel GB, un paquete comprimido con archivos de 100,000 niveles puede descomprimirse de manera confiable. El flujo de trabajo admite hasta un año de ejecución, y casi cualquier paquete ZIP de cualquier tamaño también puede descomprimirse con éxito mediante transmisión.

El flujo de trabajo proporciona capacidades de personalización flexibles para el proceso de descompresión. La siguiente figura muestra a un usuario que notifica su cola MNS después de la descompresión. Una vez completada la notificación, el siguiente paso es eliminar el paquete comprimido original.

Comida para llevar

Se puede ver que la popularización a gran escala de OSS también ha traído una serie de problemas, pero la forma de resolver los problemas es engorrosa, aburrida y propensa a errores. En este artículo, presentamos el cálculo de la función y el flujo de trabajo sin servidor simple y liviano basado en tres escenarios comunes de copia de seguridad de archivos por lotes, descongelación simultánea grande y descompresión controlada por eventos de archivos ZIP grandes. La solución sin servidor resuelve de manera eficiente y confiable los siguientes problemas:

1. Admite procesos de larga duración, hasta un año de ejecución ininterrumpida
2. Mantenimiento del estado, no afectado por la conmutación por error del sistema
3. Mejora la tolerancia a errores transitorios
4. Personalización altamente flexible

Los escenarios masivos de procesamiento por lotes de archivos OSS son mucho más que los tres mencionados en el artículo. Esperamos más escenarios y requisitos. También damos la bienvenida a los estudiantes que estén interesados ​​en la ecología sin servidor, el flujo de trabajo y el cálculo de funciones para unirse al grupo de clavado interno.