Feb28a

Young-Kyoo Kim·2026년 3월 2일

Cloud Native Data Lakehouse 운영 계획서

DevOps 관점 — 800대 규모 (Compute 600 / Storage 200)

문서 버전: v1.0
작성일: 2026-03-02
검토 상태: Multi-Agent Review 완료 (APPROVED with REVISIONS)

1. 프로젝트 개요

1.1 목적

800대(연산 600, 저장 200) 규모의 엔터프라이즈급 Cloud Native Data Lakehouse를 구축하고, DevOps 관점에서 안정적이고 자동화된 운영 체계를 수립한다.

1.2 대상 사용자

단계	사용자	주요 워크로드
Phase 1 (현재)	데이터 분석가	StarRocks(OLAP), Spark/Airflow(ETL), JupyterLab(개발)
Phase 2 (향후)	AI/ML 엔지니어	모델 학습, 벡터 검색, GPU 워크로드

1.3 운영 모델

Namespace 기반 분산 스택: 사용자별 독립 분석 환경(StarRocks, Airflow, Jupyter, CNPG 등) 제공
Workbench 오케스트레이션: 프로그래밍적으로 K8s Operator를 통해 엔진 생성/삭제/정지 제어
ArgoCD 범위: 플랫폼 코어(Keycloak, Monitoring, Cilium 설정 등) 전용 GitOps

1.4 비목표 (Explicit Non-Goals)

퍼블릭 클라우드 관리형 서비스 의존
레거시 스토리지 프로토콜(NFS/iSCSI) 사용
오프사이트 DR 구축 (버킷 레벨 복제로 대체)

2. 확정 아키텍처

2.1 솔루션 스택 종합

graph TD
    subgraph "External/Management — bond0"
        User((데이터 분석가)) --> WB[Workbench UI]
        WB --> KC[Keycloak SSO / AD]
        WB --> Vault[HashiCorp Vault]
    end

    subgraph "Platform Core — ArgoCD Managed"
        CD[ArgoCD] --> KC
        CD --> Polaris[Apache Polaris]
        CD --> Thanos[Thanos Querier]
        CD --> OS[OpenSearch]
        CD --> Nexus[Nexus Repository]
    end

    subgraph "Control Plane — Operator Based"
        WB -- "Create Engine CR" --> K8sAPI[K8s API Server]
        K8sAPI --> SRO[StarRocks Operator]
        K8sAPI --> AFO[Airflow/Spark Operator]
        K8sAPI --> CPO[CNPG Operator]
        K8sAPI --> KV[KubeVirt]
    end

    subgraph "600 Compute Nodes — bond1 BGP/ECMP/MTU 9000"
        direction LR
        subgraph "NS: user-alpha"
            SRA[StarRocks] 
            JUP[JupyterLab]
            AF[Airflow + Spark]
        end
        subgraph "NS: user-beta"
            SRB[StarRocks]
            JUPB[JupyterLab]
        end
    end

    subgraph "200 Storage Nodes — MinIO / AIStor"
        MinIO[(MinIO Object Storage)]
        Iceberg[[Apache Iceberg]]
        AIStor[AIStor High-Perf]
    end

    subgraph "Observability — Federated"
        Thanos --> PromA[Prometheus Agent A]
        Thanos --> PromB[Prometheus Agent B]
        OS -- "Cold → S3" --> MinIO
    end

    SRA -- "S3/Iceberg" --> MinIO
    AF -- "Read/Write" --> Iceberg

2.2 핵심 기술 결정 사항 (Decision Log)

영역	결정	대안	선택 이유
운영 모델	Namespace 기반 분산 스택	단일 공유 클러스터	800대 규모에서 Blast Radius 최소화
네트워크	Cilium BGP + Direct Routing	Overlay (VxLAN)	캡슐화 제거로 하드웨어 최대 성능 확보
망 분리	bond0(관리/외부), bond1(데이터/내부)	논리적 VLAN만	물리적 분리로 트래픽 영향 완전 차단
배포 전략	Workbench + K8s Operator	ArgoCD 직접 관리	사용자 셀프 서비스 환경 제공(민첩성 확보)
데이터 카탈로그	Apache Iceberg + Polaris	Hive Metastore	다중 엔진 간 데이터 일관성 및 거버넌스
모니터링	연합형 Prometheus (Thanos)	단일 대형 Prometheus	800대 메트릭 분산 처리, 수집기 병목 방지
인증	Keycloak (AD SSO 연동)	개별 ID 관리	엔터프라이즈 인사 시스템 연동 및 SSO 편의
보안	Vault (민감정보 → 점진 확장)	K8s Secrets 단독	전사적 감사 기능 및 동적 비밀 확장 가능성
스토리지 확장	Server Pool 추가 방식	기존 노드 디스크 추가	가용성 보장 무중단 확장
업그레이드	랙 단위 순차 + 사용자 선택형	빅뱅(전체) 업데이트	800대 규모에서 서비스 연속성 불가

