khseon7 님의 블로그

AI 모델을 쓴다는 것은 지금까지 곧 텍스트를 받는 일이었다. 무엇을 묻든 문장이 돌아왔고, 우리는 그 문장에서 필요한 값을 다시 꺼내 썼다. 그런데 실제 서비스 코드가 모델에게 시키는 일을 들여다보면 상당수는 문장이 필요 없다. 이 문의가 결제 문제인지 기술 문제인지, 이 쉘 명령어를 실행해도 안전한지 같은 질문은 답이 나올 수 있는 범위가 이미 정해져 있다.2026년 9월 15일 공개된 Jev는 정확히 이 지점만 노린 모델이다. 텍스트를 한 글자도 생성하지 않고, 미리 정의한 질문에 대해 정해진 타입의 답과 확률만 돌려준다. 만든 곳은 TypeSafe AI라는 스타트업이고, 창업자는 OpenAI에서 RLHF와 ChatGPT 개발에 참여했던 Diogo Almeida다.공개 데모부터 성격이 드러난다. 채..

지난 포스팅에서 Istio의 Fault Injection 기능을 활용해 강제로 500 에러를 유도하고, Flagger가 이를 감지해 자동으로 롤백하는 시나리오를 기대하며 글을 마쳤다. 하지만 기대와 달리, 한 번 더 테스트를 진행해 보아도 여전히 메트릭은 잡히지 않았고 Flagger는 Metric가 보이지 않아 Halt 상태에 빠져버렸다. 처음에는 왜 메트릭 수집이 먹통인지 답답함이 밀려왔다.결국 문제를 해결하기 위해 실시간으로 트래픽을 처리하고 메트릭을 생성하는 주체인 Envoy Proxy(istio-proxy) 단에서 정확히 어떤 작업과 데이터 흐름이 이루어지고 있는지 하나씩 뜯어보기로 했다.분석 결과, 제가 작성한 VirtualService 규칙과 Flagger가 메트릭을 바라보는 시점 사이에 치명..

지난 포스팅에서 Flagger를 통해 Metrics 기반 롤백을 구현했다. 이때 서버 접속시 500에러가 뜨는 부분을 만들기 위해 임의로 VirtualService를 apply -f 하여 적용을 해보았으나, Prometheus에서 메트릭을 확인할 수 없어 에러가 발생했었다. 이번 포스팅에서는 이러한 문제가 생긴 이유를 분석한다.Flagger가 메트릭을 확인하지 못한 이유결론부터 말하자면, 수동으로 적용한 VirtualService가 트래픽을 100% 독점하며 플래거가 감시해야 할 신버전의 메트릭 자체가 완전히 증발했기 때문이다. 시스템 내부의 유기적인 원인은 다음과 같다.1. 신버전 테스트 트래픽의 완벽한 차단 (Traffic Hijacking)수동으로 적용한 VirtualService 설정을 보면 pe..

이전 포스팅에 이어서, 이번에는 단순한 트래픽 제어를 넘어 시스템이 스스로 지표를 판단하고 의사결정을 내리는 점진적 전달 체계를 구축했다.지난 실습이 Istio를 통해 엔지니어의 의도대로 트래픽을 흐르게 하는 과정이었다면, 이번 과정은 Prometheus와 Flagger를 연동하여 지표를 근거로 배포의 성공 여부를 확언하고, 장애 시 즉각적인 통제권을 행사하는 역량을 확보하는 데 집중했다.특히 시스템 하단에서 발생하는 변수를 통제하고자 하는 엔지니어링 관점에서, Flagger를 활용해 수동 개입 없이도 안정성을 보장할 수 있는 환경을 설정한 과정을 공유한다.1. Flagger란?Flagger는 kubernetes 환경에서 애플리케이션 배포 전략을 자동화하는 Progressive Delivery 오퍼레이터..

