[AWS] RDS로 데이터 삽입 삽질

RDS로 데이터 삽입하고 스테이징서버 구축하기

상황: 어떤 문제가 있었나?

부하테스트를 실제 서버와 같은 스펙에서 진행하기 위해 스테이징 서버와 K6서버 그리고 RDS를 구축해야 했다.

그 중 RDS에 어떻게 데이터를 삽입했는지에 대한 소개이다.
경매 데이터 130만 건을 csv 파일 기반으로 파싱해서 읽고 파이썬 코드가 1300만 건의 입찰과 2000만 건의 스크랩 데이터를 생성해서 삽입한다.

접근: 어떤 기술로 어떻게 해결했나? / 사고 과정 설명하기

예전 NCP에서는 앞에 퍼블릭 인스턴스를 두고 SSH 점프호스트를 사용해서 프라이빗에 접근했다.

지금은 EIC 엔드포인트가 생성되어 있어서 이것을 활용하면 SCP를 통해 데이터를 전송할 수 있지 않을까? 생각했다.

첫 번째 시도, scp를 통해서 csv 파일을 전송하고 Python으로 데이터를 생성하면서 삽입하기

소제목에 써진대로 진행했다.
csv파일은 약 80개 있었고, 전부 크기를 합치면 100MB 정도되었다.

해당 csv는 중고 플랫폼에서 실제 글이 어떻게 작성되었는지에 대한 정보를 가지고 있었다.
이 글을 기반으로 가상의 입찰, 스크랩, 검색 기록 등을 만드는 코드가 파이썬으로 작성되어 있었고,
나는 이 코드를 EC2에서 실행시켰다.

하지만 아래와 같은 상황이 발생했다.

❌ 배치 3 실패y: 1205 (HY000): Lock wait timeout exceeded; try restarting transaction "ip-10-0-2-220" 21:51 18-Jun-25 ❌ 배치 4 실패 : 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

이런 식으로 데이터 삽입이 실패하는 경우가 너무 많았다.

배치 크기가 너무 크거나 RDS의 MySQL 환경 세팅이 대용량 업데이트에 적합하지 않게 설정되어 있을 수도 있겠다는 생각을 했다.

그래서 다시 생각한 것은 python으로 생성하고 파싱한 데이터를 로컬 MySQL에 삽입한 다음 mysqldump를 사용해서 DB를 복제하는 것이었다.

두 번째 시도, mysqldump로 DB 복제하기

# 1. 로컬에서 덤프 생성
mysqldump -u username -p database_name > backup.sql

# 2. RDS로 복원
mysql -h your-rds-endpoint.amazonaws.com -u username -p database_name < backup.sql

dump 파일이 생각보다 많이 커서 gzip으로 압축해서 EC2로 업로드했다.
dump 파일이 대략 4.5GB를 차지했고, gzip으로 압축하니 300MB의 크기 정도로 압축되었다.
업로드 완료 후 압축해제하고 RDS에 업데이트를 시도했다.
(이 과정에서도 EC2 볼륨을 너무 작게 잡은 탓에 압축 실패 및 에러가 발생했었다. 볼륨 크기를 조심하자.)

이 작업 역시 오래 걸리는 작업이기에 tmux 를 활용해서 백그라운드로 동작하게 만들어 EC2 연결이 종료되어도 계속 작업이 진행할 수 있도록 설정했다.
(EIC로 SSH 터널을 생성해서 SSH 연결을 하면 최대 1시간의 제한이 있다.)

이 이후로 FK 제약조건 등으로 데이터 삽입해서 에러가 발생했다. 28분 동안 락이 걸리는 현상이 발생했다.

Query | 1694 | Waiting for table metadata lock | update auction a1_0 set status='active' where a1_0.status='pending' and a1_0.start_time<='2025-06-19 |

그래서 데이터 복원에 방해되는 설정을 비활성화했다.

SET foreign_key_checks = 0;
SET sql_log_bin = 0;
SET autocommit = 1;
SET unique_checks = 0;
SET sql_mode = '';

이후 데이터가 모두 삽입되면 설정을 원상복구했다.

SET foreign_key_checks = 1;
SET unique_checks = 1;
SET sql_log_bin = 1;

정리

# 압축 해제
cd /home/ubuntu
gunzip backup.sql.gz

# 해제된 파일 확인
ls -lh backup.sql

# RDS 연결 테스트 먼저
mysql -h db-palgoosam-staging-a.c9ao6gsuk007.ap-northeast-2.rds.amazonaws.com \
  -u palgoosam -p palgoosam -e "SELECT 1;"

tmux new-session -s mysql_restore

# 백업 파일을 RDS로 복원
mysql -h db-palgoosam-staging-a.c9ao6gsuk007.ap-northeast-2.rds.amazonaws.com \
  -u palgoosam -p palgoosam < backup.sql

# RDS 연결 상태 확인
mysql -h db-palgoosam-staging-a.c9ao6gsuk007.ap-northeast-2.rds.amazonaws.com \
  -u palgoosam -p palgoosam -e "SHOW PROCESSLIST;"

# Ctrl+B, 그다음 D 키 (세션 유지하고 나가기)

# 테이블 개수 확인 (복원 중에 증가하는지 확인)
mysql -h db-palgoosam-staging-a.c9ao6gsuk007.ap-northeast-2.rds.amazonaws.com \
  -u palgoosam -p palgoosam -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='palgoosam';"

# tmux 세션 다시 접속
tmux attach-session -t mysql_restore

# 또는 간단히
tmux a -t mysql_restore

배운 것: 새로 알게 된 것들

• EIC 엔드포인트를 활용해서 프라이빗 인스턴스로 SSH 연결하기
• MySQL의 제약조건이 대용량 데이터 삽입 시 30분 동안 락을 걸 수도 있음.
• tmux를 활용해서 오랜 시간이 소요되는 작업은 백그라운드로 관리하기
• gzip 압축률이 생각보다 높다는 것
  • 특히 EIC를 활용해서 SCP 프로토콜을 사용하니 속도가 정말 느렸다.
    수십 테라바이트의 크기라면 EIC를 활용할 수 없을지도 모른다는 생각을 했다.
• EC2 볼륨 크기는 압축 해제를 고려해서 여유롭게 설정해야 함

느낀 것: 이 경험에서 느낀 점

• 처음에는 편의를 위해 프라이빗 인스턴스를 잠깐 퍼블릭 인스턴스로 열어버릴까도 생각했지만AWS의 EIC 기능을 제대로 활용하면 보안과 편의성을 모두 확보할 수 있었다.
• 문제가 생겼을 때 근본적인 원인을 파악하고 해결해야지, 우회하려하지 말자.
• 대용량 데이터 삽입 시 네트워크 안정성이 중요함을 느꼈다.

아쉬운 것: 다음엔 이렇게 하겠다

• Lock이 왜 걸리는지는 파악을 하지 못했음.
  제약 조건의 어떤 것 때문에 이런 무한 대기 현상이 발생하는지 더 자세하게 알면 좋을 것 같음.