3. 팀 구성 및 모듈별 운영 계획

3.1 운영 TF 구성

팀원	담당 모듈	핵심 미션
팀원 1	K8s Core	800대 노드 라이프사이클 관리 및 스케줄링 최적화
팀원 2	Cilium/BGP	L3 네트워킹 안정화 및 bond1 데이터망 가속
팀원 3	MinIO AIStor, OpenEBS, local-path-provisioner	스토리지 가용성 보장 및 로컬 자원 레이아웃 관리
팀원 4	Keycloak, Vault	AD 연동 SSO 보안 거버넌스 및 비밀 정보 관리
팀원 5	Jenkins, ArgoCD	플랫폼 코어 형상 관리 및 자동화 파이프라인 구축
팀원 6	Nexus, KubeVirt	컨테이너 이미지 공급망 및 레거시 VM 통합 관리
팀원 7	Prometheus, Grafana, OpenSearch	전역 메트릭/로그 통합 가시성 및 지능형 알람 체계

3.2 팀원 1 — K8s Core (인프라의 척추)

Day-1 체크리스트 (구축 완료 기준)

K8s Control Plane HA 구성 (최소 3 Master, etcd 분리)
etcd 성능 기준선 수립: 600+ Namespace 환경에서 etcd 지연 시간 < 10ms 검증
etcd 자동 백업 정책 수립 (30분 주기, MinIO 보관)
PriorityClass 3계층 정의 및 전 클러스터 적용
- system-critical (Keycloak, Polaris, DNS, Monitoring)
- interactive (JupyterLab, StarRocks FE)
- batch (Spark executor, Airflow worker)
랙(Rack) 인식 토폴로지 라벨링 (topology.kubernetes.io/zone)
노드 그룹별 Taint/Toleration 정의 (Storage 전용 노드 격리)
ResourceQuota 및 LimitRange 템플릿 정의 (Workbench 자동 주입용)

Day-2 운영 루틴

주기	업무	상세
일간	노드 상태 점검	`NotReady` 노드 즉시 감지 및 자동 Drain → 복구
주간	etcd 헬스체크	DB 크기, 리더 변경 횟수, Snapshot 무결성 확인
월간	랙 단위 순차 업그레이드	Control Plane → Worker 순, BGP Graceful Restart 연동
분기	API Server 부하 리뷰	Audit 로그 기반 API 호출량 분석, Rate-limit 조정

KPI

지표	목표값
Control Plane API 응답 시간	< 200ms (p99)
etcd 디스크 지연	< 10ms
노드 가용률	> 99.9%
etcd 백업 성공률	100%

[!IMPORTANT]
Multi-Agent 보완 사항: 600개 Namespace에서 etcd 성능 병목이 발생할 수 있으므로, 초기 도입 시 Namespace 50개 단위로 부하 테스트를 수행하여 etcd 한계치를 정량적으로 파악해야 합니다.

3.3 팀원 2 — Cilium / BGP (초고속 데이터 혈관)

Day-1 체크리스트

Cilium 설치 (kube-proxy replacement 모드, Direct Routing 활성화)
BGP CRD 기반 피어링 설정 (모든 ToR 스위치 대상)
ECMP 해시 알고리즘 검증 (5-tuple 기반)
bond1 전 노드 MTU 9000 (Jumbo Frame) 설정 및 End-to-End 확인
XDP 가속 활성화 (NIC 지원 여부별 fallback 포함)
Hubble Relay 배포 및 Grafana 연동
기본 CiliumNetworkPolicy 템플릿 작성 (테넌트 간 격리)
Bandwidth Manager 활성화 및 기본 QoS 프로필 정의

