인프라·배포·모니터링·파이프라인 핵심 개념 정리

이 글은 인프라·배포·운영을 시작할 때 자주 고민하게 되는 네 가지 주제 — 제로 다운타임 배포 전략, AWS RDS 운영 시 실수하기 쉬운 점, 서버 한 대에서 시작하는 모니터링, CI/CD 파이프라인 설계 — 를 개발자 관점에서 정리한 메모이다.

1. 제로 다운타임 배포 전략

제로 다운타임 배포는 배포 중에도 사용자가 끊김 없이 서비스를 이용할 수 있도록 하는 배포 방식이다. 대표적인 전략은 블루/그린, 카나리, 롤링 배포이다.

1) 블루/그린 배포

블루/그린은 두 개의 동일한 환경(블루=현재 운영, 그린=새 버전)을 두고, 트래픽을 한쪽에서 다른 쪽으로 한 번에 전환하는 방식이다.

• 장점 — 전환 전후 환경이 분리되어 있고, 문제가 생기면 다시 이전 환경으로 빠르게 롤백할 수 있다.
• 단점 — 두 세트를 동시에 유지해야 하므로 인프라 비용이 상대적으로 크다.

2) 카나리 배포

카나리 배포는 새 버전을 일부 트래픽(예: 1% → 10% → 50% → 100%)에만 점진적으로 적용한 뒤, 이상이 없을 때 비율을 늘리는 방식이다.

• 장점 — 문제 발생 시 영향을 받는 사용자가 제한적이고, 조기 징후를 통해 롤백할 수 있다.
• 단점 — 트래픽 분배·모니터링 설정이 복잡해질 수 있다.

3) 롤링 배포

롤링 배포는 여러 인스턴스를 조금씩 교체하면서 새 버전을 배포하는 방식이다. 예를 들어 10대 중 2대씩 새로운 버전으로 교체해 나간다.

• 장점 — 추가 인프라 없이도 점진 배포 가능, 많은 클러스터 오케스트레이터(Kubernetes 등)가 기본 지원한다.
• 단점 — 배포 중 일정 기간 동안 구버전·신버전이 섞여 있어, 호환성 문제가 있으면 이 구간에서 오류가 날 수 있다.

2. AWS RDS 운영 시 실수하기 쉬운 점

AWS RDS는 관리형 데이터베이스 서비스이지만, 여전히 설정·운영에서 실수하기 쉬운 부분이 있다.

1) 파라미터 그룹 미설정

RDS 인스턴스는 파라미터 그룹을 통해 DB 설정을 관리한다. 파라미터 그룹을 기본값으로 두고 utf8mb4, time_zone, innodb_buffer_pool_size 등 핵심 설정을 조정하지 않으면, 문자셋 깨짐·성능 저하·시간대 혼선이 발생할 수 있다.

2) 문자셋(utf8mb4) 누락

MySQL·MariaDB 기반 RDS에서 utf8mb4 대신 utf8(3바이트)만 쓰면, 이모지 등 4바이트 문자를 저장할 때 에러가 발생한다. 파라미터 그룹과 DB/테이블/컬럼의 문자셋을 일관되게 utf8mb4로 맞추는 것이 좋다.

3) 백업·복원 시 주의점

스냅샷 복원으로 새 인스턴스를 만들면, 엔드포인트·파라미터 그룹·보안 그룹 등이 기존 인스턴스와 다를 수 있다. 복원 후에는 다음 항목을 반드시 점검해야 한다.

• 애플리케이션이 바라보는 엔드포인트를 새 인스턴스로 변경했는지
• 파라미터 그룹·옵션 그룹이 원본과 동일한지
• 보안 그룹·서브넷 그룹이 올바른지

3. 서버 한 대에서 시작하는 모니터링

초기에는 서버 한 대로 서비스를 시작하는 경우가 많다. 이때도 기본적인 모니터링을 해 두면, 문제를 조기에 발견할 수 있다.

1) 무엇을 볼 것인가

• 인프라 지표 — CPU, 메모리, 디스크 사용량, 네트워크 트래픽
• 애플리케이션 지표 — 요청 수, 응답 시간, 에러 비율
• DB 지표 — 연결 수, 슬로우 쿼리, 버퍼 캐시 히트율

2) 어떤 도구를 쓸 것인가

• CloudWatch — AWS EC2/RDS를 쓴다면 기본 메트릭·알람을 설정해 두기 쉽다.
• Datadog — 에이전트 설치만으로 인프라·애플리케이션 메트릭을 통합해서 볼 수 있다.
• Prometheus + Grafana — 자체 호스팅 환경에서 많이 쓰는 조합으로, 메트릭 수집(Prometheus) + 시각화(Grafana) 구조이다.

서버 한 대라도, 최소한 CPU·메모리·디스크·응답 시간·에러율 정도의 대시보드와 알람은 설정해 두는 것이 좋다.

4. CI/CD 파이프라인 설계 – 빌드 → 테스트 → 스테이징 → 프로덕션

CI/CD 파이프라인은 빌드 → 테스트 → 스테이징 배포 → 운영 배포까지 흐름을 자동화하는 것이다. 앞서 다룬 배포 전략·모니터링과 함께 설계해야 한다.

1) 기본 단계 설계

• 빌드 — 의존성 설치·정적 자원 빌드·컨테이너 이미지 생성 등
• 테스트 — 유닛/통합 테스트, 린트, 정적 분석
• 스테이징 배포 — 실제 운영과 유사한 환경에 배포 후 기본 헬스 체크
• 프로덕션 배포 — 블루/그린·카나리·롤링 중 하나를 적용해 배포

2) 롤백 전략 포함

배포 설계 시 항상 롤백 경로를 함께 고려해야 한다.

• 이전 버전 이미지·아티팩트를 보관해 두고, 배포 기록과 연결
• DB 마이그레이션은 롤백 가능 여부를 검토하고, 필요 시 단계적 배포(백워드 호환 스키마) 설계
• 블루/그린·카나리에서는 트래픽을 다시 이전 환경으로 되돌리는 절차를 문서화

한 줄 요약

인프라·배포·운영을 설계할 때는 끊김 없는 배포(블루/그린·카나리·롤링), RDS 설정·백업 복원 시 주의점, 서버 한 대부터 시작하는 기본 모니터링, 빌드→테스트→스테이징→프로덕션으로 이어지는 CI/CD 파이프라인과 롤백 전략을 함께 고민해야 한다. 이렇게 해 두면 서비스 규모가 커질수록 운영 안정성과 대응 속도를 유지하기 쉬워진다.