해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 54 - Mastering AWS OpenSearch: Terraform Provisioning and Cost Efficiency Series
1. OpenSearch란?
OpenSearch는 대규모의 비정형 데이터 (로그, 메트릭)를 실시간으로 수집, 저장, 검색, 분석하는 데 특화된 분산 시스템이다.
1-1. OpenSearch 클러스터
OpenSearch 클러스터는 일반적인 관찰성 아키텍처에서 다른 클러스터 및 애플리케이션을 관찰하고 데이터를 모아 관리하는 역할을 한다.
-
데이터 소스: EC2 인스턴스, 쿠버네티스 클러스터, 서버리스 함수 등 로그를 생성하는 모든 자원들이 관찰 대상
-
저장 및 분석: Logstash와 같은 에이전트가 수집한 모든 로그를 Index 형태로 저장하고, 내장된 Kibana를 통해 실시간으로 검색 및 시각화
-
운영 목적: 클러스터를 여러 노드와 가용 영역(Available Zone)에 분산 구성하여, 확장성, 고가용성, 빠른 검색 속도를 확보
1-2. Logstash 에이전트
Logstash는 OpenSearch 클러스터로 데이터를 전송하는 에이전트이자 데이터 수집 엔진으로, 로그의 실시간 처리를 담당한다.
-
Input: 수집하고자 하는 로그 파일 (예: /var/log/*.log)을 지정
-
Filter (생략 가능): 수집된 데이터를 정제하거나 변환
-
Output: 로그가 도달해야 하는 AWS OpenSearch 클러스터의 엔드포인트를 지정하고 인증 (액세스/비밀 키) 정보를 포함
2. Terraform을 이용한 OpenSearch Cluster 구축
프레젠테이션에서는 Terraform을 사용하여 OpenSearch 클러스터와 로그를 전송할 EC2 인스턴스를 프로비저닝하는 과정을 보여준다.
2-1. OpenSearch 클러스터 구성
OpenSearch 클러스터는 고가용성을 위해 다수의 AZ에 걸쳐 배포하는 것이 일반적이며, 데모에서는 다음과 같이 정의되었다.
-
버전: OpenSearch 7.10 버전
-
인스턴스 유형: d2.small.elasticsearch (데모 목적으로 작게 설정)
-
볼륨 크기: EBS 10GB
-
접근 제어: 특정 IP 주소를 화이트리스트에 추가하여 Kibana 접속 및 클러스터 접근을 허용하는 액세스 정책을 설정
2-2. Logstash 인스턴스 구성
로그를 생성하고 수집 에이전트를 설치할 EC2 인스턴스도 Terraform으로 구성한다.
-
AMI 유형: Amazon 2 유형의 EC2 인스턴스
-
보안 그룹: 인바운드 트래픽을 위해 포트 443 (HTTPS), 80 (HTTP), 22 (SSH)를 개방한다.
2-3. Logstash 설치 및 플러그인 설정
EC2 인스턴스가 준비되면, 공식 Elasticsearch 문서에서 Logstash를 다운로드 및 설치하고, AWS OpenSearch로 데이터를 보내기 위한 전용 플러그인을 설치한다.
-
설치 과정: JDK 설치 → Logstash 압축 해제 → logstash-output-amazon-es 플러그인 설치
-
파이프라인 실행:
-
Logstash를 시작할 때, 인덱스 이름 (production_logs), OpenSearch 엔드포인트, AWS 인증 정보 (액세스/비밀 키)를 포함한 최종 설정 파일을 지정하여 실행한다.
-
실행 후 OpenSearch Kibana에서 production_logs라는 인덱스가 생성된 것을 확인할 수 있다.
-
해당 프레젠테이션에서는 설치 과정은 자동화 스크립트를 사용하여 진행하였다.
3. Index Lifecycle Policy (ILM)
로그 데이터는 시간이 지날수록 접근 빈도가 낮아지지만, 저장 공간과 비용은 지속적으로 증가한다.
따라서, 이에 대한 해결책으로 OpenSearch 클러스터의 저장 공간과 비용을 관리하는 기술로 Index Lifecycle Policy (ILM)가 제시되었다.
ILM은 오래되고 접근되지 않는 인덱스를 자동으로 삭제하거나 더 저렴한 저장소로 이동시켜 비용 효율성을 높이는 정책이다.
ILM은 인덱스의 접근 빈도에 따라 저장 공간을 여러 단계로 나누어 관리한다.
-
Hot Tier: 방금 도착한 인덱스, 자주 접근하는 최신 로그가 저장된다. (고성능 SSD 사용)
-
Warm Tier: 오래되었지만 가끔 접근할 필요가 있는 로그가 저장된다. (저비용 스토리지 사용)
-
Cold Tier: 가장 오래된 로그가 저장되며, 일반적으로 S3 버킷과 같은 저렴하고 내구성이 높은 저장소에 보관된다.
발표자는 ILM에 대한 커스텀 정책을 적용하여 해당 비용 최적화를 위한 4일 정책을 제시하였다.
-
정책 : 로그를 4일 후에 삭제하는 정책
-
Hot 상태: 2일 유지 (최신 데이터에 빠른 접근 제공)
-
Warm/Cold 상태: 2일 유지 (접근 빈도 감소에 따라 저비용 스토리지로 이동)
-
최종 삭제: 4일보다 오래된 모든 인덱스는 Read Only 단계를 거쳐 최종적으로 삭제된다.
-
이러한 ILM 정책 설정을 통해 조직은 필요한 기간 동안만 고성능 저장소를 사용하고, 그 외의 데이터는 저렴하게 관리하거나 자동 삭제하여 OpenSearch 클러스터의 총 운영 비용을 효과적으로 절감할 수 있다.
4. 정리
AWS OpenSearch 클러스터는 분산 시스템의 로그 및 메트릭을 통합 관리하는 중앙 허브이다.
Terraform을 사용하여 OpenSearch 클러스터와 Logstash 에이전트를 설치한 EC2 인스턴스를 프로비저닝하면, Logstash가 로그를 수집하여 OpenSearch로 전송한다.
또한, 운영 비용을 통제하기 위해 ILM(Index Lifecycle Policy)을 통해 인덱스를 Hot, Warm, Cold 저장소 단계로 나누고 접근 빈도에 따라 자동 삭제 또는 이동시켜 불필요한 고비용 스토리지를 줄이는 전략을 사용한다.