Day-2 운영 루틴

주기	업무	상세
일간	BGP 세션 모니터링	Established 상태 확인, Flapping 알람 자동 발송
일간	Hubble Flow 기반 트래픽 점검	East-West 대역폭 Top-10, 패킷 드롭 추적
주간	ECMP 경로 밸런싱 검증	특정 스위치로 쏠림 여부 분석, 경로 가중치 조정
월간	Cilium 매이너 업그레이드	BGP Graceful Restart 모드 활성화 후 순차 적용

KPI

지표	목표값
BGP 세션 Uptime	100%
Packet drop rate (bond1)	< 0.001%
East-West 지연 시간 (p99)	< 1ms (동일 랙), < 3ms (교차 랙)
XDP 가속 적용률	> 95% 노드

3.4 팀원 3 — Storage (데이터의 요새)

Day-1 체크리스트

MinIO 최소 2 Server Pool 구성 (EC:4 기반, 풀 당 최소 4노드 × 4드라이브)
AIStor 전용 풀 분리 (고성능 NVMe 노드 그룹)
ILM(Information Lifecycle Management) 정책 초기 설정
OpenEBS / local-path-provisioner 구성 (CNPG, OpenSearch 전용 로컬 PV)
MinIO 전용 ServiceAccount 및 Bucket Policy 템플릿 작성
Bucket Replication 대상 버킷 선정 및 성능 기준선 수립
Observability 용 버킷 용량 할당: Thanos 메트릭 저장 전용 버킷 분리 및 초기 용량 계획 수립 (팀원 7 협의)

Day-2 운영 루틴

주기	업무	상세
일간	Healing 백로그 확인	Background Scanner 진행률, 드라이브 오류 감지
주간	풀별 용량 추이 모니터링	80% 도달 시 자동 알람 → 확장 계획 착수
월간	ILM 정책 효과 검증	Cold 데이터 이동량, 비용 절감 효과 분석
분기	Server Pool 확장 또는 리밸런싱	신규 랙 추가 시 풀 추가 절차 실행

풀 확장 절차 (SOP)

1. 신규 노드 하드웨어 준비 (기존 풀과 동일 사양 권장)
2. K8s 워커 등록 + Cilium BGP 연동 확인 (팀원 1, 2 협업)
3. MinIO Operator / CLI로 신규 Server Pool Endpoint 추가
4. 쓰기(Write) 가중치 자동 분산 확인
5. Erasure Coding 수렴 정상 여부 모니터링 (24시간)
6. Prometheus 메트릭으로 성능 기준선 재측정

KPI

지표	목표값
읽기 가용성	> 99.99%
Healing 백로그 해소 시간	< 24시간
풀 용량 가용률	> 20% (항시)
로컬 PV 프로비저닝 성공률	100%

[!WARNING]
Multi-Agent 보완 사항: 팀원 7(Observability)의 Thanos가 MinIO에 대량의 메트릭 블록을 저장합니다. 전용 버킷을 분리하고, 월간 용량 증가 추이를 팀원 7과 공동으로 리뷰해야 합니다.

3.5 팀원 4 — IAM & Security (보안 파수꾼)

Day-1 체크리스트

Keycloak HA 구성 (최소 2 인스턴스 + CNPG 백엔드)
AD(LDAP) Federation 설정 및 SSO 동기화 확인
OIDC Client 등록 (Workbench, JupyterLab, Airflow, Grafana, OpenSearch 등)
Vault HA + Auto-unseal 구성 (필수)
Vault KV Secret Engine 활성화 (MinIO Credential, DB 패스워드 등)
Vault Agent Injector 배포 (Namespace별 자동 Secret 주입)
RBAC ↔ Keycloak Role 매핑 표준 문서화

Day-2 운영 루틴

주기	업무	상세
일간	Keycloak SSO 로그인 성공률 확인	AD 동기화 지연 또는 실패 감지
주간	Vault Seal 상태 확인	Auto-unseal 정상 동작, 토큰 만료 감시
월간	Secret Rotation 실행	MinIO AccessKey, DB 패스워드, TLS 인증서 자동 갱신
분기	접근 권한 감사 (Audit)	AD 탈퇴 계정 잔존 여부, 과다 권한 부여 점검

