Issue 1. EC2 스토리지 부족으로 인한 배포 중단 및 인스턴스 업그레이드
문제 상황 (Symptom)
- 새로운 기능을 구현하고 ECR(Elastic Container Registry)에서 최신 도커 이미지를 받아 배포하려 했으나, "No space left on device" 에러와 함께 배포가 무한 실패함.
- EC2 쉘(Shell)에 접속해
df -h와docker images를 확인한 결과, AI 모델이 포함된 도커 이미지 용량이 너무 커서 남은 용량이 거의 없었음.
원인 분석 (Cause)
- AI 이미지의 비대화: Python AI 서버 이미지가 딥러닝 라이브러리와 모델 파일을 포함하면서 수 GB 단위로 커짐.
- 인스턴스 자원 한계: 기존
t3.micro인스턴스는 디스크 용량뿐만 아니라 메모리(1GB)도 부족하여, 무거운 도커 이미지를 압축 해제하고 실행하는 과정을 버티지 못함.
해결 방법 (Solution)
- 인스턴스 타입 업그레이드: CPU와 메모리 사양을 높이기 위해 인스턴스를
t3.micro에서t3.small로 스케일 업(Scale-up)함. - 도커 환경 정리:
docker system prune -a명령어를 통해 사용하지 않는 오래된 이미지와 컨테이너를 삭제하여 가용 공간을 확보함. - EBS 볼륨 최적화: 인스턴스 타입 변경과 함께 루트 볼륨(EBS) 크기를 증설하여 향후 이미지 업데이트에 대비함.
Issue 2. AI 퀴즈 생성 데이터의 DB 저장 정합성 오류
문제 상황 (Symptom)
- Python AI 서버에서 퀴즈 생성 로직은 정상적으로 동작하여 응답을 보내주지만, Spring Boot 서버에서 이를 받아 DB(
Content,Question테이블 등)에 저장할 때 데이터가 누락되거나 저장되지 않는 현상 발생.
원인 분석 (Cause)
- API 데이터 정합성 불일치: Python 서버가 보내주는 JSON 필드 구조와 Spring Boot의 DTO 구조가 미세하게 달러 역직렬화(Deserialization) 과정에서 데이터가 유실됨.
- 트랜잭션 관리 실패: 퀴즈 생성 요청은 성공했으나, 연관된 여러 테이블(Step -> Content -> Choice)에 데이터를 넣는 과정에서 하나라도 실패할 경우 전체가 롤백(Rollback)되어야 하는데, 이 처리가 미흡하여 데이터가 꼬임.
- 영속성 컨텍스트 이슈: 부모 엔티티가 저장되기 전에 자식 엔티티를 저장하려다 외래 키(FK) 제약 조건 위반이 발생함.
해결 방법 (Solution)
- DTO 및 검증 로직 강화: Python 서버와의 규약을 재정의하고,
@Valid를 통해 들어오는 데이터의 정합성을 최우선으로 검증함. - Cascade 옵션 및 연관관계 편의 메서드 활용:
JPA CascadeType.ALL설정을 통해 부모 엔티티(Step) 저장 시 자식 엔티티들이 한 번에 안전하게 저장되도록 구조를 개선함. - 트랜잭션 원자성 확보: 퀴즈 저장 서비스 로직에
@Transactional을 적용하여 전체 프로세스가 "All or Nothing"으로 동작하게 하여 데이터 무결성을 보장함.
회고를 마치며
"인프라는 한 번 구축하면 끝나는 것이 아니라, 서비스 규모와 데이터 크기에 따라 지속적으로 모니터링하고 스케일링해야 한다는 것을 배웠습니다. 또한, 서로 다른 언어(Spring-Python)로 구성된 서버 간 통신에서는 데이터 정합성을 맞추는 것이 시스템 안정성의 핵심임을 깨달았습니다...어렵다 ㅠㅠㅠ"
