카테고리 없음

[26WKRD2] Aurora MySQL에서 Lambda 함수 사용하기

CloudBackend 2026. 4. 5. 23:53

Image by Amazon Web Services

개요

Aurora MySQL과 AWS Lambda를 함께 사용하면, 데이터베이스 내부 로직을 애플리케이션 서버 밖으로 분리하면서도 이벤트 기반으로 유연하게 확장할 수 있습니다. 특히 저장 프로시저나 배치 작업으로 처리하던 일부 업무를 Lambda 함수로 넘기면, 외부 API 호출, 비동기 후처리, 알림 발송, 데이터 변환 같은 작업을 더 현대적인 방식으로 구성할 수 있습니다. 이 글에서는 Aurora MySQL 환경에서 Lambda 함수를 어떻게 연동할 수 있는지, 어떤 상황에서 유용한지, 그리고 기본적인 동작 흐름을 중심으로 간단히 살펴봅니다.

 

또한 실제 구성 시 함께 고려해야 할 IAM 권한, 네트워크 연결, 호출 방식, 성능 및 운영상의 주의점도 짚어볼 예정입니다. 단순히 "연결하는 방법"에 그치지 않고, Aurora MySQL과 Lambda 조합이 어떤 아키텍처적 장점을 주는지까지 이해할 수 있도록 전체 그림을 짧고 명확하게 정리하는 것을 목표로 합니다.

0. 기본 세팅 및 리소스 셋업

실습 시 <이 레포>를 사용하니 클론받아 준비해두기 바랍니다.

 

Database와 Lambda를 배포하기 위해 VPC와 Subnet, SG, IAM Role 등을 생성합니다. 

먼저, VPC를 구성해봅시다. 필자는 아래와 같이 구성하였습니다

 

이후, VPC Endpoint와 Security Group을 한번에 생성해준다.

만약 필요하다면, create_endpoint.sh의 services 부분에 추가적으로 필요한 것을 추가할 수 있도록 하자.

curl https://gist.githubusercontent.com/ninejuan/7431cff155d42ef56fd4d86454eb8316/raw/adc1bdbbd605f57af3d40d76f0cc8f801038ce78/0_create_aurora_lambda_network.sh > 0_create_aurora_lambda_network.sh
chmod +x 0_create_aurora_lambda_network.sh
./0_create_aurora_lambda_network.sh aurfunc-vpc

 

마지막으로, 아래 명령어를 통해 IAM Role을 생성하겠습니다.

curl https://gist.githubusercontent.com/ninejuan/fda56ee47c9636e7a807966a7b3614d8/raw/825bc29531c11f494e98efbf1227f9cbae95634e/1_create_iam_roles.sh > 1_create_iam_roles.sh
chmod +x 1_create_iam_roles.sh
./1_create_iam_roles.sh aurfunc-vpc

1. Database Provisioning

이제 Aurora RDS 클러스터를 생성해보겠습니다.

먼저 서브넷 그룹과 파라미터 그룹을 아래 스크린샷을 예시로 삼아 생성합니다.

 

이제, Aurora DB를 생성해봅시다.

MySQL Compatible Aurora를 선택하고, 아래와 같이 잘 구성합니다.

 

필자의 경우 Aurora Serverless v2로 설정하였으나, 여러분들의 상황에 맞게 적절히 선택하시기 바랍니다.

 

이후, 설정 값의 속성을 채워넣습니다.

 

아래 내용도 적절히 선택합니다.

 

연결 파트에서는 앞서 생성한 VPC와 서브넷 그룹을 선택해준 후, 퍼블릭 액세스 비활성화, SG 설정 등을 진행합니다.

 

이후, 모니터링 관련 설정을 진행해주고, 초기 DB 이름과 클러스터/인스턴스 파라미터 그룹을 선택합니다.

 

이 외의 값은 여러분들이 임의로 설정한 후 생성합니다. 

 

생성이 잘 되었습니다.

 

이제 Aurora에서 Lambda 호출을 위해 파라미터 그룹을 수정해준 후, Writer 인스턴스를 재부팅하겠습니다.

클러스터의 aws_default_lambda_role 파라미터를 찾아 arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME> 형식으로 수정 후, 이를 저장합니다. 그 후, activate_all_roles_on_login 파라미터 또한 1로 변경합니다.

(수정 전)

(수정 후)

2. Target Lambda 함수 생성하기

