SigNoz와 OneUptime를 사용한 멀티 테넌트 관측 플랫폼 구축
Source: Dev.to
번역을 진행하려면 번역하고자 하는 전체 텍스트(본문 내용)를 제공해 주시겠어요?
본문을 알려주시면 원본 형식과 마크다운을 그대로 유지하면서 한국어로 번역해 드리겠습니다.
아키텍처 개요
현대 SaaS 팀은 테넌트 격리와 컴플라이언스를 희생하지 않으면서 깊은 가시성이 필요합니다. 이 글에서는 로그, 메트릭, 트레이스를 격리된 SigNoz 및 OneUptime 스택으로 라우팅하고, 강력한 보안 제어를 적용하며, SOC 2 및 ISO 27001 실무와 일치하도록 구축한 다중 테넌트 모니터링 플랫폼에 대해 설명합니다. 결과적으로 각 고객은 전용 모니터링 경험을 얻고, 우리는 운영 부담을 가볍고 반복 가능하게 유지합니다.
우리는 허브‑앤‑스포크 모델을 설계했습니다:
- 중앙 모니터링 VM이 관측 스택을 호스팅합니다.
- 각 테넌트는 다음 중 하나를 가집니다:
- 완전 격리된 SigNoz 스택(프론트엔드, 쿼리, 컬렉터, ClickHouse), 또는
- 테넌트 식별자를 기반으로 엄격히 라우팅되는 공유 스택(경량 테넌트를 위한).
- 각 애플리케이션 VM은 OpenTelemetry (OTEL) Collector를 실행하여:
- PM2 로그를 tail하고,
- OTLP 트레이스/메트릭을 수신하고,
- 모든 데이터를 모니터링 VM으로 전달합니다.
이렇게 하면 일관된 수집 파이프라인을 제공하면서 필요에 따라 기본 격리를 구현할 수 있습니다.
테넌트 분리 전략
두 가지 격리 모드를 지원합니다:
-
테넌트당 완전 격리
- 테넌트당 전용 SigNoz 스택
- 별도 ClickHouse 인스턴스
- 별도 OTEL 컬렉터 업스트림
- 가장 강력한 데이터 격리
-
공유 스택에서 논리적 격리
- 단일 SigNoz + ClickHouse 인스턴스
business_id(헤더 + 리소스 속성) 기반 라우팅- 소규모 테넌트에 적합
기본값 – 규제 대상 또는 고트래픽 고객을 위한 완전 격리.
핵심 라우팅 헤더
- SigNoz용
x-business-id - OneUptime용
x-oneuptime-token
모니터링 VM 프로비저닝 및 하드닝
우리는 모니터링 VM을 제어된 프로덕션 시스템으로 취급합니다:
- SSH 키만 사용, 비밀번호 인증 없음
- 최소 인바운드 포트:
22, 80, 443, 4317, 4318 - Nginx를 단일 TLS 인그레스로 사용
- Docker Compose를 사용해 불변 서비스 레이아웃 구현
예시 프로비저닝 단계 (고수준)
# SSH key‑based access only
az vm user update \
--resource-group \
--name \
--username \
--ssh-key-value ""
# Open required ports (restrict SSH to trusted IPs)
az network nsg rule create ... \
--destination-port-ranges 22 80 443 4317 4318엣지에서 멀티‑테넌트 라우팅
우리는 Nginx maps를 사용하여 UI와 OTLP 수집 모두에 대해 호스트명으로 트래픽을 라우팅합니다:
map $host $signoz_collector_upstream {
signoz.tenant-a.example signoz-otel-collector-tenant-a;
signoz.tenant-b.example signoz-otel-collector-tenant-b;
default signoz-otel-collector-default;
}
server {
listen 4318;
location / {
proxy_pass http://$signoz_collector_upstream;
}
}이는 단일 IP 주소를 유지하면서 깔끔한 DNS‑기반 테넌트 라우팅을 제공합니다.
컬렉터 구성: 로그, 트레이스, 메트릭
각 테넌트 VM은 filelog와 OTLP를 사용하여 OTEL Collector를 실행합니다. 우리는 PM2 로그(JSON 래퍼)를 파싱하고, 심각도를 정규화하며, SigNoz에서 빠른 필터링을 위해 리소스 필드를 첨부합니다.
우리가 강제하는 핵심 필드
severity_text(info / warn / error)service.namedeployment.environmenthost.namebusiness_id
최소 구성 발췌
processors:
resourcedetection:
detectors: [system]
resource:
attributes:
- key: business_id
value: ${env:BUSINESS_ID}
action: upsert
transform/logs:
log_statements:
- context: log
statements:
- set(severity_text, attributes["severity"])
where attributes["severity"] != nil이러한 보강으로 severity_text, service.name, host.name을 SigNoz에서 즉시 검색할 수 있게 됩니다.
클라이언트 측 통합 (앱)
우리는 백엔드, 웹, 에이전트 서비스 전반에 걸쳐 일관된 OTEL 패턴을 사용합니다:
- Backend – 트레이스를 위한 OTLP 익스포터
- Web – 브라우저 트레이스를 백엔드로 전달(백엔드가 재내보냄)
- Agents –
OTEL_EXPORTER_OTLP_ENDPOINT로 구성된 OTEL SDK
일반적인 환경 변수
BUSINESS_ID=tenant-a
SIGNOZ_ENDPOINT=http://signoz.tenant-a.example:4318
ONEUPTIME_ENDPOINT=http://status.tenant-a.example:4318
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://127.0.0.1:4318/v1/traces
DEPLOY_ENV=productionDNS 및 TLS (공용 UX)
각 테넌트는 자체 서브도메인을 갖습니다:
signoz.<tenant>.examplestatus.<tenant>.example
TLS 종료는 Nginx에서 실제 인증서(ACME/Let’s Encrypt)로 수행됩니다:
sudo certbot --nginx \
-d signoz.tenant-a.example \
-d status.tenant-a.example우리는 강력한 암호와 HSTS를 사용하여 테넌트별 TLS 정책을 일관되게 유지합니다.
검증 및 가시성 QA
파이프라인을 다음으로 검증합니다:
- OTEL 헬스 엔드포인트 (
/healthon collector) - 백엔드 서비스에서 발생하는 테스트 트래픽
- 로그 속성을 확인하기 위한 ClickHouse 쿼리
severity_text,service.name,host.name에 대한 SigNoz 필터
예시 ClickHouse 검사 (내부)
SELECT severity_text, count()
FROM signoz_logs.logs_v2
WHERE resources_string['business_id'] = 'tenant-a'
AND timestamp >= now() - INTERVAL 15 MINUTE
GROUP BY severity_text;보안 및 규정 준수 (SOC 2 + ISO 27001)
SOC 2 및 ISO 27001에 맞춘 제어 항목:
- 액세스 제어 – SSH 키만 사용, 최소 권한 IAM, 클라우드 콘솔 MFA 적용.
- 네트워크 분할 – 최소한의 개방 포트; SSH는 소스 IP로 제한.
- 시크릿 관리 – 런타임 시크릿을 금고에 저장, 코드에 절대 포함되지 않음.
- 전송 중 암호화 – 전역 TLS 적용, 평문 트래픽 없음.
- 감사 로깅 – 모든 관리자 작업을 로그에 기록하고 규정 보관 기간에 따라 유지.
- 패치 관리 – CVE 스캔을 포함한 자동 OS 및 컨테이너 이미지 업데이트.
보안 및 운영 제어
- 평문 엔드포인트 노출.
- 휴식 중 암호화: VM 및 DB 볼륨에 디스크 암호화 적용.
- 감사 추적: 시스템 로그 보관; 인프라 변경 사항을 코드에 추적.
- 변경 관리: 모든 구성은 저장소에 보관; 배포 전 변경 검토 필요.
- 모니터링 및 알림: SLO 및 가동 시간 검사를 위한 OneUptime.
- 사고 대응: 문서화된 절차, 보관 및 에스컬레이션.
- 백업 전략: 테넌트별 ClickHouse 백업 정책.
재현성: 인프라 + 테넌트 구성 코드화
우리는 구성을 책임에 따라 분리합니다:
- Monitoring services repo: 모든 인프라와 Nginx 라우팅.
- Tenant repos: OTEL 컬렉터 구성 및 배포 훅.
즉, 새로운 VM을 다음과 같이 재구성할 수 있습니다:
-
모니터링 레포를 가져와 실행합니다:
docker compose up -d -
DNS 및 TLS를 업데이트합니다.
-
테넌트 배포 스크립트를 실행하여 컬렉터와 환경을 설치합니다.
Final Takeaways
이 아키텍처는 다음과 같은 장점을 모두 제공합니다:
- 규정 준수를 중시하는 고객을 위한 강력한 테넌트 격리.
- 공유 운영 프로세스와 표준 구성.
- 높은 신호‑대‑잡음 디버깅을 위한 빠른 로그 필터링(심각도 / 서비스 / 환경 / 호스트).
- SOC 2 및 ISO 27001 요구사항에 적합한 반복 가능하고 감사 가능한 배포 흐름.