Soluções para Problemas Práticos Pós-Implantação em Infraestrutura PaaS Serverless
TuBrief 편집팀
2026년 7월 24일
0
Internet Technology원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Uma PaaS all-in-one que permite implantar o frontend e o backend com apenas alguns cliques parece perfeita no início. O problema surge quando os usuários reais começam a entrar. O código que rodava perfeitamente no ambiente local começa a disparar timeouts em produção, e tentar alterar um único esquema do banco de dados pode deixar todo o serviço fora do ar. Além disso, ficar preso ao fornecedor (vendor lock-in) sem poder fazer nada gera uma enorme dor de cabeça.
Aqui estão alguns padrões de infraestrutura organizados para aproveitar a conveniência dessas plataformas e, ao mesmo tempo, eliminar os obstáculos que vêm junto com elas.
O processo do Node.js local permanece continuamente em execução, mas o ambiente serverless é ativado brevemente apenas quando chega uma requisição e depois desaparece. Se você gerenciar variáveis globais ou conexões singleton de banco de dados de forma descuidada durante um cold start, o pool de conexões será esgotado rapidamente.
Não dá para ficar verificando isso fazendo implantações no servidor de staging a todo momento. É muito mais rápido simular a própria camada de rede no ambiente local e executar os handlers.
`typescript
// src/mocks/handlers.ts
import { http, HttpResponse } from 'msw';
export const handlers = [
http.get('/api/v1/user/profile', ({ request }) => {
const authHeader = request.headers.get('Authorization');
if (!authHeader) {
return new HttpResponse(null, { status: 401, statusText: 'Unauthorized' });
}
return HttpResponse.json({
id: 'usr_102938',
email: 'dev@example.com',
role: 'ADMIN',
createdAt: new Date().toISOString()
});
})
];
// src/mocks/node.ts
import { setupServer } from 'msw/node';
import { handlers } from './handlers';
export const server = setupServer(...handlers);
`
O processo para aplicar esse padrão é simples:
setupServer..env.local do endpoint do pooler de transações de produção.Você pode validar o comportamento da interface do backend no ambiente local com 100% de precisão sem precisar apertar o botão de deploy. Trata-se de uma estrutura que elimina o tempo desperdiçado com testes remotos instáveis e fornece feedback imediato assim que o código é escrito.
Ao usar um PostgreSQL serverless como o Supabase ou o Neon, executar um simples comando ALTER TABLE é perigoso. Um lock ACCESS EXCLUSIVE é aplicado na tabela de destino, fazendo com que as consultas subsequentes entrem em fila de espera, o que eventualmente resulta em falhas por timeout.
Em primeiro lugar, é necessário definir limites de timeout para a sessão de migração.
`sql
SET lock_timeout = '2000ms';
SET statement_timeout = '5000ms';
ALTER TABLE users ADD COLUMN bio VARCHAR(255);
`
Para alterar a estrutura de um banco de dados em operação com segurança, você deve usar uma abordagem onde o código e o banco de dados são expandidos simultaneamente e, em seguida, o que é antigo é removido gradualmente.
`typescript
import { db } from './db';
interface UpdateUserProfileInput {
userId: string;
fullName: string;
}
export async function updateUserProfile({ userId, fullName }: UpdateUserProfileInput) {
await db.transaction(async (tx) => {
await tx.user.update({
where: { id: userId },
data: {
full_name: fullName,
name: fullName
}
});
});
}
`
Estes são os três passos para uma operação segura:
lock_timeout para criar uma trava de segurança que interrompe a operação imediatamente caso haja disputa por lock.Seguindo este procedimento, é possível substituir o esquema sem perder uma única requisição de usuário.
No ambiente serverless, se você deixar apenas instruções console.log, os logs de várias instâncias se misturarão, criando uma grande bagunça. Para rastrear o fluxo desde a entrada até a saída de uma requisição, um ID de requisição (Request ID) exclusivo e o formato JSON estruturado são essenciais.
`typescript
import { Hono } from 'hono';
import { requestId } from 'hono/request-id';
import pino from 'pino';
const logger = pino({
level: process.env.LOG_LEVEL || 'info',
formatters: {
level: (label) => ({ level: label.toUpperCase() })
},
base: { env: process.env.NODE_ENV }
});
const app = new Hono();
app.use('', requestId());
app.use('', async (c, next) => {
const reqId = c.var.requestId;
const startTime = performance.now();
c.set('logger', logger.child({ reqId }));
await next();
const durationMs = Math.round(performance.now() - startTime);
logger.info({
reqId,
method: c.req.method,
path: c.req.path,
status: c.res.status,
durationMs
}, 'Request processing finished');
});
`
Aqui está a configuração para evitar cobranças excessivas ao usar ferramentas de monitoramento externas:
Server-Timing nos cabeçalhos de resposta para enviar os pontos de gargalo ao sistema de monitoramento.`typescript
import * as Sentry from '@sentry/node';
Sentry.init({
dsn: process.env.SENTRY_DSN,
tracesSampleRate: 0.1,
beforeSend(event, hint) {
const error = hint.originalException;
if (error && error instanceof Error && error.message.includes('ECONNRESET')) {
return null;
}
return event;
}
});
`
Apenas filtrando logs sem sentido de 200 OK e exceções irrelevantes, você já consegue gerenciar perfeitamente o sistema dentro dos limites do plano gratuito das plataformas de monitoramento.
Se você acoplar o SDK exclusivo de uma PaaS diretamente à sua lógica de negócios, terá que reescrever todo o código quando decidir mudar de plataforma no futuro. Esse é o motivo de usar o Padrão Adapter (Adapter Pattern) sintetizado por Martin Fowler para separar o ponto de contato entre a lógica principal da aplicação e o SDK da nuvem externa.
`typescript
export interface IStorageService {
uploadFile(path: string, fileBuffer: Buffer, mimeType: string): Promise<{ url: string }>;
deleteFile(path: string): Promise;
}
import { S3Client, PutObjectCommand, DeleteObjectCommand } from '@aws-sdk/client-s3';
export class S3StorageAdapter implements IStorageService {
private s3: S3Client;
private bucket: string;
constructor(region: string, bucket: string) {
this.s3 = new S3Client({ region });
this.bucket = bucket;
}
async uploadFile(path: string, fileBuffer: Buffer, mimeType: string): Promise<{ url: string }> {
await this.s3.send(new PutObjectCommand({
Bucket: this.bucket,
Key: path,
Body: fileBuffer,
ContentType: mimeType
}));
return { url: https://${this.bucket}.s3.amazonaws.com/${path} };
}
async deleteFile(path: string): Promise {
await this.s3.send(new DeleteObjectCommand({ Bucket: this.bucket, Key: path }));
}
}
`
Automação do backup de dados para que você possa migrar a qualquer momento:
`bash
#!/usr/bin/env bash
set -euo pipefail
TIMESTAMP=(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/tmp/db_backup_{TIMESTAMP}"
S3_BUCKET="s3://my-app-exit-backups/pg_dumps"
export PGPASSWORD="${DB_PASSWORD}"
mkdir -p "${BACKUP_DIR}"
pg_dump -h "{DB_PORT}" -U "{DB_NAME}"
-Fc --exclude-table-data='logs_*' > "${BACKUP_DIR}/full_schema_data.dump"
tar -czvf "{BACKUP_DIR}" .
aws s3 cp "{S3_BUCKET}/{R2_ENDPOINT_URL}"
rm -rf "{BACKUP_DIR}.tar.gz"
`
pg_dump para extrair o esquema e os dados.crontab para enviar os arquivos de backup para um bucket do Cloudflare R2 ou S3 externo.Reduzir o risco de ficar preso a uma plataforma específica torna muito mais fácil lidar com aumentos de custos de infraestrutura ou falhas na plataforma.