Cloud Native

제가 CTO로 있는 디비디랩에서는 좋은 유저 리서치를 할 수 있게 돕기 위해서 여러 LLM 프롬프트와 이를 종합한 에이전트를 개발해서 사용하고 있어요. 그 중에서 Dify라는 서비스를 활용해 두 개 이상의 프롬프트에 로직과 플로우 제어를 더해서 하나의 목표를 가진 워크플로우를 만드는 데 유용하게 사용하고 있어요. 디파이는 유료 플랜을 사용해서 사용할 수도 있지만, 태생적으로 오픈소스 솔루션(깃허브 리포지토리)이기 때문에 직접 호스팅해서 사용하는 것도 당연히 가능합니다. 이 아티클에서는 고유 요구사항을 따라서 디파이를 자체 호스팅한 과정을 소개합니다. 1. 요구사항 헬름 차트를 통해서 쿠버네티스 클러스터 위에 배포할 수 있어야 합니다. PostgreSQL은 Amazon RDS를 사용합니다. Redis는 쿠버네티스 클러스터 위에 이미 존재하는 클러스터를 사용합니다. 벡터 스토어는 Qdrant를 사용하고, 쿠버네티스 위에 자체 호스팅합니다. 인그레스 자원을 사용하지 않고 Gateway API의 HTTPRoute 자원을 사용합니다. VPN을 통해 내부망에 접속한 다음에 디파이에 접속할 수 있습니다. 2. 디파이 헬름 차트 디파이는 공식 헬름 차트를 제공하지 않고, docker-compose를 사용한 설치 방법과 소스 코드로부터 설치하는 방법만 제공하고 있어요. 😢 (공식 문서 참조) 다행히 깃허브 리포지토리에 커뮤니티에서 관리하는 헬름 차트를 소개(깃허브 리포지토리 참조)하고 있어서, 아예 바닥부터 차트를 만들어야 하는 수고는 덜 수 있었습니다! 2.1. 차트 선정 공식 리포지토리에서 소개한 헬름 차트는 두 개입니다. LeoQuote가 관리하는 차트 (douban/dify) BorisPolonsky가 관리하는 차트 (BorisPolonsky/dify-helm) 여기서 첫 번째 차트는 두 번째 차트보다 나중에 시작된 프로젝트인데요. 패스워드와 API 키와 같은 민감정보를 평문으로 넘겨야 하는 한계때문에 만들어진 차트이지만, 현재는 둘 다 시크릿을 사용할 수 있게 되어 있어요. 솔직히 말해서, 어느 쪽도 완성되었거나 완벽하다고 할 수 없지만 첫 번째 차트의 경우가 사용자 입장에서 더 편리하다고 생각합니다. 우선 BorisPolonsky의 차트는 밸류가 너무 많아서 완전히 이해하고 값을 통제하기가 어려워요...

지금까지 배부른 회사에서 데이터독만 쓰면서 신경 끄며 살아와서 그런가, 모니터링에 대한 지식이 너무 빈약하다는 것을 많이 느끼는 요즘이네요... 😢 쿠버네티스에서 로그를 수집 및 저장하기 위해 로키(Loki)를 배포하기 위한 노력의 흔적을 공유합니다! 로키가 출시된지 꽤 시간이 지났지만 여전히 로키 설치에 관해 자세히 설명하는 글이 많지 않았고, loki-stack 헬름 차트가 더 이상 활발하게 개발되고 있지 않아 설정에 어려움을 많이 겪었답니다. 그러므로 이번 글에서는 loki , promtail 차트를 사용해서 로키를 배포하고, 최소한의 동작을 하도록 설정해 보도록 할게요! 1. 큰 그림 우선 프로메테우스(Prometheus)의 경우 kube-prometheus-stack 헬름 차트(차트 리포지토리 링크)로 설치했다고 가정하겠습니다. 그라파나의 경우 프로메테우스를 예전에 설치해서 이미 사용하고 있었고, 이번에 설치해야 할 차트는 아래의 두 가지였어요. loki : 로그 소스로부터 로그를 push받아 로그를 처리, 저장하여 그라파나 등을 통해 시각화하기 위한 로그 시스템이에요. (차트 리포지토리 링크) promtail : 각 쿠버네티스 노드로부터 컨테이너 로그를 가져와 로키로 push하기 위한 에이전트예요. (차트 리포지토리 링크) 다시 말하면, 프롬테일로 로그를 긁어모아서 로키로 쏴 주는 구조예요. 2. 로키 차트 설정 2.1. 로키의 배포 모드 로키의 배포 모드(공식 문서 링크)는 세 가지가 있어요. 이 중, 로키 차트에서 지정한 기본값은 단순 확장가능 모드(v3.3.2 밸류 참조)입니다. 우리 클러스터에는 단순 확장가능 모드로 로키를 설치하기로 결정했어요. 모놀리식 모드 (monolithic mode) 로키의 모든 컴포넌트가 한 바이너리로 되어 있어요. 레플리카 확장이 가능하지만, 복제하지 않아도 되는 컴포넌트까지 모두 복제하게 돼요. 단순 개발 환경, PoC 환경이나 하루 최대 20GB 정도의 로그를 처리할 때 적합해요. 단순 확장가능 모드 (simple scalable mode) 로키의 컴포넌트를 의미 단위로 묶어 두었어요.

카펜터를 배포하고 설정하기 위해서 기존 자체 EKS 모듈을 어떻게 수정했는지 소개합니다. 이 과정에서 겪었던 시행착오도... 공유합니다. 😢 왜 카펜터를 쓰고 싶었나? 스팟 인스턴스로 자원을 저렴하게 사용하고 싶었습니다. 그런데 스팟 인스턴스는 spot interrupt가 발생하면 2분 안에 방을 빼 줘야 하는, 비유하자면 몰래 쓴 공유 오피스의 회의실같은 것이지요. 그런데! 카펜터를 사용하면 스팟 인터럽트 핸들링이 아주 간단해지고, 스팟 인스턴스와 별개로 온디맨드 인스턴스도 할당할 수 있고, 여러모로 관리가 편해질 것 같아서 사용하게 되었습니다. 고려할 점 카펜터의 컨트롤러는 카펜터가 프로비저닝하는 노드에 띄우면 안 됩니다. Disruption이나 스팟 인터럽션에 자기 자신이 당할 수 있습니다. 그러므로 노드 그룹을 없애고 싶은 입장에서는 Fargate 노드를 선택하게 됩니다. 클러스터를 처음부터 띄우는 환경이면 CoreDNS가 카펜터가 먼저 떠야 합니다!? 이 부분은 존경하는 홍랩님의 아티클([AWS EKS] CoreDNS Addon을 FARGATE로 띄우기 (w. Terraform))로 알게 되었는데요. 선구자의 희생이 아니었으면 더 큰 시행착오를 겪었을 것 같습니다 허허... 카펜터 설치 EKS 모듈은 /modules/eks 에 있다고 가정하고, 테라폼 실행 환경은 /envs/test 에 있다고 가정하겠습니다. Fargate 프로파일 설정 우선 실행 환경에서 예쁘게 프로파일 정보를 전달받을 수 있도록 모듈에 variable 블록을 선언해 줍니다. Fargate 프로파일에 필요한 입력값인 name , namespace , labels 를 키를 가진 오브젝트의 리스트로 정의하였습니다.