sigridjineth

python threadvars

• WSGI와 ASGI 환경에서의 threading.local과 contextvars의 사용 및 차이점

• WSGI 환경에서는 각 요청마다 별개의 스레드가 생성되기 때문에 threading.local을 사용해 스레드별로 독립된 데이터 저장소를 관리할 수 있음. 하지만, ASGI 환경에서는 하나의 스레드 안에서 여러 태스크가 동시에 실행되기 때문에 threading.local로는 데이터의 격리가 어려워짐.

• 이 문제를 해결하기 위해 contextvars가 등장했음. contextvars는 동시성 코드에서 현재 컨텍스트에 대한 데이터를 독립적으로 관리할 수 있는 방법을 제공함. 각각의 비동기 태스크가 자신만의 컨텍스트를 가지고, 이 컨텍스트는 다른 태스크와 공유되지 않아 데이터가 서로 침해받지 않음.

• 아래 예제 코드는 contextvars를 사용하여 여러 "평행세계"(비동기 태스크)에서 각각의 데이터를 독립적으로 관리하는 방법을 보여주고 있음. 이는 Python 3.7부터 사용 가능한 기술로, 동시성 코드에서 컨텍스트 관리를 더욱 쉽고 명확하게 할 수 있게 해줌.

sigridjineth

Istio

• Istio는 오픈소스 서비스 메쉬로, 분리된 어플리케이션을 투명하게 계층화할 수 있다.
• 현재 쿠버네티스의 네트워크 구성에 가장 많이 사용되고 있는 오픈소스기도 하다.
• Istio는 쿠버네티스 네트워크의 복잡성을 줄이고, 분산 네트워크 환경에서 여러 어플리케이션들의 연결을 쉽게 설정할 수 있게 지원한다.

Specification

• Sidecar 패턴(Pod 내에 Envoy proxy sidecar로 존재)을 이용하여 application 코드의 변경없이 작업자가 VirtualService, DestinationRule이라는 Custom Resource로 손쉽게 원하는 서비스로 트래픽 전송이 가능
• k8s로 Canary 배포를 하기 위해선 직접 replica 개수를 조정해야 했으나, Istio VirtualService의 Weight와 subset을 통해 이 과정이 Envoy로 Header와 Path의 L7 라우팅이 매우 간단해짐
• log, metric, trace를 Istio를 통해 모두 수집 가능 - Envoy를 통해 Observability 구현
• MSA 구조로 인한 Man in middle 공격과 manifest 노출의 리스크를 mTLS로 통신 레이어 보안 향상시킴

sigridjineth

유튭 영상

https://www.youtube.com/watch?v=xUpi8pXyiyk

사용 기술: 솔라(Solr)

• 솔라는 아파치 루씬 기반의 오픈소스 검색 플랫폼, 역색인 구조를 사용하여 빠른 검색을 가능

색인 파이프라인 고도화

• 색인 파이프라인은 데이터 처리 및 분석을 위한 일련의 단계를 의미
• 현재 구조 및 이슈: 필요한 데이터를 생성하고 전처리한 다음 색인하는 과정을 거치지만
• 그러나, 이 과정에서 많은 데이터베이스 테이블에서 변경 사항을 가져와 처리해야 하며, 증분 처리 시에도 각 문서에 많은 데이터를 반복적으로 생성해야 함

sigridjineth

• 대용량 데이터를 처리할 때 병렬 프로그래밍은 필수적이다. 파이썬에서는 병렬 연산을 위해 사용하는 default 패키지로 multiprocessing이 있다. 지금까지는 multiprocessing만 사용해봤는데, 최근에 joblib에 대하여 접하게 되어 간단하게 메모하는 겸 공식문서를 정리해보았다. 이번 게시물에서는 주로 Parallel과 Delayed에 대한 설명을 하고자 한다.

pip install joblib
# poetry add joblib

• 일반적인 for loop를 병렬 처리로 전환해보자

• 아래의 예시는 0에서 9까지의 수를 제곱하고 제곱근을 구하는 단순한 for loop이다.

sigridjineth

앤서블로 시작하는 인프라 자동화 - POR로 읽기

POR이란

• 김창준님이 만드신 독서법으로, 개인의 문제를 해결하는 것에 중점을 두고 독서하는 방식을 의미한다.
• 나는 3장, 앤서블을 적용한 예시부터 독서하기 시작했다.

예시 - IP 자동으로 설정하기

ansible.cfg

[defaults]

sigridjineth

• VDB (벡터 데이터베이스)는 세그먼트 수준에서 optimize가 이루어집니다. 하기 장표의 예시는 Rust 기반 VDB인 Qdrant의 Optimizer에 대한 것입니다. 일반적으로 다른 데이터베이스와 마찬가지로 배치 전략으로 인덱스를 빌드하는 것이 각각 수행하는 것보다 일반적입니다. 공식 문서에서는 해당 구조를 처음부터 완전히 재구축하는 것이 필요하다고 명시하기도 합니다.