지난 포스팅에서는 AWS EKS 클러스터 위에 서비스를 배포하고, 별도의 라우팅 설정 없이 트래픽이 흐르는 모습을 관찰했다. 당시 Istio 내부 설정이 없어 EKS 내부의 쿠버네티스 서비스는 모든 파드에 트래픽을 균등하게 배분하는 라운드 로빈 방식으로 동작했다.이번 포스팅에서는 이 기본 모드를 해제하고, 엔지니어가 직접 가중치를 조정해보는 과정을 기록한다. Istio의 VirtualService를 적용하여 트래픽의 비율을 정교하게 제어하는 카나리 배포를 수행하고, 이 통제가 의도대로 이루어지는지 Prometheus와 Grafana를 통해 기술적 근거를 확보해 보겠다.1. 카나리 배포(Canary Deployment)란?카나리 배포는 새로운 소프트웨어 버전을 전체 사용자에게 한꺼번에 배포하기 전, 일부 ..

서비스 메시란? - 서비스 메시 설명 - AWS서비스 메시란 무엇이고 비즈니스에서 서비스 메시를 사용하는 방법 및 이유와 AWS를 통해 서비스 메시를 사용하는 방법을 알아봅니다.aws.amazon.com istio/samples/bookinfo/platform/kube/bookinfo.yaml at master · istio/istioConnect, secure, control, and observe services. Contribute to istio/istio development by creating an account on GitHub.github.com얼마 전 참여했던 Dev Meetup에서 가장 흥미롭게 들었던 부분은 Service Mesh 중 Istio 였다. "애플리케이션 코드 수정 없이 ..

https://arxiv.org/abs/2504.19874 TurboQuant: Online Vector Quantization with Near-optimal Distortion RateVector quantization, a problem rooted in Shannon's source coding theory, aims to quantize high-dimensional Euclidean vectors while minimizing distortion in their geometric structure. We propose TurboQuant to address both mean-squared error (MSE) and innerarxiv.orgAI 모델이 커질수록 가장 먼저 문제가 되는 것은 단..

기존에 docker-compose로 간단히 구축하던 Personal AI Dispatcher 서비스를 쿠버네티스(Minikube) 환경으로 이관하여 가시성을 확보하기 위해 모니터링 시스템을 구축했다. 단순 설치를 넘어 k8s 네트워크 계층과 Prometheus Operator의 동작 원리를 이해했던 내용들을 정리한다.1. Application Layer: Prometheus Metrics 서버 구축먼저 Python 앱에서 지표를 노출하기 위해, prometheus_client 라이브러리를 활용해 메트릭 서버를 별도의 스레드로 실행했다.💡 지표 정의와 'Lazy Initialization'의 함정프로메테우스의 Counter는 선언만 한다고 데이터가 생성되지 않는다. 실제로 데이터가 기록되기 전까지는 En..

Oracle Cloud와 같은 클라우드 무료 티어나 저가형 서버를 쓰다 보면 당황스러운 순간이 온다. Docker를 올리거나 Nginx 설정을 바꾸는데 갑자기 터미널이 멈추고 서버 접속이 끊겨버리는 경우가 있다.원인은 명확하다. 1GB라는 미니미한 RAM 용량 때문입니다. 서버가 처리할 데이터는 많은데 담을 그릇이 부족하니 결국 서버가 '기절'해버리는 것이다. 오늘은 이 좁은 그릇을 대신해 하드디스크의 일부를 메모리처럼 사용하는 Swap(스왑) 설정으로 서버에 8GB급 맷집을 키워보자.🛠️ 1GB RAM 서버 심폐소생술 (Swap 7GB 설정)1. 7GB 크기의 빈 공간 확보하기서버 안에 7GB짜리 거대한 빈 파일을 만든다. 약 10~20초 정도 소요sudo fallocate -l 7G /swapfil..

대규모 언어 모델을 포함한 AI 서빙 환경에서 가장 치명적인 위협은 CPU 부하가 아닌 메모리 고갈(OOM, Out Of Memory)이다. CPU 부하는 서비스의 지연을 초래하지만, 메모리 임계치 초과는 쿠버네티스 커널에 의한 컨테이너 즉시 사살로 이어지기 때문이다.이번 실습에서는 의도적으로 메모리 부하를 일으켜 k8s의 Self-healing 메커니즘과 메모리 기반 HPA(Horizontal Pod Autoscaler)의 실제 동작 방식을 분석했다.실험 환경 구축Infra: Minikube (Metrics Server 활성화)Monitoring: Prometheus & Grafana (w. Helm)App: Flask 기반의 'Mock-LLM' 서버 (요청 시마다 20MB씩 메모리 점유하는 로직 구현..