k8s

[k8s] 개발자가 꼭 알아야 할 k8s DNS, iptable 업데이트 타이밍

k8s 환경에서 어플리케이션을 이중화했음에도  rollout restart할 때 서비스가 일시적으로 사용 불가할 수 있습니다. 이는 k8s의 pod의 DNS, ip 업데이트시 CoreDNS와 iptable에 업데이트 시차가 존재할 수 있어 발생합니다. 이번 글에서는 pod을 statefulset으로 배포하는 경우와 deployment로 배포하는 경우를 나누고, 각각의 케이스에서 어떻게 이슈가 발생할 수 있는지 알아보겠습니다. [요약] * k8s + grpc에서 pod들을 rollout

Go

[Go] 서버 개발자를 위한 graceful shutdown 가이드

[요약] * graceful shutdown을 적용하면 클라이언트가 타임아웃으로 인해 실패한 요청을 다른 서버로 재시도를 못하는 케이스를 막을 수 있습니다. * gRPC와 echo 프레임워크 모두 graceful shutdown 함수를 지원하여 쉽게 구현할 수 있습니다. graceful shutdown 적용 필요성 서버가 요청을 처리하다 갑자기 종료되면 처리가 거의 완료된 요청들도 정상 응답을 반환하지 못하고 에러를 반환합니다. 클라이언트는 에러가

Paper

[구글 시리즈] #3. Chubby (feat ZooKeeper)

현재 검색 시장뿐만 아니라 다양한 분야를 장악한 구글은 불과 1998년에 설립되었습니다. 구글은 매우 빠른 속도로 성장했고, 이를 위한 인프라 시스템들을 구축했습니다. 구글의 인프라 시스템은 다른 회사 및 개발자에게 많은 영향을 끼쳤습니다. 구글 시리즈는 이러한 논문들 중 일부를 뽑아 소개를 하고자 합니다. 이번 글에서는 구글의 Chubby만 다루는 것이 아니라, Zookeeper도 같이

Paper

[구글 시리즈] #2. Bigtable: A Distributed Storage System for Structured Data (2006)

현재 검색 시장뿐만 아니라 다양한 분야를 장악한 구글은 불과 1998년에 설립되었습니다. 구글은 매우 빠른 속도로 성장했고, 이를 위한 인프라 시스템들을 구축했습니다. 구글의 인프라 시스템은 다른 회사 및 개발자에게 많은 영향을 끼쳤습니다. 구글 시리즈는 이러한 논문들 중 일부를 뽑아 소개를 하고자 합니다. 1. The Google File System (2003) 2. BigTable: A

Paper

[구글 시리즈] #1. The Google File System(2003)

현재 검색 시장뿐만 아니라 다양한 분야를 장악한 구글은 불과 1998년에 설립되었습니다. 구글은 매우 빠른 속도로 성장했고, 이를 위한 인프라 시스템들을 구축했습니다. 구글의 인프라 시스템은 다른 회사 및 개발자에게 많은 영향을 끼쳤습니다. 구글 시리즈는 이러한 논문들 중 일부를 뽑아 소개를 하고자 합니다. 1. The Google File System (2003) 2. BigTable: A

Book

AI 딥 다이브 리뷰

💡Disclaimer 이 리뷰는 한빛미디어로부터 책을 지원받아 작성하였습니다. 항상 AI에 관심이 있었지만, 많은 시간을 들여 공부할 여유는 없었다. 그래서 쉽고 빠르게 학습을 하기 위해 여러 AI 관련 책들을 살펴보곤 했었다. 대부분 일반인들을 위한 입문 책이거나 딥러닝 모델을 작성하기 위한 구현 위주의 책이었다. 큰 맥락을 짚어주는 책이 없었다. 이 책은 저자가 2015년부터

Linux

eBPF/XDP: 당신만 모르는 안전하고 빠른 Networking

[요약] * eBPF: kernel space 내에서 프로그램을 실행할 수 있도록 하여 어플리케이션 개발자가 런타임에 OS의 기능을 사용할 수 있도록 하는 기술 * XDP: eBPF를 기반으로 한 기술로 packet processing을 할 수 있도록 지원 * XDP는 XDP driver hook 및 eBPF virtual machine 등으로 구성되어 있고 높은 성능으로 안전하게 kernel space에서 packet processing을 할

Paper