AD 계정 삭제 시 즉시 회수 프로세스 (SOP)

1. AD에서 계정 비활성화/삭제
2. Keycloak LDAP 동기화 (5분 주기) → 해당 사용자 세션 즉시 무효화
3. Workbench → 해당 Namespace의 엔진 자동 정지(Scale to zero) 트리거
4. Vault에서 해당 사용자 전용 Secret 경로 접근 차단
5. 감사 로그 아카이빙 (OpenSearch)

KPI

지표	목표값
AD-Keycloak SSO 로그인 성공률	> 99.9%
Secret TTL (최대 유효 기간)	< 30일
Vault 가용률	> 99.99%
권한 회수 소요시간 (AD 삭제 → 접근 차단)	< 10분

[!CAUTION]
Multi-Agent 보완 사항 (필수): Vault가 다운되면 전체 분석 서비스가 중단됩니다. Vault HA(최소 3노드) + Auto-unseal은 Day-1 필수 항목이며, Vault 장애 시 비상 복구 Runbook을 사전에 준비해야 합니다.

3.6 팀원 5 — CI/CD & Automation (운영 자동화 엔진)

Day-1 체크리스트

ArgoCD App-of-Apps 구조 수립 (플랫폼 코어 전용)
Jenkins 공통 파이프라인 라이브러리 (Shared Library) 정의
Helm Chart 버전 관리 전략 수립 (Semantic Versioning)
GitOps Repository 구조 확정 (모노레포 vs 멀티레포)
팀 간 의존성 매트릭스 작성 (필수)
에스컬레이션 경로 정의 및 유지보수 창(Maintenance Window) 운영 정책 수립 (필수)

Day-2 운영 루틴

주기	업무	상세
일간	ArgoCD Sync 상태 확인	OutOfSync 또는 Degraded 애플리케이션 즉시 조치
주간	ArgoCD Sync 실패 건 리뷰	반복 실패 원인 분석, Helm Chart 수정
월간	Jenkins 파이프라인 성능 최적화	빌드 시간 > 10분인 파이프라인 개선
분기	GitOps 정책 전체 리뷰	불필요한 리소스 정리, 접근 권한 재검토

KPI

지표	목표값
ArgoCD Sync 성공률	> 99%
롤백 소요 시간	< 5분
환경 재현성 (Drift 감지)	ArgoCD Auto-Sync 활성 시 < 3분
빌드 파이프라인 평균 시간	< 10분

3.7 팀원 6 — Artifacts & VM (자산 및 레거시 관리)

Day-1 체크리스트

Nexus Docker Registry (Proxy + Hosted) 구성
Nexus Helm Repository 구성
주요 외부 레지스트리 미러링 설정 (DockerHub, Quay, GCR 등)
KubeVirt Operator 배포 및 Cilium 네트워킹 통합 확인
KubeVirt 수용 대상 VM 워크로드 명세서 작성 (범위 확정)
이미지 보안 스캔 파이프라인 연동 (Trivy 또는 Grype)

Day-2 운영 루틴

주기	업무	상세
일간	Nexus 서비스 헬스체크	이미지 Pull 성공률, 응답 시간 모니터링
주간	KubeVirt VM 상태 점검	Live Migration 실패 건, 자원 사용량 리뷰
월간	이미지 취약점 스캔 리포트	Critical/High CVE 0건 목표 관리
분기	Nexus 디스크 사용량 정리	미사용 이미지 태그 GC, 보관 정책 재검토

KPI

지표	목표값
이미지 Pull 성공률 (내부)	> 99.9%
CVE Critical + High	0건 (골든 이미지 기준)
KubeVirt VM 가용률	> 99.5%
Nexus 응답 시간 (p95)	< 500ms

3.8 팀원 7 — Observability (플랫폼의 눈)

Day-1 체크리스트

Prometheus Agent Mode 배포 (10~15개 수집 그룹으로 분할)
Thanos Querier + Store Gateway 구성
Thanos 메트릭 MinIO 전용 버킷 설정 (팀원 3 협의 완료)
Grafana 플랫폼/테넌트 대시보드 분리 구성
Fluent Bit DaemonSet 배포 (Cilium 메타데이터 테넌시 마킹)
OpenSearch 클러스터 (Hot 3노드 + Warm 3노드 이상)
Alertmanager 알람 라우팅 규칙 정의 (7개 팀별 수신 채널 분리)

