2024/11 5

PostgreSQL Connection이 90분만에 끊어지는 상황 해결하기

네트워크 라우터의 TCP 연결 타임아웃과 Postgres keep-alive 설정에 대한 흥미로운 사례를 공유하고자 한다.부제는 "Cisco와 Windows의 조합으로 만들어진 혼돈" 정도로 하고자 한다. 문제 상황Windows 환경에서 Postgres 클라이언트와 DB 서버를 사용하던 중, 90분이 지나면 연결이 끊어지는 현상이 발생했다. 이 문제를 해결하기 위해 Cisco 공식 문서를 찾아보면서 원인을 파악할 수 있었다.라우터의 연결 상태 관리 방식라우터는 로컬 상태 테이블에서 연결들을 추적하며, 이를 통해 라우팅 결정을 내리고 유효하지 않은 패킷을 필터링한다. 이 상태 정보는 다음과 같은 경우에 제거된다:양쪽 중 한 쪽이 연결을 종료할 때연결이 너무 오랫동안 유휴 상태일 때 (클라이언트와 서버가 모..

DB/PostgreSQL 2024.11.29

AI 데이터 인프라의 부상

문서에서 정보를 추출하는 것은 새로운 개념은 아님. 하지만 생성형AI(GenAI)는 대량의 고품질 데이터를 필요로 함훈련과 추론 모두에 데이터가 중요하며 데이터 규모뿐만 아니라 텍스트, 테이블 데이터에서 비디오, 이미지, 오디오로 확장됨위성 이미지, 로봇 센서 데이터 등 공간 데이터의 증가도 관찰됨데이터 계층에서 AI로 인해 가장 즉각적으로 재창조될 수 있는 새로운 영역은 무엇일까?비정형 데이터 추출과 파이프라인, 검색 증강 생성 (Retrieval-Augmented Generation, RAG), 데이터 큐레이션, 데이터 스토리지 , - 인공지능 메모리이 글의 목적은 AI 데이터 인프라 환경을 분석하고, 최신 트렌드를 공유하고, 가장 유망한 혁신 영역에 대해 이야기 하는 것AI 데이터 인프라 현황AI ..

AI/AI News 2024.11.25

NVIDIA garak - LLM 취약점 스캐너

Garak은 LLM 기반 시스템의 취약점을 찾기 위해 개발된 무료 도구주로 LLM의 오작동과 보안 문제를 검사하며, nmap의 LLM 버전이라 할 수 있음다양한 정적, 동적, 적응형 탐침(probes)을 사용하여 LLM의 여러 취약점을 탐색Garak의 주요 기능LLM의 실패 지점 확인: 잘못된 정보 생성, 데이터 유출, 프롬프트 인젝션, 독성 생성, 제일브레이크(jailbreak) 등 여러 약점을 탐색다양한 프로빙 기법 사용: 수십 개의 플러그인과 수많은 탐침을 통해 다양한 LLM 실패 모드를 분석로그 기록: 각 실패 사례에 대해 프롬프트, 목표, 응답을 포함한 상세한 로그 제공지속적인 업데이트: 커뮤니티의 기여로 새로운 탐침이 추가되고 기존 탐침이 개선되며, 테스트 범위가 지속적으로 확대Garak의 주..

AI/AI News 2024.11.19

벡터 데이터베이스는 잘못된 추상화임

AI 애플리케이션을 구축하려는 엔지니어링 팀을 괴롭히는 메시지 : "임베딩이 다시 동기화되지 않았습니다"간단한 벡터 검색 구현은 모니터링, 동기화 및 문제 해결의 복잡한 오케스트라로 발전함벡터 데이터베이스로 AI 시스템을 구축하는 엔지니어링 팀과 이야기를 나눈 결과, 벡터 데이터베이스의 잘못된 추상화와 오늘날 사용 방식의 결함을 발견함"RAG 시스템을 구축하는 공통적인 사례"Pinecone을 벡터 데이터베이스로 사용하여 임베딩을 저장하고 검색함텍스트 데이터가 Pinecone의 메타데이터에 잘 맞지 않아 DynamoDB로 블롭과 애플리케이션 데이터를 처리함어휘 검색을 위해 OpenSearch가 필요했음 이제 3개의 시스템을 연결하고 동기화하는 것이 악몽임소스 문서를 삭제할 때 다음을 수행해야 함:boto3..

DB/Vector DB 2024.11.05

Rate Limiter 시스템 디자인 및 설계 방안

Token Bucket토큰 버켓의 경우 사전에 정해진 용량을 갖는다. 토큰은 주기적으로 사전에 설정된 비율로 버켓에 저장된다. 그리고 버켓이 꽉차게 되면 정해진 용량을 초과하여 토큰을 추가하지 않는다.각 API 요청은 1개의 토큰을 사용한다. 요청이 오면 버켓에 적어도 1개의 토큰이 존재하는지 확인한다. 존재하는 경우 1개의 토큰을 버켓에서 꺼내고 요청이 처리된다. 버켓이 비어있는 경우 요청들은 버려진다.   위 사진을 보면 유저마다 분당 3개의 요청량 제한이 설정되어있다.1번 유저가 10:00:00에 첫 번째 요청을 보냈을 때 토큰은 3개가 존재하므로 해당 요청은 정상 처리되며 잔여 토큰은 2개로 감소한다.10:00:10에 유저의 두 번째 요청이 오고 토큰은 2개가 존재하기 때문에 정상 처리되며 잔여 ..