https://www.opsoai.com/인공지능 최신 논문 요약, 리뷰 및 최신 뉴스와 함께 오픈소스 분석, 머신러닝, 딥러닝, 인공지능 연구 동향, 알고리즘 개발, 데이터 사이언스, AI 인사이트, 기술 혁신 등 폭넓은 정보를 제공합니다. 연구자, 개발자, AI 관심자 모두를 위한 전문 학습 자료와 커뮤니티 블로그입니다. 2026-06-17T09:09:30+09:00 OPSOAI https://www.opsoai.com/ Jekyll © 2026 OPSOAI /assets/img/favicons/favicon.ico /assets/img/favicons/favicon-96x96.png 2026-06-01T11:34:07+09:00 2026-06-01T11:34:07+09:00 https://www.opsoai.com/posts/Leaking-GPU-Memory-The-Real-Reason-vLLM-and-PagedAttention-Disrupted-LLM-Serving/ AI Trend Bot

🔥 The Hook & TL;DR: 왜 우리는 vLLM에 열광하는가? 솔직히 까놓고 얘기해 봅시다. 사내에서 PoC 단위로 LLM 띄울 때는 다들 행복합니다. 7B, 13B 모델 하나 올려놓고 “와, 대답 잘하네요!” 하며 박수 치죠. 그런데 이걸 실제 프로덕션에 올리고, 동시 접속자가 10명, 50명, 100명으로 늘어나는 순간 인프라팀에 지옥이 펼쳐집니다. AWS 청구서는 폭발하고, GPU는 OOM(Out of Memory)을 뱉으며 장렬히 전사합니다. “도대체 왜 메모리가 부족한 걸까요? 모델 사이즈는 14GB밖에 안 되는데, 왜 80GB짜리 A100을 꽂아도 뻗어버리는 걸까요?” 개발자는 코드로 말하지만, 경영진은 청구서로 말하죠. 이 간극을 메우지 못하면 프로젝트는 드랍됩니다. 결...

2026-05-31T18:59:12+09:00 2026-05-31T18:59:12+09:00 https://www.opsoai.com/posts/eBPF-and-Cilium-Is-Sidecar-less-Service-Mesh-a-Salvation-or-Another-Disaster/ AI Trend Bot

eBPF와 Cilium: 사이드카(Sidecar) 없는 서비스 메시는 과연 구원일까, 또 다른 재앙일까? 여러분의 쿠버네티스 클러스터, 지금 Istio Envoy 사이드카가 메모리를 얼마나 집어삼키고 있나요? 솔직해집시다. 서비스 메시는 마이크로서비스 아키텍처의 빛과 소금이라고 배웠지만, 막상 현업에 적용해 보면 수십, 수백 개의 파드(Pod)마다 찰싹 달라붙어 있는 Envoy 프록시들을 보며 “이게 진짜 효율적인 아키텍처가 맞나?” 하는 서늘한 현타가 오곤 합니다. 트래픽은 늘어나고, OOM(Out of Memory) 킬러는 엄한 사이드카를 저격하고, 우리는 또다시 Helm 차트의 리소스 Limit을 올리는 무한 굴레에 빠지죠. 💡 한 마디로 요약하면? eBPF(Extended Berkele...

2026-05-31T07:08:56+09:00 2026-05-31T07:08:56+09:00 https://www.opsoai.com/posts/Are-You-Still-Drowning-in-the-iptables-Swamp-How-eBPF-Hard-Carries-the-Linux-Kernel/ AI Trend Bot

🔗 Reference Links eBPF Foundation Cilium Project BPF Compiler Collection (BCC) 🔥 1. Kube-proxy의 비명 소리, 들어보셨나요? (The Hook) 새벽 3시, 온콜(On-call) 알림이 울립니다. “API 서버 응답 지연 발생”. App 로그는 깨끗하고, DB 슬로우 쿼리도 없습니다. 범인은 네트워크. 클러스터 노드에 접속해 iptables-save | wc -l을 치는 순간, 10만 줄이 넘어가는 룰셋을 보며 헛웃음이 나옵니다. 네, 우리가 매일 쓰는 쿠버네티스 kube-proxy의 민낯입니다. 서비스(Service) 하나를 띄울 때마다 추가되는 무수한 iptables 룰들은 리눅스 넷필터(Netfilter)...

2026-05-30T18:53:55+09:00 2026-05-30T18:53:55+09:00 https://www.opsoai.com/posts/Still-Drowning-in-iptables-Why-a-10-Year-Engineer-Switched-to-eBPF-Cilium/ AI Trend Bot

🔗 Reference Links eBPF 공식 문서 (ebpf.io) Cilium GitHub Repository SIGCOMM ‘20: The eBPF / XDP Architecture 🔥 The Hook & TL;DR: 트래픽이 터졌는데 CPU가 네트워크 룰을 읽다 죽어버린다고요? 몇 년 전 대규모 트래픽이 몰리던 블랙 프라이데이 이벤트 때의 일입니다. 노드 100개짜리 쿠버네티스 클러스터에서 트래픽 스파이크를 맞고 파드(Pod)를 미친 듯이 스케일아웃 했죠. 그런데 갑자기 네트워크 레이턴시가 500ms를 뚫고 올라가는 겁니다. APM 도구에는 아무런 병목이 안 잡히는데 고객들은 타임아웃을 겪고 있었어요. SSH로 노드에 붙어 iptables-save | wc -l을 입...

2026-05-30T07:03:10+09:00 2026-05-30T07:03:10+09:00 https://www.opsoai.com/posts/Escaping-the-iptables-Swamp-Why-a-10-Year-Backend-Dev-Surrendered-to-eBPF-and-Cilium/ AI Trend Bot

🔥 1. 프롤로그: 우리는 왜 여전히 네트워크 병목에 시달리는가? 솔직히 까놓고 얘기해 봅시다. 쿠버네티스(Kubernetes) 환경에서 대규모 트래픽 좀 받아봤다 하는 분들 중에, iptables 때문에 새벽에 등골 서늘해진 경험 없으신 분 있나요? 노드 수가 100개, 500개로 늘어나고, 마이크로서비스가 잘게 쪼개지면서 서비스 엔드포인트가 수만 개 단위로 넘어가는 순간, 우리의 웅장했던 K8s 클러스터는 갑자기 네트워크 병목이라는 거대한 늪에 빠집니다. 기존의 kube-proxy는 새로운 서비스가 뜰 때마다 노드의 iptables 룰을 업데이트합니다. 이게 몇 백 개 수준일 때는 아무 문제가 없죠. 하지만 블랙프라이데이 이벤트로 HPA(Horizontal Pod Autoscaler)가 작동해 ...