Day-2 운영 루틴

주기	업무	상세
일간	알람 발생 건 리뷰	잦은 오탐(False Positive) 규칙 튜닝
일간	OpenSearch 인덱스 상태 확인	Hot 인덱스 용량, 인제스트 파이프라인 지연
주간	Thanos 메트릭 보관 비용 점검	MinIO 버킷 크기 증가 추이 분석 (팀원 3 공동)
월간	대시보드 유효성 검증	미사용 패널 정리, 신규 SLI 반영
분기	OpenSearch Hot → Warm 마이그레이션 정책 리뷰	보관 기간, 인덱스 롤오버 전략 조정

알람 라우팅 맵

Alertmanager Route Tree:
├── node_exporter (CPU/Mem/Disk)  → 팀원 1 (K8s)
├── cilium_*  (BGP/Hubble/Drop)  → 팀원 2 (Cilium)
├── minio_*  (Bucket/Healing)    → 팀원 3 (Storage)
├── keycloak_* / vault_*         → 팀원 4 (Security)
├── argocd_* / jenkins_*         → 팀원 5 (CI/CD)
├── nexus_* / kubevirt_*         → 팀원 6 (Artifacts)
└── thanos_* / opensearch_*      → 팀원 7 (Self)

KPI

지표	목표값
MTTD (Mean Time to Detect)	< 3분
로그 검색 응답 시간	< 5초
알람 오탐율	< 10%
메트릭 장기 보관 가용성	> 99.9% (Thanos + MinIO)

4. Multi-Agent 검토 보완 사항 (필수 적용)

4.1 팀 간 의존성 매트릭스

[!IMPORTANT]
800대 규모 인프라에서는 한 모듈의 장애가 다른 모듈로 연쇄 전파(Cascading Failure)될 수 있습니다. 아래 매트릭스를 기반으로 배포 순서와 장애 대응 우선순위를 결정합니다.

솔루션	의존 대상	영향 범위	담당 협업
K8s API Server	etcd	전체 시스템 마비	팀원 1 단독
Cilium BGP	K8s API, 물리 스위치	전체 네트워크 단절	팀원 1 + 2
Keycloak SSO	CNPG(DB), Cilium(NetworkPolicy)	전체 인증 실패	팀원 2 + 3 + 4
Vault	CNPG(DB Auto-unseal용), Cilium	전체 Secret 주입 실패	팀원 1 + 3 + 4
MinIO	Cilium(bond1 통신), K8s(PV/Operator)	전체 데이터 I/O 중단	팀원 1 + 2 + 3
Thanos	Prometheus Agent, MinIO(장기 저장)	모니터링 가시성 상실	팀원 3 + 7
OpenSearch	Fluent Bit, OpenEBS(로컬 PV)	로그 검색 불가	팀원 3 + 7
ArgoCD	K8s API, Git Repository	플랫폼 코어 배포 불가	팀원 1 + 5
Nexus	로컬 디스크, Cilium(bond0 외부 미러)	이미지 Pull 실패	팀원 2 + 6
KubeVirt	K8s API, Cilium(VM 네트워킹)	레거시 VM 서비스 중단	팀원 1 + 2 + 6

배포 순서 (Bootstrap Order)

Phase 1: K8s Control Plane + etcd (팀원 1)
Phase 2: Cilium CNI + BGP Peering (팀원 2)
Phase 3: OpenEBS / local-path-provisioner (팀원 3)
Phase 4: CNPG PostgreSQL (팀원 3)
Phase 5: Vault HA + Auto-unseal (팀원 4)
Phase 6: Keycloak + AD Federation (팀원 4)
Phase 7: MinIO / AIStor (팀원 3)
Phase 8: Nexus Registry Mirror (팀원 6)
Phase 9: ArgoCD + Jenkins (팀원 5)
Phase 10: Prometheus Agent + Thanos + Grafana (팀원 7)
Phase 11: OpenSearch + Fluent Bit (팀원 7)
Phase 12: Polaris(Iceberg Catalog) (팀원 5 GitOps)
Phase 13: KubeVirt (팀원 6)
Phase 14: Workbench + Operators (개발팀)

4.2 에스컬레이션 경로 및 유지보수 창(Maintenance Window) 정책

