[22편] 서버 반복적 오류 해결

 

[Aura AI] 서버가 반복적으로 터진 이유와 전체 복구 과정 정리

(EC2 재생성, DB 재정비, GPT 안정화, CloudWatch 자동 복구 적용)

---

1️⃣ 장애 증상 요약

처음 발생한 증상은 단순 500 에러였습니다.
하지만 시간이 지날수록 서버 전체가 불안정해지는 문제가 반복되었습니다.

✔ 프론트엔드 증상

• /api/proxy/users/me → 500 에러
• 로그인 후 마이페이지 정보 로드 실패
• GPT 응답 생성 시
  → "응답을 생성하지 못했습니다." 반복

✔ 인프라 증상

• EC2 상태 검사 2/3 통과
• SSH 연결 간헐적 타임아웃
• 일정 시간이 지나면 서버가 다시 불안정해짐

즉,

프론트 → 백엔드 → DB → GPT 호출까지
전체 스택이 동시에 불안정한 상태였습니다.

---

2️⃣ 원인 분석 (복합 장애)

이번 장애는 단일 원인이 아니라, 여러 문제가 동시에 얽혀 있던 상황이었습니다.

---

2-1. EC2 인스턴스 상태 검사 2/3 문제

백엔드는 Amazon EC2 위에서 운영 중이었습니다.

상태 확인 결과:

• Status Check: 2/3
• Instance Status Check 실패

이로 인해:

• SSH 접속 불안정
• 서버 프로세스 간헐적 중단
• 일정 시간 후 다시 장애 발생

즉, 기존 인스턴스 자체가 이미 불안정한 상태였습니다.

---

2-2. DB 연결 실패

백엔드 로그에서 다음 오류가 반복 확인되었습니다.

ECONNREFUSED
Can't connect to MySQL server

원인:

• MySQL이 정상적으로 실행되지 않음
• bind-address 문제
• 포트 차단 가능성
• DB 초기화 미완료

---

2-3. DB 스키마 불일치

로그에서 다음 오류가 발견되었습니다.

Unknown column 'bio' in 'field list'

문제 상황:

• 코드에서는 bio, location, style_preference, profile_image 컬럼 사용
• 실제 DB에는 해당 컬럼이 존재하지 않음

결과적으로 /users/me 호출 시 500 에러 발생

---

2-4. GPT 호출 파라미터 오류

GPT 호출 시 다음 문제가 있었습니다.

• max_tokens 파라미터가 새 모델 정책과 호환되지 않음
• temperature 값 정책 불일치
• 일부 요청에서 응답이 빈 문자열로 내려오는 문제

결과:

• 400 에러 발생
• 응답 생성 실패 메시지 반복

---

3️⃣ 해결 과정 (실제 작업 순서)

---

3-1. 인스턴스 재생성

기존 EC2는 재사용하지 않기로 결정했습니다.

✔ 신규 인스턴스 생성

• t3.small 생성
• 기존 인스턴스는 폐기
• Elastic IP 재연결하여 IP 고정

→ IP 변경으로 인한 재발 방지

---

3-2. SSH 및 Git 환경 복구

✔ Host key mismatch 해결

~/.ssh/known_hosts 수정

✔ GitHub SSH 키 등록

• 새 인스턴스에 SSH 키 등록
• git clone 정상 완료

---

3-3. 백엔드 재설치 및 서비스 등록

✔ Python 가상환경 생성

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

✔ systemd 서비스 등록

sudo nano /etc/systemd/system/aura-api.service

등록 후:

sudo systemctl daemon-reload
sudo systemctl enable aura-api
sudo systemctl start aura-api

→ 서버 재부팅 시 자동 실행

---

3-4. MySQL 설치 및 초기화

✔ MySQL 설치

sudo apt install mysql-server
sudo systemctl start mysql

✔ DB 및 계정 생성

CREATE DATABASE aura_ai;
CREATE USER 'aura_user'@'%' IDENTIFIED BY '비밀번호';
GRANT ALL PRIVILEGES ON aura_ai.* TO 'aura_user'@'%';
FLUSH PRIVILEGES;

---

3-5. MySQL 외부 연결 허용

✔ bind-address 수정

bind-address = 0.0.0.0

✔ 방화벽 오픈

sudo ufw allow 3306/tcp

✔ EC2 보안 그룹에서도 3306 허용

---

3-6. DB 스키마 불일치 해결

부족한 컬럼을 직접 추가했습니다.

ALTER TABLE users ADD COLUMN bio TEXT NULL;
ALTER TABLE users ADD COLUMN location VARCHAR(255) NULL;
ALTER TABLE users ADD COLUMN style_preference VARCHAR(255) NULL;
ALTER TABLE users ADD COLUMN profile_image VARCHAR(255) NULL;

이후 /users/me 500 에러 해결 완료

---

4️⃣ 프론트 / 프록시 연결 안정화

프론트는 Vercel 에 배포되어 있었습니다.

✔ 환경변수 수정

BACKEND_API_BASE_URL=http://54.116.93.58:8000

✔ /api/proxy/* 연결 확인

• 실제 연결 URL 로그 출력 추가
• 프록시 디버깅 가능하도록 개선

---

5️⃣ GPT 응답 오류 해결

---

5-1. 파라미터 호환성 수정

• max_tokens → max_completion_tokens
• temperature 정책 범위에 맞게 조정

---

5-2. 빈 응답 안정화

로직 개선:

1. 응답이 빈 문자열이면 재시도
2. 재시도 후에도 실패 시 gpt-4o-mini fallback

→ 단일 실패가 전체 실패로 이어지지 않도록 개선

---

6️⃣ 토큰 사용량 제한 기능 추가

• 사용자별 일일 토큰 제한
• 과도한 요청 사전 차단
• 사용량 추적 DB 테이블 생성

(해당 내용은 별도 정리 글과 동일)

---

7️⃣ CloudWatch 기반 자동 복구 설정

문제가 며칠 후 다시 터질 가능성을 줄이기 위해
모니터링 + 자동 복구를 적용했습니다.

---

7-1. CloudWatch Agent 설치

Amazon CloudWatch Agent 설치

• 메모리
• 디스크 사용량

지표 수집 설정

---

7-2. 경보 생성

• 시스템 상태 검사 실패 시 경보 생성
• 인스턴스 경보는 콘솔 오류로 1차 실패 (추후 재시도 가능)

---

7-3. 자동 복구 활성화

경보 설정에서 복구 옵션 활성화

→ 시스템 상태 검사 실패 시 자동 복구 수행

즉,

서버가 터져도 자동으로 다시 살아나는 구조 구축

---

8️⃣ 최종 결과

✔ 인스턴스 안정화
✔ DB 연결 정상화
✔ /users/me 정상 반환
✔ GPT 응답 정상 동작
✔ CloudWatch 자동 복구 준비 완료

---

9️⃣ 핵심 요약

이번 장애는 단순 서버 다운이 아니라:

• EC2 인스턴스 불안정
• DB 스키마 불일치
• GPT 호출 파라미터 오류
• 인프라 설정 미정비

가 동시에 발생한 복합 장애였습니다.

저는:

1. 인스턴스를 재생성하고
2. DB와 코드 스키마를 정확히 맞추고
3. GPT 호출을 안정화하고
4. CloudWatch 자동 복구까지 적용하여

단순 복구가 아닌 재발 방지 구조까지 구축했습니다.

---