[INFRA-05] 통합 오케스트레이션 + E2E 검증
작업 내용 (설계 의도)
근거 TDD: ../TDD.md “Release Scenario”, “Testing Plan” scenario. Success Metrics 전 항목.
변경 사항
분리된 compose 파일들을 병합하는 오케스트레이션을 단독 소유하고(공통 파일 Single Writer), 전체 스택 E2E를 검증한다. 이 티켓만 루트 오케스트레이션 파일을 만진다.
.env.observability.example:APP_ENV·OTEL_EXPORTER_OTLP_ENDPOINT·OTEL_SERVICE_NAME변수 예시Makefile(또는scripts/observability-up.sh):docker compose -f docker-compose.yml -f <⑧ base compose> -f docker-compose.observability.yml -f docker-compose.observability-agents.yml up병합 명령. 데이터스토어는 ⑧ base compose 소유(senior-pm #4) — ⑤는 관측 백엔드·에이전트 파일만 얹는다. ⑧ 미완 시 로컬 데이터스토어를 대상으로 하는 대체 안내 포함observability/README.md: Grafana URL·접근법(FR-7 Operations)·⑧ base compose 기동 선행 안내·service.name 규약(BE=sports-application/web=sports-web)·⑦⑧ override 파일 확장법- E2E 검증 수행 및 결과 기록
파일 소유: 루트 오케스트레이션 파일(Makefile/.env/README) — BE·INFRA-01~04와 교집합 0. 마지막 wave 단독 통합 티켓.
롤백: 오케스트레이션 파일은 실행 편의일 뿐 — 개별 -f ... down으로 스택별 롤백.
의존
- BE-02, BE-03, BE-04 (앱 계측 완료)
- INFRA-01, INFRA-02, INFRA-03, INFRA-04 (인프라·관측·config·대시보드)
다이어그램
처리 흐름
sequenceDiagram participant O as 운영자 participant M as make up participant S as 전체 스택 participant G as Grafana O->>M: make observability-up M->>S: 3개 compose 병합 기동 S-->>M: 전 컨테이너 healthy O->>S: 임의 API 10건 호출 O->>G: trace 연결율·대시보드·lag 확인
클래스 의존
flowchart LR MAKE["Makefile / up 스크립트"] --> BASE["docker-compose.yml"] MAKE --> DS["⑧ base compose (데이터스토어)"] MAKE --> OBS["docker-compose.observability.yml"] MAKE --> AGENTS["docker-compose.observability-agents.yml"] ENV[".env.observability"] --> MAKE
테스트 케이스
make observability-up으로 3개 compose가 병합 기동되고 전 컨테이너가 healthy가 된다(메모리 8GB 이내 — NFR).- 임의 API 요청 10건 중 9건 이상이 Tempo에서 단일 trace로 조회된다(연결율 99%, Success Metric).
- Grafana 4종 대시보드가 실데이터로 패널을 렌더한다(P95 3초 이내 로딩).
- Kafka UI에서 consumer lag이 실시간 조회된다.
- Collector 컨테이너를 정지해도
/actuator/prometheusscrape가 계속된다(장애 격리, User Scenario 4). - Prometheus
up{job="otel-collector"}==0으로 Collector 다운이 감지된다. APP_ENV=dev·APP_ENV=prod로 각각 기동 시 대시보드가env로 구분된다.