[18편] pgvector 기반 AI 검색 시스템의 확장 및 운영 전략

 

이 글에서는 PostgreSQL pgvector를 기반으로 한 AI 검색 시스템을 확장하고 운영하는 방법을 다룹니다.

특히, 트래픽 증가에 대비한 확장 전략, Multi-Region 배포, 장애 복구(Failover) 및 성능 최적화 방안을 중심으로 설명합니다.

 

✅ 벡터 검색 시스템의 트래픽 확장 전략 (수평/수직 확장)

✅ Multi-Region 데이터베이스 배포 및 글로벌 서비스 운영

✅ 고가용성을 위한 장애 복구 및 Failover 전략

 

---

🚀 1. pgvector 기반 AI 검색 시스템의 확장 전략

 

AI 검색 시스템은 사용량이 증가할수록 데이터베이스 부하가 증가하기 때문에 확장성이 중요합니다.

확장 방식에는 수직 확장(Vertical Scaling) 과 수평 확장(Horizontal Scaling) 이 있으며, 각 방식의 장단점이 있습니다.

 

---

🔹 1️⃣ 수직 확장(Vertical Scaling)

 

✅ 더 높은 성능의 인스턴스로 업그레이드하는 방식

✅ 간단하게 확장 가능하지만, 한계가 존재

 

📌 AWS RDS에서 인스턴스 타입 업그레이드

aws rds modify-db-instance --db-instance-identifier pgvector-db --db-instance-class db.r6g.2xlarge --apply-immediately

✅ 기존 서버에서 성능을 올리는 방식이므로 설정 변경이 쉬움

 

---

🔹 2️⃣ 수평 확장(Horizontal Scaling)

 

✅ 여러 개의 데이터베이스 노드를 추가하여 트래픽을 분산하는 방식

✅ 대량의 벡터 데이터 검색 시, 샤딩(Sharding) 및 리플리케이션(Replication) 활용

 

📌 Citus 확장을 활용한 샤딩 적용

CREATE EXTENSION citus;
SELECT create_distributed_table('embeddings', 'id');

✅ 샤딩을 적용하면 여러 개의 데이터베이스에 벡터 데이터를 분산하여 처리 성능이 향상됨

 

---

🚀 2. Multi-Region 데이터베이스 배포

 

AI 검색 시스템이 글로벌 서비스를 운영하는 경우, Multi-Region 배포를 통해 검색 속도를 최적화할 수 있습니다.

 

✅ Multi-Region 운영 방식

 

배포 방식설명

Active-Active	여러 리전에 읽기/쓰기 노드를 배포하여 부하를 분산
Active-Passive	한 개의 주요 리전에서 쓰기, 다른 리전에서는 읽기 전용
Read Replica	여러 개의 리드 레플리카를 운영하여 읽기 성능 향상

 

 

---

🔹 1️⃣ AWS RDS 글로벌 데이터베이스 설정

 

📌 AWS RDS에서 Multi-Region 리드 레플리카 생성

aws rds create-db-instance-read-replica \
    --db-instance-identifier pgvector-replica \
    --source-db-instance-identifier pgvector-db \
    --region ap-northeast-1

✅ 이제 일본(ap-northeast-1) 리전에 읽기 전용 데이터베이스가 생성됨

 

---

🔹 2️⃣ Google Cloud SQL Multi-Region 배포

 

📌 Google Cloud SQL에서 자동 페일오버를 지원하는 Multi-Region 설정

gcloud sql instances patch pgvector-db --enable-point-in-time-recovery --enable-binlog

✅ Cloud SQL에서도 Multi-Region 배포를 지원하여 글로벌 검색 속도를 최적화할 수 있음

 

---

🚀 3. 장애 복구 및 Failover 전략

 

🔹 1️⃣ PostgreSQL 자동 장애 감지 및 복구

 

✅ HAProxy를 활용하여 장애 발생 시 자동으로 다른 노드로 전환

 

📌 HAProxy 설정 (primary → replica 자동 전환)

frontend postgresql
    bind *:5432
    mode tcp
    default_backend db_nodes

backend db_nodes
    mode tcp
    option pgsql-check user postgres
    server primary-db primary-db.local:5432 check
    server replica-db replica-db.local:5432 check backup

✅ Primary DB 장애 시, HAProxy가 자동으로 Replica로 트래픽을 전환

 

---

🔹 2️⃣ AWS RDS 자동 장애 복구 설정

 

📌 Multi-AZ 배포를 활용한 장애 복구

aws rds modify-db-instance --db-instance-identifier pgvector-db --multi-az

✅ Multi-AZ 설정을 활성화하면 장애 발생 시 자동으로 페일오버 수행

 

---

🔹 3️⃣ PITR(Point-in-Time Recovery)를 활용한 데이터 복원

 

✅ 특정 시점으로 데이터를 복구할 수 있도록 PITR을 설정

 

📌 PITR을 활용한 데이터 복원

aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier pgvector-db \
    --target-db-instance-identifier pgvector-recovery \
    --restore-time "2024-03-10T10:00:00Z"

✅ PITR을 활용하면 특정 시점의 데이터로 복원 가능

 

---

🚀 4. 성능 최적화를 위한 벡터 검색 튜닝

 

대규모 데이터에서 빠르게 검색하기 위해 벡터 인덱스를 최적화해야 합니다.

 

📌 HNSW 인덱스 생성

CREATE INDEX embeddings_hnsw ON embeddings USING hnsw (embedding vector_l2_ops);

 

📌 IVFFlat 인덱스 생성

CREATE INDEX embeddings_ivfflat ON embeddings USING ivfflat (embedding vector_l2_ops)
WITH (lists = 100);

✅ HNSW & IVFFlat 인덱스를 활용하면 벡터 검색 속도를 크게 향상 가능

 

---

📌 5. 최종 정리

 

✅ 벡터 검색 시스템의 트래픽 확장 전략 (수평/수직 확장)

✅ Multi-Region 데이터베이스 배포 및 글로벌 서비스 운영

✅ 고가용성을 위한 장애 복구 및 Failover 전략