필자의 경우, 회원 가입 시 Lambda를 통해 이메일이 차단된 이메일 리스트에 있는지 조회하는 예제를 실습해보겠습니다.

클론받은 레포의 examples/3_sync_validation_before_insert를 참고합니다.

 

Lambda로 이동하여 함수 생성을 선택합니다. 역할의 경우 사전에 생성한 LambdaRole을 선택합니다.

 

함수 URL, VPC 옵션의 경우 단순 Validation 작업이므로 지정하지 않았습니다.

 

함수가 생성되면, 아래와 같이 lambda_function.py를 우리의 코드로 대체합니다.

 

이후, example.sql의 Lambda 함수 ARN을 우리의 것을 대체합니다.

 

이후, 아래 skills db에서 SQL 쿼리를 각각 실행합니다.

- 0.sql; admin user에 Lambda access 권한 부여

GRANT AWS_LAMBDA_ACCESS TO 'admin'@'%';
SET ROLE AWS_LAMBDA_ACCESS;

 

- 1.sql; table 생성

CREATE TABLE IF NOT EXISTS user_signups (
  id BIGINT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

 

- 2.sql; Trigger 생성

DROP TRIGGER IF EXISTS trg_user_signups_before_insert;

DELIMITER $$

CREATE TRIGGER trg_user_signups_before_insert
BEFORE INSERT ON user_signups
FOR EACH ROW
BEGIN
  SET @resp = lambda_sync(
    'arn:aws:lambda:ap-northeast-2:156041424727:function:sync-validation-before-insert',
    JSON_OBJECT(
      'event', 'signup_validate',
      'email', NEW.email
    )
  );

  SET @allow = JSON_UNQUOTE(JSON_EXTRACT(CAST(@resp AS JSON), '$.allow'));

  IF @allow <> 'true' THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Signup blocked by Lambda validator';
  END IF;
END$$

DELIMITER ;

 

- 3.sql; (테스트) 데이터 생성 1

INSERT INTO user_signups (id, email) VALUES (3001, 'user@example.com');

 

- 4.sql; (테스트) 데이터 생성 2

INSERT INTO user_signups (id, email) VALUES (3002, 'user@tempmail.com');

 

3번 쿼리는 정상 통과되어야 하며, 4번 쿼리는 아래와 같이 에러가 발생해야 합니다.

Troubleshooting

- ERROR 63987 (HY000) at line 1: Lambda API returned error: Missing designated IAM role (aws_default_lambda_role)

RDS Parameter Group에서 IAM Role 세팅이 되지 않았거나, or 클러스터에 Role이 연결되지 않음. 또는 Role 잘못됨.

 

- 만약 제대로 안 먹는 것 같을 때.

SELECT lambda_sync 문 실행 시간과 insert 등 테스트 쿼리 진행 시간을 비교. 그리고 파라미터 제대로 설정했는지 확인.

 

마치며

물론 이런 구성이 만능은 아닙니다. 실제로 붙여보면 권한 설정 하나만 어긋나도 바로 에러가 나고, 네트워크나 호출 지연 같은 부분도 생각보다 신경 쓸 게 많습니다. 그래도 DB 안에 로직을 계속 우겨 넣기보다, 필요한 작업만 Lambda로 빼서 다루면 구조가 훨씬 깔끔해지고 나중에 손보기도 편해집니다.

결국 Aurora MySQL과 Lambda를 함께 쓰는 방식은 “DB에서 이벤트를 감지하고, 필요한 처리는 바깥에서 유연하게 한다”는 흐름으로 이해하면 됩니다. 처음엔 조금 번거로워 보여도 한 번 구조를 잡아두면 검증, 알림, 후처리 같은 작업을 훨씬 다루기 쉬워지니, 비슷한 요구사항이 있는 분들이라면 한 번쯤 직접 붙여보면서 감을 잡아보셔도 좋겠습니다.

참고 문서

[1] https://ninejuan.tistory.com/entry/26WKRD2-Lambda%EC%97%90-%ED%8C%A8%ED%82%A4%EC%A7%80-%EC%B6%94%EA%B0%80%ED%95%98%EB%8A%94-%EB%B2%95-Lambda-Layer

[2] 라이언권의 팁 - 근데 중요한건 sync랑 async에 따른 용례가 있는데 sync 잘못쓰면 DB 락걸린상태로 뒤지니까 조심하셔야합니다.