본문 바로가기

전체 글

(16)
[자유주제] 나의 일하는 법 (feat. 애자일 원칙과 스크럼) 배경:최근, 동아리에서 "가장 빠르게 개발하는 법"이라는 지극히 자극적인 주제로 세션 발표를 진행했다.이 발표에서는 프로토타이핑 방법론을 애자일 방법론과 스크럼 방법론에 어떻게 접목시킬 수 있는지 다루었다. 그 중 핵심적인 부분으로, 애자일의 4가지 가치를 나만의 언어로 재해석하여 구체적인 행동 강령을 정의하는 과정을 포함했다. 비록 인턴 생활, 팀 프로젝트, 부트캠프 등을 통한 제한된 경험이지만, 이는 스스로 진정성 있게 느낀 바였다. 이번 기회에 체계적으로 정리하며, 회고 및 반성의 소중한 시간이었다.  애자일의 4가지 가치1.프로세스와 도구보다는 개인과 상호작용을 중시한다.- 팀원들 간의 협력과 소통을 최우선으로 하여, 복잡한 프로세스나 도구에 의존하지 않는다 나의 언어:- 찾아가거나 메신저로 연락..
[DB] 벡터 DB: Milvus 사용 후기 프로젝트를 하는 중 shape matching 과정 중에 벡터 검색이 필요한데, 이를 빠르게 해야 할 필요가 있었다. 그 중 고민이 되었던 것이 벡터 DB의 선정 과정이었다. 따라서 PostgreSQL의 pgvector 익스텐션과 Milvus의 사용 둘 중 하나를 고민했다(사실 엄밀히 말하면 그 정도의 대규모 데이터는 필요하지 않지만 나름대로 고려해보았다) 1. 충분한 래퍼런스를 찾을 수 있는가?- Milvus는 커뮤니티가 크다.- pgvector 또한 커뮤니티가 크다(한국어 자료가 많다).  pgvector > Milvus (1 : 0) 2. 확장 가능성- Milvus는 클러스터 단위로 확장이 가능하고, Query 노드와 Index 노드, 데이터 노드 등을 따로 확장시킬 수 있다.- pgvector는 ..
[세션발표] 티끌모아 GPU, GCP에서 GPU 모델 서빙하기(RetroFest 2024 후기) 2024년 말, GDG on Campus 가천대, 경희대, 한국외대 챕터에서 감사하게도  2024 RetroFest 행사를 열어주어 세션 Speaker로 참석하였다.  RetroFest 2024: Back to the Future, 미래를 위한 돌아보기 | Festa!Festa에서 당신이 찾는 이벤트를 만나보세요.festa.ioSpeaker 선정기:세션 Speaker를 모집하고 있었을 때, 한 번쯤 기술 세션 발표를 진행하고 싶었기에 바로 어떤 것을 주제로 할 지 생각해봤다. 이 중에서 올해 기술적으로 가장 가치가 있었던 경험을 곰곰히 생각해본 결과, 내게는 이전에 삽질하면서 느꼈던 "클라우드 환경에서의 GPU 사용기"가 가장 힘들었지만 보람이 있었던 경험이었던 것 같아 선정하였다. 아래 포스팅을 참고하..
[MSA] terraform으로 GKE Autopilot 배포하기 이전에 포스팅에서 언급한 gRPC 코드를 GKE 환경에 Terraform으로 배포하였다. https://ket0825.tistory.com/12 [gRPC] Go코드와 함께하는 gRPC1. 관련 개념Static Linking: 정적 링킹 프로그래밍 언어가 컴파일링 과정 중에 코드가 기계어 (OBJ) 파일로 변환되고, 링킹 과정에서 사용하는 라이브러리를 합쳐 같이 실행 파일을 만드는 과정. 따ket0825.tistory.com  시스템 아키텍처는 아래와 같다  이러한 시스템을 구현하기 위하여 쿠버네티스를 사용하였다.  쿠버네티스쿠버네티스(Kubernetes, k8s)는 클러스터 환경에서 노드를 관리하고, 컨테이너를 배포하기 위한 컨테이너 오케스트레이션 오픈소스 플랫폼이다. 내부 내용이 매우 방대하고 복잡하..
[HTTP/2] HTTP/2 개념과 실습코드 HTTP/1.1의 문제점HTTP/1.1은 설계 자체가 논문을 주고 받기 위해 탄생한 기술이다. 따라서, html, css, js, 작은 사진 파일을 받기 위한 것이지, 큰 정보를 주고 받기 위해 탄생한 것이 아니다! 따라서 생겨난 단점이 존재한다. 1. HTTP/1.1 layer 상에서의 Head-of-Line Blocking 문제Head-of-Line Blocking: Client가 보내는 페이로드에 대해 서버 측에서 보내는 페이로드가 와야 client가 다음 페이로드를 보낼 수 있기에 Client는 그 동안 새로운 요청을 보내지 못하고 기다려야 하는 문제이다. 2. 헤더가 중복되는 경우가 많고, 헤더가 기본적으로 너무 크다. 3. 페이로드가 5개로 분할이 되는 큰 요청이 먼저 오고, 작은 요청들이 뒤..
[Algorithm] ANN: ANNoy 알고리즘 도입: 한 벡터(Query)에 대한 가장 유사한 벡터를 고를 때, 벡터 검색이 필요하다. 대표적으로 추천 알고리즘, RAG, 벡터 DB 등이 있다. 이 때, 모든 벡터와의 거리를 비교해가며 전역 탐색을 해나가는 것이 옳을까? 벡터 차원이 100이라고 할 때, 100개의 벡터 포인트가 기존에 있다면 10000번의 연산이지만, 1만 개라면, 혹은 그 이상인 100만 개라면 엄청난 연산량이 필요하게 된다.즉, 적어도 벡터 차원 d * 벡터 포인트의 갯수 N이면 d * N인 것이다.만약 가장 근접한 벡터 k개를 찾는 k-NN이라면, 그 중에 또 상위 k개를 더 뽑아야 한다. 즉, 막대한 연산량이 필요하고, 이는 시간 문제와 직결된다.ANNoy:이를 해결하기 위하여 ANN이 소개되었다.ANN(Approximate..
[gRPC] Go코드와 함께하는 gRPC 1. 관련 개념Static Linking: 정적 링킹 프로그래밍 언어가 컴파일링 과정 중에 코드가 기계어 (OBJ) 파일로 변환되고, 링킹 과정에서 사용하는 라이브러리를 합쳐 같이 실행 파일을 만드는 과정. 따라서 실행 파일에 코드와 라이브러리가 모두 합쳐져 있어 용량이 크다.  Dynamic linking: 동적 링킹.실행 파일안에 라이브러리 코드가 복사되는 것이 아니라, 메모리 공간에 올라가서 필요할 때 실행 파일이 여러 프로그램이 공유하여 사용하는 방식. 실행 파일 안에 소스 코드만 존재하고, 동적 라이브러리는 따로 존재하여 실행 파일 자체의 크기가 작다. 실행 시에도 한번에 모든 동적 라이브러리를 메모리에 로드하지 않고, 필요할 때 메모리에 로드하니 상대적으로 적은 메모리를 사용한다. 단, 호환성..
[GCP] 티끌모아 GPU, 구글 클라우드에서의 GPU 모델 서빙기 (feat. BATCH) 문제점: 대부분의 CSP는 GPU 부족 상태H100 기준으로 2023에 GCP는 약 5만 여대의 GPU를 확보한 것으로 추정된다고 합니다.  리드타임이 거의 1년이므로, 아직 수요에 비하면 GPU 공급이 따라오지 못하는 실정입니다. 저같은 경우는 적어도 제가 사용하는 T4 GPU는 부족한 것을 몸소 느끼는 중입니다(asia-northeast3 한국 기준). 이로 인해 비용 효율적인 SPOT 형태의 Provisioning은 어렵습니다. 그렇지만 제가 GPU로 모델 서빙에 필요한 작업은 near real time이고, 주기적으로 inference를 하면 되기에 Cron 형태의 작업을 실행하면 됩니다.따라서 GCP의 Job as Service 인 Batch를 선택하였습니다. Batch는 결국 GCE 기반이기에..