OpenSearch 기반 멀티 테넌트 로깅 플랫폼의 워크로드 자동화 관리 가이드

중앙 집중형 로깅 플랫폼에서 OpenSearch 기반 워크로드 관리 활용 가이드

소개

현대 애플리케이션 아키텍처는 멀티 테넌트 환경에서 발생하는 로그 및 텔레메트리 데이터를 효과적으로 관리하고 분석할 수 있어야 합니다. 특히 서비스 관측성과 규정 준수, 보안, 성능 최적화 요구가 증가함에 따라 중앙 집중형 로깅 플랫폼에 대한 수요가 커지고 있습니다. Amazon OpenSearch Service를 활용하면 멀티 테넌트 구조에서도 로그 데이터를 효과적으로 저장하고, 쿼리하며, 운영 부담을 줄일 수 있지만, 성능 격리 및 리소스 할당 문제는 여전히 과제로 남아 있습니다.

이 글에서는 Amazon OpenSearch Service를 활용한 멀티 테넌트 기반 중앙 로그 분석 플랫폼에서 다양하고 복잡한 워크로드를 자동화하고 안정화하기 위해 활용할 수 있는 프로세스, 자동화 구성 요소, 계층화, 프록시 게이트웨이, 워크로드 그룹 등의 실제 사례와 배포 가이드를 소개합니다.

본론

멀티 워크로드 환경에서 가장 중요한 요소 중 하나는 각 테넌트별로 리소스를 적절히 격리하여 성능 저하 없이 서비스 수준 계약(SLA)에 맞는 처리를 보장하는 것입니다. 이를 위해 소개된 핵심 기술은 다음과 같습니다.

1. 계층별 테넌트 분류 및 리소스 할당

GlobalLog 사례에서는 테넌트를 4개의 계층으로 나누어 리소스를 구분하고, OpenSearch Workload Management(이하 WLM)를 통해 각 테넌트에 CPU 및 메모리를 지정합니다.

계층별 주요 사양은 아래와 같습니다.

• Tier 1 (엔터프라이즈 중요): 금융, 보안, 연중무휴 99.99% SLA, 50% CPU, 50% 메모리, 쿼리 우선순위 최상
• Tier 2 (비즈니스 중요): 헬스케어 등 규제 산업, 업무 시간 내 99.9% SLA, 중간 리소스 사용량
• Tier 3 (표준): 리테일, 대시보드 사용량 많고 피크 시즌에 트래픽 급등
• Tier 4 (기본): 내부 운영, 개발 환경, 최소 리소스, 자동화된 쿼리 최적화 적용

이러한 계층화를 통해 각 산업군의 다양한 요구사항을 효과적으로 수용할 수 있으며, 비용 할당 및 서비스 품질 관리가 탄력적으로 이루어집니다.

2. 프록시 계층 아키텍처 및 동적 트래픽 제어

GlobalLog는 OpenSearch Traffic Gateway를 중심으로 각 테넌트의 로그 쿼리 요청을 라우팅하고, 트래픽을 정형화(rule-based shaping)하여 서비스 품질을 유지합니다.

DynamoDB를 규칙 저장소로 사용하며, 트래픽 경로 및 규칙은 실시간으로 반영됩니다. 이벤트 기반(rule update)으로 AWS EventBridge와 Lambda를 연동해 이상 탐지 또는 SLA 위반 시 자동으로 트래픽 제어 정책을 갱신합니다. 이로써 트래픽 변동성에 따라 동적으로 대응이 가능하며, 다음과 같은 제어가 지원됩니다.

• 경량 쿼리 전환(Fallback)
• 폭주 방지 회로 차단기(Circuit Breaker)
• 운영 시간에 따른 제한(스케줄 기반 제어)

예를 들어 월말 보고 기간에는 Tier 4 운영 부서가 야간에만 리포트를 실행하도록 시간 기반 규칙이 활성화됩니다.

3. OpenSearch Workload Management 로직 구성

OpenSearch WLM 기능을 활용해 쿼리 단위로 리소스를 분배하고, 서비스 우선순위에 따라 처리 지연이나 리소스 병목을 방지합니다.

예를 들어:

PUT _wlm/workload_group
{
"name": "Enterprise Critical",
"resiliency_mode": "enforced",
"resource_limits": {
"cpu": 0.5,
"memory": 0.5
}
}

이처럼 등급별로 워크로드 그룹을 구성하고 쿼리 요청 시 해당 그룹 ID를 삽입하여 실행합니다. 각 그룹은 OpenSearch 서버 수준에서 리소스 제한 및 우선순위를 보장받게 되며 대형 운영 환경에서 자동화된 안정성을 도모할 수 있습니다.

4. 실제 활용 사례

사례 1 – 보안 사고 대응

보안 사고 발생 시 다수의 비즈니스 유닛이 동시에 로그 조회를 요청하는 경우, 프록시 계층에서 Tier 1(보안, 금융)을 최우선으로 처리하고, 리테일과 내부 IT는 제한된 쿼리만 허용하여 자원 부담을 완화시킵니다. 이때 OpenSearch는 복잡한 리테일 쿼리를 자동으로 취소하거나 제한합니다.

사례 2 – 월말 보고 로드 대응

매월 말 리포트 용량이 증가하는 것을 고려해 Tier 4 그룹에는 오프 피크 시간대(18:00~08:00)에 한해서만 조회 허용하도록 설정해 리소스를 전략적으로 분산합니다. 다음은 관련 규칙 예시입니다.

• 허용 규칙:
  "dayOfMonth": "25-30", "hours": "18:00-8:00"
• 차단 규칙:
  "dayOfMonth": "25-30", "hours": "9:00-18:00"

결과적으로 야간 리포트는 문제없이 처리되며, 주간 시간에는 주요 그룹의 성능이 보장됩니다.

결론

OpenSearch 기반의 로깅 시스템을 멀티 테넌트 환경에 적용할 경우, 프록시 계층과 워크로드 관리 계층을 통합한 자동화 전략은 필수입니다. GlobalLog의 사례처럼 트래픽 제어, 리소스 분배, SLA 지원 측면에서 계층적 워크로드 관리 기법을 도입하면 대규모 분석 환경에서도 안정성과 성능을 확보할 수 있습니다.

운영 중인 로깅 시스템의 자동화 및 최적화를 고민 중이라면 OpenSearch의 Workload Management 및 트래픽 게이트웨이를 적극 도입해보시길 권장합니다.

https://aws.amazon.com/blogs/big-data/workload-management-in-opensearch-based-multi-tenant-centralized-logging-platforms/