• Milvus와 Qdrant 모두 데이터를 저장하는 기본 단위로 segment를 명시합니다. 세그먼트 최적화 과정은 copy-on-write segment 기법이 사용되는데 만약 기존의 인덱스를 다시 빌드해야 한다고 하면 기존의 새로운 세그먼트 데이터를 copy하여 새로운 세그먼트를 생성하고 새로운 세그먼트에 대한 변경사항을 적용합니다. 이러한 과정을 통하여 데이터를 수정할 때 데이터 무결성을 유지할 수 있습니다. 인덱스를 전체 리빌딩하는 과정이 있더라도 기존의 인덱스에서 계속 접근 가능하기 때문에 장애가 발생하기 어렵습니다.

• 세그먼트 최적화 과정이 필요한 이유는, 일반적으로 세그먼트 단위로 독립적으로 검색될 수 있어 전체 데이터베이스를 검색하는 것보다 훨씬 빠른 검색이 가능하다는 전제에도 시작합니다. 세그먼트 별로 각기 다른 시점에서 최적화를 수행할 수 있으므로 전체 데이터베이스를 full rebuild해야 하는 상황도 피할 수 있습니다. 다만 embedding data point의 수가 1만 개 미만일 때는 특정한 인덱싱 전략을 사용하는 것보다는 단순하게 BF (brute force) 전략을 사용하는 것이 효과적일 수 있고, 세그먼트 크기가 일정한 threshold를 초과하면 Qdrant는 읽기 전용의 메모리 매핑된 파일로 데이터를 저장하도록 세부적인 하이퍼 파라미터를 조정할 수 있습니다. 혹은 벡터의 크기가 일정한 임계값을 초과할 경우, 벡터 임베딩을 활성화하도록 조정할 수도 있습니다.

• 또한 구성 파일 외에도 각 컬렉션에 대해서도 최적화가 가능한지 (override 가능 여부) 도 살펴봐야하고, 위에서 언급

sigridjineth

Python Decorators

• 다음의 코드가 있다고 생각하자

def decorator(extra):
    extra = f" {extra}"
    def inner(func):
        def wrapper(*args, **kwargs):
            print(f"before {func.__name__}{extra}") # before를 출력
            func(*args, **kwargs) # func를 실행
 print(f"after {func.__name__}{extra}") # after를 출력

sigridjineth

Structured Concurrency

Introduction

• 예전의 프로그래밍 언어는 control flow가 상하로 왔다갔다 하였고 이런 코드는 흐름을 읽는 것을 방해함
• 하지만 요즘은 구조화된 프로그래밍 방법을 통해 이를 쉽게 읽을 수 있음
• 이러한 것이 가능하게 된 것은, block을 사용했기 때문이다.
• block 안에서는 변수가 살아있고, 그 scope를 벗어나게 되는 경우 변수는 사라진다.
• 이런 static scope와 structured programming 방법은, 변수의 life time과 제어문을 이해하기 쉽게 만들었다.
• 이렇게 structured programming 방식은 이미 우리에게 상당히 익숙하다.
• 하지만 요즘의 program은 비동기, concurrent code가 많아졌다. 이런 부분에 있어서 structured 한 방식으로 처리하는 것이 매우 어려웠다.

sigridjineth

FastAPI와 Uvicorn의 동작 방식

• FastAPI는 ASGI 프레임워크 중 하나로, 비동기적으로 작동하는 uvicorn과 함께 사용된다.
• 구조는 FastAPI - Starlette - Uvicorn - uvloop - libuv 순으로 이루어져 있다.

비동기 처리의 중요성

• Python에서는 Global Interpreter Lock(GIL)을 사용하여 race condition을 방지한다.
• 이는 멀티스레딩을 제대로 지원하지 않지만, uvicorn은 비동기 처리를 위해 멀티 프로세싱 방식을 사용한다.
• 이렇게 실행된 여러 개의 프로세스는 각각 독립적으로 요청을 처리한다.

sigridjineth

Challenges

벡터 검색 ≠ 벡터 데이터베이스

• 벡터 검색 자체는 '쉬운' 문제가 아니며, 벡터 데이터베이스가 해결해야 할 전통적인 데이터베이스 문제들이 더 어렵다.
• 벡터 데이터베이스는 원자성, 일관성, 성능 최적화, 스케일링 등 많은 문제를 해결해야 한다.

벡터의 점진적 색인화 (Incremental Indexing) 문제

• 새로운 벡터를 추가할 때마다 빠른 조회 속성이 빠르게 떨어지므로 주기적으로 인덱스를 처음부터 다시 구축해야 한다. 이러한 문제를 해결하기 위한 각 VDB의 접근 방식은 서로 상이한데, 예를 들어 Milvus는 일정한 주기마다 full-reindex를 시도하는 데 이 때 높은 CPU 로드를 경험하여 서비스 다운의 원인이 될 수 있다.
• 벡터를 생성하고 얼마나 빨리 검색 가능해야 하는지가 시스템의 주 설계 요소가 될 수 있다. 이러한 비용과 데이터 지연성 간의 중요한 트레이드오프가 있다.
• 내가 도입하려고 하는 VDB는 Indexing 전략에 따라 In memory인가 On-disk index인가?