하얀잔디

NVIDIA Omniverse 란

시뮬리에션 로봇과 같은 Physical AI를 개발하고 검증할 수 있도록 현실과 유사한 가상환경을 구축하고 시뮬레이션하는 플랫폼임! Omniverse는 로봇 학습만을 위한 기술은 아니고 크게 세 가지 목적으로 활용됨.로봇 AI 학습: 가상환경에서 로봇이 물건을 집거나 이동하는 행동을 반복적으로 학습로봇 동작 검증: 학습한 로봇이 장애물을 피하거나 안전하게 동작하는지 테스트디지털 트윈: 실제 공장이나 물류창고를 가상으로 구현해 설비 배치와 생산 효율 등을 검증 여기서 구분해야 할 건:Omniverse: 가상환경과 시뮬레이션을 구축하는 기반 플랫폼Isaac Sim: Omniverse 기반으로 로봇 시뮬레이션을 수행하는 도구Isaac Lab: 시뮬레이션 환경을 활용해 로봇 AI를 학습시키는 프레임워..

쿠베에 GPU 꽂아도 바로 못 쓰는 이유

서버에 그래픽카드 꽂는다고 쿠베가 알아서 인식하지 않는다. 개념좀 잡으려고 글쓴다NVIDIA Driver: OS용 드라이버Container Toolkit: 컨테이너가 GPU 접근할 수 있게 뚫어줌Device Plugin: 쿠베 노드에 GPU 몇 개 있는지 리소스로 등록DCGM Exporter: GPU 온도/사용률 모니터링이걸 노드마다 수동으로 세팅하면 지옥이라, 데몬셋으로 한번에 밀어 넣고 관리해 주는 게 GPU Operator다. 할당 팁대형 LLM은 보통 Pod 1개가 GPU 1장(이상)을 통째로 먹는다. 반면 가벼운 음성/비전 모델은 MIG 써서 GPU 1대를 물리적으로 쪼개 여러 Pod에 나눠주는 게 돈 아끼는 길. GPU 구조 & KV Cache 우선 요약SM / Core: 일하는 작업자VR..

검토 배경 현재 API 응답 지연 발생 시 Gateway의 request_id와 API 로그의 trace.id를 기준으로 원인 분석 중임.다만 API 내부에서 DB 조회, Redis 처리, 외부 Interface 호출 중 어느 구간에서 시간이 많이 소요되는지 확인하려면 개별 로그를 분석해야 하는 불편함 있음.이를 개선하기 위해 OpenTelemetry + Tempo 기반 분산 추적 방식 확인함. OpenTelemetry / Tempo 역할 OpenTelemetry(OTel): API, DB, Redis, 외부 HTTP 호출 등의 실행 시간과 호출 관계를 수집하는 오픈소스 도구OTel Collector: 수집된 데이터를 중간에서 필터링, 배치 처리 후 저장소로 전달하는 역할 (필수 아님)Tempo: OT..

최근 운영 중인 파일 API에서 응답 지연이 발생해 NFS 상태를 확인했다. 기존엔 0.05초 이내로 서빙되던 파일이 0.5초 넘게 걸리는 현상이 발견되었다. 확인 과정에서 NFS 서버로 들어오는 TEST_STATEID 요청이 초당 약 200~300회 반복되는 현상을 발견했다. NFS 서버 자체의 문제인지, 클라이언트가 이전 상태를 계속 확인하는 것인지 살펴봤고, 개발 환경에서 먼저 NFS 클라이언트 강제 만료(Expire)를 테스트한 뒤 운영 환경에도 적용했다.이번에 사용한 명령어와 확인 과정을 정리해 둔다.1. NFS 서버와 클라이언트 확인먼저 어느 서버가 NFS 서버이고, 어디서 마운트해 사용하고 있는지 확인했다.NFS 클라이언트(WAS)에서 실행한다.findmnt -t nfs,nfs4실제 개발 환..

1. 작업 배경서비스를 운영하다 보면 CPU나 메모리 사용률은 정상인데 실제로는 API 오류가 발생하거나 응답이 느려지는 경우가 있다.기존에는 Prometheus와 Grafana를 통해 서버 상태를 모니터링하고, 장애가 발생하면 OpenSearch에서 로그를 직접 검색해 원인을 확인했다.그런데 장애가 발생할 때마다 로그를 조회하고, 어떤 API에서 오류가 발생했는지 확인하고, 파드 상태까지 하나씩 살펴보는 과정이 생각보다 번거로웠다.그래서 장애를 자동으로 감지하고, 관련 로그와 메트릭을 AI가 분석해 원인까지 알려주는 기능을 만들어봤다. 2. 장애 감지 및 텔레그램 알림먼저 장애를 빠르게 인지하기 위해 모니터링 항목을 추가했다. Gateway 모니터링NGINX Gateway 로그를 기반으로 5xx 오류..

