Dash&Rush Hanbus

Service쿠버네티스에서 Pod에 안정적으로 접근하기 위한 내부 추상화다. Pod는 IP가 바뀔 수 있어서, Service가 고정된 접근 지점 역할을 한다. 즉,Pod 여러 개를 묶고트래픽을 분산하고안정적인 네트워크 endpoint를 제공한다대표 타입:ClusterIP: 클러스터 내부에서만 접근NodePort: 각 노드 포트로 외부 접근LoadBalancer: 클라우드 L4 LB와 연동해 외부 접근LoadBalancerLoadBalancer는 보통 외부에서 클러스터로 들어오는 트래픽을 받는 진입점이다.쿠버네티스에서 Service type=LoadBalancer를 만들면, 클라우드 환경에서는 AWS ELB 같은 외부 로드밸런서가 붙는다. 역할은 보통:외부 요청 수신여러 노드/서비스로 분산주로 L4 레벨(..

RAG 시스템을 Kubernetes에 올릴 때 많이 헷갈리는 부분이 있다.Vector DB는 서버로 띄워야 하나?초기 임베딩 적재는 Job으로 해야 하나?새 문서가 들어오면 또 Job을 돌려야 하나?Deployment와 StatefulSet은 언제 나눠 써야 하나?처음에는 전부 Deployment로 띄우거나, 반대로 모든 걸 Job처럼 생각하기 쉬운데,실제로는 역할에 따라 Kubernetes 리소스를 나누는 것이 중요하다.이 글에서는 RAG 시스템을 Kubernetes에 배포할 때 어떤 컴포넌트를 어떤 리소스로 운영하면 좋은지 정리한다.1. 먼저 결론RAG를 Kubernetes에 올릴 때는 보통 아래처럼 나누는 것이 자연스럽다.초기 전체 문서 임베딩/적재 → Job주기적 문서 반영 → CronJob실시간..

🔹 ServiceAccount 한 줄 정의👉 Pod(애플리케이션)가 Kubernetes API를 사용할 때 쓰는 “신분증”🔹 왜 필요하냐?쿠버네티스에서 Pod도 뭔가를 할 수 있음 예:다른 리소스 조회 (Pod 목록 조회)ConfigMap 읽기Secret 접근Deployment 생성 (CI/CD나 Operator에서 많이 함)👉 근데 아무나 다 하면 위험하잖아→ 그래서 “너 누구야?” 인증이 필요함그게 바로 ServiceAccount🔹 동작 구조Pod → ServiceAccount → (토큰) → Kubernetes API Server 좀 풀어서 보면:Pod 생성될 때 ServiceAccount가 연결됨그 안에 JWT 토큰이 자동으로 들어감Pod 안의 애플리케이션이 API 호출할 때이 토큰으로 ..

1. 전체 큰 그림클라이언트가 API 요청을 보내면 대충 이런 흐름이야.클라이언트 요청→ WAS(톰캣)→ Filter→ DispatcherServlet→ HandlerMapping→ HandlerAdapter→ Controller→ Service→ Repository→ 응답 반환예외가 나면:Controller / Service / Repository 어디선가 예외 발생→ DispatcherServlet 쪽으로 예외 전파→ HandlerExceptionResolver 동작→ @ExceptionHandler / @RestControllerAdvice 가 처리→ HTTP 에러 응답 반환 즉 핵심은:DispatcherServlet = 스프링 MVC의 중앙 관제실Filter / Interceptor = 요청 전후..

1. 한 줄 결론👉Port(인터페이스)를 쓰면 → Mock으로 쉽게 대체 가능 → 테스트 쉬움구현체 직접 쓰면 → Mock 어려움 → 테스트 어려움2. 구조 차이 먼저 보자❌ 구현체 직접 의존class AuthService {private final RedisRefreshTokenRepository repository; // 구현체}👉 문제:Redis 실제 연결 필요DB / 네트워크 영향 받음테스트 느리고 불안정⭕ Port 사용class AuthService {private final RefreshTokenPort refreshTokenPort; // 인터페이스}👉 실제 구현은 따로 있음class RedisRefreshTokenAdapter implements RefreshTokenPort 3. ..