MySQL 운영 개요¶
운영 서버(Production Server) 에서 MySQL을 안정적으로 운영하기 위한 운영 기준과 구조적 원칙을 정의함.
설치 명령이나 설정 값을 나열하지 않음.
왜 이렇게 운영해야 하는가”에 대한 기준 문서임.
1. MySQL의 운영상 위치¶
운영 환경에서 MySQL은 다음 역할을 가짐.
- 서비스의 유일한 데이터 저장소
- 애플리케이션 상태의 영구 보존 책임
- 장애 발생 시 복구의 기준점
즉,
운영 환경에서 MySQL은 모든 애플리케이션보다 하위에 위치하는 핵심 인프라 컴포넌트임
MySQL의 안정성은
상위 계층(Node.js, Laravel, Lumen 등)의 안정성을 직접적으로 좌우함.
2. 개발 환경과 운영 환경은 완전히 다름¶
MySQL 역시 개발 환경과 운영 환경의 성격은 명확히 다름.
개발 환경¶
- 로컬 또는 임시 서버
- 단일 사용자 위주
- 보안 및 복구보다 편의성 우선
- 데이터 유실 허용 가능
운영 환경¶
- 데이터 유실 허용하지 않음
- 다수 애플리케이션 동시 접근
- 장기 실행 프로세스
- 보안, 백업, 복구가 전제 조건
운영 환경 기준으로만 작성됨.
3. MySQL 직접 노출을 금지하는 이유¶
운영 환경에서 MySQL은 다음을 허용하지 않음.
- 외부 네트워크에서의 직접 접근
- 불특정 Host(
%)에서의 무제한 접속 - 애플리케이션과 동일한 보안 레벨에서의 운영
MySQL은 외부 서비스가 아닌 내부 인프라 자원임.
[ Application ]
↓
[ Internal Network ]
↓
[ MySQL ]
MySQL은 외부 트래픽의 진입점이 될 수 없음
4. 계정 및 권한 운영 원칙¶
운영 서버에서 MySQL 계정은 다음 원칙을 따름.
- 애플리케이션별 계정 분리
- 최소 권한 원칙 적용
- root 계정은 관리 목적으로만 사용
- 애플리케이션에서 root 계정 사용 금지
권한 설계는 편의성이 아니라 사고 발생 시 영향 범위를 기준으로 결정함.
5. 네트워크 및 접근 제어 원칙¶
- 기본 포트는 3306 사용
- 외부 직접 공개하지 않음
- 방화벽 및 보안 그룹 기준으로 접근 제어
- 가능하면 내부 네트워크 또는 Bastion 경유 접근
MySQL은 “접근을 허용하는 서비스”가 아니라 접근을 제한해야 하는 자원임.
6. 성능 튜닝의 기본 방향¶
운영 환경에서 MySQL 튜닝의 목적은 다음과 같음.
- 최대 성능 추구 ❌
- 벤치마크 점수 향상 ❌
- 예측 가능한 안정성 확보 ⭕
기본 원칙은 다음과 같음.
- InnoDB 기준 운영
- 메모리는 충분히, 디스크 I/O는 보수적으로 사용
- 성능보다 데이터 무결성 우선
튜닝은 “빠르게 만드는 작업”이 아니라 문제 발생 가능성을 줄이는 작업임.
7. SELinux 운영 원칙¶
운영 서버에서 SELinux는 다음 기준을 따름.
- SELinux 비활성화하지 않음
- 정책 기반으로 명시적 허용
- 포트 또는 데이터 디렉터리 변경 시
SELinux 컨텍스트를 함께 관리함
setenforce 0은 해결책이 아니라
운영 리스크를 미래로 미루는 행위임.
8. 백업과 복구는 선택이 아님¶
운영 환경에서 MySQL은 다음 전제를 가짐.
- 백업 없는 DB는 운영 대상이 아님
- 장애는 언제든 발생 가능함
- 복구 절차는 문서로 검증되어야 함
백업이 없다면, 해당 DB는 이미 장애 상태와 다르지 않음
9. 모니터링은 운영의 일부임¶
MySQL 운영에서 모니터링은 선택 사항이 아님.
- 동시 연결 수
- InnoDB 상태
- 디스크 사용량
- Slow Query 발생 여부
문제가 발생한 뒤 확인하는 로그는 사후 분석 자료일 뿐, 운영이 아님
10. 정리¶
- MySQL은 모든 서비스의 신뢰 기반
- 외부에 노출되지 않는 내부 인프라 자원
- 보안, 백업, 복구, 모니터링이 전제되지 않으면 운영 불가
MySQL 운영의 기준선이며 이후 모든 설치, 설정, 튜닝 문서의 전제가 됨.