멀티 서버 아키텍처: 관심사의 분리

이 글은 우리의 인프라가 관심사의 분리를 통해 확장성, 신뢰성, 성능을 달성하기 위해 어떻게 전문화된 서버를 사용하는지 설명합니다.

문제점: 모놀리식 서버의 한계

모든 것을 한 서버에서 실행하면 다음과 같은 문제가 발생합니다:

자원 경쟁: 웹 서버가 검색 서비스와 CPU/메모리를 두고 경쟁
확장 어려움: 구성 요소를 독립적으로 확장할 수 없음
단일 장애점: 한 서버 다운 = 전체 시스템 다운
비용 비효율성: 워크로드별로 인스턴스 유형을 최적화할 수 없음
배포 위험: 한 구성 요소 배포가 다른 모든 구성 요소에 영향

우리는 여러 서버에 걸쳐 관심사의 분리가 필요합니다.

해결책: 전문화된 서버 역할

우리는 각각의 워크로드에 최적화된 전문화된 서버를 실행합니다:

graph TB
    subgraph prod[프로덕션 ERP 서버]
        erp[내부 관리 시스템
인사, 재무, 제조
24/7 가동 시간
공유 스토리지 및 이메일]
    end
    
    subgraph web[공개 웹사이트 서버]
        www[공개 웹사이트
제품 카탈로그, 블로그
24/7 가동 시간
CDN 뒤에 위치]
    end
    
    subgraph dev[개발/스테이징 서버]
        devenv[개발 및 스테이징
이메일 캠페인
야간/주말에 전원 꺼짐]
    end
    
    subgraph search[검색 서비스 서버]
        searchsvc[벡터 검색
필터 추출
관련 검색어
24/7 가동 시간]
    end
    
    subgraph cache[캐시 서버 - Valkey]
        valkey[RediSearch 인덱스
쿼리 임베딩
자동 완성
24/7 가동 시간]
    end
    
    www --> searchsvc
    searchsvc --> valkey

왜 서버를 분리하나요?

1. 자원 격리

각 서버는 한 가지 유형의 워크로드를 실행합니다:

웹 서버: HTTP 요청 처리에 최적화

높은 네트워크 대역폭
중간 수준 CPU
중간 수준 메모리
캐싱을 위한 빠른 디스크

검색 서비스: 벡터 연산에 최적화

높은 CPU (코사인 유사도)
높은 메모리 (임베딩 캐시)
낮은 디스크 I/O

캐시 서버: 메모리 접근에 최적화

매우 높은 메모리
낮은 CPU
빠른 네트워크

장점: 워크로드 간 자원 경쟁이 없음.

2. 독립적 확장

각 구성 요소를 독립적으로 확장할 수 있습니다:

트래픽이 많나요? 로드 밸런서 뒤에 웹 서버를 더 추가합니다.
검색이 느리나요? 검색 서버 CPU를 업그레이드하거나 복제본을 추가합니다.
캐시 미스가 많나요? 캐시 서버 메모리를 늘립니다.
장점: 필요한 것만 확장하고, 모든 것을 확장하지 않음.

3. 장애 격리

장애가 격리됩니다:

검색 서비스가 다운되었나요? 웹사이트는 캐시된 결과를 계속 제공합니다.

캐시 서버가 다운되었나요? 검색 서비스는 캐시 없이 계산합니다 (느리지만 기능함).

웹 서버가 다운되었나요? 내부 ERP는 영향을 받지 않습니다.

장점: 부분적 장애가 전체 시스템으로 전파되지 않음.

4. 배포 안전성

환경을 통해 배포합니다:

개발 → 디버그 도구로 변경 사항 테스트

스테이징 → 프로덕션과 유사한 환경에서 테스트

프로덕션 → 확신을 가지고 배포

장점: 사용자에게 도달하기 전에 문제를 발견.

5. 비용 최적화

서버별로 비용을 최적화합니다:

개발 서버: 야간/주말에 전원 꺼짐 (50% 비용 절감)
IPv6 전용 서버: 탄력적 IP 비용 없음 (인스턴스당 월 $5 절감)
적정 크기 인스턴스: 워크로드별로 필요한 자원에만 비용 지불
장점: 성능을 희생하지 않고 인프라 비용 절감.

서버 간 데이터 흐름

데이터가 어떻게 흐르는지 이해하면 분리가 왜 중요한지 설명하는 데 도움이 됩니다:

사용자 요청 흐름

제품 페이지 요청:

sequenceDiagram
    participant User
    participant CDN
    participant Web as Web Server
    participant Search as Search Service
    participant Cache as Cache Server
    
    User->>CDN: 제품 페이지 요청
    CDN->>CDN: 캐시 확인
    alt Cache hit
        CDN->>User: 캐시된 페이지 제공
    else Cache miss
        CDN->>Web: 요청 전달
        Web->>Search: 관련 제품 가져오기
        Search->>Cache: 임베딩 쿼리
        Cache->>Search: 결과 반환
        Search->>Web: 관련 제품
        Web->>CDN: 렌더링된 페이지
        CDN->>CDN: 응답 캐싱
        CDN->>User: 페이지 제공
    end

검색 쿼리 흐름:

sequenceDiagram
    participant User
    participant Web as Web Server
    participant Search as Search Service
    participant Cache as Cache Server
    
    User->>Web: 검색 쿼리 제출
    Web->>Search: 쿼리 전달
    Search->>Search: 필터 추출
    Search->>Search: 임베딩 계산
    Search->>Cache: 벡터 검색
    Cache->>Search: 순위가 매겨진 결과
    Search->>Web: 제품 일치 항목
    Web->>User: 결과 렌더링