요즘 AIOps 관련해서 이것저것 보다가 간단하게 PoC 해봄.목표는 자동 장애조치 같은 거창한 건 아니고, Prometheus 메트릭이랑 OpenSearch 로그를 AI가 읽고 분석하게 해서 장애 확인할 때 도움받는 정도임.기존에는 장애나 성능 이슈가 생기면 Grafana에서 메트릭 확인하고, OpenSearch 들어가서 같은 시간대 로그 찾고, 다시 비교하는 식으로 봤음.이걸 조금 편하게 해보려고 자연어로 질문하면 필요한 데이터를 조회해서 정리해주는 형태로 만들어봄.예를 들면 이런 식으로 물어볼 수 있음.최근 30분 동안 API 쪽에 이상 있었는지 확인해줘15시 이후 응답시간이 느려진 원인 찾아줘CPU 올라간 시간대에 에러 로그도 같이 증가했는지 봐줘 구성은 로컬 PC에서 Python으로 간단하게 만..

Kubernetes에서 여러 Pod를 운영하다 보면 특정 Pod만 CPU가 튀거나 응답이 느려지는 경우가 있음.Pod A → 50msPod B → 60msPod C → 3초기본 Kubernetes Service는 Pod C가 느리다고 해서 자동으로 해당 Pod를 제외해주지는 않음.HPA를 사용하면 CPU 증가에 따라 Pod를 추가할 수 있지만, 느린 Pod를 직접 피하는 방식은 아님.그래서 Service Mesh를 찾아봄. Linkerd Linkerd는 Pod에 Proxy를 붙여 서비스 간 통신을 관리함.특히 Latency-aware Load Balancing을 통해 최근 응답시간이 빠른 Endpoint를 선호하도록 트래픽을 분산할 수 있음. Pod A → 50msPod B → 60msPod C → 3..

Node JS 에서 나타났던 상황이지만 Java 등 모든 WAS서버에서 나올수 있는 상황 상황 DB 커넥션 풀이 꽉 차서 API가 504 뜨고, 완전 가벼운 API도 덩달아 느려지고, SequelizeConnectionAcquireTimeoutError까지 터짐. 원인 파보니 트랜잭션 하나를 안 닫고 있었음.문제 코드이미 있으면 그거 리턴, 없으면 새로 생성 패턴에서 나왔던 실수임.const findOrCreateRoom = async (userId: string) => { const transaction = await sequelize.transaction() // 커넥션 하나 확보 try { const existing = await Room.findOne({ where: { u..

Pod별 CPU / Memory 사용량을 확인하기 위해 Kubernetes의 kubelet cAdvisor metric을 활용함. cAdvisor는 각 Node의 10250 포트를 통해 metric을 제공하고 있어서, 해당 endpoint를 Prometheus에서 조회하도록 구성함. 다만 kubelet API이기 때문에 그냥 접근하지 않고 ServiceAccount + RBAC을 구성해서 인증/권한을 설정함.Prometheus ↓RBAC 인증 ↓kubelet :10250 ↓/metrics/cadvisor ↓Pod별 CPU / Memory 이후 Prometheus에서 cAdvisor metric을 수집하고 Grafana에서 namespace, pod 기준으로 조회하도록 구성함. CPU..

운영 서버 로그를 보다 보면 Vite 관련 요청이나 /.env, /.git, /admin 같은 이상한 외부 요청이 들어오는 경우가 있음.이런 요청이 들어왔다고 무조건 서버가 공격받았다고 볼 필요는 없음. 중요한 건 무엇을 요청했는가보다 서버가 무엇을 응답했는가임.1. 외부에서 불필요한 파일이 노출되지 않는지 확인특히 아래 파일들은 외부 접근이 불가능해야 함..env.git/.git/configvite.config.jspackage.jsondocker-compose.yml/.env → 200 OK처럼 실제 파일 내용이 반환된다면 바로 확인 필요.2. 개발 서버를 운영에 그대로 노출하지 않기Vite 개발 서버나 각종 개발용 포트를 외부에 그대로 열어두지 않는 게 중요함.운영에서는 보통Vite ↓npm bui..