YG Tech Blog

운영 환경에서 로그 및 메타데이터는 단순 검색만으로 끝나지 않습니다.감사, 법적 보존, 보안 사고 대응, R&D 분석 등을 위해장기적이고 변경 불가능한 방식으로 안전하게 보존되어야 하며,이와 동시에 검색 가능한 상태를 유지하는 것이 중요합니다. 이번 글에서는 MinIO 기반 Searchable Snapshot 구조에 보안성과 컴플라이언스 기능을 더하는 전략을 정리합니다. 📦 보안 및 규정 대응이 필요한 상황 예시상황필요 기능전자금융감독원, ISMS, SOC2 등 대응데이터 변경 불가, 장기 보존사고 조사 및 감사 대응원본 스냅샷 보존 + 추적 가능고의적 삭제 방지오브젝트 삭제 제한 (Object Lock)실수 복구 대비버전 관리로 과거 상태 복원 가능개인정보 암호화 저장저장 시점에서 암호화 적용 필요..

지난 글에서는 MinIO 기반의 Searchable Snapshot을 다른 OpenSearch 클러스터로 복원하는 방법과 DR 구조를 알아보았습니다.이제는 Searchable Snapshot 구조를 운영 환경에서 실제로 빠르게 활용할 수 있도록 만드는 검색 성능 최적화 전략에 대해 다뤄보겠습니다. 📌 전제 상황snapshot은 MinIO에 저장됨 (storage_type: remote_snapshot)검색 쿼리는 remote object storage에서 데이터를 읽어옴OpenSearch는 로컬 캐시와 node role을 통해 이를 최적화할 수 있음 🧩 주요 성능 영향 요소요소설명📡 네트워크 대역폭MinIO와 OpenSearch 간 I/O 속도📦 MinIO 스토리지 성능HDD vs SSD, 분..

이전 글에서 우리는 Searchable Snapshot + MinIO + SLM + ILM 조합을 통해로그 데이터를 자동 백업하고 검색 가능한 형태로 저장하는 구조를 완성했습니다. 이번 글에서는 이 구조를 기반으로, 재해 복구(Disaster Recovery) 및 멀티 클러스터 복원 전략을 설계하는 방법을 소개합니다. 💥 왜 DR 구조가 필요한가? 운영 중인 클러스터가 장애나 삭제, 혹은 심각한 성능 저하로 인해 사용 불가능할 경우,백업된 데이터를 다른 OpenSearch 클러스터에 빠르게 복원할 수 있어야 합니다. 🔁 기존 구조 요약운영 클러스터: snapshot을 MinIO에 저장 (SLM 자동화)MinIO: 중앙 오브젝트 스토리지 (S3 호환)DR 클러스터: 필요 시 MinIO로부터 snap..

앞서 우리는 Searchable Snapshot을 직접 생성하고 복원하여 원격에서 검색하는 방법까지 살펴봤습니다.하지만 운영 환경에서는 매번 수동으로 API를 호출하기보다는, 자동으로 snapshot을 생성하고 관리하는 것이 필요합니다. 이번 글에서는 OpenSearch의 Snapshot Lifecycle Management(SLM) 기능을 사용하여,정기적으로 Searchable Snapshot을 만들고, 기존 인덱스를 remote searchable 형태로 전환하는 전체 과정을 소개합니다. 📌 왜 SLM이 필요한가?항목설명💼 자동화수동 API 호출 없이 자동으로 snapshot 생성🧹 관리 용이성snapshot 보존 주기, 이름 규칙, 실패 알림 등 설정 가능🔁 ILM 연계특정 시점에 인덱스를..

지난 포스트에서는 기존 Warm Tier를 제거하고, MinIO 기반 Searchable Snapshot 구조로 전환하는 방법을 정리했습니다.이번 글에서는 실제로 이렇게 저장된 Searchable Snapshot을 어떻게 원격에서 검색하는지 실습을 통해 자세히 알아보겠습니다. 🧩 전제 조건: 환경 구성 요약OpenSearch 2.x 이상repository-s3 플러그인 설치됨minio 오브젝트 스토리지 준비됨버킷에 snapshot이 이미 존재함 (logs-snap-202308)snapshot은 remote_snapshot 으로 복원됨 지난 포스트에서 설명한 구조를 그대로 이어받습니다. 🔁 1. 스냅샷 복원 (remote_snapshot 설정) 먼저, 원격 스냅샷을 복원하되, 로컬로 가져오지 않고 바..

