compose 구성 분리 전략 선택 (옵저버빌리티 파일 분리)
상태
승인
후보군
| 방안 | 설명 |
|---|---|
| 별도 compose 파일 분리 | 앱/Grafana/SigNoz/Collector를 각각 별도 compose 파일로 분리 |
| 단일 docker-compose.yml 통합 | 기존 파일에 옵저버빌리티 서비스를 모두 추가 |
결정
옵저버빌리티를 별도 compose 파일로 분리한다.
docker-compose.yml— 앱·인프라(MySQL·Kafka·Redis·exporter)docker-compose.grafana.yml— Tempo·Prometheus·Loki·Grafanadocker-compose.signoz.yml— SigNoz·ClickHousedocker-compose.otel.yml— Collector 게이트웨이
결정 이유
- PoC 동안 두 스택을 독립 기동해야 한다(한쪽만 켜서 리소스 측정 등). 파일 분리로
-f조합 기동이 자유롭다. - PoC 종료 후 탈락 스택의 compose 파일만 제거하면 정리 끝.
- 티켓별 Single Writer per File 원칙 충족 — Grafana/SigNoz/Collector 티켓이 서로 다른 파일을 만들어 같은 wave 병렬 시 머지 충돌이 없다.
검토 대안
| 방안 | 기각 이유 |
|---|---|
| 단일 docker-compose.yml 통합 | 모든 옵저버빌리티 티켓이 한 파일을 수정 → 병렬 작업 머지 충돌, 한쪽만 끄기 어려움 |
트레이드 오프
- (득) 독립 기동, 충돌 없는 병렬 작업, 깔끔한 PoC 정리.
- (실)
docker compose -f a.yml -f b.yml up식 다중 파일 기동 명령이 길어짐 → README로 표준 명령 안내.