Please enable JavaScript.

Coggle requires JavaScript to display documents.

Elasticsearch를 활용한 비디오 검색 기능 - Coggle Diagram

- - - - 특징 및 장점
        
        빠른 검색 성능
        
        캐싱 메커니즘
        
        필터 캐시: 자주 쓰이는 filter 절의 결과를 캐시
        
        파일 시스템 캐시: 운영체제 차원의 페이지 캐시 활용
        
        디스크/메모리 최적화
        
        세그먼트 단위 읽기: 랜덤 I/O 최소화
        
        핫 데이터는 OS 파일 캐시에 머물러 거의 메모리 수준의 속도를 제공
        
        풍부한 쿼리 DSL
        
        Full‑text: match, multi_match, match_phrase
        
        구조화: term, terms, range
        
        부울(Boolean): bool (must/should/filter)
        
        집계(Aggregations): terms, date_histogram, stats 등 대규모 로그/메트릭 실시간 통계
        
        지오포인트(Geo): geo_distance, geo_bounding_box
        
        스크립트 기반: Painless 스크립트를 활용한 커스텀 점수 및 집계
        
        역색인(Inverted Index) 구조
        원본 문서 → 단어 단위로 분해(토큰화-tokenization)
        → 각 단어가 등장한 문서 리스트를 역으로 매핑
        
        왜 빠른가?
        
        직접 조회
        모든 문서를 스캔하지 않고도, 키(단어)에 해당하는
        포인터만 접근해 결과 리스트를 조회
        
        효율적인 압축
        포스팅 리스트를 델타 인코딩, 비트맵 등으로 압축해
        디스크 I/O 및 메모리 점유 최소화
        
        병렬 처리 최적화
        색인 샤드(shard) 단위 분산 배치로 동시 검색
        
        구조 예시
        * 키: “video”, “search”, … * "video" → [doc1 (pos:2), doc3 (pos:4)] * "search" → [doc2 (pos:5), doc4 (pos:1), doc7 (pos:3)] * → “search”가 들어간 문서 곧바로 추적, 위치 기반 순위 산정(phrase query, proximity) 가능
        
        실시간 색인/검색
        색인 요청이 들어오면 수십~수백 밀리초 내 검색 결과에 반영
        
        Memory-mapped files가 디스크 I/O를 OS 캐시로 우회하는 메커니즘
        
        Elasticsearch는 검색 시 디스크에서 직접 블록 단위로 읽지 않고, Lucene 세그먼트를 메모리-매핑(mmap)하여 운영체제 파일시스템 캐시를 활용
        
        이로 인해 운영체제 레벨의 페이지 캐시에 핫 데이터(hot regions)가 상주하게 되고, 시스템 콜 오버헤드 없이 메모리처럼 빠르게 접근 가능
        
        Refresh Cycle
        
        색인된 문서는 메모리 버퍼에 먼저 저장된 뒤, 주기적(index.refresh_interval)으로 새 세그먼트에 플러시(flush)되어 검색 인덱스에 반영
        
        기본값인 1s를 더 짧게(예: 100ms) 조정하면 더 빠른 반영이 가능하지만, 세그먼트 수 증가로 인한 오버헤드도 고려해야 함
        
        분산 처리 구조
        (Cluster ↔ Node ↔ Shard)
        
        클러스터와 노드
        
        클러스터
        
        하나의 논리적 검색 도메인
        
        여러 노드(Node)가 모여 구성됨
        
        단일 cluster.name으로 묶임
        
        노드
        
        클러스터를 이루는 개별 서버 프로세스 (가상 머신, 컨테이너 등)
        
        역할:
        
        마스터 노드 / 데이터 노드 / 클라이언트(코디네이터) 노드 등
        
        샤드와 복제본(Replica)
        
        샤드
        
        인덱스를 여러 개의 파티션(shard)로 분할
        
        각 샤드는 Lucene 인스턴스(작은 독립 인스턴스)
        
        대용량 데이터를 수평(scale-out)으로 분산 저장/검색 가능
        
        Replica(복제본)
        
        각 샤드를 복제하여 고가용성 및 읽기 성능 향상
        
        한 노드 장애 시에도 데이터/검색 서비스 중단 없음
        
        데이터 흐름
        
        색인 요청 → Coordinating Node 수신
        
        요청을 해당 문서의 라우팅 키(기본 _id 해시)에 따라 Primary Shard에 전달
        
        Primary Shard가 색인 후, Replica Shard에 동기 복제(sync)
        
        검색 요청 → 모든 활성 Shard (Primary + Replica)에서 병렬 검색
        
        결과 통합 후 반환
        
        주요 장점
        
        수평 확장성(Scalability)
        인덱스를 여러 개의 샤드로 분할하고, 이 샤드를 다수의 노드에 분산 배치함으로써 데이터 볼륨이 늘어나거나 부하가 높아질 때, 노드를 추가하기만 하면 용량과 처리량을 선형적으로 늘릴 수 있음
        
        고가용성/내결함성
        각 샤드는 하나의 Primary와 복제본인 Replica로 구성 → 특정 노드가 다운되더라도 Replica가 Primary의 역할을 대신해, 서비스의 중단 없이 안정적인 운영 가능
        
        부하 분산(Load Balancing)
        모든 노드는 클러스터 메타데이터를 공유하며, 검색 요청이나 색인 요청을 가장 적합한 노드(Primary or Replica)로 자동 라우팅해, 전체 클러스터에 부하를 고르게 분산
        
        자동 관리(Automatic Management)
        샤드 할당, 복제본 생성/복구, 노드 추가/제거 시 자동으로 데이터 재분배와 재복제를 수행하여, 운영자가 수작업으로 개입하지 않아도 항상 최적화된 상태를 유지
        
        ETC
        
        확장성 플러그인 생태계
        Ingest-Attachement, Vector Search, 머신러닝(X-Pack ML) 등 자유롭게 확장
        
        머신러닝 통합
        
        8.x 부터 내장된 이상 탐지 및 분석 기능
        
        이상 탐지(Anomaly Detection), 예측 모델이 기본 제공됨 (X-Pack ML)
        
        다양한 클라우드 제공
        Elastic Cloud, AWS OpenSearch, GCP Elasticsearch 등 매니지드 서비스
        
        RESTful API
        HTTP + JSON 인터페이스로 모든 언어에서 접근 용이
        
        문서 지향 구조
        (Document-Oriented)
        
        스키마 유연성
        JSON 문서를 바로 색인하므로, RDMBS 처럼 미리 테이블/컬럼을 정의할 필요 없이 필드를 자유롭게 추가/변경하는 것이 가능
        
        Self-containted 객체 저장
        한 문서 안에 모든 관련 데이터를 담아 조인 없이 즉시 검색 가능
        
        다양한 데이터 타입 지원
        배열, 중첩 객체(nested), 지리 정보(geo_point) 등 복합 구조를 자연스럽게 표현/색인
        
        개발 생산성 향상
        스키마 마이그레이션/DDL 작업 없이도 민첩하게 애플리케이션 변경 대응 가능
        
        데이터 수명주기 관리
        
        ILM
        (Index Lifecycle Management)
        디스크 사용 최적화 및 장기 성능 유지 목적
        (Hot → Warm → Cold → Frozen → Delete 단계 자동 관리)
        
        Hot Phase
        rollover: 인덱스가 최대 크기(ex. 50GB) 또는
        최대 나이(ex. 30일)에 도달하면 새 인덱스로 전환
        
        Warm Phase(Optional)
        shrink: 샤드 수를 줄여 디스크 및 메모리 자원 절감
        
        Cold Phase
        읽기 전용 상태로 이전해 인덱스가 더 이상 업데이트 되지 않게 함
        
        1 more item...
      - 등장 배경
        
        2010년 Shay Banon이 자신의 아내가 쓴 요리책 검색 엔진 프로젝트인 Compass를 발전 시켜 만든 프로젝트로, 기존 Lucene의 단일 JVM 제약을 뛰어넘어 분산 환경에서 실시간 검색/분석을 가능하게 하고자 함
        
        2012년 첫 공개 후, 자동 샤딩/복제, RESTful API, 클러스터 관리 기능을 빠르게 추기하며 대규모 로그/문서 검색 엔진 표준으로 자리잡음
        
        2015년 ELK 스택이 표준화 되면서 Elasticsearch의 채택 증가
        (산업적 영향력⬆)
      - 주의 및 고려 사항
        
        라이선스
        라이선스 확인 필요 - 일부 상용화 시 라이선스 제약이 있을 수 있음
        
        기본 검색/색인 기능만 사용하고, 소스코드 수정 및 재배포나
        X-Pack 상용 플러그인을 쓰지 않으면 라이선스 위반이 아님.
        단순 검색 API 호출만 필요하다면, 8.x 버전 사용에 문제 없음.
        하지만, "SaaS 제공"은 제한되므로 OSS를 선호한다면 OpenSearch 고려.
        
        트랜직션/롤백 미지원
        Elasticsearch는 검색/분석용 분산 엔진으로 설계되었으며,
        전통적인 RDBMS 스타일의 트랜잭선/롤백 기능은 제공하지 않음
        
        Shay Banon의 공식 답변에 따르면 앞으로도 지원 예정 없음
        
        단일 문서 업데이트(versioning)을 지원해 충돌 감지가 가능하지만,
        다중 문서를 한 트랜잭션으로 묶어 커밋/롤백하는 기능은 없음
        
        진정한 의미의 update 없음
        실제로는 delete + reinsert 동작.
        기존 문서는 삭제되고 새 버전으로 삽입되며,이에 따라 _version 필드 값 증가
        
        Lucene 세그먼트의 불변성
        각 세그먼트는 immutable 파일 구조로 저장되며,
        한 번 쓰인 세그먼트는 변경되지 않음
        
        Soft delete
        update API의 내부 동작:
        문서 조회(GET) => 스크립트 실행 또는 doc 병합 => 결과 문서를 새 세그먼트에 색인(index)
        
        이 과정에서 기존 문서는 soft delete로 표시만 되고, 실제로는 새로운 문서로 대체됨
        
        삭제된(soft delete) 문서의 잔재
        "deleted"로 표시된 문서는 곧장 디스크에서 없어지지 않으므로,
        실제 데이터 파일 안에는 여전히 남아있고,
        검색 시에는 이를 무시하지만 디스크의 공간은 차지
        
        세그먼트 머지(segment merge)의 필요성
        삭제된 문서가 많은 세그먼트가 계속 쌓이면, 디스크 사용량이 증가하고 검색 성능 및 I/O 부하에도 악영향.
        이를 해결하기 위해 Elasticsearch는 백그라운드에서 주기적으로 여러 작은 세그먼트를 하나로 머지하면서,
        soft delete 표시 문서는 실제 제거되고, 살아남은 문서들만 새 세그먼트에 모아서 저장
        
        1 more item...
        
        운영 리스크 및 완화 전략
        
        샤드 불균형
        
        원인: 문서 분포가 특정 샤드에 편중
        
        전략: /_cluster/allocation/explain 으로 원인 파악 후 리밸런스 API 실행
        
        메모리 과다 사용
        
        원인: 대용량 집계/필드데이터(fielddata) 사용
        
        전략: 필드데이터 캐시 제한, doc_values 사용
        
        색인 지연(Refresh Delay)
        
        원인: 높은 색인 부하 → 기본 refresh interval(1s) 미달
        
        전략: index.refresh_interval 늘리기, 배치 색인 사용
        
        세그먼트 머지 부하
        
        원인: 잦은 업데이트/삭제 → 작은 세그먼트 과다 생성
        
        전략: ILM 정책으로 merge 스케줄 제어
    - - DB 내장 검색 vs. Elasticsearch
        
        RDBMS 텍스트 검색
        
        색인 구조: B-Tree, InnoDB Full-text 등
        
        퍼포먼스: 대규모에서 느림
        
        확장성:수직 확장 위주
        
        쿼리 표현력: 제한적 (Like, MATCH)
        
        Elasticsearch
        
        색인 구조: 역색인 (Inverted Index)
        
        퍼포먼스: 수백만~수십억 문서 고속 검색
        
        확장성: 수평 확장(샤딩/복제) 용이
        
        쿼리 표현력: 다양한 Full-text, 분석기, 집계
      - 검색 엔진 비교
        
        Apache Solr
        
        색인 엔진: Lucene 기반
        
        분산 관리: ZooKeeper 연동 필요
        
        기능 확장: 플러그인 지원
        
        커뮤니티/지원: Apache 재단 커뮤니티
        
        무료이지만 Zookeeper 운영 오버헤드로
        총비용 상승 가능
        
        장점: 성숙한 커뮤니티, 복잡한 스키마 지원
        
        단점: 초기 설정 및 운영 복잡
        
        비용/라이선스/운영 관점
        
        라이선스
        Apache 2.0 완전 무료
        
        기존 인프라 활용
        
        Elasticsearch와 동일하게 설치만으로 추가 라이선스 필요 없음
        
        다만, ZooKeeper 기반 클러스터링 필요 → 운영 오버헤드 증가
        
        비용 예측
        
        노드 사용에 따라 PoC-운영 비용 범위 유사 (수십~수백 달러)
        
        ZooKeeper 관리 및 운영을 위한 추가 서버 또는 매니지드 솔루션 고려 시 비용 발생
        
        직접 호스팅 vs. 매니지드
        
        자체 호스팅이 주류 (Elastic Cloud 처럼 공식 매니지드 제공 없음)
        
        커뮤니티 및 상업 지원은 별도 계약 필요
        
        스케일 아웃
        SolrCloud로 샤딩 가능하지만 ZooKeeper 의존성이 있어 운영 복잡도 상승
        
        OpenSearch
        
        색인 엔진: Elasticsearch 7.10 OSS 포크
        
        분산 관리: ELK와 호환, ALv2 오픈소스
        
        기능 확장: 대부분 Elasticsearch 기능 계승
        
        커뮤니티/지원: AWS/커뮤니티 지원
        
        무료 OSS + AWS 통합 관리형 옵션
        자체 호스팅 시 비용 구조는 Elasticsearch와 유사
        
        장점: 7.10 OSS 기반, AWS 통합, Apache 2.0
        
        단점: 최신 Elastic 기능 일부 미반영
        
        비용/라이선스/운영 관점
        
        라이선스
        Apache 2.0 (Elasticsearch 7.10 OSS 포크)로 모든 기능 무료
        
        AWS 통합 관리형 서비스
        
        AWS OpenSearch Service → 프리티어/온디맨드 요금제 (수십~수백 달러)
        
        IAM, S3 snapshot, CloudWatch 통합 → 운영 스크립트, 추가 구성 최소화
        
        자체 호스팅
        
        Elasticsearch와 마찬가지로 서버에 설치 시 순수 OSS 무료
        
        샤드/노드 추가만으로 수평 확장 → 비용 예측 단순
        
        직접 호스팅 vs. 매니지드
        
        AWS 관리형은 편의성 대가로 구독료가 발생함
        
        자체 호스팅 시 사용자 스크림트로 관리 → TCO 절감
        
        스케일 아웃
        Elasticsearch 7.10 호환 → 동일한 샤드/복제본 전략 사용 가능
        
        Elasticsearch
        
        색인 엔진: Lucene 기반
        
        분산 관리: 내장 샤드/노드 조율 자동화
        
        기능 확장: 플러그인 풍부
        
        커뮤니티/지원: Elastic 상업지원/커뮤니티
        
        비용/라이선스/운영 관점
        
        추가 라이선스 비용
        
        OSS 기본 검색 기능은 무료(소스코드 변경 불가)
        
        키바나, X-Pack 상용 기능 미사용 시 구독료 없음
        
        기존 인프라 활용
        이미 보유한 서버에 설치 시 순수 증분 비용 '0'에 가까움
        
        단계적 확장 비용 예측 용이
        
        PoC: t3.micro/t3.small 한 대 → 월 $1–2
        
        중간: t3.medium/t3.large → 월 $10–20
        
        운영: 노드만 추가 → 클러스터당 단순 비용 모델
        
        직접 호스팅 vs. 매니지드
        
        관리형 서비스(Elastic Cloud)는 월 수백 달러 구독료 발생
        
        직접 호스팅 시 "편의성"을 자체 스크립트로 대체하면 장기 TCO 절감 가능
        
        스케일 아웃
        샤드/노드 최소화 → 필요 시 확장 → 언제나 가장 작은 비용 구조 유지
        
        라이선스 무료/기존 인프라 증분 비용 거의 없음
        가장 세밀한 비용 제어 가능
        
        성능 벤치마크
        Elasticsearch 8.7은 OpenSearch 2.7보다 40-140% 더 빠른 성능을 보임
        2023년 8월 Elastic 공개
        
        1TB 의 데이터셋을 사용해
        텍스트 쿼리, 정렬, 날짜 히스토그램, 용어, 범위 쿼리 등 다양한 작업에서 측정
        
        주요 결과
        
        색인 속도
        Elasticsearch는 OpenSearch보다
        더 적은 자원으로 동일한 데이터를 더 빠르게 색인
        
        검색 속도
        모든 쿼리 유형에서 Elasticsearch가 OpenSearch를 앞섰으며,
        특히 복잡한 집계 작업에서 차이가 두드러짐.
        벡터 검색(ANN) 역시 최대 12배 빠름
        
        자원 효율성
        Elasticsearch는 CPU와 메모리 사용량이 더 낮아,
        동일한 하드웨어에서 더 높은 처리량을 제공
        
        Elastic은 이 벤치마크 과정을 오픈 소스로 공개해 투명성을 확보하고, Elasticsearch의 검색 및 색인 성능이 OpenSearch보다 우수함을 입증
    - - Elasticsearch 클러스터 준비
        Docker 또는 EC2에 Elasticsearch 8.x 싱글/멀티 노드 설치
        (단순 검색 엔진용은 라이선스 이슈 X)
        
        데이터 소스(DB) 연결
        Logstash의 JDBC Input 플러그인을 이용해
        기존 RDMBS 테이블에서 비디오 메타데이터(tags, title, description 등) 확보
        
        Logstash 파이프라인 구성
        
        Input: JDBC로 DB 쿼리(증분 로딩 쿼리 포함)
        
        FIlter: 필요 시, mutate, split, date 등으로 데이터 가공
        
        Output: Elasticsearch에 색인 (index 이름 지정, document_id 매핑)
        
        인덱스 설계 및 매핑
        
        tags 등 텍스트 필드는 text 타입 + 적절한 분석기(analyzer) 설정
        
        video id 는 keyword 타입으로 식별자 매핑
        
        업로드 일자 등 날짜 필드는 date 타입으로 매핑
        
        검색 쿼리 호출
        
        애플리케이션에서 Elasticsearch REST API로 match, bool 쿼리 실행
        
        연관도(_score) 및 날짜순 등으로 정렬
        
        결과 파싱 및 UI 렌더링
        쿼리 결과(JSON)에서 상위 N개 문서 추출 후, 인앱 화면에서 비디오 썸네일, 제목, 태그 등을 사용자에게 표시
  - - - 다양한 종류의 비트를 통해 데이터를 수집해서 Logstash나 Elasticsearch로 전송
        OR
        Logstash에서 원하는 데이터를 수집해 Elasticsearch에 전송
        
        Elasticsearch에서 데이터를 저장 / 분석
        
        Kibana에서 시각화