RAG의 짧은 역사 훑어보기(첫 논문부터 최근 동향까지)

[요약] * RAG는 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks(2020)에서 처음 등장하였고 모델과 Retriever을 학습시키는데 사용되었다. * 최근 RAG는 모델의 학습이 아닌 모델의 Inference 성능을 레버리지하기 위해 주로 사용되고 있다. * RAG는 문서를 어떻게 잘 검색해서 가져오고 LLM에 잘 넘겨주는지 중요하다. * RAG를 도와주는 구글의 Vertex AI는 문서 검색에 벡터 검색뿐만 아니라 전통적인

Paper

[논문 리뷰] Efficient Memory Management for Large Language Model Serving with PagedAttention

[요약] 1. Efficient Memory Management for Large Language Model Serving with PagedAttention 은 vLLM의 기반이 된 논문이다. 2. LLM 서빙에서 throughput을 향상시키려면 배치 처리를 해야한다. 배치 처리의 바틀넥은 KV 캐시가 차지하는 메모리 크기이며 이에 따라 최대 배치 크기가 결정된다. 3. vLLM은 OS의 virtual memory처럼 KV 캐시가 저장되는 메모리를 block단위로 나누고

Paid-members only

Life

[회고] 23년 11,12월 / 24년 1월

Paper

구글 Spanner의 Paxos 및 TrueTime 활용을 알아보자

[요약] * Paxos는 분산 시스템에서 사용되는 합의 알고리즘으로 2PC를 확장한 알고리즘으로 볼 수 있습니다. * Spanner는 lease를 활용한 리더 기반 Paxos를 사용합니다. * Spanner의 TrueTime은 오차가 제한되는 전역 동기화 시계로 이벤트 간 순서를 정할 때 도움을 줍니다. * TrueTime을 통해 Spanner는 external consistency 및 MVCC를 제공합니다. [목차] * 2PC * paxos * Spanner의 paxos * Spanner의 TrueTime 및

[Go] Go에서 Core dump 파일 생성하기

[요약] * GOTRACEBACK 환경변수를 crash로 설정 * ulimit의 core file size를 해제 * 빌드시 컴파일러 최적화로 인해 core 파일 분석시 일부 정보가 안보일 수 있음 * core 파일은 IDE(Goland), dlv, gdb 등으로 분석 가능 * /proc/sys/kernel/core_pattern을 변경하면 core 파일 생성 경로 및 이름을 변경할 수 있다 Go 어플리케이션에서 panic이 발생했을

Paid-members only

Life

[회고] 23년 8, 9, 10월

Programming

OOP는 죽었다. DOD를 적용해보자

본 포스트는 "OOP Is Dead, Long Live Data-oriented Design" 을 보고 정리한 것입니다. [목차] 1. Data-oriented design의 접근법 2. OOP로 짠 코드의 예시 3. DOD로 짠 코드의 예시 4. DOD로 짰을 때 성능 개선 5. DOD의 단점 6. 개인적인 느낀점 Data-oriented design의 접근법 OOP(Object-oriented programming)는 많은 사람들이 애용하는

Paper

[논문 리뷰] On-demand Container Loading in AWS Lambda

[요약] 1. On-demand Container Loading in AWS Lambda는 Block-level loading, Deduplication 및 Tiered cache을 도입해 scalability 및 cold start latency를 줄이는 방법을 소개한다. 2. Block-level loading은 이미지를 flattening process를 거쳐 하나의 파일 시스템으로 만든 뒤 chunk로 나누어 캐시에 올린다. 3. 캐시에 이미지를 올릴 때 같은 내용의 이미지는 같은 key로 암호화하여

Information Retrieval

[FAISS 뜯어보기(1)] Similarity Search와 HNSW

[요약] 1. FAISS는 similarity search를 도와주는 Facebook에서 만든 라이브러리다. 2. Voronoi diagram은 데이터 셋을 region으로 나누어 벡터 검색 인덱스를 만들 수 있다. 3. Product Quantization은 데이터 벡터를 압축하여 스토리지를 아낄 수 있다. Voronoi diagram과 같이 사용할 수 있다. 4. NSW는 ANN 검색시 사용하는 graph 자료구조다. Skip list는 검색과 입력이 평균

Paid-members only

Life

[회고] 23년 5,6,7월

Paper

[논문 리뷰] ColBERT, ColBERTv2

