🔥 The Hook & TL;DR: 왜 우리는 vLLM에 열광하는가? 솔직히 까놓고 얘기해 봅시다. 사내에서 PoC 단위로 LLM 띄울 때는 다들 행복합니다. 7B, 13B 모델 하나 올려놓고 “와, 대답 잘하네요!” 하며 박수 치죠. 그런데 이걸 실제 프로덕션에 올리고, 동시 접속자가 10명, 50명, 100명으로 늘어나는 순간 인프라팀에 ...

eBPF와 Cilium: 사이드카(Sidecar) 없는 서비스 메시는 과연 구원일까, 또 다른 재앙일까? 여러분의 쿠버네티스 클러스터, 지금 Istio Envoy 사이드카가 메모리를 얼마나 집어삼키고 있나요? 솔직해집시다. 서비스 메시는 마이크로서비스 아키텍처의 빛과 소금이라고 배웠지만, 막상 현업에 적용해 보면 수십, 수백 개의 파드(Pod)마다 ...

🔗 Reference Links eBPF Foundation Cilium Project BPF Compiler Collection (BCC) 🔥 1. Kube-proxy의 비명 소리, 들어보셨나요? (The Hook) 새벽 3시, 온콜(On-call) 알림이 울립니다. “API 서버 응답 지연 발생”. App 로그는 깨끗하고, DB ...

🔗 Reference Links eBPF 공식 문서 (ebpf.io) Cilium GitHub Repository SIGCOMM ‘20: The eBPF / XDP Architecture 🔥 The Hook & TL;DR: 트래픽이 터졌는데 CPU가 네트워크 룰을 읽다 죽어버린다고요? 몇 년 전 대규모 트래픽이 몰리던 블랙...

🔥 1. 프롤로그: 우리는 왜 여전히 네트워크 병목에 시달리는가? 솔직히 까놓고 얘기해 봅시다. 쿠버네티스(Kubernetes) 환경에서 대규모 트래픽 좀 받아봤다 하는 분들 중에, iptables 때문에 새벽에 등골 서늘해진 경험 없으신 분 있나요? 노드 수가 100개, 500개로 늘어나고, 마이크로서비스가 잘게 쪼개지면서 서비스 엔드포인트가 수만...

새벽 3시, 슬랙 온콜 채널이 미친 듯이 울리기 시작합니다. 대규모 선착순 쿠폰 이벤트에 트래픽이 몰리면서 메인 Redis 클러스터의 레이턴시가 폭증했기 때문이죠. 서둘러 CloudWatch 대시보드를 켜보니, 전체 메모리 사용량은 10%도 안 되는데 CPU 1번 코어만 100%를 찍고 장렬히 산화하고 있습니다. 서버 장비는 64코어짜리 최고급 스펙인...

🔗 References & Deep Dives:- Cilium Official Docs: eBPF-based Networking- Linux Kernel Archive: BPF Documentation- The eBPF Foundation Architecture Drafts<h3>🔥 들어가는 말: “우리 서비스, 왜 이렇게 무겁고 느...

[Metadata] 📄 Paper: From Local to Global: A Graph RAG Approach to Query-Focused Summarization 🐙 GitHub: microsoft/graphrag 🛠️ Tech Stack: Python, Neo4j, LangGraph, GPT-4o, vLLM (Llama-3-8B) ...

마이크로서비스 아키텍처(MSA)가 은탄환인 줄 알았던 시절이 있었습니다. 그런데 막상 뚜껑을 열어보니 어땠나요? 서비스 간의 통신과 트래픽을 정교하게 제어하겠다고 Istio나 Linkerd 같은 서비스 메시(Service Mesh)를 도입하는 순간, 우리는 ‘사이드카(Sidecar) 프록시’라는 거대한 괴물과 마주하게 됩니다. “팀장님, 비즈니스 로...

🔗 Reference Links eBPF Official: https://ebpf.io/ Cilium Project: https://cilium.io/ BCC (BPF Compiler Collection): https://github.com/iovisor/bcc 🔥 The Hook: 사이드카(Sidecar)의 배신, 그리고 커널과의 타...