분석가 에스컬레이션 경로

분석가가 장애를 인지함
  ├─ Workbench UI에서 "문제 신고" 버튼 클릭
  │    → 자동으로 해당 Namespace의 최근 알람/로그 수집
  │    → Alertmanager 라우팅 기반으로 담당 팀원 자동 배정
  │
  ├─ 1차 대응 (15분 이내)
  │    → 배정된 팀원이 Grafana/Hubble/OpenSearch로 원인 분석
  │    → 타 모듈 연관 시 의존성 매트릭스 기반으로 협업 팀 소환
  │
  └─ 2차 대응 (1시간 이내 미해결 시)
       → 팀원 1(K8s Core) + 팀원 7(Observability) 공동 War Room 개설
       → 근본 원인 분석(RCA) 및 사후 Postmortem 작성

유지보수 창 운영 정책

유형	시간대	사전 공지	영향 범위
긴급 보안 패치	즉시	최소 1시간 전 (Workbench 배너)	최소 범위
플랫폼 코어 업그레이드	매주 토요일 02:00~06:00	3 영업일 전 (이메일 + Workbench)	Keycloak, Polaris 등
K8s/Cilium 노드 업그레이드	매월 첫째 주 토요일	5 영업일 전	랙 단위 순차 (서비스 영향 최소)
MinIO 풀 확장	업무 시간 내 가능	1 영업일 전	무중단 (신규 풀 추가)

5. 핵심 운영 시나리오

5.1 스토리지 풀 무중단 확장 (MinIO Server Pool Addition)

사전 조건: 풀 용량 > 80% 알람 수신
  1. 신규 노드 하드웨어 투입 (팀원 3 주도)
  2. K8s 워커 등록 (팀원 1) + Cilium BGP 피어링 확인 (팀원 2)
  3. MinIO CLI로 Server Pool 추가 (mc admin pool add)
  4. Erasure Coding 수렴 확인 (~24h)
  5. Thanos 전용 버킷 용량 재할당 (팀원 7 협의)
  6. Prometheus로 Read/Write 성능 기준선 재측정
사후: 용량 로드맵 갱신

5.2 대규모 무중단 업그레이드 (K8s + Cilium)

사전 조건: 테스트 랙(10대)에서 카나리 검증 완료
  1. BGP Graceful Restart 모드 활성화 (팀원 2)
  2. 대상 랙 노드 Cordon + Drain (팀원 1)
  3. K8s kubelet 업그레이드 + Cilium Agent 업그레이드
  4. BGP 세션 재수립 확인 (팀원 2)
  5. Uncordon 후 Pod 재스케줄링 확인
  6. Thanos/Hubble로 정상 메트릭 수집 확인 (팀원 7)
  7. 다음 랙으로 이동 (반복)
사후: RCA 리포트, 다음 업그레이드 일정 확정

5.3 대규모 장애 복구 (Rack-level Failure)

트리거: Prometheus → Alertmanager → "Rack-N 전체 노드 NotReady"
  1. 팀원 1: K8s 스케줄러가 자동으로 해당 랙의 Pod를 타 랙으로 재배치
  2. 팀원 2: Cilium BGP ECMP가 장애 경로 자동 우회
  3. 팀원 3: MinIO Erasure Coding이 나머지 풀에서 읽기 서비스 유지
  4. 팀원 7: OpenSearch에 장애 시점 로그 마킹, Grafana에 인시던트 어노테이션
  5. 물리적 복구 후: MinIO Reconstructor가 데이터 블록 자동 복원 (~24h)
사후: Postmortem 작성, 토폴로지 Spread 정책 재검토

5.4 보안 사고 대응 (AD 계정 탈퇴/권한 회수)

트리거: AD 계정 비활성화 이벤트
  1. 팀원 4: Keycloak LDAP Sync → 세션 즉시 무효화 (< 5분)
  2. Workbench: 해당 Namespace 엔진 자동 정지 (Scale to zero)
  3. 팀원 4: Vault에서 해당 사용자 Secret 경로 접근 차단
  4. 팀원 7: OpenSearch 감사 로그 아카이빙
사후: 분기 감사 리포트에 포함

6. 주간/월간 동기화 체계

