Kubernetes로 대용량 오픈소스 웹 상용화하기 시리즈 목차
- 대용량 트래픽을 고려한 오픈소스 선정 및 분석 (현재글)
- 컨테이너화와 Kubernetes 리소스 관리 (Pod, Deployment, StatefulSet)
- Helm chart로 Kubernetes에 오픈 소스 웹 배포하기
- Kubernetes 서비스(Service) 및 Ingress 관리 (HTTP 및 gRPC 프로토콜 이해)
- 보안 강화를 위한 인증서(Certificate) 관리
- 서비스 안정성을 위한 튜닝(성능테스트, HA 구성, 리소스 최적화)
1. 대용량 트래픽을 고려한 오픈소스 선정 및 분석
이번 시리즈에서는 대용량 트래픽을 처리할 수 있는 오픈소스 웹 서비스를 직접 Kubernetes 클러스터 환경에 배포하여 상용화했던 과정을 단계적으로 다룹니다. 첫 번째 글에서는 해당 오픈 소스를 선정한 이유, 오픈소스 사용 시 고려해야 할 라이센스, 오픈 소스의 아키텍처 및 공식 문서를 파악했던 방법 대해 살펴보겠습니다.
목적 및 대상
AI Agent 개발자들이 Agent 어플리케이션 및 LLM을 시각화, 모니터링, 튜닝할 수 있는 환경 제공이 필요했습니다.
특징은 웹 자체의 사용자는 약 100명 내외로 적은 편이지만 AI 애플리케이션 사용자는 10만명 예상으로, 최소 100 RPS 이상 감당해야 합니다.
-> Langfuse VS Langtrace를 리서치로 찾아내었습니다.
오픈소스 서비스 선정 기준
리서치 후 Langfuse가 선택되었는데 그 기준은 아래와 같았습니다.
- 서비스 목적과 기능이 명확하며 커뮤니티가 활발한가? 깃허브 이슈, discussion, discord 등의 커뮤니티가 활발합니다. 이슈에 대한 답변이 1일 내로 매우 빠른 편으로 버그 수정이 적극적으로 반영되고 있었습니다. 한달에 2-3개 이상 다음 버전 출시 텀 또한 짧았습니다.
- 트래픽 처리 능력과 확장성이 뛰어난가? 공식 문서에서 제공하는 벤치마크에 따르면 Langfuse SDK를 사용 시 약 3,759 RPS 처리 가 가능하다고 합니다. (100*0.000266≈3,759.4) https://langfuse.com/guides/cookbook/langfuse_sdk_performance_test
- 쿠버네티스(Kubernetes) 환경과 호환성이 좋은가? 공식 문서에서 정식으로 지원하는 것은 물론이며, 헬름 차트까지 제공하고 있었습니다. https://langfuse.com/self-hosting/kubernetes-helm
라이센스 및 티어 확인
오픈소스 프로젝트를 상용화할 때는 라이센스를 필히 검토해야 합니다.
- Langfuse는 MIT License로 배포되어 상업적 이용이 자유롭습니다.
- 상용 서비스 구축 시 법적 문제를 최소화할 수 있습니다.
다만 Self-hosted로 직접 배포할 때, Enterprise 버전과 제공하는 기능에 차이가 있었습니다.
특히나 Security 쪽에서 관리자용 API 및 RBAC은 Enterprise 버전에서만 제공하고 있었죠.
https://langfuse.com/pricing-self-host
공식 문서 파악하기
상용 서비스 구축을 위해 공식 문서를 체계적으로 검토하였습니다.
한 번에 모든 문서와 깃코드를 확인할 수는 없었기 때문에 작업 때 수시로 확인했습니다.
공식 문서에서 설치 가이드, 환경 설정, API 명세, 운영 가이드 등을 세부적으로 확인할 수 있습니다.
Langfuse 아키텍처 파악
이제 선정과 라이센스를 확인했으니 오픈 소스 웹 서비스의 구조인 아키텍처를 확인해야 합니다.
Langfuse의 Self-hosted 오픈소스 버전은 다음과 같은 주요 컴포넌트로 구성되어 있었습니다.
- Web UI (Next.js 기반): 사용자 인터페이스 제공 및 데이터 시각화
- API Server (Express.js 기반): 데이터 처리 및 저장 요청을 처리하는 백엔드 서버
- ClickHouse: 대규모 로그 데이터 처리를 위한 고성능 분석용 데이터베이스
- PostgreSQL: 메타데이터 및 사용자 정보 관리
- Redis: Langfuse는 작업 큐 처리 및 임시 데이터 캐시
- ZooKeeper: ClickHouse의 메타데이터 동기화를 위한 클러스터
- S3 or Minio: 이벤트 보조 저장소
아키텍처를 파악하며 운영 시 발생하는 비용 문제도 빼놓을 수 없죠.
모든 컴포넌트 및 리소스를 쿠버네티스에 올릴지, 혹은 몇 리소스는 클라우드에 올리는 방안을 생각해볼 수 있습니다.
특히 DB는 확장과 장애대처 관점에서 클라우드 서비스의 관리가 용이할 수 있습니다.
Clickhouse를 클라우드에 올릴 수 있었다면 관리하기 수월했겠지만 Azure에서는 제공하지 않는 서비스였습니다.
따라서 PostgreSQL과 S3만 스토리지 관리를 위해 클라우드 서비스로 사용하기로 했습니다.
다음 글 예고
다음 글에서는 Langfuse를 컨테이너화하여 Kubernetes 환경에 배포한 과정을 다루겠습니다. Pod, Deployment, PVC 등을 활용한 리소스 구조와 helm chart 사용 이유까지 다루겠습니다.
'Technical architecture > Kubernetes' 카테고리의 다른 글
| Kubernetes로 대용량 오픈소스 웹 상용화하기 ⑤: 보안 강화를 위한 인증서(Certificate) 관리 (3) | 2025.08.10 |
|---|---|
| Kubernetes로 대용량 오픈소스 웹 상용화하기 ④: Ingress로 외부통신 설정하기 (3) | 2025.07.27 |
| Kubernetes로 대용량 오픈소스 웹 상용화하기 ③: Helm chart로 Kubernetes에 오픈 소스 웹 배포하기 (3) | 2025.07.13 |
| Kubernetes로 오픈소스 상용화하기 ②: 컨테이너화와 Kubernetes 리소스 관리 (5) | 2025.06.22 |
| [Kubernetes] PVC, PV, Storage class 개념 (0) | 2023.10.24 |