[요약] ‌1. IR의 랭킹 방법은 BM25가 널리 쓰이고 있지만 2016년부터 Neural Network를 사용한 랭킹 방법들이 등장하기 시작했다. 2. Neural IR은 대체로 높은 MRR을 보여주었지만 계산이 비싸다는 단점이 있었다. 특히 BERT는 월등한 MRR을 보이지만 서비스에 적용하기에 너무 느리다. 3. ColBERT는 BERT보다 약간 모자란 MRR을 보이지만 훨씬 빠른 성능을 보여주었다. 4. ColBERTv2는

Blockchain

[Blockchain 입문] 개발자를 위한 Why Blockchain

[요약] * 비트코인은 인터넷 결제 시스템에서 처음으로 중앙 주체를 성공적으로 없앤 시스템이다. * 비트코인은 분산 DB의 일종으로 볼 수 있다. 일반적인 분산 DB와 다른 점은 Permissionless 하여 어느 노드든 이 시스템에 참여할 수 있다는 점이다. * 이더리움은 월드 컴퓨터를 표방한다. 화폐 결제 시스템이 목표인 비트코인과 다르다. * 이더리움의 등장으로 web3가 본격적으로 논의되기 시작했다. Web3는

Blockchain

[Blockchain] 가버넌스 토큰에 밸류에이션을 할 수 있을까?

[요약] 1. 가버넌스 토큰은 소유권을 가진다는 점에서 web2의 주식과 유사한 성격을 가지고 있다 2. 주식의 경우 대량 매수를 통해 회사의 경영에 깊게 관여할 수 있다. PEF는 이를 통해 회사 자산을 매각하여 배당을 늘리거나 경영을 도와 회사 가치를 키우는 등 여러 전략을 구사한 바 있다. 3. Defi 프로젝트의 경우 시가총액이 자본(

Go

[Go] Interface 구현과 Reflection Package

[요약] * Go의 interface는 내부적으로 한 쌍의 word로 구성된다. 하나는 itable을, 하나는 data를 가리킨다. * Go의 컴파일러는 concrete 타입과 interface 타입마다 메소드 리스트를 작성한다. 런타임 때 이 둘을 조합하여 itable을 생성한다. * Golang의 reflect 패키지는 interface 타입 객체로부터 concrete 타입 및 값을 다룰 수 있도록 도와준다.   * Interface와 reflect 패키지를 활용하면 인자의 타입과 상관

Paid-members only

Life

[회고] 23년 3,4월

k8s

[K8s & Github Action] self-hosted-runner를 k8s로 구성해보자

[요약] k8s 클러스터 구성 1. k8s 클러스터 구성시 공식 문서에 나와있는 kubeadm 쓰지 말자. 훨씬 편리한 프로젝트들 많이 있다(k0s, k3s). Github Action 1. Github Action은 runner로 자신의 서버를 쓸 수 있는 self-hosted runner를 지원한다. 2. ARC를 사용하면 k8s에 self-hosted runner를 비교적 쉽게 구성할 수 있다. 3. 그러나 ARC는 self-hosted

Compiler

[LLVM & Clang] LLVM 최적화, 어디까지 아시나요?(LTO, PGO, BOLT)

[요약] 1. Clang은 LLVM 기반 C/C++/Objective C 오픈소스 컴파일러다. Clang을 사용하면 LLVM의 최적화 기법을 적용하여 프로그램 성능 향상을 이끌어낼 수 있다. 2. C/C++ 외 다른 언어도 맞는 프론트엔드를 사용하면 LLVM을 사용할 수 있다. 3. LTO는 컴파일시 link 단계에서 적용되는 최적화이다. 함수를 사용하는 파일들이 나눠지거나 언어가 달라도 최적화를

Frontend

[RTK Query] useQuery 리렌더링 문제 해결기 - useLazyQuery 사용

[요약] 1. RTK Query의 useQuery는 호출이 되는 시점에 데이터를 fetch한다. 그리고 그 과정에서 컴포넌트의 렌더링이 여러 번 발생할 수 있다. 2. 이로 인해 개발자가 예상하지 못한 시점에 컴포넌트가 렌더링되며 사이드 이펙트가 생길 수 있다. 3. RTK Query의 useLazyQuery를 사용하면 데이터 fetch 시점을 조절할 수 있어 사이드 이펙트를 줄일 수 있다.