미팅	주기	주도	참석	안건
Hubble View	주간 (화)	팀원 2 + 7	전원	트래픽 병목 현황, 알람 리뷰, QoS 조정
Storage Sync	주간 (목)	팀원 3	팀원 1, 7	용량 추이, Healing 상태, Thanos 버킷 리뷰
Security Gate	월간	팀원 4 + 5	전원	Secret Rotation 결과, 접근 권한 감사, 취약점 스캔 결과
Platform Review	분기	팀원 5	전원	업그레이드 로드맵, 의존성 매트릭스 갱신, KPI 달성도

7. 가정 및 제약 사항

가정 (Assumptions)

800대 노드 간 BGP 피어링이 원활하며, bond1(내부망) 대역폭이 대규모 Shuffle 트래픽을 감당할 수 있다.
Keycloak OIDC 기반의 인증이 모든 플랫폼 서비스(Jupyter, Airflow 등)에 일관되게 적용 가능하다.
초기에는 Namespace별 Strict ResourceQuota를 적용하여 자원 파편화를 제어한다.
Vault는 민감 정보 저장 용도로 시작하나, 안정화 후 KMS/동적 계정 등으로 기능을 확장할 수 있다.

제약 사항 (Constraints)

DR(재해 복구) 시설은 미구축 상태이며, 일부 버킷에 한해 복제(Replication)만 적용한다.
KubeVirt로 수용할 레거시 VM의 범위는 아직 미확정이며, 별도 협의가 필요하다.
Kafka(로그 버퍼)는 현재 선택 사항이며, OpenSearch 인제스트 부하에 따라 추후 결정한다.

문서 검토 상태: Multi-Agent Brainstorming 완료
최종 판정: ✅ APPROVED (4건 보완 사항 반영 완료)

Young-Kyoo Kim

engineer

이전 포스트

26F26I

다음 포스트

Feb28a

Cloud Native Data Lakehouse 운영 계획서

DevOps 관점 — 800대 규모 (Compute 600 / Storage 200)

1. 프로젝트 개요

1.1 목적

1.2 대상 사용자

1.3 운영 모델

1.4 비목표 (Explicit Non-Goals)

2. 확정 아키텍처

2.1 솔루션 스택 종합

2.2 핵심 기술 결정 사항 (Decision Log)

3. 팀 구성 및 모듈별 운영 계획

3.1 운영 TF 구성

3.2 팀원 1 — K8s Core (인프라의 척추)

Day-1 체크리스트 (구축 완료 기준)

Day-2 운영 루틴

KPI

3.3 팀원 2 — Cilium / BGP (초고속 데이터 혈관)

Day-1 체크리스트

Day-2 운영 루틴

KPI

3.4 팀원 3 — Storage (데이터의 요새)

Day-1 체크리스트

Day-2 운영 루틴

풀 확장 절차 (SOP)

KPI

3.5 팀원 4 — IAM & Security (보안 파수꾼)

Day-1 체크리스트

Day-2 운영 루틴

AD 계정 삭제 시 즉시 회수 프로세스 (SOP)

KPI

3.6 팀원 5 — CI/CD & Automation (운영 자동화 엔진)

Day-1 체크리스트

Day-2 운영 루틴

KPI

3.7 팀원 6 — Artifacts & VM (자산 및 레거시 관리)

Day-1 체크리스트

Day-2 운영 루틴

KPI

3.8 팀원 7 — Observability (플랫폼의 눈)

Day-1 체크리스트

Day-2 운영 루틴

알람 라우팅 맵

KPI

4. Multi-Agent 검토 보완 사항 (필수 적용)

4.1 팀 간 의존성 매트릭스

배포 순서 (Bootstrap Order)

4.2 에스컬레이션 경로 및 유지보수 창(Maintenance Window) 정책

분석가 에스컬레이션 경로

유지보수 창 운영 정책

5. 핵심 운영 시나리오

5.1 스토리지 풀 무중단 확장 (MinIO Server Pool Addition)

5.2 대규모 무중단 업그레이드 (K8s + Cilium)

5.3 대규모 장애 복구 (Rack-level Failure)

5.4 보안 사고 대응 (AD 계정 탈퇴/권한 회수)

6. 주간/월간 동기화 체계

7. 가정 및 제약 사항

가정 (Assumptions)

제약 사항 (Constraints)

26F26I

Mar04a

0개의 댓글