삽질 교훈 후기 - Aurora Database Activity Stream

[주의]
이 후기는 구축의 기술적인 내용을 거의 담고있지 않습니다.
주말 삽질의 레슨런들을 남겨두고 싶어서 적는 글입니다.

[배경]
기존에 AWS RDS LOG를 보안 분석에 활용하기 위해 Cloudwatch -> S3 -> Lambda 흐름을 사용하고 있는데, Aurora Database Activity Stream을 활용하는 경우 어떤 기대효과가 있을지 살펴보고 싶었다.

해당 기술에 대한 소개는 아래 링크를 참고해보자.

[소개 블로그]
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/DBActivityStreams.html

[코드 샘플]
https://github.com/aws-samples/aurora-das-processing

[겪었던 일들]

1. 분명 블로그에 있는 해당 기능을 지원하는 타입이면 콘솔에서 Action에 활성화 메뉴가 있다고 했는데 아무리 봐도 메뉴가 보이지 않았다.
   리전도, 인스턴스 타입도, 다른 것들도 아무 이슈가 없었지만 기능이 보이지 않았고, CLI로는 아무 이슈없이 활성화되었기에 버그가 아닐까 생각한다.

2. 람다 코드 중에 AWS Encryption SDK가 필요한데, MAC에서 개발하던 패키지 그대로 올리면 동작하지 않는다.
   SAM 배포를 사용하거나, Amazon Linux 환경에서 패키징하는게 필요하다.
   나는 CloudShell에서 처리했다.

3. AWS 공식 깃헙 가이드에는 패키지 버전이 안나와있는데, 버전 명시하지않고 설치하면,
   별의 별 오류를 다 보게 된다.
   테스트 해 본 경험으로는 Python 3.13에서는 이것저것 이슈가 많이 생겨서 Python 3.11로 내려서 진행하는게 좋았고, 또 지나치게 최신 패키지 쓰면 GLIBC 2.28을 요구하는데, Amazon Linux2 기반인 Lambda 환경은 GLIBC 2.26 환경이어서 여기 맞춰서 패키지 버전 조정이 필요한 경우가 있었다.

4. 혹시나 바이브 코딩을 생각한다면, 적어도 이 글을 작성하는 시점에는 AWS 샘플 코드 보고 내 손으로 작성하는게 좋았다. 커서로 작업하고 GPT로 중간중간 보정했는데, 바이브 코딩이 인기 없는 작업(이라고 쓰고 학습 경험이 적은 작업)에서는 아주 끝없는 오류 덩어리 코드를 뿜어내는 경우가 많고, 이 경우도 그러했다.
   없는 파라미터도 창의적으로 몇개씩 만들어내는 바람에 버그 잡느라 고생한 나 자신.

5. 물론 그럴 일이 거의 없었지만 스트림 사이즈가 커지면 토큰 소모량이 엄청나게 되는 경우가 생겨서 토큰 사이즈에 제약을 주는 구현이 반드시 필요했다.

[의도했던 아키텍처]
Aurora MySQL Database Activty Stream -> Kinesis -> Firehose -> S3 -> SNS -> Lambda 이벤트 트리거의 흐름으로 로그를 Bedrock으로 평가해서 위험도나 이슈 체크

나중에 든 생각이지만, 분석이 메인이라면 Firehose에서 바로 API GATEWAY를 만들어서 던지고, 로깅이 필요하다면 S3에는 백업 기능으로 남기는 것도 좋은 구성이지 않았을까 하는 생각이 들었다.

후자처럼 구성했다면 S3의 이벤트 트리거를 받고, S3에서 파일 오브젝트를 일일이 읽는 작업에 대한 개선이 가능하지 않았을까 생각해본다.

[고민과 생각들]
로그 양이 적은 곳이면 모르겠지만, 로그 양이 많은 경우 해당 스트림을 S3에 넣고 모두 람다에 던지는게 좋은 아키텍처일까하는 고민이 들었다.
기존 방식은 적재되는 로그를 필터링할 수 있는데 스트림은 일단 모든게 쌓이기때문에 모니터링 용도로 쓰기에는 처리량이 지나치게 커질 수 있었다.
R계열 특정 타입에서만 쓸 수 있다는 제약사항도 이슈가 되었고, 적어도 내가 생각하는 의도에는 기존 방식 대비 특별한 장점이 있다고 보기 어려웠다.