장점: 각 서버가 최적화된 작업을 수행.

서버별 저장 전략

다른 서버는 다른 저장 전략을 사용합니다:

웹 서버

S3 기반 정적 파일: S3에서 제공되는 이미지, CSS, JS

높은 가용성
로컬 디스크 사용 없음
CDN 친화적

로컬 캐시: Nginx가 렌더링된 페이지 캐싱

빠른 반복 접근
자동 무효화

검색 서비스

NumPy 배열: 이진 배열로 저장된 제품 임베딩

빠른 벡터 연산
효율성을 위한 메모리 매핑
65K 제품 × 768 차원 = ~190 MB

JSON 파일: 필터 매핑, 구문 테이블

사람이 읽을 수 있음
업데이트 용이
작은 크기 (<10 MB)

캐시 서버

Valkey (Redis): 쿼리 임베딩, 인기 쿼리, 자동 완성

속도를 위한 메모리 내 저장
벡터 인덱스를 위한 RediSearch
내구성을 위한 지속성

왜 다른 저장소를 사용하나요?

NumPy: 벡터 수학에 최적화 (코사인 유사도)
JSON: 사람이 편집하는 데 최적화 (필터 규칙)
Valkey: 키-값 조회에 최적화 (쿼리 캐시)

CDN 아키텍처

공개 웹사이트는 콘텐츠 전송 네트워크 뒤에 위치합니다:

무엇이 캐시되나요

정적 자산 (긴 TTL):

이미지, CSS, JavaScript
글꼴, 아이콘
1년 동안 캐시

제품 페이지 (중간 TTL):

제품 설명
사양
1시간 동안 캐시

쿼리 페이지 (짧은 TTL):

검색 결과
필터 조합
5분 동안 캐시

캐시되지 않음:

사용자별 콘텐츠
API 엔드포인트
동적 검색

왜 CDN이 중요한가

글로벌 지연 시간: 에지 로케이션이 사용자에게 더 가까운 곳에서 콘텐츠 제공
오리진 보호: CDN이 트래픽 급증을 흡수, 오리진 서버 보호
DDoS 완화: CDN이 악성 트래픽을 오리진에 도달하기 전에 필터링
비용 절감: 오리진 요청 감소 = 컴퓨팅 비용 절감

배포 파이프라인

문제를 조기에 발견하기 위해 환경을 통해 배포합니다:

개발 환경

목적: 디버그 도구를 통한 빠른 반복 기능:

코드 변경 시 자동 재로드
상세한 오류 페이지
디버그 도구 모음
캐싱 없음

장점: 개발자를 위한 빠른 피드백 루프.

스테이징 환경

목적: 프로덕션과 유사한 테스트 기능:

프로덕션과 동일한 구성
동일한 서버 설정 (Gunicorn, Nginx)
동일한 캐싱 동작
프로덕션 데이터로부터 격리

장점: 배포 전 프로덕션 특정 문제 발견.

프로덕션 환경

목적: 실제 사용자 제공 기능:

성능에 최적화
전체 캐싱 활성화
모니터링 및 경고
충돌 시 자동 재시작

장점: 안정적이고 신뢰할 수 있는 서비스.

참고 자료

기술 개념

관심사의 분리 - 위키백과
콘텐츠 전송 네트워크 (CDN) - 위키백과
수평 확장 - 위키백과
코사인 유사도 - 위키백과

AWS 서비스

CloudFront - AWS CDN 문서
S3 - AWS 객체 저장소 문서
DynamoDB - AWS NoSQL 데이터베이스 문서

검색 서비스 아키텍처 - 독립형 검색 서비스 상세
SEO 임베딩 전략 - all-mpnet-base-v2 사용 이유
SEO 제품 매칭 - 벡터 검색 작동 방식
번역 시스템 - 다국어 지원 아키텍처

요약

우리의 멀티 서버 아키텍처는 전문화된 서버에 걸쳐 관심사를 분리합니다:

프로덕션 ERP 서버:

내부 관리 시스템
24/7 가동 시간
공유 스토리지 및 이메일

공개 웹사이트 서버:

고객 대면 웹사이트
24/7 가동 시간
S3 기반 정적 파일과 함께 CDN 뒤에 위치

개발/스테이징 서버:

안전한 테스트 환경
이메일 캠페인 처리
비용 최적화 (야간/주말에 전원 꺼짐)

검색 서비스 서버:

벡터 유사도 검색
필터 추출
NumPy 기반 임베딩

캐시 서버 (Valkey):

쿼리 임베딩 캐시
RediSearch 벡터 인덱스
인기 쿼리 순위

주요 장점:

✅ 자원 격리: 워크로드 간 경쟁 없음
✅ 독립적 확장: 필요한 것만 확장
✅ 장애 격리: 장애가 전파되지 않음
✅ 배포 안전성: 프로덕션 전 테스트
✅ 비용 최적화: 적정 크기 인스턴스, 전원 일정
✅ 성능: CDN 캐싱, 전문화된 저장 전략

이 아키텍처는 높은 가용성, 낮은 지연 시간, 관리 가능한 비용을 유지하면서 수백만 건의 요청을 제공할 수 있게 합니다.

← 문서 색인으로 돌아가기

제품

인기 검색어 및 블로그