Show GN: Kuberian: LLM 을 사용한 Kubernetes 소스코드 자연어 검색 서비스
(kuberian.pages.dev)[소개]
Kuberian = Kubernetes + Librarian
"쿠버네티스 사서" 라는 느낌으로 개발한 토이프로젝트입니다.
[용도]
Kubernetes Repository 에 존재하는 4만개 넘는 함수들에 대해서
내가 원하는 역할을 하는 함수를 빠르게 찾는것을 목표로 합니다.
[사용법]
영어로 that 으로 시작하기 알맞게 문장을 작성하면 가장 유사한 함수를 찾아줍니다.
[검색 샘플]
- makes scaling decision link
- 오토스케일 결정을 어떤기준으로 하는지 알아내기 위해 사용한 쿼리
- checks if the system supports IPVS link
- 시스템이 IPVS 를 지원하는지 알아내는 함수를 찾을때 사용한 쿼리
- make requests for checking readiness of the container link
- Readiness Probe 요청거는 함수를 찾아낼 때 사용한 쿼리
대충 that 이하절로 문장을 던져주면 적당히 가장 유사한 함수를 찾아줍니다.
[만든 이유]
쿠버네티스 문서가 가끔 모호하게 적혀있을때가 있어서 구현 코드를 찾아봐야하는데 프로젝트 규모가 규모인만큼 일일히 수동으로 찾기가 귀찮아서 만들었습니다.
[기술 스택]
- Llama 2
- Rust
- eui (Elasticsearch UI)
- Knative w/ Google Cloud Run
[후기]
Google Cloud Run 쓰고나니깐 AWS Lambda 가지고 고민했던 지난날들이 바보같아졌습니다. 가장 저평가된 클라우드 기술같은데 가격도 놀라울정도로 저렴하니깐 한번 써보세요!
CloudRun 에 관한 저의 의견은 아래 댓글에 남겨두었습니다. :-)
해커뉴스는 사용자 패턴 맛보기 용도로 선공개 하였습니다 ㅎㅎ
(구글 애널리틱스 이용중입니다.)
혹시 추천해주시는 다른 커뮤니티가 있으신가요? 저는 별로 떠오르는곳이 많지는 않네요
오오 재밌는 프로젝트네요!
Google Cloud Run이 AWS Lambda에 비해 어떤 점들이 만족스러웠나요? 저도 람다만 써봐서 궁금합니다.
나중에 블로그 글 등의 형태로 자세히 밝혀 볼 예정이기는 한데 HTTP API 환경에 한정해서 간단하게 몇가지만 뽑아보자면
HTTP
Lambda: APIGateway 의 RPC 콜을 받아서 요청을 처리하는 로직 구현해야함
Cloud Run: 일반적인 HTTP 통신 / HTTP 기반 라이브러리나 프레임워크 그대로 활용가능
Concurrency
Lambda: 무조건 하나의 인스턴스는 한번에 하나의 요청만 처리 (한번에 100개의 요청이 들어오면 100개의 인스턴스가 실행되야함)
Cloud Run: 하나의 인스턴스는 사용자가 정한 한계선까지 동시에 처리 가능
부가설명: Cloud Run 이 Lambda 대비 시간당으로 보면 1.5배정도 비싸지만, 하나의 인스턴스가 100개의 Concurrency 를 허용한다면 1.5/100 정도로 저렴해짐
Cold / Warm / Hot
Lambda: Cold, Hot 말고 CPU 자원을 주지 않는 Warm 상태가 존재. APM 정보같은걸 보내기가 굉장히 힘들어짐 (APM 정보 보낼려고 응답속도가 늦어지면 보통 손해이니...) DB Connection 같은것도 Warm 상태에서 끊기던가 제대로 자원 해제가 안되서 DB Connection Pool 을 전부 소진해버리기도 함
Cloud Run: Cold 와 Hot 만 존재. 그럼에도 불구하고 AWS 로 치면 API Gateway 의 응답속도 만큼만 과금. 종료될때는 정상적인 자원 정리의 기회를 줌
개발환경
Lambda: 로컬에 개발환경 구축하기 굉장히 까다롭거나 언어 생태계 / CPU 아키텍처 제약이 굉장히 큼
Cloud Run: 일반 개발환경과 동일
이식성
Lambda: 람다용으로 짠 코드는 람다에 종속성을 가져서 다른 플랫폼으로 이식하기 어려움
Cloud Run: 코드수정 없이 Kubernetes 환경으로 이전 가능
이거 말고도 많은데, 보통 공감하실만한 내용들만 몇개 뽑아봤습니다 ㅎㅎ