[Aura_AI] [8편] 서버가 반복적으로 터진 이유와 전체 복구 과정

 

[Aura_AI] [8편] 서버가 반복적으로 터진 이유와 전체 복구 과정

(EC2 재생성, DB 스키마 정합성 확보, GPT 오류 수정, CloudWatch 자동 복구 적용)

---

1️⃣ 문제 상황: 기능은 있는데, 서버가 버티지 못했다

배포 이후 일정 기간이 지나면서 이상 현상이 반복적으로 발생했습니다.

✔ /api/proxy/users/me → 500 에러

✔ 로그인 후 마이페이지 로딩 실패

✔ GPT 응답 생성 시 “응답을 생성하지 못했습니다.” 반복

✔ SSH 접속 간헐적 타임아웃

✔ EC2 상태 검사 2/3

특징은 이랬습니다.

고쳐놓으면 잠깐 정상 작동
며칠 뒤 다시 서버가 불안정해짐

단순 코드 문제가 아니라,
인프라 레벨 + DB + GPT 호출 문제가 동시에 얽힌 복합 장애였습니다.

---

2️⃣ 원인 분석

---

2-1. EC2 인스턴스 상태 불안정

백엔드는 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 에러 발생

이는 단순 서버 다운이 아니라
코드와 DB 구조가 맞지 않는 상태였습니다.

---

2-4. GPT 호출 파라미터 충돌

또 다른 문제는 GPT 호출 부분이었습니다.

• max_tokens 파라미터가 새 모델 정책과 충돌
• 일부 요청에서 400 에러 발생
• 응답이 빈 문자열로 내려오는 케이스 존재

즉,

서버, DB, GPT 호출 모두 동시에 불안정

---

3️⃣ 해결 전략: 부분 수리가 아닌 전체 재정비

이번에는 “고쳐 쓰기”가 아니라
구조를 다시 세우기로 결정했습니다.

---

3-1. EC2 인스턴스 재생성

기존 인스턴스는 폐기했습니다.

✔ 신규 t3.small 생성

✔ Elastic IP 재연결 (IP 고정)

이전에는 Stop/Start 시 IP가 변경되는 구조였습니다.
이번에는 Elastic IP를 적용해 재발 방지했습니다.

---

3-2. SSH 및 Git 환경 복구

✔ Host key mismatch 해결

~/.ssh/known_hosts 수정

✔ GitHub 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

✔ DB 및 계정 생성

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

---

외부 연결 허용

✔ bind-address 수정

bind-address = 0.0.0.0

✔ 방화벽 오픈

sudo ufw allow 3306/tcp

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

---

3-5. 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 정상 동작 확인

---

4️⃣ 프론트/프록시 연결 재정비

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

✔ 환경변수 수정

BACKEND_API_BASE_URL=http://<Elastic-IP>:8000

✔ /api/proxy/* 연결 로그 추가

→ 실제 연결 주소 디버깅 가능하도록 개선

---

5️⃣ GPT 오류 수정

---

✔ 파라미터 수정

• max_tokens → max_completion_tokens
• 정책에 맞는 temperature 값 적용

---

✔ 빈 응답 안정화

1️⃣ 동일 모델 재시도
2️⃣ 재시도 실패 시 fallback 모델 적용

→ 단일 API 실패가 전체 실패로 이어지지 않도록 설계

---

6️⃣ CloudWatch 자동 복구 적용

며칠 뒤 다시 터지는 문제를 줄이기 위해
모니터링 + 자동 복구 구조를 추가했습니다.

---

6-1. CloudWatch Agent 설치

Amazon CloudWatch Agent 설치 후:

• 메모리
• 디스크 사용량

지표 수집

---

6-2. 상태 검사 경보 생성

• 시스템 상태 검사 실패 시 경보
• 복구 옵션 활성화

---

6-3. 자동 복구 설정

경보 설정에서 “복구” 체크

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

즉,

서버가 터져도 자동으로 다시 올라오는 구조 확보

---

7️⃣ 최종 결과

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

---

8️⃣ 이번 경험에서 배운 점

이번 장애는 단순한 버그가 아니었습니다.

• 인프라 불안정
• DB 구조 불일치
• 외부 API 정책 변경
• 환경 설정 누락

이 모두가 겹친 복합 문제였습니다.

하지만 이를 통해:

✔ 인스턴스 레벨 복구 경험

✔ DB 스키마 정합성 관리 중요성 체감

✔ 외부 API 의존성 관리 필요성 학습

✔ 자동 복구 기반 운영 구조 구축

단순 “기능 구현자”가 아니라
운영 가능한 시스템을 설계하는 경험을 할 수 있었습니다.

---