🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개) · 출처: 수집물 2026-04
0한눈에
- 대상: AWS EC2에서 직접 운영하던 MySQL · 수집 · 배포 서비스를 사내 IDC/In-house 서버로 이전.
- 방식: MySQL 백업·복원과 데이터 정합성 검증을 거쳐 서비스별 전환 순서를 확정.
- 종료: 전환 완료 후 운영 DB용 EC2만 남기고 다른 EC2 인스턴스를 정리해 월 AWS 비용을 약 94% 절감.
1왜 이전했나
MySQL과 수집·배포 서비스가 AWS EC2에서 운영되며 반복 클라우드 비용 부담이 컸다. DB·수집 인프라를 사내(IDC/In-house) 서버로 옮겨 비용을 줄이고, 데이터 인프라를 사내에서 직접 운영·통제할 수 있는 구조로 전환하는 것이 목표였다.
2진행 순서
- EC2에서 운영하던 MySQL 데이터를 백업해 사내 서버에 복원
- 테이블별 데이터 정합성과 서비스 연결을 확인한 뒤 전환
- 사내 IDC/In-house에 수집·배포 DB의 primary/replica, 수집 서버, 모니터링 재구성 + 네트워크·백업·복원 체계 정비
- 전환 완료 후 운영 DB용 EC2만 남기고 다른 EC2 인스턴스를 종료
단순 복사가 아니라 검증 후 전환이 핵심. 복원한 DB의 정합성과 서비스 연결을 확인한 뒤 트래픽을 사내로 넘기고 EC2 인스턴스를 정리한다.
3온보딩 포인트
- 이전 경로는 AWS EC2의 self-managed MySQL → 백업·복원·검증 → IDC/In-house(DB·수집·배포) → 불필요한 EC2 종료.
- AWS 관리형 DB나 오브젝트 스토리지를 사용한 작업으로 설명하지 않는다. 실제 서비스 범위는 EC2뿐이다.
- 사내 재구성 시 DB primary/replica 토폴로지, 수집 서버, 모니터링, 그리고 백업·복원·네트워크까지 같이 세워야 운영 통제가 완성된다.
- 비용 효과는 인스턴스를 실제로 종료해야 발생하므로 전환 후 미사용 EC2 정리까지 마무리한다.
4공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/aws-to-idc-migration.html)은 내부 식별자(티켓 ID·내부 테이블/뷰명·호스트명·IP·고객사명·동료 이름)를 제거하고 배경·이전 흐름·결과 중심으로 일반화했다. 사용 기술은 AWS EC2, self-managed MySQL, IDC/In-house로 한정한다. 이 내부 문서는 본인 참고/온보딩용.