운영 로그 데이터가 점점 늘어나면서, 과거에는 흔히 사용하던 Hot-Warm-Cold 아키텍처도 진화할 필요가 생겼습니다. 최근에는 Warm Tier 노드 없이도 장기 데이터를 검색 가능하게 해주는 “Searchable Snapshot” 기능이 등장하며, MinIO와 OpenSearch를 함께 사용하는 사례가 늘고 있습니다. 이번 글에서는 기존 Warm Tier를 제거하고, MinIO 오브젝트 스토리지를 기반으로 Searchable Snapshot 구조를 도입하는 방법을 총체적으로 정리합니다. 📌 왜 Warm Tier를 Searchable Snapshot으로 대체해야 할까? 기존 구조Hot Tier (NVMe SSD) → Warm Tier (HDD) → Cold Tier Warm Tier는 상대적으..

이 글에서는 전통적인 메시지 큐(RabbitMQ, ActiveMQ 등)와 Apache Kafka 간의 핵심적인 차이점을 살펴봅니다. 아키텍처, 성능, 활용 사례, 데이터 처리 방식 등 여러 측면에서 두 시스템을 비교하여 각각 어떤 상황에서 더 적합한지 이해할 수 있도록 도와드립니다.📌 메시지 큐와 Kafka: 개념 비교메시지 큐와 Kafka는 모두 애플리케이션 간 비동기 통신을 지원하는 미들웨어지만, 근본적인 설계 철학과 목적에 차이가 있습니다. ✅ 메시지 큐(Message Queue)란?애플리케이션 간 메시지를 전달하는 중간 저장소 역할주로 작업 부하 분산, 비동기 처리, 시스템 간 결합도 감소를 위해 설계AMQP(Advanced Message Queuing Protocol)와 같은 표준 프로토콜 기..

이 글에서는 Apache Kafka의 기본 개념, 탄생 배경과 문제 해결 목적을 알아보겠습니다. 분산 시스템의 메시지 처리에 관심 있는 분들에게 Kafka가 왜 중요한지, 그리고 어떤 특징을 가지고 있는지 명확히 이해할 수 있도록 도와드립니다.📌 Kafka의 정의와 핵심 특징Kafka는 LinkedIn에서 개발되어 2011년 오픈소스로 공개된 분산 이벤트 스트리밍 플랫폼입니다. 간단히 말하면, Kafka는 다양한 시스템 간에 대용량 데이터를 안정적으로 주고받을 수 있게 해주는 메시징 시스템입니다. ✅ Kafka의 세 가지 핵심 기능데이터 스트림 발행(publish)과 구독(subscribe) - 다른 시스템에서 발생한 이벤트를 실시간으로 주고받을 수 있습니다데이터 스트림 저장 - 내구성 있게 데이터를 ..

이 글에서는 쿠버네티스 Secret을 활용하여 MinIO의 민감한 자격 증명 정보를 안전하게 관리하는 방법에 대해 알아보겠습니다. 보안 모범 사례와 함께 실제 구현 방법을 상세히 설명합니다.📌 쿠버네티스 Secret 개념 이해하기✅ Secret이란 무엇인가?Secret은 비밀번호, API 키, 인증서와 같은 민감한 정보를 저장하기 위한 쿠버네티스 리소스입니다. ConfigMap과 유사하지만 보안에 중점을 둔 리소스입니다.▶️ Secret의 주요 특징:민감 데이터를 저장하도록 설계됨Base64 인코딩으로 저장 (암호화는 아님)etcd에 저장될 때 암호화 가능 (추가 구성 필요)메모리에만 마운트 가능 (tmpfs)Pod 간 공유 제한 가능apiVersion: v1 # 핵심 ..

이 글에서는 Cilium을 사용하여 MinIO에 기본 네트워크 정책을 적용하는 방법을 실습 형태로 살펴보겠습니다. 네트워크 정책을 통해 MinIO 서버에 대한 접근을 효과적으로 제한하고 보안을 강화하는 방법을 단계별로 설명합니다.📌 네트워크 정책 개요✅ 네트워크 정책이란?네트워크 정책은 쿠버네티스에서 Pod 간 통신을 제어하는 규칙 집합입니다. Cilium은 쿠버네티스 표준 NetworkPolicy를 지원할 뿐만 아니라, 확장된 기능을 제공하는 CiliumNetworkPolicy도 지원합니다.▶️ 네트워크 정책의 주요 특징:Pod 간 통신을 명시적으로 허용/거부기본적으로 화이트리스트 모델(명시적으로 허용한 트래픽만 허용)인그레스(수신) 및 이그레스(송신) 트래픽 제어라벨 선택자를 통한 세밀한 타겟팅✅ ..